linux-toradex.git/drivers/of, branch v4.4.93

of: device: Export of_device_{get_modalias, uvent_modalias} to modules

2017-07-27T22:06:09+00:00

commit 7a3b7cd332db08546f3cdd984f11773e0d1999e7 upstream.

The ULPI bus can be built as a module, and it will soon be
calling these functions when it supports probing devices from DT.
Export them so they can be used by the ULPI module.

Acked-by: Rob Herring 
Cc: 
Signed-off-by: Stephen Boyd 
Signed-off-by: Peter Chen 
Signed-off-by: Greg Kroah-Hartman

of: Add check to of_scan_flat_dt() before accessing initial_boot_params

2017-06-29T10:48:52+00:00

commit 3ec754410cb3e931a6c4920b1a150f21a94a2bf4 upstream.

An empty __dtb_start to __dtb_end section might result in
initial_boot_params being null for arch/mips/ralink. This showed that the
boot process hangs indefinitely in of_scan_flat_dt().

Signed-off-by: Tobias Wolf 
Cc: Sergei Shtylyov 
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/14605/
Signed-off-by: Ralf Baechle 
Signed-off-by: Amit Pundir 
Signed-off-by: Greg Kroah-Hartman

of: fix sparse warning in of_pci_range_parser_one

2017-05-25T12:30:10+00:00

commit eb3100365791b06242b8bb5c3c2854ba41dabfbc upstream.

sparse gives the following warning for 'pci_space':

../drivers/of/address.c:266:26: warning: incorrect type in assignment (different base types)
../drivers/of/address.c:266:26:    expected unsigned int [unsigned] [usertype] pci_space
../drivers/of/address.c:266:26:    got restricted __be32 const [usertype] 

It appears that pci_space is only ever accessed on powerpc, so the endian
swap is often not needed.

Signed-off-by: Rob Herring 
Signed-off-by: Greg Kroah-Hartman

of: silence warnings due to max() usage

2016-11-15T06:46:39+00:00

commit aaaab56dba9af4fe75461e0ee13231c1a6ea174d upstream.

pageblock_order can be (at least) an unsigned int or an unsigned long
depending on the kernel config and architecture, so use max_t(unsigned
long ...) when comparing it.

fixes these warnings:

In file included from include/linux/list.h:8:0,
                 from include/linux/kobject.h:20,
                 from include/linux/of.h:21,
                 from drivers/of/of_reserved_mem.c:17:
drivers/of/of_reserved_mem.c: In function ‘__reserved_mem_alloc_size’:
include/linux/kernel.h:748:17: warning: comparison of distinct pointer types lacks a cast
  (void) (&_max1 == &_max2);  \
                 ^
include/linux/kernel.h:747:9: note: in definition of macro ‘max’
  typeof(y) _max2 = (y);   \
         ^
drivers/of/of_reserved_mem.c:131:48: note: in expansion of macro ‘max’
   align = max(align, (phys_addr_t)PAGE_SIZE << max(MAX_ORDER - 1, pageblock_ord
                                                ^
include/linux/kernel.h:748:17: warning: comparison of distinct pointer types lacks a cast
  (void) (&_max1 == &_max2);  \
                 ^
include/linux/kernel.h:747:21: note: in definition of macro ‘max’
  typeof(y) _max2 = (y);   \
                     ^
drivers/of/of_reserved_mem.c:131:48: note: in expansion of macro ‘max’
   align = max(align, (phys_addr_t)PAGE_SIZE << max(MAX_ORDER - 1, pageblock_ord
                                                ^

Fixes: 1cc8e3458b51 ("drivers: of: of_reserved_mem: fixup the alignment with CMA setup")
Signed-off-by: Stephen Rothwell 
Signed-off-by: Rob Herring 
Cc: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman

of: fix reference counting in of_graph_get_endpoint_by_regs

2016-09-07T06:32:41+00:00

commit 34276bb062b8449b3b0a208c9b848a1a27920075 upstream.

The called of_graph_get_next_endpoint() already decrements the refcount
of the prev node, so it is wrong to do it again in the calling function.

Use the for_each_endpoint_of_node() helper to interate through the
endpoint OF nodes, which already does the right thing and simplifies
the code a bit.

Fixes: 8ccd0d0ca041
(of: add helper for getting endpoint node of specific identifiers)
Reported-by: David Jander 
Signed-off-by: Lucas Stach 
Acked-by: Philipp Zabel 
Signed-off-by: Rob Herring 
Signed-off-by: Greg Kroah-Hartman

of: fix memory leak related to safe_name()

2016-08-20T16:09:25+00:00

commit d9fc880723321dbf16b2981e3f3e916b73942210 upstream.

Fix a memory leak resulting from memory allocation in safe_name().
This patch fixes all call sites of safe_name().

Mathieu Malaterre reported the memory leak on boot:

On my PowerMac device-tree would generate a duplicate name:

[    0.023043] device-tree: Duplicate name in PowerPC,G4@0, renamed to "l2-cache#1"

in this case a newly allocated name is generated by `safe_name`. However
in this case it is never deallocated.

The bug was found using kmemleak reported as:

unreferenced object 0xdf532e60 (size 32):
  comm "swapper", pid 1, jiffies 4294892300 (age 1993.532s)
  hex dump (first 32 bytes):
    6c 32 2d 63 61 63 68 65 23 31 00 dd e4 dd 1e c2  l2-cache#1......
    ec d4 ba ce 04 ec cc de 8e 85 e9 ca c4 ec cc 9e  ................
  backtrace:
    [] kvasprintf+0x64/0xc8
    [] kasprintf+0x4c/0x5c
    [] safe_name.isra.1+0x80/0xc4
    [] __of_attach_node_sysfs+0x6c/0x11c
    [] of_core_init+0x8c/0xf8
    [] kernel_init_freeable+0xd4/0x208
    [] kernel_init+0x24/0x11c
    [] ret_from_kernel_thread+0x5c/0x64

Link: https://bugzilla.kernel.org/show_bug.cgi?id=120331

Signed-off-by: Frank Rowand 
Reported-by: mathieu.malaterre@gmail.com
Tested-by: Mathieu Malaterre 
Signed-off-by: Rob Herring 
Signed-off-by: Greg Kroah-Hartman

of: irq: fix of_irq_get[_byname]() kernel-doc

2016-07-27T16:47:29+00:00

commit 3993546646baf1dab5f5c4f7d9bb58f2046fd1c1 upstream.

The kernel-doc for the of_irq_get[_byname]()  is clearly inadequate in
describing the return values -- of_irq_get_byname() is documented better
than of_irq_get() but it  still doesn't mention that 0 is returned iff
irq_create_of_mapping() fails (it doesn't return an error code in this
case). Document all possible return value variants, making the writing
of the word "IRQ" consistent, while at it...

Fixes: 9ec36cafe43b ("of/irq: do irq resolution in platform_get_irq")
Fixes: ad69674e73a1 ("of/irq: do irq resolution in platform_get_irq_byname()")
Signed-off-by: Sergei Shtylyov 
Signed-off-by: Rob Herring 
Signed-off-by: Greg Kroah-Hartman

of: alloc anywhere from memblock if range not specified

2016-04-12T16:08:55+00:00

commit e53b50c0cbe392c946807abf7d07615a3c588642 upstream.

early_init_dt_alloc_reserved_memory_arch passes end as 0 to
__memblock_alloc_base, when limits are not specified. But
__memblock_alloc_base takes end value of 0 as MEMBLOCK_ALLOC_ACCESSIBLE
and limits the end to memblock.current_limit. This results in regions
never being placed in HIGHMEM area, for e.g. CMA.
Let __memblock_alloc_base allocate from anywhere in memory if limits are
not specified.

Acked-by: Marek Szyprowski 
Signed-off-by: Vinayak Menon 
Signed-off-by: Rob Herring 
Signed-off-by: Greg Kroah-Hartman

of/irq: Fix msi-map calculation for nonzero rid-base

2016-03-03T23:07:29+00:00

commit 5d589d81acf974d23af98044aac56c6339d659f8 upstream.

The existing msi-map code is fine for shifting the entire RID space
upwards, but attempting finer-grained remapping reveals a bug. It turns
out that we are mistakenly treating the msi-base part as an offset, not
as a new base to remap onto, so things get squiffy when rid-base is
nonzero. Fix this, and at the same time add a sanity check against
having msi-map-mask clash with a nonzero rid-base, as that's another
thing one can easily get wrong.

Signed-off-by: Robin Murphy 
Reviewed-by: Marc Zyngier 
Tested-by: Stuart Yoder 
Acked-by: Mark Rutland 
Acked-by: David Daney 
Signed-off-by: Rob Herring 
Signed-off-by: Greg Kroah-Hartman

of/irq: Export of_irq_find_parent again

2015-12-09T15:08:36+00:00

of_irq_find_parent was made static since it had no users outside of
of_irq.c. Export it again since we are going to use it again.

Signed-off-by: Carlo Caione 
[robh: move of_irq_find_parent to correct ifdef section]
Signed-off-by: Rob Herring