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

of: fix memory leak related to safe_name()

2016-08-16T12:25:06Z

[ Upstream commit d9fc880723321dbf16b2981e3f3e916b73942210 ] 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 Cc: stable@vger.kernel.org Signed-off-by: Rob Herring Signed-off-by: Sasha Levin

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

2016-06-17T19:39:10Z

[ Upstream commit 3993546646baf1dab5f5c4f7d9bb58f2046fd1c1 ] 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 CC: stable@vger.kernel.org Signed-off-by: Rob Herring Signed-off-by: Sasha Levin

of: alloc anywhere from memblock if range not specified

2016-04-18T12:50:47Z

[ Upstream commit e53b50c0cbe392c946807abf7d07615a3c588642 ] 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 Cc: stable@vger.kernel.org Signed-off-by: Rob Herring Signed-off-by: Sasha Levin

MFD/OF: document MFD devices and handle simple-mfd

2015-11-09T22:33:39Z

commit 22869a9eca4ea5b534538d160b68c7aef44e378a upstream. This defines a new compatible option for MFD devices "simple-mfd" that will make the OF core spawn child devices for all subnodes of that MFD device. It is optional but handy for things like syscon and possibly other simpler MFD devices. Since there was no file to put the documentation in, I took this opportunity to make a small writeup on MFD devices and add the compatible definition there. Suggested-by: Lee Jones Acked-by: Lee Jones Acked-by: Antoine Tenart Acked-by: Alexandre Belloni Cc: Arnd Bergmann Cc: Devicetree Cc: Rob Herring Cc: Benjamin Herrenschmidt Cc: Grant Likely Cc: Pawel Moll Cc: Mark Rutland Cc: Ian Campbell Cc: Kumar Gala Signed-off-by: Linus Walleij Cc: Henrik Juul Pedersen Signed-off-by: Greg Kroah-Hartman

of_mdio: add new DT property 'managed' to specify the PHY management type

2015-10-03T11:49:17Z

[ Upstream commit 4cba5c2103657d43d0886e4cff8004d95a3d0def in net-next tree, will be pushed to Linus very soon. ] Currently the PHY management type is selected by the MAC driver arbitrary. The decision is based on the presence of the "fixed-link" node and on a will of the driver's authors. This caused a regression recently, when mvneta driver suddenly started to use the in-band status for auto-negotiation on fixed links. It appears the auto-negotiation may not work when expected by the MAC driver. Sebastien Rannou explains: << Yes, I confirm that my HW does not generate an in-band status. AFAIK, it's a PHY that aggregates 4xSGMIIs to 1xQSGMII ; the MAC side of the PHY (with inband status) is connected to the switch through QSGMII, and in this context we are on the media side of the PHY. >> https://lkml.org/lkml/2015/7/10/206 This patch introduces the new string property 'managed' that allows the user to set the management type explicitly. The supported values are: "auto" - default. Uses either MDIO or nothing, depending on the presence of the fixed-link node "in-band-status" - use in-band status Signed-off-by: Stas Sergeev CC: Rob Herring CC: Pawel Moll CC: Mark Rutland CC: Ian Campbell CC: Kumar Gala CC: Florian Fainelli CC: Grant Likely CC: devicetree@vger.kernel.org CC: linux-kernel@vger.kernel.org CC: netdev@vger.kernel.org Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

of/fdt: make memblock maximum physical address arch configurable

2015-09-29T17:25:59Z

commit 8eafeb48022816513abc4f440bdad4c350fe81a3 upstream. When parsing the memory nodes to populate the memblock memory table, we check against high and low limits and clip any memory that exceeds either one of them. However, for arm64, the high limit of (phys_addr_t)~0 is not very meaningful, since phys_addr_t is 64 bits (i.e., no limit) but there may be other constraints that limit the memory ranges that we can support. So rename MAX_PHYS_ADDR to MAX_MEMBLOCK_ADDR (for clarity) and only define it if the arch does not supply a definition of its own. Acked-by: Rob Herring Reviewed-by: Catalin Marinas Tested-by: Stuart Yoder Signed-off-by: Ard Biesheuvel Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman

of/address: Don't loop forever in of_find_matching_node_by_address().

2015-09-21T17:05:43Z

commit 3a496b00b6f90c41bd21a410871dfc97d4f3c7ab upstream. If the internal call to of_address_to_resource() fails, we end up looping forever in of_find_matching_node_by_address(). This can be caused by a defective device tree, or calling with an incorrect matches argument. Fix by calling of_find_matching_node() unconditionally at the end of the loop. Signed-off-by: David Daney Signed-off-by: Rob Herring Signed-off-by: Greg Kroah-Hartman

of: return NUMA_NO_NODE from fallback of_node_to_nid()

2015-08-03T16:29:16Z

commit c8fff7bc5bba6bd59cad40441c189c4efe7190f6 upstream. Node 0 might be offline as well as any other numa node, in this case kernel cannot handle memory allocation and crashes. Signed-off-by: Konstantin Khlebnikov Fixes: 0c3f061c195c ("of: implement of_node_to_nid as a weak function") Signed-off-by: Grant Likely Signed-off-by: Greg Kroah-Hartman

of/address: use atomic allocation in pci_register_io_range()

2015-08-03T16:29:16Z

commit 294240ffe784e951dc2ef070da04fa31ef6db3a0 upstream. When kzalloc() is called under spin_lock(), GFP_ATOMIC should be used to avoid sleeping allocation. The call tree is: of_pci_range_to_resource() --> pci_register_io_range() <-- takes spin_lock(&io_range_lock); --> kzalloc() Signed-off-by: Jingoo Han Signed-off-by: Rob Herring Signed-off-by: Greg Kroah-Hartman

of/pci: Fix pci_address_to_pio() conversion of CPU address to I/O port

2015-07-21T17:10:05Z

commit 5dbb4c6167229c8d4f528e8ec26699a7305000a3 upstream. 41f8bba7f555 ("of/pci: Add pci_register_io_range() and pci_pio_to_address()") added support for systems with several I/O ranges described by OF bindings. It modified pci_address_to_pio() look up the io_range for a given CPU physical address, but the conversion was wrong. Fix the conversion of address to I/O port. [bhelgaas: changelog] Fixes: 41f8bba7f555 ("of/pci: Add pci_register_io_range() and pci_pio_to_address()") Signed-off-by: Zhichang Yuan Signed-off-by: Bjorn Helgaas Acked-by: Liviu Dudau Signed-off-by: Greg Kroah-Hartman