user/sven/linux.git/drivers/of, branch v5.10.48

of: overlay: fix for_each_child.cocci warnings

2021-05-14T07:50:24Z

[ Upstream commit c4d74f0f978ed5ceee62cd3f6708081042e582a1 ] Function "for_each_child_of_node" should have of_node_put() before goto. Generated by: scripts/coccinelle/iterators/for_each_child.cocci Fixes: 82c2d81361ec ("coccinelle: iterators: Add for_each_child.cocci script") CC: Sumera Priyadarsini Reported-by: kernel test robot Signed-off-by: kernel test robot Signed-off-by: Julia Lawall Reviewed-by: Frank Rowand Tested-by: Frank Rowand Link: https://lore.kernel.org/r/alpine.DEB.2.22.394.2103221918450.2918@hadrien Signed-off-by: Rob Herring Signed-off-by: Sasha Levin

of: property: fw_devlink: do not link ".*,nr-gpios"

2021-04-14T06:41:58Z

commit d473d32c2fbac2d1d7082c61899cfebd34eb267a upstream. [,]nr-gpios property is used by some GPIO drivers[0] to indicate the number of GPIOs present on a system, not define a GPIO. nr-gpios is not configured by #gpio-cells and can't be parsed along with other "*-gpios" properties. nr-gpios without the "," prefix is not allowed by the DT spec[1], so only add exception for the ",nr-gpios" suffix and let the error message continue being printed for non-compliant implementations. [0] nr-gpios is referenced in Documentation/devicetree/bindings/gpio: - gpio-adnp.txt - gpio-xgene-sb.txt - gpio-xlp.txt - snps,dw-apb-gpio.yaml [1] Link: https://github.com/devicetree-org/dt-schema/blob/cb53a16a1eb3e2169ce170c071e47940845ec26e/schemas/gpio/gpio-consumer.yaml#L20 Fixes errors such as: OF: /palmbus@300000/gpio@600: could not find phandle Fixes: 7f00be96f125 ("of: property: Add device link support for interrupt-parent, dmas and -gpio(s)") Signed-off-by: Ilya Lipnitskiy Cc: Saravana Kannan Cc: stable@vger.kernel.org # v5.5+ Link: https://lore.kernel.org/r/20210405222540.18145-1-ilya.lipnitskiy@gmail.com Signed-off-by: Rob Herring Signed-off-by: Greg Kroah-Hartman

of: unittest: Fix build on architectures without CONFIG_OF_ADDRESS

2021-03-09T10:11:15Z

commit aed5041ef9a3f594ed9dc0bb5ee7e1bbccfd3366 upstream. of_dma_get_max_cpu_address() is not defined if !CONFIG_OF_ADDRESS, so return early in of_unittest_dma_get_max_cpu_address(). Fixes: 07d13a1d6120 ("of: unittest: Add test for of_dma_get_max_cpu_address()") Reported-by: kernel test robot Signed-off-by: Catalin Marinas Cc: Jing Xiangfeng Signed-off-by: Greg Kroah-Hartman

of: unittest: Add test for of_dma_get_max_cpu_address()

2021-03-09T10:11:13Z

commit 07d13a1d6120d453c3c1f020578693d072deded5 upstream Introduce a test for of_dma_get_max_cup_address(), it uses the same DT data as the rest of dma-ranges unit tests. Signed-off-by: Nicolas Saenz Julienne Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20201119175400.9995-5-nsaenzjulienne@suse.de Signed-off-by: Catalin Marinas Cc: Signed-off-by: Jing Xiangfeng Signed-off-by: Greg Kroah-Hartman

of/address: Introduce of_dma_get_max_cpu_address()

2021-03-09T10:11:13Z

commit 964db79d6c186cc2ecc6ae46f98eed7e0ea8cf71 upstream Introduce of_dma_get_max_cpu_address(), which provides the highest CPU physical address addressable by all DMA masters in the system. It's specially useful for setting memory zones sizes at early boot time. Signed-off-by: Nicolas Saenz Julienne Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20201119175400.9995-4-nsaenzjulienne@suse.de Signed-off-by: Catalin Marinas Cc: Signed-off-by: Jing Xiangfeng Signed-off-by: Greg Kroah-Hartman

of/fdt: Make sure no-map does not remove already reserved regions

2021-03-04T10:37:56Z

[ Upstream commit 8a5a75e5e9e55de1cef5d83ca3589cb4899193ef ] If the device tree is incorrectly configured, and attempts to define a "no-map" reserved memory that overlaps with the kernel data/code, the kernel would crash quickly after boot, with no obvious clue about the nature of the issue. For example, this would happen if we have the kernel mapped at these addresses (from /proc/iomem): 40000000-41ffffff : System RAM 40080000-40dfffff : Kernel code 40e00000-411fffff : reserved 41200000-413e0fff : Kernel data And we declare a no-map shared-dma-pool region at a fixed address within that range: mem_reserved: mem_region { compatible = "shared-dma-pool"; reg = <0 0x40000000 0 0x01A00000>; no-map; }; To fix this, when removing memory regions at early boot (which is what "no-map" regions do), we need to make sure that the memory is not already reserved. If we do, __reserved_mem_reserve_reg will throw an error: [ 0.000000] OF: fdt: Reserved memory: failed to reserve memory for node 'mem_region': base 0x0000000040000000, size 26 MiB and the code that will try to use the region should also fail, later on. We do not do anything for non-"no-map" regions, as memblock explicitly allows reserved regions to overlap, and the commit that this fixes removed the check for that precise reason. [ qperret: fixed conflicts caused by the usage of memblock_mark_nomap ] Fixes: 094cb98179f19b7 ("of/fdt: memblock_reserve /memreserve/ regions in the case of partial overlap") Signed-off-by: Nicolas Boichat Reviewed-by: Stephen Boyd Signed-off-by: Quentin Perret Link: https://lore.kernel.org/r/20210115114544.1830068-3-qperret@google.com Signed-off-by: Rob Herring Signed-off-by: Sasha Levin

fdt: Properly handle "no-map" field in the memory region

2021-03-04T10:37:56Z

[ Upstream commit 86588296acbfb1591e92ba60221e95677ecadb43 ] Mark the memory region with NOMAP flag instead of completely removing it from the memory blocks. That makes the FDT handling consistent with the EFI memory map handling. Cc: Rob Herring Cc: Frank Rowand Cc: devicetree@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: KarimAllah Ahmed Signed-off-by: Quentin Perret Link: https://lore.kernel.org/r/20210115114544.1830068-2-qperret@google.com Signed-off-by: Rob Herring Signed-off-by: Sasha Levin

of/device: Update dma_range_map only when dev has valid dma-ranges

2021-02-03T22:28:50Z

[ Upstream commit 89c7cb1608ac3c7ecc19436469f35ed12da97e1d ] The commit e0d072782c73 ("dma-mapping: introduce DMA range map, supplanting dma_pfn_offset") always update dma_range_map even though it was already set, like in the sunxi_mbus driver. the issue is reported at [1]. This patch avoid this(Updating it only when dev has valid dma-ranges). Meanwhile, dma_range_map contains the devices' dma_ranges information, This patch moves dma_range_map before of_iommu_configure. The iommu driver may need to know the dma_address requirements of its iommu consumer devices. [1] https://lore.kernel.org/linux-arm-kernel/5c7946f3-b56e-da00-a750-be097c7ceb32@arm.com/ CC: Frank Rowand Fixes: e0d072782c73 ("dma-mapping: introduce DMA range map, supplanting dma_pfn_offset"), Suggested-by: Robin Murphy Signed-off-by: Yong Wu Signed-off-by: Paul Kocialkowski Reviewed-by: Rob Herring Reviewed-by: Robin Murphy Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20210119105203.15530-1-yong.wu@mediatek.com Signed-off-by: Sasha Levin

of/address: Fix of_node memory leak in of_dma_is_coherent

2020-11-11T23:10:16Z

Commit dabf6b36b83a ("of: Add OF_DMA_DEFAULT_COHERENT & select it on powerpc") added a check to of_dma_is_coherent which returns early if OF_DMA_DEFAULT_COHERENT is enabled. This results in the of_node_put() being skipped causing a memory leak. Moved the of_node_get() below this check so we now we only get the node if OF_DMA_DEFAULT_COHERENT is not enabled. Fixes: dabf6b36b83a ("of: Add OF_DMA_DEFAULT_COHERENT & select it on powerpc") Signed-off-by: Evan Nimmo Link: https://lore.kernel.org/r/20201110022825.30895-1-evan.nimmo@alliedtelesis.co.nz Signed-off-by: Rob Herring

of: Drop superfluous ULL suffix for ~0

2020-11-02T17:32:46Z

There is no need to specify a "ULL" suffix for "all bits set": "~0" is sufficient, and works regardless of type. In fact adding the suffix makes the code more fragile. Fixes: 48ab6d5d1f09 ("dma-mapping: fix 32-bit overflow with CONFIG_ARM_LPAE=n") Suggested-by: Linus Torvalds Signed-off-by: Geert Uytterhoeven Signed-off-by: Linus Torvalds