kernel_replicant_linux/drivers/of, branch replicant-11

of: Don't allow __of_attached_node_sysfs() without CONFIG_SYSFS

2021-09-18T11:40:31+00:00

[ Upstream commit 6211e9cb2f8faf7faae0b6caf844bfe9527cc607 ]

Trying to boot without SYSFS, but with OF_DYNAMIC quickly
results in a crash:

[    0.088460] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000070
[...]
[    0.103927] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.14.0-rc3 #4179
[    0.105810] Hardware name: linux,dummy-virt (DT)
[    0.107147] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO BTYPE=--)
[    0.108876] pc : kernfs_find_and_get_ns+0x3c/0x7c
[    0.110244] lr : kernfs_find_and_get_ns+0x3c/0x7c
[...]
[    0.134087] Call trace:
[    0.134800]  kernfs_find_and_get_ns+0x3c/0x7c
[    0.136054]  safe_name+0x4c/0xd0
[    0.136994]  __of_attach_node_sysfs+0xf8/0x124
[    0.138287]  of_core_init+0x90/0xfc
[    0.139296]  driver_init+0x30/0x4c
[    0.140283]  kernel_init_freeable+0x160/0x1b8
[    0.141543]  kernel_init+0x30/0x140
[    0.142561]  ret_from_fork+0x10/0x18

While not having sysfs isn't a very common option these days,
it is still expected that such configuration would work.

Paper over it by bailing out from __of_attach_node_sysfs() if
CONFIG_SYSFS isn't enabled.

Signed-off-by: Marc Zyngier 
Link: https://lore.kernel.org/r/20210820144722.169226-1-maz@kernel.org
Signed-off-by: Rob Herring 
Signed-off-by: Sasha Levin

of: Fix truncation of memory sizes on 32-bit platforms

2021-07-14T14:56:46+00:00

[ Upstream commit 2892d8a00d23d511a0591ac4b2ff3f050ae1f004 ]

Variable "size" has type "phys_addr_t", which can be either 32-bit or
64-bit on 32-bit systems, while "unsigned long" is always 32-bit on
32-bit systems.  Hence the cast in

    (unsigned long)size / SZ_1M

may truncate a 64-bit size to 32-bit, as casts have a higher operator
precedence than divisions.

Fix this by inverting the order of the cast and division, which should
be safe for memory blocks smaller than 4 PiB.  Note that the division is
actually a shift, as SZ_1M is a power-of-two constant, hence there is no
need to use div_u64().

While at it, use "%lu" to format "unsigned long".

Fixes: e8d9d1f5485b52ec ("drivers: of: add initialization code for static reserved memory")
Fixes: 3f0c8206644836e4 ("drivers: of: add initialization code for dynamic reserved memory")
Signed-off-by: Geert Uytterhoeven 
Acked-by: Marek Szyprowski 
Link: https://lore.kernel.org/r/4a1117e72d13d26126f57be034c20dac02f1e915.1623835273.git.geert+renesas@glider.be
Signed-off-by: Rob Herring 
Signed-off-by: Sasha Levin

of: overlay: fix for_each_child.cocci warnings

2021-05-14T07:50:24+00:00

[ 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:58+00:00

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:15+00:00

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:13+00:00

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:13+00:00

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:56+00:00

[ 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:56+00:00

[ 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:50+00:00

[ 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