diff options
| author | Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> | 2019-01-29 13:56:19 +0300 |
|---|---|---|
| committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2019-01-31 19:28:40 +0100 |
| commit | 8d84b18f5678d3adfdb9375dfb0d968da2dc753d (patch) | |
| tree | ceab5dd691fe138a67419c7d2ab85629dfaeb0eb /lib/bucket_locks.c | |
| parent | fa548d79d87fd1ad2a2c4e26f829984a106c6ca5 (diff) | |
| download | linux-stable-8d84b18f5678d3adfdb9375dfb0d968da2dc753d.tar.gz linux-stable-8d84b18f5678d3adfdb9375dfb0d968da2dc753d.tar.bz2 linux-stable-8d84b18f5678d3adfdb9375dfb0d968da2dc753d.zip | |
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>
Diffstat (limited to 'lib/bucket_locks.c')
0 files changed, 0 insertions, 0 deletions