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

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

2025-02-08T09:01:58+00:00

[ Upstream commit f73780e772c06901e99b2ad114b7f0f3fbe73ad4 ] 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) Signed-off-by: Sasha Levin

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)

of: Constify struct property pointers

2024-10-15T13:58:36+00:00

Most accesses to struct property do not modify it, so constify struct property pointers where ever possible in the DT core code. Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20241010-dt-const-v1-4-87a51f558425@kernel.org Signed-off-by: Rob Herring (Arm)

drivers/of: Improve documentation for match_string

2024-09-13T19:01:34+00:00

The description of the function now explicitly states that it's an *exact* match for the given string (i.e. not a submatch). It also better states all the possible return values. Signed-off-by: Miquel Sabaté Solà Link: https://lore.kernel.org/r/20240911204938.9172-1-mikisabate@gmail.com Signed-off-by: Rob Herring (Arm)

of: property: Do some clean up with use of __free()

2024-09-13T19:01:34+00:00

__free() provides a scoped of_node_put() functionality to put the device_node automatically, and we don't need to call of_node_put() directly. Let's simplify the code a bit with the use of __free(). Signed-off-by: Zhang Zekun Link: https://lore.kernel.org/r/20240830020626.115933-4-zhangzekun11@huawei.com Signed-off-by: Rob Herring (Arm)

of: property: Fix fw_devlink handling of interrupt-map

2024-05-31T00:43:47+00:00

Commit d976c6f4b32c ("of: property: Add fw_devlink support for interrupt-map property") tried to do what it says on the tin, but failed on a couple of points: - it confuses bytes and cells. Not a huge deal, except when it comes to pointer arithmetic - it doesn't really handle anything but interrupt-maps that have their parent #address-cells set to 0 The combinations of the two leads to some serious fun on my M1 box, with plenty of WARN-ON() firing all over the shop, and amusing values being generated for interrupt specifiers. Having 2 versions of parsing code for "interrupt-map" was a bad idea. Now that the common parsing parts have been refactored into of_irq_parse_imap_parent(), rework the code here to use it instead and fix the pointer arithmetic. Note that the dependency will be a bit different than the original code when the interrupt-map points to another interrupt-map. In this case, the original code would resolve to the final interrupt controller. Now the dependency is the parent interrupt-map (which itself should have a dependency to the parent). It is possible that a node with an interrupt-map has no driver. Fixes: d976c6f4b32c ("of: property: Add fw_devlink support for interrupt-map property") Signed-off-by: Marc Zyngier Co-developed-by: Rob Herring (Arm) Cc: Saravana Kannan Tested-by: Marc Zyngier Tested-by: Anup Patel Link: https://lore.kernel.org/r/20240529-dt-interrupt-map-fix-v2-2-ef86dc5bcd2a@kernel.org Signed-off-by: Rob Herring (Arm)

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

2024-05-18T00:27:49+00:00

Pull devicetree updates from Rob Herring: "DT Bindings: - Convert samsung,exynos5-dp, atmel,lcdc, aspeed,ast2400-wdt bindings to schemas - Add bindings for Allwinner H616 NMI controller, Renesas r8a779g0 irqc, Renesas R-Car V4M TMU and CMT timers, Freescale S32G3 linflexuart, and Mediatek MT7988 XHCI - Add 'reg' constraints on DSI and SPI display panels - More dropping of unnecessary quotes in schemas - Use full paths rather than relative paths in schema $refs - Drop redundant storing of phandle for reserved memory DT Core: - Use scope based cleanups for kfree() and of_node_put() - Track interrupt-map and power-supplies for fw_devlink - Add buffer overflow check in of_modalias() - Add and use __of_prop_free() helper for freeing struct property" * tag 'devicetree-for-6.10' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux: (25 commits) of: property: Add fw_devlink support for interrupt-map property dt-bindings: display: panel: constrain 'reg' in DSI panels dt-bindings: display: panel: constrain 'reg' in SPI panels dt-bindings: display: samsung,ams495qa01: add missing SPI properties ref dt-bindings: Use full path to other schemas dt-bindings: PCI: qcom,pcie-sm8350: Drop redundant 'oneOf' sub-schema of: module: add buffer overflow check in of_modalias() dt-bindings: PCI: microchip: increase number of items in ranges property dt-bindings: Drop unnecessary quotes on keys dt-bindings: interrupt-controller: mediatek,mt6577-sysirq: Drop unnecessary quotes of: property: Use scope based cleanup on port_node of: reserved_mem: Remove the use of phandle from the reserved_mem APIs of: property: fw_devlink: Add support for "power-supplies" binding dt-bindings: watchdog: aspeed,ast2400-wdt: Convert to DT schema dt-bindings: irq: sun7i-nmi: Add binding for the H616 NMI controller dt-bindings: interrupt-controller: renesas,irqc: Add r8a779g0 support dt-bindings: timer: renesas,tmu: Add R-Car V4M support dt-bindings: timer: renesas,cmt: Add R-Car V4M support of: Use scope based of_node_put() cleanups of: Use scope based kfree() cleanups ...