user/sven/linux.git/drivers/of, branch v4.4.29

of: fix reference counting in of_graph_get_endpoint_by_regs

2016-09-07T06:32:41Z

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:25Z

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:29Z

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:55Z

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:29Z

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:36Z

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

of/fdt: Add mutex protection for calls to __unflatten_device_tree()

2015-12-08T15:50:42Z

__unflatten_device_tree() calls unflatten_dt_node(), which declares a static variable. It is therefore not reentrant. One of the callers of __unflatten_device_tree(), unflatten_device_tree(), is only called once during early initialization and does not need to be protected. The other caller, of_fdt_unflatten_tree(), can be called at any time, possibly multiple times in parallel. This can happen, for example, if multiple devicetree overlays have to be loaded and installed. Without this protection, errors such as the following may be seen. kernel: End of tree marker overwritten: e6a3a458 kernel: find_target_node: Failed to find target-indirect node at /fragment@0 kernel: __of_overlay_create: of_build_overlay_info() failed for tree@/ Add a mutex to of_fdt_unflatten_tree() to make the call reentrant. Cc: Pantelis Antoniou Signed-off-by: Guenter Roeck Cc: stable@vger.kernel.org # v4.1+ Signed-off-by: Rob Herring

of/address: fix typo in comment block of of_translate_one()

2015-11-30T23:57:01Z

Remove the "not" before "cannot". I am fixing the comment block style while I am here. Signed-off-by: Masahiro Yamada Signed-off-by: Rob Herring

of: do not use 0x in front of %pa

2015-11-30T23:56:54Z

Signed-off-by: Dmitry V. Krivenok Signed-off-by: Rob Herring

of: Fix comparison of reserved memory regions

2015-11-30T23:56:44Z

In order to check for overlapping reserved memory regions, we first need to sort the array of memory regions. This is implemented using sort(), and a custom comparison function __rmem_cmp(). Unfortunatley __rmem_cmp() doesn't work in all cases. Because the two base values are phys_addr_t, they may be u64 on some platforms, in which case subtracting one from the other and then (implicitly) casting to int does not give us the -ve/0/+ve value we need. This leads to incorrect reports about overlaps, eg: ibm,slw-image@1ffe600000 (0x0000001ffe600000--0x0000001ffe700000) overlaps with ibm,firmware-allocs-memory@1000000000 (0x0000001000000000--0x0000001000dc0200) Fix it by just doing the standard double if and return 0 logic. Fixes: ae1add247bf8 ("of: Check for overlap in reserved memory regions") Signed-off-by: Michael Ellerman Signed-off-by: Rob Herring