lib: devres: Simplify API devm_ioport_unmap() implementation

Simplify devm_ioport_unmap() implementation by dedicated API
devres_release(), compared with current solution, namely
ioport_unmap() + de

lib: devres: Simplify API devm_ioport_unmap() implementation

Simplify devm_ioport_unmap() implementation by dedicated API
devres_release(), compared with current solution, namely
ioport_unmap() + devres_destroy(), devres_release() has below advantages:

- it is simpler if devm_ioport_unmap()'s parameter @addr was ever
returned by devm_ioport_map().

- it can avoid unnecessary ioport_unmap(@addr) if @addr was not
ever returned by devm_ioport_map().

Signed-off-by: Zijun Hu <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

lib: devres: Simplify API devm_iounmap() implementation

Simplify devm_iounmap() implementation by dedicated API devres_release()
compared with current solution, namely, devres_destroy() + iounmap()

lib: devres: Simplify API devm_iounmap() implementation

Simplify devm_iounmap() implementation by dedicated API devres_release()
compared with current solution, namely, devres_destroy() + iounmap()
devres_release() has the following advantages:

- it is simpler if devm_iounmap()'s parameter @addr is valid, namely
@addr was ever returned by one of devm_ioremap() variants.

- it can avoid unnecessary iounmap(@addr) if @addr is not valid.

Signed-off-by: Zijun Hu <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

devres: don't use "proxy" headers

Update header inclusions to follow IWYU (Include What You Use) principle.

Link: https://lkml.kernel.org/r/[email protected]

devres: don't use "proxy" headers

Update header inclusions to follow IWYU (Include What You Use) principle.

Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Andy Shevchenko <[email protected]>
Reviewed-by: Philipp Stanner <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

show more ...

devres: switch to use dev_err_probe() for unification

Patch series "devres: A couple of cleanups".

A couple of ad-hoc cleanups. No functional changes intended.


This patch (of 2):

The devm_*() A

devres: switch to use dev_err_probe() for unification

Patch series "devres: A couple of cleanups".

A couple of ad-hoc cleanups. No functional changes intended.


This patch (of 2):

The devm_*() APIs are supposed to be called during the ->probe() stage.
Many drivers (especially new ones) have switched to use dev_err_probe()
for error messaging for the sake of unification. Let's do the same in the
devres APIs.

Link: https://lkml.kernel.org/r/[email protected]
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Andy Shevchenko <[email protected]>
Reviewed-by: Philipp Stanner <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

show more ...

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/[email protected]
Suggested-by: Danilo Krummrich <[email protected]>
Signed-off-by: Philipp Stanner <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>

show more ...

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/[email protected]
Signed-off-by: Ben Dooks <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

show more ...

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 <[email protected]>
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 <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

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/[email protected]
Signed-off-by: Mark-PK Tsai <[email protected]>
Cc: Matthias Brugger <[email protected]>
Cc: YJ Chiang <[email protected]>
Cc: Hans de Goede <[email protected]>
Cc: Thomas Zimmermann <[email protected]>
Cc: Zhen Lei <[email protected]>
Cc: Jacob Keller <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

show more ...

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 <[email protected]>
Reviewed-by: Hans de Goede <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

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 <[email protected]>
Reviewed-by: Hans de Goede <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

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/[email protected]
Signed-off-by: Zhen Lei <[email protected]>
Reviewed-by: Jacob Keller <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

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 <[email protected]>
Signed-off-by: Zhen Lei <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

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 <[email protected]>
Signed-off-by: Hector Martin <[email protected]>

show more ...

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: <[email protected]>
Signed-off-by: Stephen Boyd <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

lib: devres: delete duplicated words

Drop the repeated word "the".

Signed-off-by: Randy Dunlap <[email protected]>
Cc: Andrew Morton <[email protected]>
Cc: Arnd Bergmann <[email protected]

lib: devres: delete duplicated words

Drop the repeated word "the".

Signed-off-by: Randy Dunlap <[email protected]>
Cc: Andrew Morton <[email protected]>
Cc: Arnd Bergmann <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

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 <[email protected]>
Acked-by: Arnd Bergmann <[email protected]>
Link: https://lore.kernel.org/r/20200609104642.GA43074@mwanda
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

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 <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

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 <[email protected]>
Acked-by: Arnd Bergmann <[email protected]>

show more ...

lib: devres: add a helper function for ioremap_uc

Implement a resource managed strongly uncachable ioremap function.

Cc: <[email protected]> # 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: <[email protected]> # v4.19+
Tested-by: AceLan Kao <[email protected]>
Signed-off-by: Tuowen Zhao <[email protected]>
Acked-by: Mika Westerberg <[email protected]>
Acked-by: Andy Shevchenko <[email protected]>
Acked-by: Luis Chamberlain <[email protected]>
Signed-off-by: Lee Jones <[email protected]>

show more ...

lib: devres: provide devm_ioremap_resource_wc()

Provide a variant of devm_ioremap_resource() for write-combined ioremap.

Signed-off-by: Bartosz Golaszewski <[email protected]>
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 <[email protected]>
Reviewed-by: Arnd Bergmann <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

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 <[email protected]>
Reviewed-by: Arnd Bergmann <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

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/[email protected]
Link: https://lore.kernel.org/r/[email protected]
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Denis Efremov <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Acked-by: Sebastian Ott <[email protected]> # arch/s390/
Acked-by: Bartlomiej Zolnierkiewicz <[email protected]> # video/fbdev/
Acked-by: Gustavo Pimentel <[email protected]> # pci/controller/dwc/
Acked-by: Jack Wang <[email protected]> # scsi/pm8001/
Acked-by: Martin K. Petersen <[email protected]> # scsi/pm8001/
Acked-by: Ulf Hansson <[email protected]> # memstick/

show more ...

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/[email protected]
Fixes: 9bb2e0452508 ("gpio: amd: Make resource struct const")
Signed-off-by: Arnd Bergmann <[email protected]>
Acked-by: Greg Kroah-Hartman <[email protected]>
Reviewed-by: Enrico Weigelt <[email protected]>
Reviewed-by: Andrew Morton <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Linus Walleij <[email protected]>
Cc: Arnd Bergmann <[email protected]>
Cc: "Rafael J. Wysocki" <[email protected]>
Cc: Ulf Hansson <[email protected]>
Cc: Andy Shevchenko <[email protected]>
Cc: Heikki Krogerus <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

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-

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.

Fixes: 9bb2e0452508 ("gpio: amd: Make resource struct const")
Signed-off-by: Arnd Bergmann <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Acked-by: Greg Kroah-Hartman <[email protected]>
Reviwed-By: Enrico Weigelt <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>

show more ...

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 <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...