#
acc2364f |
| 31-Jan-2024 |
Philipp Stanner <pstanner@redhat.com> |
PCI: Move PCI-specific devres code to drivers/pci/
The pcim_*() functions in lib/devres.c are guarded by an #ifdef CONFIG_PCI and, thus, don't belong to this file. They are only ever used for PCI an
PCI: Move PCI-specific devres code to drivers/pci/
The pcim_*() functions in lib/devres.c are guarded by an #ifdef CONFIG_PCI and, thus, don't belong to this file. They are only ever used for PCI and are not generic infrastructure.
Move all pcim_*() functions in lib/devres.c to drivers/pci/devres.c. Adjust the Makefile.
Add drivers/pci/devres.c to Documentation.
Link: https://lore.kernel.org/r/20240131090023.12331-4-pstanner@redhat.com Suggested-by: Danilo Krummrich <dakr@redhat.com> Signed-off-by: Philipp Stanner <pstanner@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
show more ...
|
#
875e0c31 |
| 21-Jun-2023 |
Ben Dooks <ben.dooks@codethink.co.uk> |
devres: show which resource was invalid in __devm_ioremap_resource()
The other error prints in this call show the resource which wsan't valid, so add this to the first print when it checks for basic
devres: show which resource was invalid in __devm_ioremap_resource()
The other error prints in this call show the resource which wsan't valid, so add this to the first print when it checks for basic validity of the resource.
Link: https://lkml.kernel.org/r/20230621163050.477668-1-ben.dooks@codethink.co.uk Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
show more ...
|
#
3954cf43 |
| 22-Aug-2022 |
Christoph Hellwig <hch@lst.de> |
devres: remove devm_ioremap_np
devm_ioremap_np has never been used anywhere since it was added in early 2021, so remove it.
Signed-off-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.o
devres: remove devm_ioremap_np
devm_ioremap_np has never been used anywhere since it was added in early 2021, so remove it.
Signed-off-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20220822061424.151819-1-hch@lst.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
55656016 |
| 08-Jul-2022 |
Mark-PK Tsai <mark-pk.tsai@mediatek.com> |
lib: devres: use numa aware allocation
Allocate device resource from local node memory when the numa locality of the device is specified.
Link: https://lkml.kernel.org/r/20220708131952.14500-1-mark
lib: devres: use numa aware allocation
Allocate device resource from local node memory when the numa locality of the device is specified.
Link: https://lkml.kernel.org/r/20220708131952.14500-1-mark-pk.tsai@mediatek.com Signed-off-by: Mark-PK Tsai <mark-pk.tsai@mediatek.com> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: YJ Chiang <yj.chiang@mediatek.com> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Zhen Lei <thunder.leizhen@huawei.com> Cc: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
show more ...
|
#
c8223107 |
| 16-Sep-2021 |
Thomas Zimmermann <tzimmermann@suse.de> |
lib: devres: Add managed arch_io_reserve_memtype_wc()
Add devm_arch_io_reserve_memtype_wc() as managed wrapper around arch_io_reserve_memtype_wc(). Useful for several graphics drivers that set frame
lib: devres: Add managed arch_io_reserve_memtype_wc()
Add devm_arch_io_reserve_memtype_wc() as managed wrapper around arch_io_reserve_memtype_wc(). Useful for several graphics drivers that set framebuffer memory to write combining.
v2: * fix typo in commit description
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210916181601.9146-3-tzimmermann@suse.de
show more ...
|
#
3229b906 |
| 16-Sep-2021 |
Thomas Zimmermann <tzimmermann@suse.de> |
lib: devres: Add managed arch_phys_wc_add()
Add devm_arch_phys_wc_add() as managed wrapper around arch_phys_wc_add(). Useful for several graphics drivers that set framebuffer memory to write combini
lib: devres: Add managed arch_phys_wc_add()
Add devm_arch_phys_wc_add() as managed wrapper around arch_phys_wc_add(). Useful for several graphics drivers that set framebuffer memory to write combining.
v2: * fix typo in commit description
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210916181601.9146-2-tzimmermann@suse.de
show more ...
|
#
9dbbc3b9 |
| 08-Jul-2021 |
Zhen Lei <thunder.leizhen@huawei.com> |
lib: fix spelling mistakes
Fix some spelling mistakes in comments: permanentely ==> permanently wont ==> won't remaning ==> remaining succed ==> succeed shouldnt ==> shouldn't alpha-numeric ==> alph
lib: fix spelling mistakes
Fix some spelling mistakes in comments: permanentely ==> permanently wont ==> won't remaning ==> remaining succed ==> succeed shouldnt ==> shouldn't alpha-numeric ==> alphanumeric storeing ==> storing funtion ==> function documenation ==> documentation Determin ==> Determine intepreted ==> interpreted ammount ==> amount obious ==> obvious interupts ==> interrupts occured ==> occurred asssociated ==> associated taking into acount ==> taking into account squence ==> sequence stil ==> still contiguos ==> contiguous matchs ==> matches
Link: https://lkml.kernel.org/r/20210607072555.12416-1-thunder.leizhen@huawei.com Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
show more ...
|
#
5c3e241f |
| 28-Apr-2021 |
Zhen Lei <thunder.leizhen@huawei.com> |
lib: devres: Add error information printing for __devm_ioremap_resource()
Ensure that all error handling branches print error information. In this way, when this function fails, the upper-layer func
lib: devres: Add error information printing for __devm_ioremap_resource()
Ensure that all error handling branches print error information. In this way, when this function fails, the upper-layer functions can directly return an error code without missing debugging information. Otherwise, the error message will be printed redundantly or missing.
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> Link: https://lore.kernel.org/r/20210428063203.691-1-thunder.leizhen@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
7c566bb5 |
| 11-Feb-2021 |
Hector Martin <marcan@marcan.st> |
asm-generic/io.h: Add a non-posted variant of ioremap()
ARM64 currently defaults to posted MMIO (nGnRE), but some devices require the use of non-posted MMIO (nGnRnE). Introduce a new ioremap() vari
asm-generic/io.h: Add a non-posted variant of ioremap()
ARM64 currently defaults to posted MMIO (nGnRE), but some devices require the use of non-posted MMIO (nGnRnE). Introduce a new ioremap() variant to handle this case. ioremap_np() returns NULL on arches that do not implement this variant.
sparc64 is the only architecture that needs to be touched directly, because it includes neither of the generic io.h or iomap.h headers.
This adds the IORESOURCE_MEM_NONPOSTED flag, which maps to this variant and marks a given resource as requiring non-posted mappings. This is implemented in the resource system because it is a SoC-level requirement, so existing drivers do not need special-case code to pick this ioremap variant.
Then this is implemented in devres by introducing devm_ioremap_np(), and making devm_ioremap_resource() automatically select this variant when the resource has the IORESOURCE_MEM_NONPOSTED flag set.
Acked-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Hector Martin <marcan@marcan.st>
show more ...
|
#
0c7a6b91 |
| 10-Sep-2020 |
Stephen Boyd <swboyd@chromium.org> |
driver core: platform: Document return type of more functions
I can't always remember the return values of these functions, and so I usually jump to the function to read the kernel-doc and see that
driver core: platform: Document return type of more functions
I can't always remember the return values of these functions, and so I usually jump to the function to read the kernel-doc and see that it doesn't tell me. Then I have to spend more time reading the code to jump to the function that actually tells me the return values. Let's document it here so that we don't all have to spend time digging through the code to understand the return values.
Cc: <linux-doc@vger.kernel.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20200910060440.2302925-1-swboyd@chromium.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
28d9fdf0 |
| 23-Aug-2020 |
Randy Dunlap <rdunlap@infradead.org> |
lib: devres: delete duplicated words
Drop the repeated word "the".
Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Arnd Bergmann <arnd@arndb.de
lib: devres: delete duplicated words
Drop the repeated word "the".
Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20200823040443.25900-1-rdunlap@infradead.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
7ae731a8 |
| 09-Jun-2020 |
Dan Carpenter <dan.carpenter@oracle.com> |
lib: devres: add a comment about the devm_of_iomap() function
We recently introduced a bug when we tried to convert of_iomap() to devm_of_iomap(). The problem was that there were two drivers mappin
lib: devres: add a comment about the devm_of_iomap() function
We recently introduced a bug when we tried to convert of_iomap() to devm_of_iomap(). The problem was that there were two drivers mapping the same io region. The first driver was using of_iomap() and the second driver was using devm_of_iomap() and the kernel booted fine. When we converted the first drive to use devm_of_iomap() then the second driver failed with -EBUSY and the kernel couldn't boot.
Let's add a comment to prevent this sort of mistake in the future.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20200609104642.GA43074@mwanda Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
35bd8c07 |
| 01-Jun-2020 |
Vladimir Oltean <vladimir.oltean@nxp.com> |
devres: keep both device name and resource name in pretty name
Sometimes debugging a device is easiest using devmem on its register map, and that can be seen with /proc/iomem. But some device driver
devres: keep both device name and resource name in pretty name
Sometimes debugging a device is easiest using devmem on its register map, and that can be seen with /proc/iomem. But some device drivers have many memory regions. Take for example a networking switch. Its memory map used to look like this in /proc/iomem:
1fc000000-1fc3fffff : pcie@1f0000000 1fc000000-1fc3fffff : 0000:00:00.5 1fc010000-1fc01ffff : sys 1fc030000-1fc03ffff : rew 1fc060000-1fc0603ff : s2 1fc070000-1fc0701ff : devcpu_gcb 1fc080000-1fc0800ff : qs 1fc090000-1fc0900cb : ptp 1fc100000-1fc10ffff : port0 1fc110000-1fc11ffff : port1 1fc120000-1fc12ffff : port2 1fc130000-1fc13ffff : port3 1fc140000-1fc14ffff : port4 1fc150000-1fc15ffff : port5 1fc200000-1fc21ffff : qsys 1fc280000-1fc28ffff : ana
But after the patch in Fixes: was applied, the information is now presented in a much more opaque way:
1fc000000-1fc3fffff : pcie@1f0000000 1fc000000-1fc3fffff : 0000:00:00.5 1fc010000-1fc01ffff : 0000:00:00.5 1fc030000-1fc03ffff : 0000:00:00.5 1fc060000-1fc0603ff : 0000:00:00.5 1fc070000-1fc0701ff : 0000:00:00.5 1fc080000-1fc0800ff : 0000:00:00.5 1fc090000-1fc0900cb : 0000:00:00.5 1fc100000-1fc10ffff : 0000:00:00.5 1fc110000-1fc11ffff : 0000:00:00.5 1fc120000-1fc12ffff : 0000:00:00.5 1fc130000-1fc13ffff : 0000:00:00.5 1fc140000-1fc14ffff : 0000:00:00.5 1fc150000-1fc15ffff : 0000:00:00.5 1fc200000-1fc21ffff : 0000:00:00.5 1fc280000-1fc28ffff : 0000:00:00.5
That patch made a fair comment that /proc/iomem might be confusing when it shows resources without an associated device, but we can do better than just hide the resource name altogether. Namely, we can print the device name _and_ the resource name. Like this:
1fc000000-1fc3fffff : pcie@1f0000000 1fc000000-1fc3fffff : 0000:00:00.5 1fc010000-1fc01ffff : 0000:00:00.5 sys 1fc030000-1fc03ffff : 0000:00:00.5 rew 1fc060000-1fc0603ff : 0000:00:00.5 s2 1fc070000-1fc0701ff : 0000:00:00.5 devcpu_gcb 1fc080000-1fc0800ff : 0000:00:00.5 qs 1fc090000-1fc0900cb : 0000:00:00.5 ptp 1fc100000-1fc10ffff : 0000:00:00.5 port0 1fc110000-1fc11ffff : 0000:00:00.5 port1 1fc120000-1fc12ffff : 0000:00:00.5 port2 1fc130000-1fc13ffff : 0000:00:00.5 port3 1fc140000-1fc14ffff : 0000:00:00.5 port4 1fc150000-1fc15ffff : 0000:00:00.5 port5 1fc200000-1fc21ffff : 0000:00:00.5 qsys 1fc280000-1fc28ffff : 0000:00:00.5 ana
Fixes: 8d84b18f5678 ("devres: always use dev_name() in devm_ioremap_resource()") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://lore.kernel.org/r/20200601095826.1757621-1-olteanv@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
4bdc0d67 |
| 06-Jan-2020 |
Christoph Hellwig <hch@lst.de> |
remove ioremap_nocache and devm_ioremap_nocache
ioremap has provided non-cached semantics by default since the Linux 2.6 days, so remove the additional ioremap_nocache interface.
Signed-off-by: Chr
remove ioremap_nocache and devm_ioremap_nocache
ioremap has provided non-cached semantics by default since the Linux 2.6 days, so remove the additional ioremap_nocache interface.
Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Arnd Bergmann <arnd@arndb.de>
show more ...
|
#
e537654b |
| 16-Oct-2019 |
Tuowen Zhao <ztuowen@gmail.com> |
lib: devres: add a helper function for ioremap_uc
Implement a resource managed strongly uncachable ioremap function.
Cc: <stable@vger.kernel.org> # v4.19+ Tested-by: AceLan Kao <acelan.kao@canonica
lib: devres: add a helper function for ioremap_uc
Implement a resource managed strongly uncachable ioremap function.
Cc: <stable@vger.kernel.org> # v4.19+ Tested-by: AceLan Kao <acelan.kao@canonical.com> Signed-off-by: Tuowen Zhao <ztuowen@gmail.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Luis Chamberlain <mcgrof@kernel.org> Signed-off-by: Lee Jones <lee.jones@linaro.org>
show more ...
|
#
b873af62 |
| 22-Oct-2019 |
Bartosz Golaszewski <bgolaszewski@baylibre.com> |
lib: devres: provide devm_ioremap_resource_wc()
Provide a variant of devm_ioremap_resource() for write-combined ioremap.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Reviewed-by:
lib: devres: provide devm_ioremap_resource_wc()
Provide a variant of devm_ioremap_resource() for write-combined ioremap.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20191022084318.22256-4-brgl@bgdev.pl Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
6e924822 |
| 22-Oct-2019 |
Bartosz Golaszewski <bgolaszewski@baylibre.com> |
lib: devres: prepare devm_ioremap_resource() for more variants
We want to add the write-combined variant of devm_ioremap_resource(). Let's first implement __devm_ioremap_resource() which takes an ad
lib: devres: prepare devm_ioremap_resource() for more variants
We want to add the write-combined variant of devm_ioremap_resource(). Let's first implement __devm_ioremap_resource() which takes an additional argument type. The types are the same as for __devm_ioremap(). The existing devm_ioremap_resource() now simply calls __devm_ioremap_resource() with regular DEVM_IOREMAP type.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20191022084318.22256-3-brgl@bgdev.pl Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
c9c13ba4 |
| 27-Sep-2019 |
Denis Efremov <efremov@linux.com> |
PCI: Add PCI_STD_NUM_BARS for the number of standard BARs
Code that iterates over all standard PCI BARs typically uses PCI_STD_RESOURCE_END. However, that requires the unusual test "i <= PCI_STD_RE
PCI: Add PCI_STD_NUM_BARS for the number of standard BARs
Code that iterates over all standard PCI BARs typically uses PCI_STD_RESOURCE_END. However, that requires the unusual test "i <= PCI_STD_RESOURCE_END" rather than something the typical "i < PCI_STD_NUM_BARS".
Add a definition for PCI_STD_NUM_BARS and change loops to use the more idiomatic C style to help avoid fencepost errors.
Link: https://lore.kernel.org/r/20190927234026.23342-1-efremov@linux.com Link: https://lore.kernel.org/r/20190927234308.23935-1-efremov@linux.com Link: https://lore.kernel.org/r/20190916204158.6889-3-efremov@linux.com Signed-off-by: Denis Efremov <efremov@linux.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Sebastian Ott <sebott@linux.ibm.com> # arch/s390/ Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> # video/fbdev/ Acked-by: Gustavo Pimentel <gustavo.pimentel@synopsys.com> # pci/controller/dwc/ Acked-by: Jack Wang <jinpu.wang@cloud.ionos.com> # scsi/pm8001/ Acked-by: Martin K. Petersen <martin.petersen@oracle.com> # scsi/pm8001/ Acked-by: Ulf Hansson <ulf.hansson@linaro.org> # memstick/
show more ...
|
#
eef778c9 |
| 04-Jul-2019 |
Arnd Bergmann <arnd@arndb.de> |
devres: allow const resource arguments
devm_ioremap_resource() does not currently take 'const' arguments, which results in a warning from the first driver trying to do it anyway:
drivers/gpio/gpi
devres: allow const resource arguments
devm_ioremap_resource() does not currently take 'const' arguments, which results in a warning from the first driver trying to do it anyway:
drivers/gpio/gpio-amd-fch.c: In function 'amd_fch_gpio_probe': drivers/gpio/gpio-amd-fch.c:171:49: error: passing argument 2 of 'devm_ioremap_resource' discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers] priv->base = devm_ioremap_resource(&pdev->dev, &amd_fch_gpio_iores); ^~~~~~~~~~~~~~~~~~~
Change the prototype to allow it, as there is no real reason not to.
Link: http://lkml.kernel.org/r/20190628150049.1108048-1-arnd@arndb.de Fixes: 9bb2e0452508 ("gpio: amd: Make resource struct const") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Enrico Weigelt <info@metux.net> Reviewed-by: Andrew Morton <akpm@linux-foundation.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com> Cc: Ulf Hansson <ulf.hansson@linaro.org> Cc: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
show more ...
|
#
8d84b18f |
| 29-Jan-2019 |
Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> |
devres: always use dev_name() in devm_ioremap_resource()
devm_ioremap_resource() prefers calling devm_request_mem_region() with a resource name instead of a device name -- this looks pretty iff a re
devres: always use dev_name() in devm_ioremap_resource()
devm_ioremap_resource() prefers calling devm_request_mem_region() with a resource name instead of a device name -- this looks pretty iff a resource name isn't specified via a device tree with a "reg-names" property (in this case, a resource name is set to a device node's full name), but if it is, it doesn't really scale since these names are only unique to a given device node, not globally; so, looking at the output of 'cat /proc/iomem', you do not have an idea which memory region belongs to which device (see "dirmap", "regs", and "wbuf" lines below):
08000000-0bffffff : dirmap 48000000-bfffffff : System RAM 48000000-48007fff : reserved 48080000-48b0ffff : Kernel code 48b10000-48b8ffff : reserved 48b90000-48c7afff : Kernel data bc6a4000-bcbfffff : reserved bcc0f000-bebfffff : reserved bec0e000-bec0efff : reserved bec11000-bec11fff : reserved bec12000-bec14fff : reserved bec15000-bfffffff : reserved e6050000-e605004f : gpio@e6050000 e6051000-e605104f : gpio@e6051000 e6052000-e605204f : gpio@e6052000 e6053000-e605304f : gpio@e6053000 e6054000-e605404f : gpio@e6054000 e6055000-e605504f : gpio@e6055000 e6060000-e606050b : pin-controller@e6060000 e6e60000-e6e6003f : e6e60000.serial e7400000-e7400fff : ethernet@e7400000 ee200000-ee2001ff : regs ee208000-ee2080ff : wbuf
I think that devm_request_mem_region() should be called with dev_name() despite the region names won't look as pretty as before (however, we gain more consistency with e.g. the serial driver:
08000000-0bffffff : ee200000.rpc 48000000-bfffffff : System RAM 48000000-48007fff : reserved 48080000-48b0ffff : Kernel code 48b10000-48b8ffff : reserved 48b90000-48c7afff : Kernel data bc6a4000-bcbfffff : reserved bcc0f000-bebfffff : reserved bec0e000-bec0efff : reserved bec11000-bec11fff : reserved bec12000-bec14fff : reserved bec15000-bfffffff : reserved e6050000-e605004f : e6050000.gpio e6051000-e605104f : e6051000.gpio e6052000-e605204f : e6052000.gpio e6053000-e605304f : e6053000.gpio e6054000-e605404f : e6054000.gpio e6055000-e605504f : e6055000.gpio e6060000-e606050b : e6060000.pin-controller e6e60000-e6e6003f : e6e60000.serial e7400000-e7400fff : e7400000.ethernet ee200000-ee2001ff : ee200000.rpc ee208000-ee2080ff : ee200000.rpc
Fixes: 72f8c0bfa0de ("lib: devres: add convenience function to remap a resource") Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
d5e83827 |
| 05-Jun-2018 |
Benjamin Herrenschmidt <benh@kernel.crashing.org> |
devres: Add devm_of_iomap()
There are still quite a few cases where a device might want to get to a different node of the device-tree, obtain the resources and map them.
We have of_iomap() and of_i
devres: Add devm_of_iomap()
There are still quite a few cases where a device might want to get to a different node of the device-tree, obtain the resources and map them.
We have of_iomap() and of_io_request_and_map() but they both have shortcomings, such as not returning the size of the resource found (which can be useful) and not being "managed".
This adds a devm_of_iomap() that provides all of these and should probably replace uses of the above in most drivers.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Joel Stanley <joel@jms.id.au>
show more ...
|
#
1b723413 |
| 29-Jan-2018 |
Yisheng Xie <xieyisheng1@huawei.com> |
devres: combine function devm_ioremap*
When I tried to use devm_ioremap function and review related code, I found devm_ioremap_* almost have the similar realize with each other, which can be combine
devres: combine function devm_ioremap*
When I tried to use devm_ioremap function and review related code, I found devm_ioremap_* almost have the similar realize with each other, which can be combined.
In the former version, I have tried to kill ioremap_cache to reduce the size of devres, which can not work for ioremap is not the same as ioremap_nocache in some ARCHs likes ia64. Therefore, as the suggestion of Christophe, I introduce a help function __devm_ioremap, let devm_ioremap* inline and call __devm_ioremap with different devm_ioremap_type.
After apply the patch, the size of devres.o can be reduce from 8216 Bytes to 8052 Bytes in my compile environment.
Suggested-by: Greg KH <gregkh@linuxfoundation.org> Suggested-by: Christophe LEROY <christophe.leroy@c-s.fr> Signed-off-by: Yisheng Xie <xieyisheng1@huawei.com> Reviewed-by: Christophe LEROY <christophe.leroy@c-s.fr> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
b2441318 |
| 01-Nov-2017 |
Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
License cleanup: add SPDX GPL-2.0 license identifier to files with no license
Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine
License cleanup: add SPDX GPL-2.0 license identifier to files with no license
Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine the correct license.
By default all files without license information are under the default license of the kernel, which is GPL version 2.
Update the files which contain no license information with the 'GPL-2.0' SPDX license identifier. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text.
This patch is based on work done by Thomas Gleixner and Kate Stewart and Philippe Ombredanne.
How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of the use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information,
Further patches will be generated in subsequent months to fix up cases where non-standard license headers were used, and references to license had to be inferred by heuristics based on keywords.
The analysis to determine which SPDX License Identifier to be applied to a file was done in a spreadsheet of side by side results from of the output of two independent scanners (ScanCode & Windriver) producing SPDX tag:value files created by Philippe Ombredanne. Philippe prepared the base worksheet, and did an initial spot review of a few 1000 files.
The 4.13 kernel was the starting point of the analysis with 60,537 files assessed. Kate Stewart did a file by file comparison of the scanner results in the spreadsheet to determine which SPDX license identifier(s) to be applied to the file. She confirmed any determination that was not immediately clear with lawyers working with the Linux Foundation.
Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines).
All documentation files were explicitly excluded.
The following heuristics were used to determine which SPDX license identifiers to apply.
- when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied.
For non */uapi/* files that summary was:
SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139
and resulted in the first patch in this series.
If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:
SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930
and resulted in the second patch in this series.
- if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary:
SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1
and that resulted in the third patch in this series.
- when the two scanners agreed on the detected license(s), that became the concluded license(s).
- when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred.
- In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics).
- When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation.
- If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time.
In total, over 70 hours of logged manual review was done on the spreadsheet to determine the SPDX license identifiers to apply to the source files by Kate, Philippe, Thomas and, in some cases, confirmation by lawyers working with the Linux Foundation.
Kate also obtained a third independent scan of the 4.13 code base from FOSSology, and compared selected files where the other two scanners disagreed against that SPDX file, to see if there was new insights. The Windriver scanner is based on an older version of FOSSology in part, so they are related.
Thomas did random spot checks in about 500 files from the spreadsheets for the uapi headers and agreed with SPDX license identifier in the files he inspected. For the non-uapi files Thomas did random spot checks in about 15000 files.
In initial set of patches against 4.14-rc6, 3 files were found to have copy/paste license identifier errors, and have been fixed to reflect the correct identifier.
Additionally Philippe spent 10 hours this week doing a detailed manual inspection and review of the 12,461 patched files from the initial patch version early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correct
This produced a worksheet with 20 files needing minor correction. This worksheet was then exported into 3 different .csv files for the different types of files to be modified.
These .csv files were then reviewed by Greg. Thomas wrote a script to parse the csv files and add the proper SPDX tag to the file, in the format that the file expected. This script was further refined by Greg based on the output to detect more types of files automatically and to distinguish between header and source .c files (which need different comment types.) Finally Greg ran the script using the .csv files to generate the patches.
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
6524754e |
| 19-Apr-2017 |
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> |
devres: fix devm_ioremap_*() offset parameter kerneldoc description
The offset parameter in the devres devm_ioremap_*() functions kerneldoc entries is erroneously defined as BUS offset whereas it is
devres: fix devm_ioremap_*() offset parameter kerneldoc description
The offset parameter in the devres devm_ioremap_*() functions kerneldoc entries is erroneously defined as BUS offset whereas it is actually a resource address.
Since it is actually misleading, fix the devres devm_ioremap_* offset parameter kerneldoc entry by replacing BUS offset with a more suitable description (ie Resource address).
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: Tejun Heo <tj@kernel.org>
show more ...
|
#
20af74ef |
| 27-Dec-2015 |
Geliang Tang <geliangtang@163.com> |
devres: use to_pci_dev()
Use to_pci_dev() instead of open-coding it.
Signed-off-by: Geliang Tang <geliangtang@163.com> Acked-by: Tejun Heo <tj@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@
devres: use to_pci_dev()
Use to_pci_dev() instead of open-coding it.
Signed-off-by: Geliang Tang <geliangtang@163.com> Acked-by: Tejun Heo <tj@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|