kernel/linux.git/drivers/of/property.c, branch v6.19.11

of: base: Add of_property_read_u8_index

2025-12-08T07:07:26+00:00

Add support for of_property_read_u8_index(), simillar to others u16 and u32 variants. Having this helper makes the code more tidy in isome cases, specially when we are parsing multiple of these into data structures. Signed-off-by: Srinivas Kandagatla Reviewed-by: Rob Herring (Arm) Tested-by: Alexey Klimov # sm8550 Link: https://patch.msgid.link/20250912083225.228778-2-srinivas.kandagatla@oss.qualcomm.com Signed-off-by: Vinod Koul

of: Add of_property_read_u16_index

2025-03-20T12:42:27+00:00

There is an of_property_read_u32_index and of_property_read_u64_index. This patch adds a similar helper for u16. Signed-off-by: Ernest Van Hoecke Signed-off-by: Francesco Dolcini Reviewed-by: Rob Herring (Arm) Reviewed-by: Charles Keepax Link: https://patch.msgid.link/20250319142059.46692-2-francesco@dolcini.it Signed-off-by: Mark Brown

Merge tag 'devicetree-for-6.14' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux

2025-01-24T23:09:20+00:00

Pull devicetree updates from Rob Herring: "DT Bindings: - Add Bindings for QCom QCS615 UFS, QCom IPQ5424 DWC3 USB, NXP imx7d MIPI DSI, QCom SM8750 PDC, QCom MSM8976 SRAM, QCom ipq6018 temp sensor, QCom QCS8300 Power Domain Controller, QCom QCS615 Power Domain Controller, QCom QCS615 APSS, QCom QCS615 qfprom, QCom QCS8300 remoteproc, Mediatek MT6328 PMIC, Allwinner A100 OPP, and NXP iMX35 GPT - Convert Altera socfpga-system, raspberrypi,bcm2835-power to DT schema - Add Siflower vendor prefix - Cleanup display, interrupt-controller, and UFS binding examples' indentation - Document preferred line wrapping (the same as the rest of the kernel) DT Core: - Add warning when of_property_read_bool() is used on non-boolean properties - Restore keeping bootloader DTB when booting with ACPI. Turns out some x86 platforms relied on that. Shrug. - Fix of_find_node_opts_by_path() handling of alias+path+options - Fix resource bounds checking for empty resources - A bunch of small fixes/cleanups all over from Zijun Hu - Cleanups in bin_attribute handling" * tag 'devicetree-for-6.14' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux: (50 commits) of: address: Fix empty resource handling in __of_address_resource_bounds() of/fdt: Restore possibility to use both ACPI and FDT from bootloader docs: dt-bindings: Document preferred line wrapping dt-bindings: ufs: Correct indentation and style in DTS example of: Correct element count for two arrays in API of_parse_phandle_with_args_map() of: reserved-memory: Warn for missing static reserved memory regions of: Do not expose of_alias_scan() and correct its comments dt-bindings: ufs: qcom: Add UFS Host Controller for QCS615 dt-bindings: usb: qcom,dwc3: Add IPQ5424 to USB DWC3 bindings dt-bindings: arm: coresight: Update the pattern of ete node name of: Warn when of_property_read_bool() is used on non-boolean properties device property: Split property reading bool and presence test ops of/fdt: Check fdt_get_mem_rsv() error in early_init_fdt_scan_reserved_mem() of: reserved-memory: Move an assignment to effective place in __reserved_mem_alloc_size() of: reserved-memory: Do not make kmemleak ignore freed address of: reserved-memory: Fix using wrong number of cells to get property 'alignment' of: Remove a duplicated code block of: property: Avoiding using uninitialized variable @imaplen in parse_interrupt_map() of: Correct child specifier used as input of the 2nd nexus node dt-bindings: interrupt-controller: ti,omap4-wugen-mpu: Add file extension ...

of: Warn when of_property_read_bool() is used on non-boolean properties

2025-01-13T23:47:29+00:00

The use of of_property_read_bool() for non-boolean properties is deprecated. The primary use of it was to test property presence, but that has been replaced in favor of of_property_present(). With those uses now fixed, add a warning to discourage new ones. Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20250109-dt-type-warnings-v1-2-0150e32e716c@kernel.org Signed-off-by: Rob Herring (Arm)

device property: Split property reading bool and presence test ops

2025-01-13T23:47:29+00:00

The fwnode/device property API currently implement (fwnode|device)_property_read_bool() with (fwnode|device)_property_present(). That does not allow having different behavior depending on the backend. Specifically, the usage of (fwnode|device)_property_read_bool() on non-boolean properties is deprecated on DT. In order to add a warning on this deprecated use, these 2 APIs need separate ops for the backend. Acked-by: Greg Kroah-Hartman Reviewed-by: Krzysztof Kozlowski Acked-by: Rafael J. Wysocki Link: https://lore.kernel.org/r/20250109-dt-type-warnings-v1-1-0150e32e716c@kernel.org Signed-off-by: Rob Herring (Arm)

of: property: Avoiding using uninitialized variable @imaplen in parse_interrupt_map()

2025-01-13T13:43:48+00:00

parse_interrupt_map() will use uninitialized variable @imaplen if fails to get property 'interrupt-map'. Fix by using the variable after successfully getting the property. Fixes: e7985f43609c ("of: property: Fix fw_devlink handling of interrupt-map") Signed-off-by: Zijun Hu Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20250109-of_core_fix-v4-6-db8a72415b8c@quicinc.com Signed-off-by: Rob Herring (Arm)

of: property: fw_devlink: Do not use interrupt-parent directly

2024-11-25T14:24:17+00:00

commit 7f00be96f125 ("of: property: Add device link support for interrupt-parent, dmas and -gpio(s)") started adding device links for the interrupt-parent property. commit 4104ca776ba3 ("of: property: Add fw_devlink support for interrupts") and commit f265f06af194 ("of: property: Fix fw_devlink handling of interrupts/interrupts-extended") later added full support for parsing the interrupts and interrupts-extended properties, which includes looking up the node of the parent domain. This made the handler for the interrupt-parent property redundant. In fact, creating device links based solely on interrupt-parent is problematic, because it can create spurious cycles. A node may have this property without itself being an interrupt controller or consumer. For example, this property is often present in the root node or a /soc bus node to set the default interrupt parent for child nodes. However, it is incorrect for the bus to depend on the interrupt controller, as some of the bus's children may not be interrupt consumers at all or may have a different interrupt parent. Resolving these spurious dependency cycles can cause an incorrect probe order for interrupt controller drivers. This was observed on a RISC-V system with both an APLIC and IMSIC under /soc, where interrupt-parent in /soc points to the APLIC, and the APLIC msi-parent points to the IMSIC. fw_devlink found three dependency cycles and attempted to probe the APLIC before the IMSIC. After applying this patch, there were no dependency cycles and the probe order was correct. Acked-by: Marc Zyngier Cc: stable@vger.kernel.org Fixes: 4104ca776ba3 ("of: property: Add fw_devlink support for interrupts") Signed-off-by: Samuel Holland Link: https://lore.kernel.org/r/20241120233124.3649382-1-samuel.holland@sifive.com Signed-off-by: Rob Herring (Arm)

of: property: use new of_graph functions

2024-10-24T21:35:48+00:00

Current of_graph_get_next_endpoint() can be replaced by using new of_graph_get_next_port(). Signed-off-by: Kuninori Morimoto Link: https://lore.kernel.org/r/87iktib5t0.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Rob Herring (Arm)

of: property: add of_graph_get_next_port_endpoint()

2024-10-24T21:35:48+00:00

We already have of_graph_get_next_endpoint(), but it is not intuitive to use in some case. (X) node { (Y) ports { (P0) port@0 { endpoint { remote-endpoint = ...; };}; (P10) port@1 { endpoint { remote-endpoint = ...; }; (P11) endpoint { remote-endpoint = ...; };}; (P2) port@2 { endpoint { remote-endpoint = ...; };}; }; }; For example, if I want to handle port@1's 2 endpoints (= P10, P11), I want to use like below P10 = of_graph_get_next_endpoint(port1, NULL); P11 = of_graph_get_next_endpoint(port1, P10); But 1st one will be error, because of_graph_get_next_endpoint() requested 1st parameter is "node" (X) or "ports" (Y), not but "port". Below works well, but it will get P0 P0 = of_graph_get_next_endpoint(node, NULL); P0 = of_graph_get_next_endpoint(ports, NULL); In other words, we can't handle P10/P11 directly via of_graph_get_next_endpoint(). There is another non intuitive behavior on of_graph_get_next_endpoint(). In case of if I could get P10 pointer for some way, and if I want to handle port@1 things by loop, I would like use it like below /* * "ep" is now P10, and handle port1 things here, * but we don't know how many endpoints port1 have. * * Because "ep" is non NULL now, we can use port1 * as of_graph_get_next_endpoint(port1, xxx) */ do { /* do something for port1 specific things here */ } while (ep = of_graph_get_next_endpoint(port1, ep)) But it also not worked as I expected. I expect it will be P10 -> P11 -> NULL, but it will be P10 -> P11 -> P2, because of_graph_get_next_endpoint() will fetch "endpoint" beyond the "port". It is not useful for generic driver. To handle endpoint more intuitive, create of_graph_get_next_port_endpoint() of_graph_get_next_port_endpoint(port1, NULL); // P10 of_graph_get_next_port_endpoint(port1, P10); // P11 of_graph_get_next_port_endpoint(port1, P11); // NULL Signed-off-by: Kuninori Morimoto Link: https://lore.kernel.org/r/87jzdyb5t5.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Rob Herring (Arm)

of: property: add of_graph_get_next_port()

2024-10-24T21:35:48+00:00

We have endpoint base functions - of_graph_get_next_endpoint() - of_graph_get_endpoint_count() - for_each_endpoint_of_node() Here, for_each_endpoint_of_node() loop finds each endpoints ports { port@0 { (1) endpoint {...}; }; port@1 { (2) endpoint {...}; }; ... }; In above case, it finds endpoint as (1) -> (2) -> ... Basically, user/driver knows which port is used for what, but not in all cases. For example on flexible/generic driver case, how many ports are used is not fixed. For example Sound Generic Card driver which is very flexible/generic and used from many venders can't know how many ports are used, and used for what, because it depends on each vender SoC and/or its used board. And more, the port can have multi endpoints. For example Generic Sound Card case, it supports many type of connection between CPU / Codec, and some of them uses multi endpoint in one port. see below. ports { (A) port@0 { (1) endpoint@0 {...}; (2) endpoint@1 {...}; }; (B) port@1 { (3) endpoint {...}; }; ... }; Generic Sound Card want to handle each connection via "port" base instead of "endpoint" base. But, it is very difficult to handle each "port" via existing for_each_endpoint_of_node(). Because getting each "port" via of_get_parent() from each "endpoint" doesn't work. For example in above case, both (1) (2) endpoint has same "port" (= A). Add "port" base functions. Signed-off-by: Kuninori Morimoto Link: https://lore.kernel.org/r/87ldyeb5t9.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Rob Herring (Arm)