kernel/linux
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ synced 2026-11-10 20:48:12 +00:00
Code Issues Releases Packages Activity
linux/drivers/of/property.c

1712 lines
49 KiB
Raw Permalink Normal View History

of: Use SPDX license tag for DT files Convert remaining DT files to use SPDX-License-Identifier tags. Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de> Cc: Paul Mackerras <paulus@samba.org> Cc: Pantelis Antoniou <pantelis.antoniou@konsulko.com> Reviewed-by: Frank Rowand <frank.rowand@sony.com> Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com> Signed-off-by: Rob Herring <robh@kernel.org>
2017-12-27 12:55:14 -06:00
of: Move OF property and graph API from base.c to property.c base.c contains both core OF functions and increasingly other functionality such as accessing properties and graphs, including convenience functions. In the near future this would also include OF specific implementation of the fwnode property and graph APIs. Create driver/of/property.c to contain procedures for accessing and interpreting device tree properties. The procedures are moved from drivers/of/base.c, with no changes other than copying only the includes required by the moved procedures. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rob Herring <robh@kernel.org>
2017-05-24 17:53:53 +03:00
of: property: stop creating callback for each pinctrl-N property While not a lot in the grand scheme of things, this eliminates 8*2 pointless function calls for almost every property present in the device tree (the exception are the few properties that were already matched). It also seems to reduce .text by about 1.5K - why gcc decides to inline parse_prop_cells() in every instantiation I don't know. Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> Link: https://patch.msgid.link/20251219121811.390988-1-linux@rasmusvillemoes.dk [robh: Drop the commit msg comment that >9 doesn't work as it would] Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2025-12-19 13:18:11 +01:00
of: Move OF property and graph API from base.c to property.c base.c contains both core OF functions and increasingly other functionality such as accessing properties and graphs, including convenience functions. In the near future this would also include OF specific implementation of the fwnode property and graph APIs. Create driver/of/property.c to contain procedures for accessing and interpreting device tree properties. The procedures are moved from drivers/of/base.c, with no changes other than copying only the includes required by the moved procedures. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rob Herring <robh@kernel.org>
2017-05-24 17:53:53 +03:00
device property: Convert device_{dma_supported,get_dma_attr} to fwnode Make the device_dma_supported and device_get_dma_attr functions to use the fwnode ops, and move the implementation to ACPI and OF frameworks. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Acked-by: Rob Herring <robh@kernel.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-03-31 15:54:47 +03:00
of: Move OF property and graph API from base.c to property.c base.c contains both core OF functions and increasingly other functionality such as accessing properties and graphs, including convenience functions. In the near future this would also include OF specific implementation of the fwnode property and graph APIs. Create driver/of/property.c to contain procedures for accessing and interpreting device tree properties. The procedures are moved from drivers/of/base.c, with no changes other than copying only the includes required by the moved procedures. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rob Herring <robh@kernel.org>
2017-05-24 17:53:53 +03:00
of: property: Add fw_devlink support for interrupts This allows fw_devlink to create device links between consumers of an interrupt and the supplier of the interrupt. Cc: Marc Zyngier <maz@kernel.org> Cc: Kevin Hilman <khilman@baylibre.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20210121225712.1118239-3-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-01-21 14:57:12 -08:00
of: Move OF property and graph API from base.c to property.c base.c contains both core OF functions and increasingly other functionality such as accessing properties and graphs, including convenience functions. In the near future this would also include OF specific implementation of the fwnode property and graph APIs. Create driver/of/property.c to contain procedures for accessing and interpreting device tree properties. The procedures are moved from drivers/of/base.c, with no changes other than copying only the includes required by the moved procedures. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rob Herring <robh@kernel.org>
2017-05-24 17:53:53 +03:00
of: property: Add functional dependency link from DT bindings Add device links after the devices are created (but before they are probed) by looking at common DT bindings like clocks and interconnects. Automatically adding device links for functional dependencies at the framework level provides the following benefits: - Optimizes device probe order and avoids the useless work of attempting probes of devices that will not probe successfully (because their suppliers aren't present or haven't probed yet). For example, in a commonly available mobile SoC, registering just one consumer device's driver at an initcall level earlier than the supplier device's driver causes 11 failed probe attempts before the consumer device probes successfully. This was with a kernel with all the drivers statically compiled in. This problem gets a lot worse if all the drivers are loaded as modules without direct symbol dependencies. - Supplier devices like clock providers, interconnect providers, etc need to keep the resources they provide active and at a particular state(s) during boot up even if their current set of consumers don't request the resource to be active. This is because the rest of the consumers might not have probed yet and turning off the resource before all the consumers have probed could lead to a hang or undesired user experience. Some frameworks (Eg: regulator) handle this today by turning off "unused" resources at late_initcall_sync and hoping all the devices have probed by then. This is not a valid assumption for systems with loadable modules. Other frameworks (Eg: clock) just don't handle this due to the lack of a clear signal for when they can turn off resources. This leads to downstream hacks to handle cases like this that can easily be solved in the upstream kernel. By linking devices before they are probed, we give suppliers a clear count of the number of dependent consumers. Once all of the consumers are active, the suppliers can turn off the unused resources without making assumptions about the number of consumers. By default we just add device-links to track "driver presence" (probe succeeded) of the supplier device. If any other functionality provided by device-links are needed, it is left to the consumer/supplier devices to change the link when they probe. kbuild test robot reported clang error about missing const Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20190904211126.47518-4-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-09-04 14:11:22 -07:00
of: Move OF property and graph API from base.c to property.c base.c contains both core OF functions and increasingly other functionality such as accessing properties and graphs, including convenience functions. In the near future this would also include OF specific implementation of the fwnode property and graph APIs. Create driver/of/property.c to contain procedures for accessing and interpreting device tree properties. The procedures are moved from drivers/of/base.c, with no changes other than copying only the includes required by the moved procedures. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rob Herring <robh@kernel.org>
2017-05-24 17:53:53 +03:00
of: Warn when of_property_read_bool() is used on non-boolean properties 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 <krzk@kernel.org> Link: https://lore.kernel.org/r/20250109-dt-type-warnings-v1-2-0150e32e716c@kernel.org Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2025-01-09 13:42:06 -06:00
of_graph: add of_graph_is_present() In some cases it's very useful to silently check whether port node exists at all in a device-tree before proceeding with parsing the graph. The DRM bridges code is one example of such case where absence of a graph in a device-tree is a legit condition. This patch adds of_graph_is_present() which returns true if given device-tree node contains OF graph port. Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200701074232.13632-2-digetx@gmail.com
2020-07-01 10:42:31 +03:00
of: Use scope based of_node_put() cleanups Use the relatively new scope based of_node_put() cleanup to simplify function exit handling. Doing so reduces the chances of forgetting an of_node_put() and simplifies error paths by avoiding the need for goto statements. Reviewed-by: Saravana Kannan <saravanak@google.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/20240409-dt-cleanup-free-v2-3-5b419a4af38d@kernel.org Signed-off-by: Rob Herring <robh@kernel.org>
2024-04-09 13:59:41 -05:00
of_graph: add of_graph_is_present() In some cases it's very useful to silently check whether port node exists at all in a device-tree before proceeding with parsing the graph. The DRM bridges code is one example of such case where absence of a graph in a device-tree is a legit condition. This patch adds of_graph_is_present() which returns true if given device-tree node contains OF graph port. Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200701074232.13632-2-digetx@gmail.com
2020-07-01 10:42:31 +03:00
of: Use scope based of_node_put() cleanups Use the relatively new scope based of_node_put() cleanup to simplify function exit handling. Doing so reduces the chances of forgetting an of_node_put() and simplifies error paths by avoiding the need for goto statements. Reviewed-by: Saravana Kannan <saravanak@google.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/20240409-dt-cleanup-free-v2-3-5b419a4af38d@kernel.org Signed-off-by: Rob Herring <robh@kernel.org>
2024-04-09 13:59:41 -05:00
of_graph: add of_graph_is_present() In some cases it's very useful to silently check whether port node exists at all in a device-tree before proceeding with parsing the graph. The DRM bridges code is one example of such case where absence of a graph in a device-tree is a legit condition. This patch adds of_graph_is_present() which returns true if given device-tree node contains OF graph port. Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200701074232.13632-2-digetx@gmail.com
2020-07-01 10:42:31 +03:00
of: Move OF property and graph API from base.c to property.c base.c contains both core OF functions and increasingly other functionality such as accessing properties and graphs, including convenience functions. In the near future this would also include OF specific implementation of the fwnode property and graph APIs. Create driver/of/property.c to contain procedures for accessing and interpreting device tree properties. The procedures are moved from drivers/of/base.c, with no changes other than copying only the includes required by the moved procedures. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rob Herring <robh@kernel.org>
2017-05-24 17:53:53 +03:00
of: Add missing 'Return' section in kerneldoc comments Many of the DT kerneldoc comments are lacking a 'Return' section. Let's add the section in cases we have a description of return values. There's still some cases where the return values are not documented. Cc: Frank Rowand <frowand.list@gmail.com> Cc: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Rob Herring <robh@kernel.org> Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/20210325164713.1296407-8-robh@kernel.org
2021-03-25 10:47:12 -06:00
of: property: fix typo in kernel-doc return description Fix the spelling of "success" in the return value description of the kernel-doc comment to improve documentation quality. Signed-off-by: Song Hongyi <szpcq123@gmail.com> Link: https://patch.msgid.link/20260225093814.124735-1-szpcq123@gmail.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2026-02-25 17:38:14 +08:00
of: Add missing 'Return' section in kerneldoc comments Many of the DT kerneldoc comments are lacking a 'Return' section. Let's add the section in cases we have a description of return values. There's still some cases where the return values are not documented. Cc: Frank Rowand <frowand.list@gmail.com> Cc: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Rob Herring <robh@kernel.org> Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/20210325164713.1296407-8-robh@kernel.org
2021-03-25 10:47:12 -06:00
of: Move OF property and graph API from base.c to property.c base.c contains both core OF functions and increasingly other functionality such as accessing properties and graphs, including convenience functions. In the near future this would also include OF specific implementation of the fwnode property and graph APIs. Create driver/of/property.c to contain procedures for accessing and interpreting device tree properties. The procedures are moved from drivers/of/base.c, with no changes other than copying only the includes required by the moved procedures. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rob Herring <robh@kernel.org>
2017-05-24 17:53:53 +03:00
of: Constify struct property pointers 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 <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20241010-dt-const-v1-4-87a51f558425@kernel.org Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2024-10-10 11:27:17 -05:00
of: Move OF property and graph API from base.c to property.c base.c contains both core OF functions and increasingly other functionality such as accessing properties and graphs, including convenience functions. In the near future this would also include OF specific implementation of the fwnode property and graph APIs. Create driver/of/property.c to contain procedures for accessing and interpreting device tree properties. The procedures are moved from drivers/of/base.c, with no changes other than copying only the includes required by the moved procedures. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rob Herring <robh@kernel.org>
2017-05-24 17:53:53 +03:00
of: Convert to using %pOF instead of full_name Now that we have a custom printf format specifier, convert users of full_name to use %pOF instead. This is preparation to remove storing of the full path string for each node. Signed-off-by: Rob Herring <robh@kernel.org>
2017-06-01 15:50:55 -05:00
of: Move OF property and graph API from base.c to property.c base.c contains both core OF functions and increasingly other functionality such as accessing properties and graphs, including convenience functions. In the near future this would also include OF specific implementation of the fwnode property and graph APIs. Create driver/of/property.c to contain procedures for accessing and interpreting device tree properties. The procedures are moved from drivers/of/base.c, with no changes other than copying only the includes required by the moved procedures. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rob Herring <robh@kernel.org>
2017-05-24 17:53:53 +03:00
of: Add missing 'Return' section in kerneldoc comments Many of the DT kerneldoc comments are lacking a 'Return' section. Let's add the section in cases we have a description of return values. There's still some cases where the return values are not documented. Cc: Frank Rowand <frowand.list@gmail.com> Cc: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Rob Herring <robh@kernel.org> Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/20210325164713.1296407-8-robh@kernel.org
2021-03-25 10:47:12 -06:00
of: Move OF property and graph API from base.c to property.c base.c contains both core OF functions and increasingly other functionality such as accessing properties and graphs, including convenience functions. In the near future this would also include OF specific implementation of the fwnode property and graph APIs. Create driver/of/property.c to contain procedures for accessing and interpreting device tree properties. The procedures are moved from drivers/of/base.c, with no changes other than copying only the includes required by the moved procedures. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rob Herring <robh@kernel.org>
2017-05-24 17:53:53 +03:00
of: Constify struct property pointers 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 <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20241010-dt-const-v1-4-87a51f558425@kernel.org Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2024-10-10 11:27:17 -05:00
of: Move OF property and graph API from base.c to property.c base.c contains both core OF functions and increasingly other functionality such as accessing properties and graphs, including convenience functions. In the near future this would also include OF specific implementation of the fwnode property and graph APIs. Create driver/of/property.c to contain procedures for accessing and interpreting device tree properties. The procedures are moved from drivers/of/base.c, with no changes other than copying only the includes required by the moved procedures. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rob Herring <robh@kernel.org>
2017-05-24 17:53:53 +03:00
of: base: Add of_property_read_u8_index 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 <srinivas.kandagatla@oss.qualcomm.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Tested-by: Alexey Klimov <alexey.klimov@linaro.org> # sm8550 Link: https://patch.msgid.link/20250912083225.228778-2-srinivas.kandagatla@oss.qualcomm.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-09-12 09:32:19 +01:00
of: Add of_property_read_u16_index 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 <ernest.vanhoecke@toradex.com> Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20250319142059.46692-2-francesco@dolcini.it Signed-off-by: Mark Brown <broonie@kernel.org>
2025-03-19 15:20:55 +01:00
of: Move OF property and graph API from base.c to property.c base.c contains both core OF functions and increasingly other functionality such as accessing properties and graphs, including convenience functions. In the near future this would also include OF specific implementation of the fwnode property and graph APIs. Create driver/of/property.c to contain procedures for accessing and interpreting device tree properties. The procedures are moved from drivers/of/base.c, with no changes other than copying only the includes required by the moved procedures. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rob Herring <robh@kernel.org>
2017-05-24 17:53:53 +03:00
of: Add missing 'Return' section in kerneldoc comments Many of the DT kerneldoc comments are lacking a 'Return' section. Let's add the section in cases we have a description of return values. There's still some cases where the return values are not documented. Cc: Frank Rowand <frowand.list@gmail.com> Cc: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Rob Herring <robh@kernel.org> Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/20210325164713.1296407-8-robh@kernel.org
2021-03-25 10:47:12 -06:00
of: Move OF property and graph API from base.c to property.c base.c contains both core OF functions and increasingly other functionality such as accessing properties and graphs, including convenience functions. In the near future this would also include OF specific implementation of the fwnode property and graph APIs. Create driver/of/property.c to contain procedures for accessing and interpreting device tree properties. The procedures are moved from drivers/of/base.c, with no changes other than copying only the includes required by the moved procedures. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rob Herring <robh@kernel.org>
2017-05-24 17:53:53 +03:00
of: Add missing 'Return' section in kerneldoc comments Many of the DT kerneldoc comments are lacking a 'Return' section. Let's add the section in cases we have a description of return values. There's still some cases where the return values are not documented. Cc: Frank Rowand <frowand.list@gmail.com> Cc: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Rob Herring <robh@kernel.org> Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/20210325164713.1296407-8-robh@kernel.org
2021-03-25 10:47:12 -06:00
of: Move OF property and graph API from base.c to property.c base.c contains both core OF functions and increasingly other functionality such as accessing properties and graphs, including convenience functions. In the near future this would also include OF specific implementation of the fwnode property and graph APIs. Create driver/of/property.c to contain procedures for accessing and interpreting device tree properties. The procedures are moved from drivers/of/base.c, with no changes other than copying only the includes required by the moved procedures. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rob Herring <robh@kernel.org>
2017-05-24 17:53:53 +03:00
of: property: Fix documentation for out values Property fetching functions which return number of successfully fetched properties should not state that out-values are only modified if 0 is returned. Fix this. Also, "pointer to return value" is slightly suboptimal phrase as "return value" commonly refers to value function returns (not via arguments). Rather use "pointer to found values". Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Reviewed-by: Frank Rowand <frowand.list@gmail.com> Signed-off-by: Rob Herring <robh@kernel.org>
2019-11-13 08:43:38 +02:00
of: Move OF property and graph API from base.c to property.c base.c contains both core OF functions and increasingly other functionality such as accessing properties and graphs, including convenience functions. In the near future this would also include OF specific implementation of the fwnode property and graph APIs. Create driver/of/property.c to contain procedures for accessing and interpreting device tree properties. The procedures are moved from drivers/of/base.c, with no changes other than copying only the includes required by the moved procedures. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rob Herring <robh@kernel.org>
2017-05-24 17:53:53 +03:00
of: Add missing 'Return' section in kerneldoc comments Many of the DT kerneldoc comments are lacking a 'Return' section. Let's add the section in cases we have a description of return values. There's still some cases where the return values are not documented. Cc: Frank Rowand <frowand.list@gmail.com> Cc: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Rob Herring <robh@kernel.org> Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/20210325164713.1296407-8-robh@kernel.org
2021-03-25 10:47:12 -06:00
of: Move OF property and graph API from base.c to property.c base.c contains both core OF functions and increasingly other functionality such as accessing properties and graphs, including convenience functions. In the near future this would also include OF specific implementation of the fwnode property and graph APIs. Create driver/of/property.c to contain procedures for accessing and interpreting device tree properties. The procedures are moved from drivers/of/base.c, with no changes other than copying only the includes required by the moved procedures. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rob Herring <robh@kernel.org>
2017-05-24 17:53:53 +03:00
of: Add missing 'Return' section in kerneldoc comments Many of the DT kerneldoc comments are lacking a 'Return' section. Let's add the section in cases we have a description of return values. There's still some cases where the return values are not documented. Cc: Frank Rowand <frowand.list@gmail.com> Cc: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Rob Herring <robh@kernel.org> Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/20210325164713.1296407-8-robh@kernel.org
2021-03-25 10:47:12 -06:00
of: Move OF property and graph API from base.c to property.c base.c contains both core OF functions and increasingly other functionality such as accessing properties and graphs, including convenience functions. In the near future this would also include OF specific implementation of the fwnode property and graph APIs. Create driver/of/property.c to contain procedures for accessing and interpreting device tree properties. The procedures are moved from drivers/of/base.c, with no changes other than copying only the includes required by the moved procedures. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rob Herring <robh@kernel.org>
2017-05-24 17:53:53 +03:00
of: property: Fix documentation for out values Property fetching functions which return number of successfully fetched properties should not state that out-values are only modified if 0 is returned. Fix this. Also, "pointer to return value" is slightly suboptimal phrase as "return value" commonly refers to value function returns (not via arguments). Rather use "pointer to found values". Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Reviewed-by: Frank Rowand <frowand.list@gmail.com> Signed-off-by: Rob Herring <robh@kernel.org>
2019-11-13 08:43:38 +02:00
of: Move OF property and graph API from base.c to property.c base.c contains both core OF functions and increasingly other functionality such as accessing properties and graphs, including convenience functions. In the near future this would also include OF specific implementation of the fwnode property and graph APIs. Create driver/of/property.c to contain procedures for accessing and interpreting device tree properties. The procedures are moved from drivers/of/base.c, with no changes other than copying only the includes required by the moved procedures. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rob Herring <robh@kernel.org>
2017-05-24 17:53:53 +03:00
of: Add missing 'Return' section in kerneldoc comments Many of the DT kerneldoc comments are lacking a 'Return' section. Let's add the section in cases we have a description of return values. There's still some cases where the return values are not documented. Cc: Frank Rowand <frowand.list@gmail.com> Cc: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Rob Herring <robh@kernel.org> Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/20210325164713.1296407-8-robh@kernel.org
2021-03-25 10:47:12 -06:00
of: Move OF property and graph API from base.c to property.c base.c contains both core OF functions and increasingly other functionality such as accessing properties and graphs, including convenience functions. In the near future this would also include OF specific implementation of the fwnode property and graph APIs. Create driver/of/property.c to contain procedures for accessing and interpreting device tree properties. The procedures are moved from drivers/of/base.c, with no changes other than copying only the includes required by the moved procedures. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rob Herring <robh@kernel.org>
2017-05-24 17:53:53 +03:00
of: Add missing 'Return' section in kerneldoc comments Many of the DT kerneldoc comments are lacking a 'Return' section. Let's add the section in cases we have a description of return values. There's still some cases where the return values are not documented. Cc: Frank Rowand <frowand.list@gmail.com> Cc: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Rob Herring <robh@kernel.org> Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/20210325164713.1296407-8-robh@kernel.org
2021-03-25 10:47:12 -06:00
of: Move OF property and graph API from base.c to property.c base.c contains both core OF functions and increasingly other functionality such as accessing properties and graphs, including convenience functions. In the near future this would also include OF specific implementation of the fwnode property and graph APIs. Create driver/of/property.c to contain procedures for accessing and interpreting device tree properties. The procedures are moved from drivers/of/base.c, with no changes other than copying only the includes required by the moved procedures. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rob Herring <robh@kernel.org>
2017-05-24 17:53:53 +03:00
of: property: Fix documentation for out values Property fetching functions which return number of successfully fetched properties should not state that out-values are only modified if 0 is returned. Fix this. Also, "pointer to return value" is slightly suboptimal phrase as "return value" commonly refers to value function returns (not via arguments). Rather use "pointer to found values". Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Reviewed-by: Frank Rowand <frowand.list@gmail.com> Signed-off-by: Rob Herring <robh@kernel.org>
2019-11-13 08:43:38 +02:00
of: Move OF property and graph API from base.c to property.c base.c contains both core OF functions and increasingly other functionality such as accessing properties and graphs, including convenience functions. In the near future this would also include OF specific implementation of the fwnode property and graph APIs. Create driver/of/property.c to contain procedures for accessing and interpreting device tree properties. The procedures are moved from drivers/of/base.c, with no changes other than copying only the includes required by the moved procedures. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rob Herring <robh@kernel.org>
2017-05-24 17:53:53 +03:00
of: Add missing 'Return' section in kerneldoc comments Many of the DT kerneldoc comments are lacking a 'Return' section. Let's add the section in cases we have a description of return values. There's still some cases where the return values are not documented. Cc: Frank Rowand <frowand.list@gmail.com> Cc: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Rob Herring <robh@kernel.org> Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/20210325164713.1296407-8-robh@kernel.org
2021-03-25 10:47:12 -06:00
of: Move OF property and graph API from base.c to property.c base.c contains both core OF functions and increasingly other functionality such as accessing properties and graphs, including convenience functions. In the near future this would also include OF specific implementation of the fwnode property and graph APIs. Create driver/of/property.c to contain procedures for accessing and interpreting device tree properties. The procedures are moved from drivers/of/base.c, with no changes other than copying only the includes required by the moved procedures. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rob Herring <robh@kernel.org>
2017-05-24 17:53:53 +03:00
of: Add missing 'Return' section in kerneldoc comments Many of the DT kerneldoc comments are lacking a 'Return' section. Let's add the section in cases we have a description of return values. There's still some cases where the return values are not documented. Cc: Frank Rowand <frowand.list@gmail.com> Cc: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Rob Herring <robh@kernel.org> Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/20210325164713.1296407-8-robh@kernel.org
2021-03-25 10:47:12 -06:00
of: Move OF property and graph API from base.c to property.c base.c contains both core OF functions and increasingly other functionality such as accessing properties and graphs, including convenience functions. In the near future this would also include OF specific implementation of the fwnode property and graph APIs. Create driver/of/property.c to contain procedures for accessing and interpreting device tree properties. The procedures are moved from drivers/of/base.c, with no changes other than copying only the includes required by the moved procedures. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rob Herring <robh@kernel.org>
2017-05-24 17:53:53 +03:00
of: property: Fix documentation for out values Property fetching functions which return number of successfully fetched properties should not state that out-values are only modified if 0 is returned. Fix this. Also, "pointer to return value" is slightly suboptimal phrase as "return value" commonly refers to value function returns (not via arguments). Rather use "pointer to found values". Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Reviewed-by: Frank Rowand <frowand.list@gmail.com> Signed-off-by: Rob Herring <robh@kernel.org>
2019-11-13 08:43:38 +02:00
of: Move OF property and graph API from base.c to property.c base.c contains both core OF functions and increasingly other functionality such as accessing properties and graphs, including convenience functions. In the near future this would also include OF specific implementation of the fwnode property and graph APIs. Create driver/of/property.c to contain procedures for accessing and interpreting device tree properties. The procedures are moved from drivers/of/base.c, with no changes other than copying only the includes required by the moved procedures. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rob Herring <robh@kernel.org>
2017-05-24 17:53:53 +03:00
of: Add missing 'Return' section in kerneldoc comments Many of the DT kerneldoc comments are lacking a 'Return' section. Let's add the section in cases we have a description of return values. There's still some cases where the return values are not documented. Cc: Frank Rowand <frowand.list@gmail.com> Cc: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Rob Herring <robh@kernel.org> Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/20210325164713.1296407-8-robh@kernel.org
2021-03-25 10:47:12 -06:00
of: Move OF property and graph API from base.c to property.c base.c contains both core OF functions and increasingly other functionality such as accessing properties and graphs, including convenience functions. In the near future this would also include OF specific implementation of the fwnode property and graph APIs. Create driver/of/property.c to contain procedures for accessing and interpreting device tree properties. The procedures are moved from drivers/of/base.c, with no changes other than copying only the includes required by the moved procedures. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rob Herring <robh@kernel.org>
2017-05-24 17:53:53 +03:00
of: Add missing 'Return' section in kerneldoc comments Many of the DT kerneldoc comments are lacking a 'Return' section. Let's add the section in cases we have a description of return values. There's still some cases where the return values are not documented. Cc: Frank Rowand <frowand.list@gmail.com> Cc: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Rob Herring <robh@kernel.org> Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/20210325164713.1296407-8-robh@kernel.org
2021-03-25 10:47:12 -06:00
of: Move OF property and graph API from base.c to property.c base.c contains both core OF functions and increasingly other functionality such as accessing properties and graphs, including convenience functions. In the near future this would also include OF specific implementation of the fwnode property and graph APIs. Create driver/of/property.c to contain procedures for accessing and interpreting device tree properties. The procedures are moved from drivers/of/base.c, with no changes other than copying only the includes required by the moved procedures. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rob Herring <robh@kernel.org>
2017-05-24 17:53:53 +03:00
of: of_property_read_string return -ENODATA when !length When the length of the string is zero of_property_read_string should return -ENODATA according to the description of the function. However, of_property_read_string doesn't check prop->length. If prop->length is zero, return -ENODATA. Without this patch the following command in u-boot: fdt set /chosen/node property-name results in of_property_read_string returning -EILSEQ when attempting to read property-name. With this patch, it returns -ENODATA as expected. Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20220416003028.1315268-1-sstabellini@kernel.org
2022-04-15 17:30:28 -07:00
of: Move OF property and graph API from base.c to property.c base.c contains both core OF functions and increasingly other functionality such as accessing properties and graphs, including convenience functions. In the near future this would also include OF specific implementation of the fwnode property and graph APIs. Create driver/of/property.c to contain procedures for accessing and interpreting device tree properties. The procedures are moved from drivers/of/base.c, with no changes other than copying only the includes required by the moved procedures. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rob Herring <robh@kernel.org>
2017-05-24 17:53:53 +03:00
drivers: of: Fixed kernel doc warning property.c:1220 : Fixed excess struct member definition warning property.c:444 : Fixed missing a blank line after declarations Signed-off-by: Muzammil Ashraf <m.muzzammilashraf@gmail.com> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Tested-by: Randy Dunlap <rdunlap@infradead.org> Link: https://lore.kernel.org/r/20231219062317.17650-1-muzammil@dreambigsemi.com Signed-off-by: Rob Herring <robh@kernel.org>
2023-12-19 11:23:17 +05:00
of: Move OF property and graph API from base.c to property.c base.c contains both core OF functions and increasingly other functionality such as accessing properties and graphs, including convenience functions. In the near future this would also include OF specific implementation of the fwnode property and graph APIs. Create driver/of/property.c to contain procedures for accessing and interpreting device tree properties. The procedures are moved from drivers/of/base.c, with no changes other than copying only the includes required by the moved procedures. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rob Herring <robh@kernel.org>
2017-05-24 17:53:53 +03:00
of: of_property_read_string return -ENODATA when !length When the length of the string is zero of_property_read_string should return -ENODATA according to the description of the function. However, of_property_read_string doesn't check prop->length. If prop->length is zero, return -ENODATA. Without this patch the following command in u-boot: fdt set /chosen/node property-name results in of_property_read_string returning -EILSEQ when attempting to read property-name. With this patch, it returns -ENODATA as expected. Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20220416003028.1315268-1-sstabellini@kernel.org
2022-04-15 17:30:28 -07:00
of: Move OF property and graph API from base.c to property.c base.c contains both core OF functions and increasingly other functionality such as accessing properties and graphs, including convenience functions. In the near future this would also include OF specific implementation of the fwnode property and graph APIs. Create driver/of/property.c to contain procedures for accessing and interpreting device tree properties. The procedures are moved from drivers/of/base.c, with no changes other than copying only the includes required by the moved procedures. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rob Herring <robh@kernel.org>
2017-05-24 17:53:53 +03:00
drivers/of: Improve documentation for match_string 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à <mikisabate@gmail.com> Link: https://lore.kernel.org/r/20240911204938.9172-1-mikisabate@gmail.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2024-09-11 22:49:38 +02:00
of: Move OF property and graph API from base.c to property.c base.c contains both core OF functions and increasingly other functionality such as accessing properties and graphs, including convenience functions. In the near future this would also include OF specific implementation of the fwnode property and graph APIs. Create driver/of/property.c to contain procedures for accessing and interpreting device tree properties. The procedures are moved from drivers/of/base.c, with no changes other than copying only the includes required by the moved procedures. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rob Herring <robh@kernel.org>
2017-05-24 17:53:53 +03:00
drivers/of: Improve documentation for match_string 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à <mikisabate@gmail.com> Link: https://lore.kernel.org/r/20240911204938.9172-1-mikisabate@gmail.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2024-09-11 22:49:38 +02:00
of: Move OF property and graph API from base.c to property.c base.c contains both core OF functions and increasingly other functionality such as accessing properties and graphs, including convenience functions. In the near future this would also include OF specific implementation of the fwnode property and graph APIs. Create driver/of/property.c to contain procedures for accessing and interpreting device tree properties. The procedures are moved from drivers/of/base.c, with no changes other than copying only the includes required by the moved procedures. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rob Herring <robh@kernel.org>
2017-05-24 17:53:53 +03:00
drivers/of: Improve documentation for match_string 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à <mikisabate@gmail.com> Link: https://lore.kernel.org/r/20240911204938.9172-1-mikisabate@gmail.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2024-09-11 22:49:38 +02:00
of: Move OF property and graph API from base.c to property.c base.c contains both core OF functions and increasingly other functionality such as accessing properties and graphs, including convenience functions. In the near future this would also include OF specific implementation of the fwnode property and graph APIs. Create driver/of/property.c to contain procedures for accessing and interpreting device tree properties. The procedures are moved from drivers/of/base.c, with no changes other than copying only the includes required by the moved procedures. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rob Herring <robh@kernel.org>
2017-05-24 17:53:53 +03:00
of: Constify struct property pointers 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 <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20241010-dt-const-v1-4-87a51f558425@kernel.org Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2024-10-10 11:27:17 -05:00
of: Move OF property and graph API from base.c to property.c base.c contains both core OF functions and increasingly other functionality such as accessing properties and graphs, including convenience functions. In the near future this would also include OF specific implementation of the fwnode property and graph APIs. Create driver/of/property.c to contain procedures for accessing and interpreting device tree properties. The procedures are moved from drivers/of/base.c, with no changes other than copying only the includes required by the moved procedures. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rob Herring <robh@kernel.org>
2017-05-24 17:53:53 +03:00
of: Constify struct property pointers 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 <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20241010-dt-const-v1-4-87a51f558425@kernel.org Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2024-10-10 11:27:17 -05:00
of: Move OF property and graph API from base.c to property.c base.c contains both core OF functions and increasingly other functionality such as accessing properties and graphs, including convenience functions. In the near future this would also include OF specific implementation of the fwnode property and graph APIs. Create driver/of/property.c to contain procedures for accessing and interpreting device tree properties. The procedures are moved from drivers/of/base.c, with no changes other than copying only the includes required by the moved procedures. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rob Herring <robh@kernel.org>
2017-05-24 17:53:53 +03:00
drivers/of: validate live-tree string properties before string use `populate_properties()` stores live-tree property values as raw byte sequences plus a separate `length`. They are not globally guaranteed to be NUL-terminated. `of_prop_next_string()` iterates string-list properties by walking raw bytes, `__of_node_is_type()` checks `device_type`, `__of_device_is_status()` checks `status`, and `of_alias_from_compatible()` reads the first `compatible` entry. These paths must validate that the relevant string fits within the property bounds before they hand it to C string helpers. Validate these live-tree string properties within their declared bounds. In particular, make `of_prop_next_string()` reject malformed entries before returning them, keep the `device_type` check inside the existing no-lock helper path, and add unit coverage for malformed first and trailing string-list entries. Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> Link: https://patch.msgid.link/20260507081812.91838-1-pengpeng@iscas.ac.cn Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2026-05-07 16:18:10 +08:00
of: Move OF property and graph API from base.c to property.c base.c contains both core OF functions and increasingly other functionality such as accessing properties and graphs, including convenience functions. In the near future this would also include OF specific implementation of the fwnode property and graph APIs. Create driver/of/property.c to contain procedures for accessing and interpreting device tree properties. The procedures are moved from drivers/of/base.c, with no changes other than copying only the includes required by the moved procedures. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rob Herring <robh@kernel.org>
2017-05-24 17:53:53 +03:00
drivers/of: validate live-tree string properties before string use `populate_properties()` stores live-tree property values as raw byte sequences plus a separate `length`. They are not globally guaranteed to be NUL-terminated. `of_prop_next_string()` iterates string-list properties by walking raw bytes, `__of_node_is_type()` checks `device_type`, `__of_device_is_status()` checks `status`, and `of_alias_from_compatible()` reads the first `compatible` entry. These paths must validate that the relevant string fits within the property bounds before they hand it to C string helpers. Validate these live-tree string properties within their declared bounds. In particular, make `of_prop_next_string()` reject malformed entries before returning them, keep the `device_type` check inside the existing no-lock helper path, and add unit coverage for malformed first and trailing string-list entries. Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> Link: https://patch.msgid.link/20260507081812.91838-1-pengpeng@iscas.ac.cn Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2026-05-07 16:18:10 +08:00
of: Move OF property and graph API from base.c to property.c base.c contains both core OF functions and increasingly other functionality such as accessing properties and graphs, including convenience functions. In the near future this would also include OF specific implementation of the fwnode property and graph APIs. Create driver/of/property.c to contain procedures for accessing and interpreting device tree properties. The procedures are moved from drivers/of/base.c, with no changes other than copying only the includes required by the moved procedures. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rob Herring <robh@kernel.org>
2017-05-24 17:53:53 +03:00
drivers/of: validate live-tree string properties before string use `populate_properties()` stores live-tree property values as raw byte sequences plus a separate `length`. They are not globally guaranteed to be NUL-terminated. `of_prop_next_string()` iterates string-list properties by walking raw bytes, `__of_node_is_type()` checks `device_type`, `__of_device_is_status()` checks `status`, and `of_alias_from_compatible()` reads the first `compatible` entry. These paths must validate that the relevant string fits within the property bounds before they hand it to C string helpers. Validate these live-tree string properties within their declared bounds. In particular, make `of_prop_next_string()` reject malformed entries before returning them, keep the `device_type` check inside the existing no-lock helper path, and add unit coverage for malformed first and trailing string-list entries. Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> Link: https://patch.msgid.link/20260507081812.91838-1-pengpeng@iscas.ac.cn Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2026-05-07 16:18:10 +08:00
of: Move OF property and graph API from base.c to property.c base.c contains both core OF functions and increasingly other functionality such as accessing properties and graphs, including convenience functions. In the near future this would also include OF specific implementation of the fwnode property and graph APIs. Create driver/of/property.c to contain procedures for accessing and interpreting device tree properties. The procedures are moved from drivers/of/base.c, with no changes other than copying only the includes required by the moved procedures. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rob Herring <robh@kernel.org>
2017-05-24 17:53:53 +03:00
drivers/of: validate live-tree string properties before string use `populate_properties()` stores live-tree property values as raw byte sequences plus a separate `length`. They are not globally guaranteed to be NUL-terminated. `of_prop_next_string()` iterates string-list properties by walking raw bytes, `__of_node_is_type()` checks `device_type`, `__of_device_is_status()` checks `status`, and `of_alias_from_compatible()` reads the first `compatible` entry. These paths must validate that the relevant string fits within the property bounds before they hand it to C string helpers. Validate these live-tree string properties within their declared bounds. In particular, make `of_prop_next_string()` reject malformed entries before returning them, keep the `device_type` check inside the existing no-lock helper path, and add unit coverage for malformed first and trailing string-list entries. Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> Link: https://patch.msgid.link/20260507081812.91838-1-pengpeng@iscas.ac.cn Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2026-05-07 16:18:10 +08:00
of: Move OF property and graph API from base.c to property.c base.c contains both core OF functions and increasingly other functionality such as accessing properties and graphs, including convenience functions. In the near future this would also include OF specific implementation of the fwnode property and graph APIs. Create driver/of/property.c to contain procedures for accessing and interpreting device tree properties. The procedures are moved from drivers/of/base.c, with no changes other than copying only the includes required by the moved procedures. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rob Herring <robh@kernel.org>
2017-05-24 17:53:53 +03:00
of: property: Use scope based cleanup on port_node Use __free cleanup handler which ensures that the resource is freed when it goes out of scope, thus removing the need to manually clean it up using of_node_put. Suggested-by: Julia Lawall <julia.lawall@inria.fr> Signed-off-by: Shresth Prasad <shresthprasad7@gmail.com> Link: https://lore.kernel.org/r/20240428115226.41345-2-shresthprasad7@gmail.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2024-04-28 17:22:27 +05:30
of: Move OF property and graph API from base.c to property.c base.c contains both core OF functions and increasingly other functionality such as accessing properties and graphs, including convenience functions. In the near future this would also include OF specific implementation of the fwnode property and graph APIs. Create driver/of/property.c to contain procedures for accessing and interpreting device tree properties. The procedures are moved from drivers/of/base.c, with no changes other than copying only the includes required by the moved procedures. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rob Herring <robh@kernel.org>
2017-05-24 17:53:53 +03:00
of: Convert to using %pOF instead of full_name Now that we have a custom printf format specifier, convert users of full_name to use %pOF instead. This is preparation to remove storing of the full path string for each node. Signed-off-by: Rob Herring <robh@kernel.org>
2017-06-01 15:50:55 -05:00
of: Move OF property and graph API from base.c to property.c base.c contains both core OF functions and increasingly other functionality such as accessing properties and graphs, including convenience functions. In the near future this would also include OF specific implementation of the fwnode property and graph APIs. Create driver/of/property.c to contain procedures for accessing and interpreting device tree properties. The procedures are moved from drivers/of/base.c, with no changes other than copying only the includes required by the moved procedures. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rob Herring <robh@kernel.org>
2017-05-24 17:53:53 +03:00
of: Use scope based of_node_put() cleanups Use the relatively new scope based of_node_put() cleanup to simplify function exit handling. Doing so reduces the chances of forgetting an of_node_put() and simplifies error paths by avoiding the need for goto statements. Reviewed-by: Saravana Kannan <saravanak@google.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/20240409-dt-cleanup-free-v2-3-5b419a4af38d@kernel.org Signed-off-by: Rob Herring <robh@kernel.org>
2024-04-09 13:59:41 -05:00
of: Move OF property and graph API from base.c to property.c base.c contains both core OF functions and increasingly other functionality such as accessing properties and graphs, including convenience functions. In the near future this would also include OF specific implementation of the fwnode property and graph APIs. Create driver/of/property.c to contain procedures for accessing and interpreting device tree properties. The procedures are moved from drivers/of/base.c, with no changes other than copying only the includes required by the moved procedures. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rob Herring <robh@kernel.org>
2017-05-24 17:53:53 +03:00
of: Use scope based of_node_put() cleanups Use the relatively new scope based of_node_put() cleanup to simplify function exit handling. Doing so reduces the chances of forgetting an of_node_put() and simplifies error paths by avoiding the need for goto statements. Reviewed-by: Saravana Kannan <saravanak@google.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/20240409-dt-cleanup-free-v2-3-5b419a4af38d@kernel.org Signed-off-by: Rob Herring <robh@kernel.org>
2024-04-09 13:59:41 -05:00
of: Move OF property and graph API from base.c to property.c base.c contains both core OF functions and increasingly other functionality such as accessing properties and graphs, including convenience functions. In the near future this would also include OF specific implementation of the fwnode property and graph APIs. Create driver/of/property.c to contain procedures for accessing and interpreting device tree properties. The procedures are moved from drivers/of/base.c, with no changes other than copying only the includes required by the moved procedures. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rob Herring <robh@kernel.org>
2017-05-24 17:53:53 +03:00
of: Use of_node_name_eq for node name comparisons Convert string compares of DT node names to use of_node_name_eq helper instead. This removes direct access to the node name pointer. Cc: Frank Rowand <frowand.list@gmail.com> Cc: Pantelis Antoniou <pantelis.antoniou@konsulko.com> Cc: devicetree@vger.kernel.org Signed-off-by: Rob Herring <robh@kernel.org>
2018-08-27 08:37:06 -05:00
of: Move OF property and graph API from base.c to property.c base.c contains both core OF functions and increasingly other functionality such as accessing properties and graphs, including convenience functions. In the near future this would also include OF specific implementation of the fwnode property and graph APIs. Create driver/of/property.c to contain procedures for accessing and interpreting device tree properties. The procedures are moved from drivers/of/base.c, with no changes other than copying only the includes required by the moved procedures. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rob Herring <robh@kernel.org>
2017-05-24 17:53:53 +03:00
of: Use scope based of_node_put() cleanups Use the relatively new scope based of_node_put() cleanup to simplify function exit handling. Doing so reduces the chances of forgetting an of_node_put() and simplifies error paths by avoiding the need for goto statements. Reviewed-by: Saravana Kannan <saravanak@google.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/20240409-dt-cleanup-free-v2-3-5b419a4af38d@kernel.org Signed-off-by: Rob Herring <robh@kernel.org>
2024-04-09 13:59:41 -05:00
of: Move OF property and graph API from base.c to property.c base.c contains both core OF functions and increasingly other functionality such as accessing properties and graphs, including convenience functions. In the near future this would also include OF specific implementation of the fwnode property and graph APIs. Create driver/of/property.c to contain procedures for accessing and interpreting device tree properties. The procedures are moved from drivers/of/base.c, with no changes other than copying only the includes required by the moved procedures. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rob Herring <robh@kernel.org>
2017-05-24 17:53:53 +03:00
of: Use scope based of_node_put() cleanups Use the relatively new scope based of_node_put() cleanup to simplify function exit handling. Doing so reduces the chances of forgetting an of_node_put() and simplifies error paths by avoiding the need for goto statements. Reviewed-by: Saravana Kannan <saravanak@google.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/20240409-dt-cleanup-free-v2-3-5b419a4af38d@kernel.org Signed-off-by: Rob Herring <robh@kernel.org>
2024-04-09 13:59:41 -05:00
of: Move OF property and graph API from base.c to property.c base.c contains both core OF functions and increasingly other functionality such as accessing properties and graphs, including convenience functions. In the near future this would also include OF specific implementation of the fwnode property and graph APIs. Create driver/of/property.c to contain procedures for accessing and interpreting device tree properties. The procedures are moved from drivers/of/base.c, with no changes other than copying only the includes required by the moved procedures. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rob Herring <robh@kernel.org>
2017-05-24 17:53:53 +03:00
of: property: add of_graph_get_next_port() 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 <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87ldyeb5t9.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2024-10-24 02:20:02 +00:00
of: property: add of_graph_get_next_port_endpoint() 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 <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87jzdyb5t5.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2024-10-24 02:20:06 +00:00
of: Move OF property and graph API from base.c to property.c base.c contains both core OF functions and increasingly other functionality such as accessing properties and graphs, including convenience functions. In the near future this would also include OF specific implementation of the fwnode property and graph APIs. Create driver/of/property.c to contain procedures for accessing and interpreting device tree properties. The procedures are moved from drivers/of/base.c, with no changes other than copying only the includes required by the moved procedures. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rob Herring <robh@kernel.org>
2017-05-24 17:53:53 +03:00
of: property: use new of_graph functions Current of_graph_get_next_endpoint() can be replaced by using new of_graph_get_next_port(). Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87iktib5t0.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2024-10-24 02:20:11 +00:00
of: Move OF property and graph API from base.c to property.c base.c contains both core OF functions and increasingly other functionality such as accessing properties and graphs, including convenience functions. In the near future this would also include OF specific implementation of the fwnode property and graph APIs. Create driver/of/property.c to contain procedures for accessing and interpreting device tree properties. The procedures are moved from drivers/of/base.c, with no changes other than copying only the includes required by the moved procedures. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rob Herring <robh@kernel.org>
2017-05-24 17:53:53 +03:00
of: property: Make 'no port node found' output a debug message There are cases where an unavailable port is not an error, making this error message a false-positive. Since commit d56de8c9a17d8 ("usb: typec: tcpm: try to get role switch from tcpc fwnode") the role switch is tried on the port dev first and tcpc fwnode afterwards. If using the latter bindings getting from port dev fails every time. The kernel log is flooded with the messages like: OF: graph: no port node found in /soc@0/bus@42000000/i2c@42530000/usb-typec@50 Silence this message by making it a debug message. Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Link: https://lore.kernel.org/r/20240117083206.2901534-1-alexander.stein@ew.tq-group.com Signed-off-by: Rob Herring <robh@kernel.org>
2024-01-17 09:32:06 +01:00
of: Move OF property and graph API from base.c to property.c base.c contains both core OF functions and increasingly other functionality such as accessing properties and graphs, including convenience functions. In the near future this would also include OF specific implementation of the fwnode property and graph APIs. Create driver/of/property.c to contain procedures for accessing and interpreting device tree properties. The procedures are moved from drivers/of/base.c, with no changes other than copying only the includes required by the moved procedures. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rob Herring <robh@kernel.org>
2017-05-24 17:53:53 +03:00
of: Convert to using %pOF instead of full_name Now that we have a custom printf format specifier, convert users of full_name to use %pOF instead. This is preparation to remove storing of the full path string for each node. Signed-off-by: Rob Herring <robh@kernel.org>
2017-06-01 15:50:55 -05:00
of: Move OF property and graph API from base.c to property.c base.c contains both core OF functions and increasingly other functionality such as accessing properties and graphs, including convenience functions. In the near future this would also include OF specific implementation of the fwnode property and graph APIs. Create driver/of/property.c to contain procedures for accessing and interpreting device tree properties. The procedures are moved from drivers/of/base.c, with no changes other than copying only the includes required by the moved procedures. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rob Herring <robh@kernel.org>
2017-05-24 17:53:53 +03:00
of: property: use new of_graph functions Current of_graph_get_next_endpoint() can be replaced by using new of_graph_get_next_port(). Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87iktib5t0.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2024-10-24 02:20:11 +00:00
of: Move OF property and graph API from base.c to property.c base.c contains both core OF functions and increasingly other functionality such as accessing properties and graphs, including convenience functions. In the near future this would also include OF specific implementation of the fwnode property and graph APIs. Create driver/of/property.c to contain procedures for accessing and interpreting device tree properties. The procedures are moved from drivers/of/base.c, with no changes other than copying only the includes required by the moved procedures. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rob Herring <robh@kernel.org>
2017-05-24 17:53:53 +03:00
of: property: use new of_graph functions Current of_graph_get_next_endpoint() can be replaced by using new of_graph_get_next_port(). Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87iktib5t0.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2024-10-24 02:20:11 +00:00
of: Move OF property and graph API from base.c to property.c base.c contains both core OF functions and increasingly other functionality such as accessing properties and graphs, including convenience functions. In the near future this would also include OF specific implementation of the fwnode property and graph APIs. Create driver/of/property.c to contain procedures for accessing and interpreting device tree properties. The procedures are moved from drivers/of/base.c, with no changes other than copying only the includes required by the moved procedures. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rob Herring <robh@kernel.org>
2017-05-24 17:53:53 +03:00
of: property: Document that of_graph_get_endpoint_by_regs needs of_node_put The node returned by of_graph_get_endpoint_by_regs has a reference taken, and we need to put that reference back when done with the node. However, the documentation for that node doesn't mention it, so let's make sure it does. Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by: Rob Herring <robh@kernel.org>
2019-03-15 10:22:47 +01:00
of: Move OF property and graph API from base.c to property.c base.c contains both core OF functions and increasingly other functionality such as accessing properties and graphs, including convenience functions. In the near future this would also include OF specific implementation of the fwnode property and graph APIs. Create driver/of/property.c to contain procedures for accessing and interpreting device tree properties. The procedures are moved from drivers/of/base.c, with no changes other than copying only the includes required by the moved procedures. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rob Herring <robh@kernel.org>
2017-05-24 17:53:53 +03:00
Merge branch 'topic/of-graph-base' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound into dt/property-move OF graph changes for ALSA conflict with the move of graph functions into property.c.
2017-07-05 08:24:05 -05:00
device property: Fix usecount for of_graph_get_port_parent() Fix inconsistent use of of_graph_get_port_parent() where asoc_simple_card_parse_graph_dai() does of_node_get() before calling it while other callers do not. We can fix this by not trashing the node passed to of_graph_get_port_parent(). Let's also make sure the callers have correct refcounts and remove related incorrect of_node_put() calls for of_for_each_phandle as that's done by of_phandle_iterator_next() except when we break out of the loop early. Let's fix both issues with a single patch to avoid kobject refcounts getting messed up more if two patches are merged separately. Otherwise strange issues can happen caused by memory corruption caused by too many kobject_del() calls such as: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:747 ... (___might_sleep) (__mutex_lock) (mutex_lock_nested) (kernfs_remove) (kobject_del) (kobject_put) (of_get_next_parent) (of_graph_get_port_parent) (asoc_simple_card_parse_graph_dai [snd_soc_simple_card_utils]) (asoc_graph_card_probe [snd_soc_audio_graph_card]) Fixes: 0ef472a973eb ("of_graph: add of_graph_get_port_parent()") Fixes: 2692c1c63c29 ("ASoC: add audio-graph-card support") Fixes: 1689333f8311 ("ASoC: simple-card-utils: add asoc_simple_card_parse_graph_dai()") Signed-off-by: Tony Lindgren <tony@atomide.com> Reviewed-by: Rob Herring <robh@kernel.org> Tested-by: Antonio Borneo <borneo.antonio@gmail.com> Tested-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-07-28 01:23:15 -07:00
Merge branch 'topic/of-graph-base' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound into dt/property-move OF graph changes for ALSA conflict with the move of graph functions into property.c.
2017-07-05 08:24:05 -05:00
of: property: Add in-ports/out-ports support to of_graph_get_port_parent() Similar to the existing "ports" node name, coresight device tree bindings have added "in-ports" and "out-ports" as standard node names for a collection of ports. Add support for these name to of_graph_get_port_parent() so that remote-endpoint parsing can find the correct parent node for these coresight ports too. Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20240207011803.2637531-4-saravanak@google.com Signed-off-by: Rob Herring <robh@kernel.org>
2024-02-06 17:18:02 -08:00
Merge branch 'topic/of-graph-base' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound into dt/property-move OF graph changes for ALSA conflict with the move of graph functions into property.c.
2017-07-05 08:24:05 -05:00
of: Move OF property and graph API from base.c to property.c base.c contains both core OF functions and increasingly other functionality such as accessing properties and graphs, including convenience functions. In the near future this would also include OF specific implementation of the fwnode property and graph APIs. Create driver/of/property.c to contain procedures for accessing and interpreting device tree properties. The procedures are moved from drivers/of/base.c, with no changes other than copying only the includes required by the moved procedures. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rob Herring <robh@kernel.org>
2017-05-24 17:53:53 +03:00
of: property: Do some clean up with use of __free() __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 <zhangzekun11@huawei.com> Link: https://lore.kernel.org/r/20240830020626.115933-4-zhangzekun11@huawei.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2024-08-30 10:06:26 +08:00
of: Move OF property and graph API from base.c to property.c base.c contains both core OF functions and increasingly other functionality such as accessing properties and graphs, including convenience functions. In the near future this would also include OF specific implementation of the fwnode property and graph APIs. Create driver/of/property.c to contain procedures for accessing and interpreting device tree properties. The procedures are moved from drivers/of/base.c, with no changes other than copying only the includes required by the moved procedures. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rob Herring <robh@kernel.org>
2017-05-24 17:53:53 +03:00
of: property: Do some clean up with use of __free() __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 <zhangzekun11@huawei.com> Link: https://lore.kernel.org/r/20240830020626.115933-4-zhangzekun11@huawei.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2024-08-30 10:06:26 +08:00
of: Move OF property and graph API from base.c to property.c base.c contains both core OF functions and increasingly other functionality such as accessing properties and graphs, including convenience functions. In the near future this would also include OF specific implementation of the fwnode property and graph APIs. Create driver/of/property.c to contain procedures for accessing and interpreting device tree properties. The procedures are moved from drivers/of/base.c, with no changes other than copying only the includes required by the moved procedures. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rob Herring <robh@kernel.org>
2017-05-24 17:53:53 +03:00
of: Add missing 'Return' section in kerneldoc comments Many of the DT kerneldoc comments are lacking a 'Return' section. Let's add the section in cases we have a description of return values. There's still some cases where the return values are not documented. Cc: Frank Rowand <frowand.list@gmail.com> Cc: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Rob Herring <robh@kernel.org> Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/20210325164713.1296407-8-robh@kernel.org
2021-03-25 10:47:12 -06:00
of: Move OF property and graph API from base.c to property.c base.c contains both core OF functions and increasingly other functionality such as accessing properties and graphs, including convenience functions. In the near future this would also include OF specific implementation of the fwnode property and graph APIs. Create driver/of/property.c to contain procedures for accessing and interpreting device tree properties. The procedures are moved from drivers/of/base.c, with no changes other than copying only the includes required by the moved procedures. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rob Herring <robh@kernel.org>
2017-05-24 17:53:53 +03:00
Merge branch 'topic/of-graph-base' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound into dt/property-move OF graph changes for ALSA conflict with the move of graph functions into property.c.
2017-07-05 08:24:05 -05:00
of: Move OF property and graph API from base.c to property.c base.c contains both core OF functions and increasingly other functionality such as accessing properties and graphs, including convenience functions. In the near future this would also include OF specific implementation of the fwnode property and graph APIs. Create driver/of/property.c to contain procedures for accessing and interpreting device tree properties. The procedures are moved from drivers/of/base.c, with no changes other than copying only the includes required by the moved procedures. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rob Herring <robh@kernel.org>
2017-05-24 17:53:53 +03:00
of: property: add missing kerneldoc for of_graph_get_endpoint_count() of_graph_get_endpoint_count() doesn't have kerneldoc. Add it. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Link: https://lore.kernel.org/r/87r0hrcvzk.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Rob Herring <robh@kernel.org>
2024-02-05 05:37:19 +00:00
of: property: use unsigned int return on of_graph_get_endpoint_count() Because of of_graph_get_endpoint_count() doesn't report error, just return count of endpoint, the return type should be unsigned. Tidyup it. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Link: https://lore.kernel.org/r/87plxbcvzb.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Rob Herring <robh@kernel.org>
2024-02-05 05:37:28 +00:00
Merge branch 'topic/of-graph-base' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound into dt/property-move OF graph changes for ALSA conflict with the move of graph functions into property.c.
2017-07-05 08:24:05 -05:00
of: property: use unsigned int return on of_graph_get_endpoint_count() Because of of_graph_get_endpoint_count() doesn't report error, just return count of endpoint, the return type should be unsigned. Tidyup it. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Link: https://lore.kernel.org/r/87plxbcvzb.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Rob Herring <robh@kernel.org>
2024-02-05 05:37:28 +00:00
Merge branch 'topic/of-graph-base' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound into dt/property-move OF graph changes for ALSA conflict with the move of graph functions into property.c.
2017-07-05 08:24:05 -05:00
of: property: add of_graph_get_next_port() 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 <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87ldyeb5t9.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2024-10-24 02:20:02 +00:00
of: Move OF property and graph API from base.c to property.c base.c contains both core OF functions and increasingly other functionality such as accessing properties and graphs, including convenience functions. In the near future this would also include OF specific implementation of the fwnode property and graph APIs. Create driver/of/property.c to contain procedures for accessing and interpreting device tree properties. The procedures are moved from drivers/of/base.c, with no changes other than copying only the includes required by the moved procedures. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rob Herring <robh@kernel.org>
2017-05-24 17:53:53 +03:00
of: Add missing 'Return' section in kerneldoc comments Many of the DT kerneldoc comments are lacking a 'Return' section. Let's add the section in cases we have a description of return values. There's still some cases where the return values are not documented. Cc: Frank Rowand <frowand.list@gmail.com> Cc: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Rob Herring <robh@kernel.org> Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/20210325164713.1296407-8-robh@kernel.org
2021-03-25 10:47:12 -06:00
of: Move OF property and graph API from base.c to property.c base.c contains both core OF functions and increasingly other functionality such as accessing properties and graphs, including convenience functions. In the near future this would also include OF specific implementation of the fwnode property and graph APIs. Create driver/of/property.c to contain procedures for accessing and interpreting device tree properties. The procedures are moved from drivers/of/base.c, with no changes other than copying only the includes required by the moved procedures. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rob Herring <robh@kernel.org>
2017-05-24 17:53:53 +03:00
of: Convert to using %pOF instead of full_name Now that we have a custom printf format specifier, convert users of full_name to use %pOF instead. This is preparation to remove storing of the full path string for each node. Signed-off-by: Rob Herring <robh@kernel.org>
2017-06-01 15:50:55 -05:00
of: Move OF property and graph API from base.c to property.c base.c contains both core OF functions and increasingly other functionality such as accessing properties and graphs, including convenience functions. In the near future this would also include OF specific implementation of the fwnode property and graph APIs. Create driver/of/property.c to contain procedures for accessing and interpreting device tree properties. The procedures are moved from drivers/of/base.c, with no changes other than copying only the includes required by the moved procedures. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rob Herring <robh@kernel.org>
2017-05-24 17:53:53 +03:00
OF: properties: add missing of_node_put Add an of_node_put when the result of of_graph_get_remote_port_parent is not available. The semantic match that finds this problem is as follows (http://coccinelle.lip6.fr): // <smpl> @r exists@ local idexpression e; expression x; @@ e = of_graph_get_remote_port_parent(...); ... when != x = e when != true e == NULL when != of_node_put(e) when != of_fwnode_handle(e) ( return e; | *return ...; ) // </smpl> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> Cc: stable@vger.kernel.org Signed-off-by: Rob Herring <robh@kernel.org>
2019-01-13 10:44:50 +01:00
of: Move OF property and graph API from base.c to property.c base.c contains both core OF functions and increasingly other functionality such as accessing properties and graphs, including convenience functions. In the near future this would also include OF specific implementation of the fwnode property and graph APIs. Create driver/of/property.c to contain procedures for accessing and interpreting device tree properties. The procedures are moved from drivers/of/base.c, with no changes other than copying only the includes required by the moved procedures. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rob Herring <robh@kernel.org>
2017-05-24 17:53:53 +03:00
device property: Move FW type specific functionality to FW specific files The device and fwnode property API supports Devicetree, ACPI and pset properties. The implementation of this functionality for each firmware type was embedded in the fwnode property core. Move it out to firmware type specific locations, making it easier to maintain. Depends-on: ("of: Move OF property and graph API from base.c to property.c") Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-06 12:37:37 +03:00
device property: Make fwnode_handle_get() return the fwnode The fwnode_handle_get() function is used to obtain a reference to an fwnode. A common usage pattern for the OF equivalent of the function is: mynode = of_node_get(node); Similarly make fwnode_handle_get() return the fwnode to which the reference was obtained. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-09-19 12:39:11 +03:00
device property: Move FW type specific functionality to FW specific files The device and fwnode property API supports Devicetree, ACPI and pset properties. The implementation of this functionality for each firmware type was embedded in the fwnode property core. Move it out to firmware type specific locations, making it easier to maintain. Depends-on: ("of: Move OF property and graph API from base.c to property.c") Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-06 12:37:37 +03:00
device property: Make fwnode_handle_get() return the fwnode The fwnode_handle_get() function is used to obtain a reference to an fwnode. A common usage pattern for the OF equivalent of the function is: mynode = of_node_get(node); Similarly make fwnode_handle_get() return the fwnode to which the reference was obtained. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-09-19 12:39:11 +03:00
device property: Move FW type specific functionality to FW specific files The device and fwnode property API supports Devicetree, ACPI and pset properties. The implementation of this functionality for each firmware type was embedded in the fwnode property core. Move it out to firmware type specific locations, making it easier to maintain. Depends-on: ("of: Move OF property and graph API from base.c to property.c") Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-06 12:37:37 +03:00
device property: Constify fwnode property API Make fwnode arguments to the fwnode property API const. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-21 14:39:36 +03:00
device property: Introduce fwnode_device_is_available() Add fwnode_device_is_available() to tell whether the device corresponding to a certain fwnode_handle is available for use. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-06 12:37:39 +03:00
device property: Convert device_{dma_supported,get_dma_attr} to fwnode Make the device_dma_supported and device_get_dma_attr functions to use the fwnode ops, and move the implementation to ACPI and OF frameworks. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Acked-by: Rob Herring <robh@kernel.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-03-31 15:54:47 +03:00
device property: Constify fwnode property API Make fwnode arguments to the fwnode property API const. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-21 14:39:36 +03:00
device property: Move FW type specific functionality to FW specific files The device and fwnode property API supports Devicetree, ACPI and pset properties. The implementation of this functionality for each firmware type was embedded in the fwnode property core. Move it out to firmware type specific locations, making it easier to maintain. Depends-on: ("of: Move OF property and graph API from base.c to property.c") Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-06 12:37:37 +03:00
device property: Split property reading bool and presence test ops 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 <gregkh@linuxfoundation.org> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://lore.kernel.org/r/20250109-dt-type-warnings-v1-1-0150e32e716c@kernel.org Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2025-01-09 13:42:05 -06:00
device property: Move FW type specific functionality to FW specific files The device and fwnode property API supports Devicetree, ACPI and pset properties. The implementation of this functionality for each firmware type was embedded in the fwnode property core. Move it out to firmware type specific locations, making it easier to maintain. Depends-on: ("of: Move OF property and graph API from base.c to property.c") Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-06 12:37:37 +03:00
device property: Constify fwnode property API Make fwnode arguments to the fwnode property API const. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-21 14:39:36 +03:00
device property: Move FW type specific functionality to FW specific files The device and fwnode property API supports Devicetree, ACPI and pset properties. The implementation of this functionality for each firmware type was embedded in the fwnode property core. Move it out to firmware type specific locations, making it easier to maintain. Depends-on: ("of: Move OF property and graph API from base.c to property.c") Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-06 12:37:37 +03:00
device property: Constify fwnode property API Make fwnode arguments to the fwnode property API const. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-21 14:39:36 +03:00
device property: Move FW type specific functionality to FW specific files The device and fwnode property API supports Devicetree, ACPI and pset properties. The implementation of this functionality for each firmware type was embedded in the fwnode property core. Move it out to firmware type specific locations, making it easier to maintain. Depends-on: ("of: Move OF property and graph API from base.c to property.c") Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-06 12:37:37 +03:00
device property: Constify fwnode property API Make fwnode arguments to the fwnode property API const. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-21 14:39:36 +03:00
device property: Move FW type specific functionality to FW specific files The device and fwnode property API supports Devicetree, ACPI and pset properties. The implementation of this functionality for each firmware type was embedded in the fwnode property core. Move it out to firmware type specific locations, making it easier to maintain. Depends-on: ("of: Move OF property and graph API from base.c to property.c") Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-06 12:37:37 +03:00
device property: Constify fwnode property API Make fwnode arguments to the fwnode property API const. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-21 14:39:36 +03:00
device property: Move FW type specific functionality to FW specific files The device and fwnode property API supports Devicetree, ACPI and pset properties. The implementation of this functionality for each firmware type was embedded in the fwnode property core. Move it out to firmware type specific locations, making it easier to maintain. Depends-on: ("of: Move OF property and graph API from base.c to property.c") Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-06 12:37:37 +03:00
device property: Add fwnode_get_name for returning the name of a node The fwnode framework did not have means to obtain the name of a node. Add that now, in form of the fwnode_get_name() function and a corresponding get_name fwnode op. OF and ACPI support is included. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Acked-by: Rob Herring <robh@kernel.org> (for OF) Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-10-03 15:32:12 +03:00
device property: Add a function to obtain a node's prefix The prefix is used for printing purpose before a node, and it also works as a separator between two nodes. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Acked-by: Rob Herring <robh@kernel.org> (for OF) Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-10-03 15:32:13 +03:00
device property: Constify fwnode property API Make fwnode arguments to the fwnode property API const. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-21 14:39:36 +03:00
device property: Move FW type specific functionality to FW specific files The device and fwnode property API supports Devicetree, ACPI and pset properties. The implementation of this functionality for each firmware type was embedded in the fwnode property core. Move it out to firmware type specific locations, making it easier to maintain. Depends-on: ("of: Move OF property and graph API from base.c to property.c") Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-06 12:37:37 +03:00
device property: Constify fwnode property API Make fwnode arguments to the fwnode property API const. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-21 14:39:36 +03:00
device property: Move FW type specific functionality to FW specific files The device and fwnode property API supports Devicetree, ACPI and pset properties. The implementation of this functionality for each firmware type was embedded in the fwnode property core. Move it out to firmware type specific locations, making it easier to maintain. Depends-on: ("of: Move OF property and graph API from base.c to property.c") Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-06 12:37:37 +03:00
device property: Constify fwnode property API Make fwnode arguments to the fwnode property API const. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-21 14:39:36 +03:00
device property: Move FW type specific functionality to FW specific files The device and fwnode property API supports Devicetree, ACPI and pset properties. The implementation of this functionality for each firmware type was embedded in the fwnode property core. Move it out to firmware type specific locations, making it easier to maintain. Depends-on: ("of: Move OF property and graph API from base.c to property.c") Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-06 12:37:37 +03:00
device property: Constify fwnode property API Make fwnode arguments to the fwnode property API const. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-21 14:39:36 +03:00
device property: Move FW type specific functionality to FW specific files The device and fwnode property API supports Devicetree, ACPI and pset properties. The implementation of this functionality for each firmware type was embedded in the fwnode property core. Move it out to firmware type specific locations, making it easier to maintain. Depends-on: ("of: Move OF property and graph API from base.c to property.c") Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-06 12:37:37 +03:00
of: Use of_node_name_eq for node name comparisons Convert string compares of DT node names to use of_node_name_eq helper instead. This removes direct access to the node name pointer. Cc: Frank Rowand <frowand.list@gmail.com> Cc: Pantelis Antoniou <pantelis.antoniou@konsulko.com> Cc: devicetree@vger.kernel.org Signed-off-by: Rob Herring <robh@kernel.org>
2018-08-27 08:37:06 -05:00
device property: Move FW type specific functionality to FW specific files The device and fwnode property API supports Devicetree, ACPI and pset properties. The implementation of this functionality for each firmware type was embedded in the fwnode property core. Move it out to firmware type specific locations, making it easier to maintain. Depends-on: ("of: Move OF property and graph API from base.c to property.c") Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-06 12:37:37 +03:00
device property: Introduce fwnode_property_get_reference_args The new fwnode_property_get_reference_args() interface amends the fwnode property API with the functionality of both of_parse_phandle_with_args() and __acpi_node_get_property_reference(). The semantics is slightly different: the cells property is ignored on ACPI as the number of arguments can be explicitly obtained from the firmware interface. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-21 15:11:49 +03:00
of: property: Fix of_fwnode_get_reference_args() with negative index fwnode_property_get_reference_args() should return -ENOENT when an out of bound index is passed. An issue arised with the OF backend because the OF API use signed indexes while the fwnode API use unsigned ones. When an index value greater the INT_MAX was passed to the OF backend it got casted to a negative value and it returned -EINVAL instead of -ENOENT. This patch add a check to of_fwnode_get_reference_args() to catch negative index before they are passed to the OF API and return -ENOENT right away. This issue appeared when the following pattern was used in the LED subsystem: index = fwnode_property_match_string(fwnode, "led-names", name) led_node = fwnode_find_reference(fwnode, "leds", index); Unlike the same pattern with the OF API, this pattern implicitly cast the signed return value of fwnode_property_match_string() to an unsigned index leading to the above issue with the OF backend. It can be argued that the return value of fwnode_property_match_string() should be checked separately, but I think there is value in supporting such simple and straight to the point patterns. Link: https://lore.kernel.org/linux-leds/aimVRwJPhlGxsIUj@tom-desktop/T/#mc43cbf7e0599991b56dd0d9680714d28d145fbc8 Cc: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Alban Bedel <alban.bedel@lht.dlh.de> Link: https://patch.msgid.link/20260618152035.1600436-1-alban.bedel@lht.dlh.de Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2026-06-18 17:20:34 +02:00
device property: Introduce fwnode_property_get_reference_args The new fwnode_property_get_reference_args() interface amends the fwnode property API with the functionality of both of_parse_phandle_with_args() and __acpi_node_get_property_reference(). The semantics is slightly different: the cells property is ignored on ACPI as the number of arguments can be explicitly obtained from the firmware interface. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-21 15:11:49 +03:00
of: property: decrement node refcount in of_fwnode_get_reference_args() In of_fwnode_get_reference_args(), the refcount of of_args.np has been incremented in the case of successful return from of_parse_phandle_with_args() or of_parse_phandle_with_fixed_args(). Decrement the refcount if of_args is not returned to the caller of of_fwnode_get_reference_args(). Fixes: 3e3119d3088f ("device property: Introduce fwnode_property_get_reference_args") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Frank Rowand <frowand.list@gmail.com> Link: https://lore.kernel.org/r/20221121023209.3909759-1-yangyingliang@huawei.com Signed-off-by: Rob Herring <robh@kernel.org>
2022-11-21 10:32:09 +08:00
device property: Introduce fwnode_property_get_reference_args The new fwnode_property_get_reference_args() interface amends the fwnode property API with the functionality of both of_parse_phandle_with_args() and __acpi_node_get_property_reference(). The semantics is slightly different: the cells property is ignored on ACPI as the number of arguments can be explicitly obtained from the firmware interface. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-21 15:11:49 +03:00
of: property: decrement node refcount in of_fwnode_get_reference_args() In of_fwnode_get_reference_args(), the refcount of of_args.np has been incremented in the case of successful return from of_parse_phandle_with_args() or of_parse_phandle_with_fixed_args(). Decrement the refcount if of_args is not returned to the caller of of_fwnode_get_reference_args(). Fixes: 3e3119d3088f ("device property: Introduce fwnode_property_get_reference_args") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Frank Rowand <frowand.list@gmail.com> Link: https://lore.kernel.org/r/20221121023209.3909759-1-yangyingliang@huawei.com Signed-off-by: Rob Herring <robh@kernel.org>
2022-11-21 10:32:09 +08:00
device property: Introduce fwnode_property_get_reference_args The new fwnode_property_get_reference_args() interface amends the fwnode property API with the functionality of both of_parse_phandle_with_args() and __acpi_node_get_property_reference(). The semantics is slightly different: the cells property is ignored on ACPI as the number of arguments can be explicitly obtained from the firmware interface. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-21 15:11:49 +03:00
device property: Move fwnode graph ops to firmware specific locations Move firmware specific implementations of the fwnode graph operations to firmware specific locations. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-06 12:37:38 +03:00
device property: Constify fwnode property API Make fwnode arguments to the fwnode property API const. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-21 14:39:36 +03:00
device property: Move fwnode graph ops to firmware specific locations Move firmware specific implementations of the fwnode graph operations to firmware specific locations. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-06 12:37:38 +03:00
device property: Constify fwnode property API Make fwnode arguments to the fwnode property API const. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-21 14:39:36 +03:00
device property: Move fwnode graph ops to firmware specific locations Move firmware specific implementations of the fwnode graph operations to firmware specific locations. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-06 12:37:38 +03:00
device property: use of_graph_get_remote_endpoint() for of_fwnode Now, we can use of_graph_get_remote_endpoint(). Let's use it. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Rob Herring <robh@kernel.org>
2017-08-10 04:38:16 +00:00
device property: Move fwnode graph ops to firmware specific locations Move firmware specific implementations of the fwnode graph operations to firmware specific locations. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-06 12:37:38 +03:00
device property: preserve usecount for node passed to of_fwnode_graph_get_port_parent() Using CONFIG_OF_DYNAMIC=y uncovered an imbalance in the usecount of the node being passed to of_fwnode_graph_get_port_parent(). Preserve the usecount by using of_get_parent() instead of of_get_next_parent() which don't decrement the usecount of the node passed to it. Fixes: 3b27d00e7b6d7c88 ("device property: Move fwnode graph ops to firmware specific locations") Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rob Herring <robh@kernel.org>
2017-08-22 02:19:12 +02:00
device property: Move fwnode graph ops to firmware specific locations Move firmware specific implementations of the fwnode graph operations to firmware specific locations. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-06 12:37:38 +03:00
of: Use of_node_name_eq for node name comparisons Convert string compares of DT node names to use of_node_name_eq helper instead. This removes direct access to the node name pointer. Cc: Frank Rowand <frowand.list@gmail.com> Cc: Pantelis Antoniou <pantelis.antoniou@konsulko.com> Cc: devicetree@vger.kernel.org Signed-off-by: Rob Herring <robh@kernel.org>
2018-08-27 08:37:06 -05:00
device property: Move fwnode graph ops to firmware specific locations Move firmware specific implementations of the fwnode graph operations to firmware specific locations. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-06 12:37:38 +03:00
device property: Constify fwnode property API Make fwnode arguments to the fwnode property API const. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-21 14:39:36 +03:00
device property: Move fwnode graph ops to firmware specific locations Move firmware specific implementations of the fwnode graph operations to firmware specific locations. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-06 12:37:38 +03:00
device property: Constify fwnode property API Make fwnode arguments to the fwnode property API const. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-21 14:39:36 +03:00
of: Use scope based of_node_put() cleanups Use the relatively new scope based of_node_put() cleanup to simplify function exit handling. Doing so reduces the chances of forgetting an of_node_put() and simplifies error paths by avoiding the need for goto statements. Reviewed-by: Saravana Kannan <saravanak@google.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/20240409-dt-cleanup-free-v2-3-5b419a4af38d@kernel.org Signed-off-by: Rob Herring <robh@kernel.org>
2024-04-09 13:59:41 -05:00
device property: Move fwnode graph ops to firmware specific locations Move firmware specific implementations of the fwnode graph operations to firmware specific locations. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-06 12:37:38 +03:00
device property: Constify device_get_match_data() Constify device_get_match_data() as OF and ACPI variants return constant value. Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-02-09 17:38:36 +02:00
OF: properties: Implement get_match_data() callback Now that we have a get_match_data() callback as part of the firmware node, implement the OF specific piece for it. Signed-off-by: Sinan Kaya <okaya@codeaurora.org> Reviewed-by: Rob Herring <robh@kernel.org> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2017-12-13 02:20:50 -05:00
device property: Constify device_get_match_data() Constify device_get_match_data() as OF and ACPI variants return constant value. Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-02-09 17:38:36 +02:00
OF: properties: Implement get_match_data() callback Now that we have a get_match_data() callback as part of the firmware node, implement the OF specific piece for it. Signed-off-by: Sinan Kaya <okaya@codeaurora.org> Reviewed-by: Rob Herring <robh@kernel.org> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2017-12-13 02:20:50 -05:00
of: property: Simplify of_link_to_phandle() The driver core now: - Has the parent device of a supplier pick up the consumers if the supplier never has a device created for it. - Ignores a supplier if the supplier has no parent device and will never be probed by a driver And already prevents creating a device link with the consumer as a supplier of a parent. So, we no longer need to find the "compatible" node of the supplier or do any other checks in of_link_to_phandle(). We simply need to make sure that the supplier is available in DT. Signed-off-by: Saravana Kannan <saravanak@google.com> Tested-by: Colin Foster <colin.foster@in-advantage.com> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Tested-by: Douglas Anderson <dianders@chromium.org> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Luca Weiss <luca.weiss@fairphone.com> # qcom/sm7225-fairphone-fp4 Link: https://lore.kernel.org/r/20230207014207.1678715-10-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-02-06 17:42:01 -08:00
of: property: fw_devlink: Add support for "post-init-providers" property Add support for this property so that dependency cycles can be broken and fw_devlink can do better probe/suspend/resume ordering between devices in a dependency cycle. Signed-off-by: Saravana Kannan <saravanak@google.com> Acked-by: "Rafael J. Wysocki" <rafael@kernel.org> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20240305050458.1400667-4-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-03-04 21:04:56 -08:00
of: property: Add functional dependency link from DT bindings Add device links after the devices are created (but before they are probed) by looking at common DT bindings like clocks and interconnects. Automatically adding device links for functional dependencies at the framework level provides the following benefits: - Optimizes device probe order and avoids the useless work of attempting probes of devices that will not probe successfully (because their suppliers aren't present or haven't probed yet). For example, in a commonly available mobile SoC, registering just one consumer device's driver at an initcall level earlier than the supplier device's driver causes 11 failed probe attempts before the consumer device probes successfully. This was with a kernel with all the drivers statically compiled in. This problem gets a lot worse if all the drivers are loaded as modules without direct symbol dependencies. - Supplier devices like clock providers, interconnect providers, etc need to keep the resources they provide active and at a particular state(s) during boot up even if their current set of consumers don't request the resource to be active. This is because the rest of the consumers might not have probed yet and turning off the resource before all the consumers have probed could lead to a hang or undesired user experience. Some frameworks (Eg: regulator) handle this today by turning off "unused" resources at late_initcall_sync and hoping all the devices have probed by then. This is not a valid assumption for systems with loadable modules. Other frameworks (Eg: clock) just don't handle this due to the lack of a clear signal for when they can turn off resources. This leads to downstream hacks to handle cases like this that can easily be solved in the upstream kernel. By linking devices before they are probed, we give suppliers a clear count of the number of dependent consumers. Once all of the consumers are active, the suppliers can turn off the unused resources without making assumptions about the number of consumers. By default we just add device-links to track "driver presence" (probe succeeded) of the supplier device. If any other functionality provided by device-links are needed, it is left to the consumer/supplier devices to change the link when they probe. kbuild test robot reported clang error about missing const Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20190904211126.47518-4-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-09-04 14:11:22 -07:00
of: property: Do some clean up with use of __free() __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 <zhangzekun11@huawei.com> Link: https://lore.kernel.org/r/20240830020626.115933-4-zhangzekun11@huawei.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2024-08-30 10:06:26 +08:00
of: property: Add functional dependency link from DT bindings Add device links after the devices are created (but before they are probed) by looking at common DT bindings like clocks and interconnects. Automatically adding device links for functional dependencies at the framework level provides the following benefits: - Optimizes device probe order and avoids the useless work of attempting probes of devices that will not probe successfully (because their suppliers aren't present or haven't probed yet). For example, in a commonly available mobile SoC, registering just one consumer device's driver at an initcall level earlier than the supplier device's driver causes 11 failed probe attempts before the consumer device probes successfully. This was with a kernel with all the drivers statically compiled in. This problem gets a lot worse if all the drivers are loaded as modules without direct symbol dependencies. - Supplier devices like clock providers, interconnect providers, etc need to keep the resources they provide active and at a particular state(s) during boot up even if their current set of consumers don't request the resource to be active. This is because the rest of the consumers might not have probed yet and turning off the resource before all the consumers have probed could lead to a hang or undesired user experience. Some frameworks (Eg: regulator) handle this today by turning off "unused" resources at late_initcall_sync and hoping all the devices have probed by then. This is not a valid assumption for systems with loadable modules. Other frameworks (Eg: clock) just don't handle this due to the lack of a clear signal for when they can turn off resources. This leads to downstream hacks to handle cases like this that can easily be solved in the upstream kernel. By linking devices before they are probed, we give suppliers a clear count of the number of dependent consumers. Once all of the consumers are active, the suppliers can turn off the unused resources without making assumptions about the number of consumers. By default we just add device-links to track "driver presence" (probe succeeded) of the supplier device. If any other functionality provided by device-links are needed, it is left to the consumer/supplier devices to change the link when they probe. kbuild test robot reported clang error about missing const Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20190904211126.47518-4-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-09-04 14:11:22 -07:00
of: property: Simplify of_link_to_phandle() The driver core now: - Has the parent device of a supplier pick up the consumers if the supplier never has a device created for it. - Ignores a supplier if the supplier has no parent device and will never be probed by a driver And already prevents creating a device link with the consumer as a supplier of a parent. So, we no longer need to find the "compatible" node of the supplier or do any other checks in of_link_to_phandle(). We simply need to make sure that the supplier is available in DT. Signed-off-by: Saravana Kannan <saravanak@google.com> Tested-by: Colin Foster <colin.foster@in-advantage.com> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Tested-by: Douglas Anderson <dianders@chromium.org> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Luca Weiss <luca.weiss@fairphone.com> # qcom/sm7225-fairphone-fp4 Link: https://lore.kernel.org/r/20230207014207.1678715-10-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-02-06 17:42:01 -08:00
of: property: Do some clean up with use of __free() __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 <zhangzekun11@huawei.com> Link: https://lore.kernel.org/r/20240830020626.115933-4-zhangzekun11@huawei.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2024-08-30 10:06:26 +08:00
of: property: Simplify of_link_to_phandle() The driver core now: - Has the parent device of a supplier pick up the consumers if the supplier never has a device created for it. - Ignores a supplier if the supplier has no parent device and will never be probed by a driver And already prevents creating a device link with the consumer as a supplier of a parent. So, we no longer need to find the "compatible" node of the supplier or do any other checks in of_link_to_phandle(). We simply need to make sure that the supplier is available in DT. Signed-off-by: Saravana Kannan <saravanak@google.com> Tested-by: Colin Foster <colin.foster@in-advantage.com> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Tested-by: Douglas Anderson <dianders@chromium.org> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Luca Weiss <luca.weiss@fairphone.com> # qcom/sm7225-fairphone-fp4 Link: https://lore.kernel.org/r/20230207014207.1678715-10-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-02-06 17:42:01 -08:00
of: property: Add functional dependency link from DT bindings Add device links after the devices are created (but before they are probed) by looking at common DT bindings like clocks and interconnects. Automatically adding device links for functional dependencies at the framework level provides the following benefits: - Optimizes device probe order and avoids the useless work of attempting probes of devices that will not probe successfully (because their suppliers aren't present or haven't probed yet). For example, in a commonly available mobile SoC, registering just one consumer device's driver at an initcall level earlier than the supplier device's driver causes 11 failed probe attempts before the consumer device probes successfully. This was with a kernel with all the drivers statically compiled in. This problem gets a lot worse if all the drivers are loaded as modules without direct symbol dependencies. - Supplier devices like clock providers, interconnect providers, etc need to keep the resources they provide active and at a particular state(s) during boot up even if their current set of consumers don't request the resource to be active. This is because the rest of the consumers might not have probed yet and turning off the resource before all the consumers have probed could lead to a hang or undesired user experience. Some frameworks (Eg: regulator) handle this today by turning off "unused" resources at late_initcall_sync and hoping all the devices have probed by then. This is not a valid assumption for systems with loadable modules. Other frameworks (Eg: clock) just don't handle this due to the lack of a clear signal for when they can turn off resources. This leads to downstream hacks to handle cases like this that can easily be solved in the upstream kernel. By linking devices before they are probed, we give suppliers a clear count of the number of dependent consumers. Once all of the consumers are active, the suppliers can turn off the unused resources without making assumptions about the number of consumers. By default we just add device-links to track "driver presence" (probe succeeded) of the supplier device. If any other functionality provided by device-links are needed, it is left to the consumer/supplier devices to change the link when they probe. kbuild test robot reported clang error about missing const Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20190904211126.47518-4-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-09-04 14:11:22 -07:00
of: property: Do some clean up with use of __free() __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 <zhangzekun11@huawei.com> Link: https://lore.kernel.org/r/20240830020626.115933-4-zhangzekun11@huawei.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2024-08-30 10:06:26 +08:00
of: property: Simplify of_link_to_phandle() The driver core now: - Has the parent device of a supplier pick up the consumers if the supplier never has a device created for it. - Ignores a supplier if the supplier has no parent device and will never be probed by a driver And already prevents creating a device link with the consumer as a supplier of a parent. So, we no longer need to find the "compatible" node of the supplier or do any other checks in of_link_to_phandle(). We simply need to make sure that the supplier is available in DT. Signed-off-by: Saravana Kannan <saravanak@google.com> Tested-by: Colin Foster <colin.foster@in-advantage.com> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Tested-by: Douglas Anderson <dianders@chromium.org> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Luca Weiss <luca.weiss@fairphone.com> # qcom/sm7225-fairphone-fp4 Link: https://lore.kernel.org/r/20230207014207.1678715-10-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-02-06 17:42:01 -08:00
of: property: Update implementation of add_links() to create fwnode links The semantics of add_links() has changed from creating device link between devices to creating fwnode links between fwnodes. So, update the implementation of add_links() to match the new semantics. Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20201121020232.908850-15-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-20 18:02:29 -08:00
of: property: Simplify of_link_to_phandle() The driver core now: - Has the parent device of a supplier pick up the consumers if the supplier never has a device created for it. - Ignores a supplier if the supplier has no parent device and will never be probed by a driver And already prevents creating a device link with the consumer as a supplier of a parent. So, we no longer need to find the "compatible" node of the supplier or do any other checks in of_link_to_phandle(). We simply need to make sure that the supplier is available in DT. Signed-off-by: Saravana Kannan <saravanak@google.com> Tested-by: Colin Foster <colin.foster@in-advantage.com> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Tested-by: Douglas Anderson <dianders@chromium.org> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Luca Weiss <luca.weiss@fairphone.com> # qcom/sm7225-fairphone-fp4 Link: https://lore.kernel.org/r/20230207014207.1678715-10-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-02-06 17:42:01 -08:00
of: property: Minor style clean up of of_link_to_phandle() Adding a debug log instead of silently ignoring a phandle for an early device. Also, return the right error code instead of 0 even though the actual execution flow won't change. Signed-off-by: Saravana Kannan <saravanak@google.com> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20191105065000.50407-2-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-11-04 22:49:58 -08:00
of: property: Update implementation of add_links() to create fwnode links The semantics of add_links() has changed from creating device link between devices to creating fwnode links between fwnodes. So, update the implementation of add_links() to match the new semantics. Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20201121020232.908850-15-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-20 18:02:29 -08:00
of: property: fw_devlink: Add support for "post-init-providers" property Add support for this property so that dependency cycles can be broken and fw_devlink can do better probe/suspend/resume ordering between devices in a dependency cycle. Signed-off-by: Saravana Kannan <saravanak@google.com> Acked-by: "Rafael J. Wysocki" <rafael@kernel.org> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20240305050458.1400667-4-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-03-04 21:04:56 -08:00
of: property: Add functional dependency link from DT bindings Add device links after the devices are created (but before they are probed) by looking at common DT bindings like clocks and interconnects. Automatically adding device links for functional dependencies at the framework level provides the following benefits: - Optimizes device probe order and avoids the useless work of attempting probes of devices that will not probe successfully (because their suppliers aren't present or haven't probed yet). For example, in a commonly available mobile SoC, registering just one consumer device's driver at an initcall level earlier than the supplier device's driver causes 11 failed probe attempts before the consumer device probes successfully. This was with a kernel with all the drivers statically compiled in. This problem gets a lot worse if all the drivers are loaded as modules without direct symbol dependencies. - Supplier devices like clock providers, interconnect providers, etc need to keep the resources they provide active and at a particular state(s) during boot up even if their current set of consumers don't request the resource to be active. This is because the rest of the consumers might not have probed yet and turning off the resource before all the consumers have probed could lead to a hang or undesired user experience. Some frameworks (Eg: regulator) handle this today by turning off "unused" resources at late_initcall_sync and hoping all the devices have probed by then. This is not a valid assumption for systems with loadable modules. Other frameworks (Eg: clock) just don't handle this due to the lack of a clear signal for when they can turn off resources. This leads to downstream hacks to handle cases like this that can easily be solved in the upstream kernel. By linking devices before they are probed, we give suppliers a clear count of the number of dependent consumers. Once all of the consumers are active, the suppliers can turn off the unused resources without making assumptions about the number of consumers. By default we just add device-links to track "driver presence" (probe succeeded) of the supplier device. If any other functionality provided by device-links are needed, it is left to the consumer/supplier devices to change the link when they probe. kbuild test robot reported clang error about missing const Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20190904211126.47518-4-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-09-04 14:11:22 -07:00
of: property: make #.*-cells optional for simple props Sometimes, future bindings for phandles will get additional arguments. Thus the target node of the phandle will need a new #.*-cells property. To be backwards compatible, this needs to be optional. Prepare the DEFINE_SIMPLE_PROPS() to handle the cells name as optional. Signed-off-by: Michael Walle <michael@walle.cc> Tested-by: Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230206134356.839737-11-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-02-06 13:43:44 +00:00
of: property: Add functional dependency link from DT bindings Add device links after the devices are created (but before they are probed) by looking at common DT bindings like clocks and interconnects. Automatically adding device links for functional dependencies at the framework level provides the following benefits: - Optimizes device probe order and avoids the useless work of attempting probes of devices that will not probe successfully (because their suppliers aren't present or haven't probed yet). For example, in a commonly available mobile SoC, registering just one consumer device's driver at an initcall level earlier than the supplier device's driver causes 11 failed probe attempts before the consumer device probes successfully. This was with a kernel with all the drivers statically compiled in. This problem gets a lot worse if all the drivers are loaded as modules without direct symbol dependencies. - Supplier devices like clock providers, interconnect providers, etc need to keep the resources they provide active and at a particular state(s) during boot up even if their current set of consumers don't request the resource to be active. This is because the rest of the consumers might not have probed yet and turning off the resource before all the consumers have probed could lead to a hang or undesired user experience. Some frameworks (Eg: regulator) handle this today by turning off "unused" resources at late_initcall_sync and hoping all the devices have probed by then. This is not a valid assumption for systems with loadable modules. Other frameworks (Eg: clock) just don't handle this due to the lack of a clear signal for when they can turn off resources. This leads to downstream hacks to handle cases like this that can easily be solved in the upstream kernel. By linking devices before they are probed, we give suppliers a clear count of the number of dependent consumers. Once all of the consumers are active, the suppliers can turn off the unused resources without making assumptions about the number of consumers. By default we just add device-links to track "driver presence" (probe succeeded) of the supplier device. If any other functionality provided by device-links are needed, it is left to the consumer/supplier devices to change the link when they probe. kbuild test robot reported clang error about missing const Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20190904211126.47518-4-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-09-04 14:11:22 -07:00
of: property: Make it easy to add device links from DT properties Add a DEFINE_SIMPLE_PROP macro to make it easy to add support for simple properties with fixed names that just list phandles and phandle args. Add a DEFINE_SUFFIX_PROP macro to make it easy to add support for properties with fixes suffix that just list phandles and phandle args. Signed-off-by: Saravana Kannan <saravanak@google.com> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20191105065000.50407-3-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-11-04 22:49:59 -08:00
of: property: Add functional dependency link from DT bindings Add device links after the devices are created (but before they are probed) by looking at common DT bindings like clocks and interconnects. Automatically adding device links for functional dependencies at the framework level provides the following benefits: - Optimizes device probe order and avoids the useless work of attempting probes of devices that will not probe successfully (because their suppliers aren't present or haven't probed yet). For example, in a commonly available mobile SoC, registering just one consumer device's driver at an initcall level earlier than the supplier device's driver causes 11 failed probe attempts before the consumer device probes successfully. This was with a kernel with all the drivers statically compiled in. This problem gets a lot worse if all the drivers are loaded as modules without direct symbol dependencies. - Supplier devices like clock providers, interconnect providers, etc need to keep the resources they provide active and at a particular state(s) during boot up even if their current set of consumers don't request the resource to be active. This is because the rest of the consumers might not have probed yet and turning off the resource before all the consumers have probed could lead to a hang or undesired user experience. Some frameworks (Eg: regulator) handle this today by turning off "unused" resources at late_initcall_sync and hoping all the devices have probed by then. This is not a valid assumption for systems with loadable modules. Other frameworks (Eg: clock) just don't handle this due to the lack of a clear signal for when they can turn off resources. This leads to downstream hacks to handle cases like this that can easily be solved in the upstream kernel. By linking devices before they are probed, we give suppliers a clear count of the number of dependent consumers. Once all of the consumers are active, the suppliers can turn off the unused resources without making assumptions about the number of consumers. By default we just add device-links to track "driver presence" (probe succeeded) of the supplier device. If any other functionality provided by device-links are needed, it is left to the consumer/supplier devices to change the link when they probe. kbuild test robot reported clang error about missing const Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20190904211126.47518-4-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-09-04 14:11:22 -07:00
of: property: Make it easy to add device links from DT properties Add a DEFINE_SIMPLE_PROP macro to make it easy to add support for simple properties with fixed names that just list phandles and phandle args. Add a DEFINE_SUFFIX_PROP macro to make it easy to add support for properties with fixes suffix that just list phandles and phandle args. Signed-off-by: Saravana Kannan <saravanak@google.com> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20191105065000.50407-3-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-11-04 22:49:59 -08:00
of: property: Add functional dependency link from DT bindings Add device links after the devices are created (but before they are probed) by looking at common DT bindings like clocks and interconnects. Automatically adding device links for functional dependencies at the framework level provides the following benefits: - Optimizes device probe order and avoids the useless work of attempting probes of devices that will not probe successfully (because their suppliers aren't present or haven't probed yet). For example, in a commonly available mobile SoC, registering just one consumer device's driver at an initcall level earlier than the supplier device's driver causes 11 failed probe attempts before the consumer device probes successfully. This was with a kernel with all the drivers statically compiled in. This problem gets a lot worse if all the drivers are loaded as modules without direct symbol dependencies. - Supplier devices like clock providers, interconnect providers, etc need to keep the resources they provide active and at a particular state(s) during boot up even if their current set of consumers don't request the resource to be active. This is because the rest of the consumers might not have probed yet and turning off the resource before all the consumers have probed could lead to a hang or undesired user experience. Some frameworks (Eg: regulator) handle this today by turning off "unused" resources at late_initcall_sync and hoping all the devices have probed by then. This is not a valid assumption for systems with loadable modules. Other frameworks (Eg: clock) just don't handle this due to the lack of a clear signal for when they can turn off resources. This leads to downstream hacks to handle cases like this that can easily be solved in the upstream kernel. By linking devices before they are probed, we give suppliers a clear count of the number of dependent consumers. Once all of the consumers are active, the suppliers can turn off the unused resources without making assumptions about the number of consumers. By default we just add device-links to track "driver presence" (probe succeeded) of the supplier device. If any other functionality provided by device-links are needed, it is left to the consumer/supplier devices to change the link when they probe. kbuild test robot reported clang error about missing const Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20190904211126.47518-4-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-09-04 14:11:22 -07:00
of: property: Make it easy to add device links from DT properties Add a DEFINE_SIMPLE_PROP macro to make it easy to add support for simple properties with fixed names that just list phandles and phandle args. Add a DEFINE_SUFFIX_PROP macro to make it easy to add support for properties with fixes suffix that just list phandles and phandle args. Signed-off-by: Saravana Kannan <saravanak@google.com> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20191105065000.50407-3-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-11-04 22:49:59 -08:00
of: replace strcmp_suffix() with strends() string.h now provides strends() which fulfills the same role as the locally implemented strcmp_suffix(). Use it in of/property.c. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://patch.msgid.link/20251217134308.33839-1-bartosz.golaszewski@oss.qualcomm.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2025-12-17 14:43:08 +01:00
of: property: Add functional dependency link from DT bindings Add device links after the devices are created (but before they are probed) by looking at common DT bindings like clocks and interconnects. Automatically adding device links for functional dependencies at the framework level provides the following benefits: - Optimizes device probe order and avoids the useless work of attempting probes of devices that will not probe successfully (because their suppliers aren't present or haven't probed yet). For example, in a commonly available mobile SoC, registering just one consumer device's driver at an initcall level earlier than the supplier device's driver causes 11 failed probe attempts before the consumer device probes successfully. This was with a kernel with all the drivers statically compiled in. This problem gets a lot worse if all the drivers are loaded as modules without direct symbol dependencies. - Supplier devices like clock providers, interconnect providers, etc need to keep the resources they provide active and at a particular state(s) during boot up even if their current set of consumers don't request the resource to be active. This is because the rest of the consumers might not have probed yet and turning off the resource before all the consumers have probed could lead to a hang or undesired user experience. Some frameworks (Eg: regulator) handle this today by turning off "unused" resources at late_initcall_sync and hoping all the devices have probed by then. This is not a valid assumption for systems with loadable modules. Other frameworks (Eg: clock) just don't handle this due to the lack of a clear signal for when they can turn off resources. This leads to downstream hacks to handle cases like this that can easily be solved in the upstream kernel. By linking devices before they are probed, we give suppliers a clear count of the number of dependent consumers. Once all of the consumers are active, the suppliers can turn off the unused resources without making assumptions about the number of consumers. By default we just add device-links to track "driver presence" (probe succeeded) of the supplier device. If any other functionality provided by device-links are needed, it is left to the consumer/supplier devices to change the link when they probe. kbuild test robot reported clang error about missing const Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20190904211126.47518-4-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-09-04 14:11:22 -07:00
of: property: Make it easy to add device links from DT properties Add a DEFINE_SIMPLE_PROP macro to make it easy to add support for simple properties with fixed names that just list phandles and phandle args. Add a DEFINE_SUFFIX_PROP macro to make it easy to add support for properties with fixes suffix that just list phandles and phandle args. Signed-off-by: Saravana Kannan <saravanak@google.com> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20191105065000.50407-3-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-11-04 22:49:59 -08:00
of: property: Add functional dependency link from DT bindings Add device links after the devices are created (but before they are probed) by looking at common DT bindings like clocks and interconnects. Automatically adding device links for functional dependencies at the framework level provides the following benefits: - Optimizes device probe order and avoids the useless work of attempting probes of devices that will not probe successfully (because their suppliers aren't present or haven't probed yet). For example, in a commonly available mobile SoC, registering just one consumer device's driver at an initcall level earlier than the supplier device's driver causes 11 failed probe attempts before the consumer device probes successfully. This was with a kernel with all the drivers statically compiled in. This problem gets a lot worse if all the drivers are loaded as modules without direct symbol dependencies. - Supplier devices like clock providers, interconnect providers, etc need to keep the resources they provide active and at a particular state(s) during boot up even if their current set of consumers don't request the resource to be active. This is because the rest of the consumers might not have probed yet and turning off the resource before all the consumers have probed could lead to a hang or undesired user experience. Some frameworks (Eg: regulator) handle this today by turning off "unused" resources at late_initcall_sync and hoping all the devices have probed by then. This is not a valid assumption for systems with loadable modules. Other frameworks (Eg: clock) just don't handle this due to the lack of a clear signal for when they can turn off resources. This leads to downstream hacks to handle cases like this that can easily be solved in the upstream kernel. By linking devices before they are probed, we give suppliers a clear count of the number of dependent consumers. Once all of the consumers are active, the suppliers can turn off the unused resources without making assumptions about the number of consumers. By default we just add device-links to track "driver presence" (probe succeeded) of the supplier device. If any other functionality provided by device-links are needed, it is left to the consumer/supplier devices to change the link when they probe. kbuild test robot reported clang error about missing const Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20190904211126.47518-4-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-09-04 14:11:22 -07:00
drivers: of: Fixed kernel doc warning property.c:1220 : Fixed excess struct member definition warning property.c:444 : Fixed missing a blank line after declarations Signed-off-by: Muzammil Ashraf <m.muzzammilashraf@gmail.com> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Tested-by: Randy Dunlap <rdunlap@infradead.org> Link: https://lore.kernel.org/r/20231219062317.17650-1-muzammil@dreambigsemi.com Signed-off-by: Rob Herring <robh@kernel.org>
2023-12-19 11:23:17 +05:00
of: property: Add functional dependency link from DT bindings Add device links after the devices are created (but before they are probed) by looking at common DT bindings like clocks and interconnects. Automatically adding device links for functional dependencies at the framework level provides the following benefits: - Optimizes device probe order and avoids the useless work of attempting probes of devices that will not probe successfully (because their suppliers aren't present or haven't probed yet). For example, in a commonly available mobile SoC, registering just one consumer device's driver at an initcall level earlier than the supplier device's driver causes 11 failed probe attempts before the consumer device probes successfully. This was with a kernel with all the drivers statically compiled in. This problem gets a lot worse if all the drivers are loaded as modules without direct symbol dependencies. - Supplier devices like clock providers, interconnect providers, etc need to keep the resources they provide active and at a particular state(s) during boot up even if their current set of consumers don't request the resource to be active. This is because the rest of the consumers might not have probed yet and turning off the resource before all the consumers have probed could lead to a hang or undesired user experience. Some frameworks (Eg: regulator) handle this today by turning off "unused" resources at late_initcall_sync and hoping all the devices have probed by then. This is not a valid assumption for systems with loadable modules. Other frameworks (Eg: clock) just don't handle this due to the lack of a clear signal for when they can turn off resources. This leads to downstream hacks to handle cases like this that can easily be solved in the upstream kernel. By linking devices before they are probed, we give suppliers a clear count of the number of dependent consumers. Once all of the consumers are active, the suppliers can turn off the unused resources without making assumptions about the number of consumers. By default we just add device-links to track "driver presence" (probe succeeded) of the supplier device. If any other functionality provided by device-links are needed, it is left to the consumer/supplier devices to change the link when they probe. kbuild test robot reported clang error about missing const Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20190904211126.47518-4-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-09-04 14:11:22 -07:00
of: property: Improve finding the consumer of a remote-endpoint property We have a more accurate function to find the right consumer of a remote-endpoint property instead of searching for a parent with compatible string property. So, use that instead. While at it, make the code to find the consumer a bit more flexible and based on the property being parsed. Fixes: f7514a663016 ("of: property: fw_devlink: Add support for remote-endpoint") Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20240207011803.2637531-2-saravanak@google.com Signed-off-by: Rob Herring <robh@kernel.org>
2024-02-06 17:18:00 -08:00
of: property: Provide missing member description and remove excess param Fixes the following W=1 kernel build warning(s): drivers/of/property.c:1239: warning: Function parameter or member 'optional' not described in 'supplier_bindings' drivers/of/property.c:1366: warning: Excess function parameter 'dev' description in 'of_link_property' Cc: Rob Herring <robh+dt@kernel.org> Cc: Frank Rowand <frowand.list@gmail.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: devicetree@vger.kernel.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20210318104036.3175910-6-lee.jones@linaro.org
2021-03-18 10:40:31 +00:00
of: property: fw_devlink: Add support for "post-init-providers" property Add support for this property so that dependency cycles can be broken and fw_devlink can do better probe/suspend/resume ordering between devices in a dependency cycle. Signed-off-by: Saravana Kannan <saravanak@google.com> Acked-by: "Rafael J. Wysocki" <rafael@kernel.org> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20240305050458.1400667-4-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-03-04 21:04:56 -08:00
of: property: Add functional dependency link from DT bindings Add device links after the devices are created (but before they are probed) by looking at common DT bindings like clocks and interconnects. Automatically adding device links for functional dependencies at the framework level provides the following benefits: - Optimizes device probe order and avoids the useless work of attempting probes of devices that will not probe successfully (because their suppliers aren't present or haven't probed yet). For example, in a commonly available mobile SoC, registering just one consumer device's driver at an initcall level earlier than the supplier device's driver causes 11 failed probe attempts before the consumer device probes successfully. This was with a kernel with all the drivers statically compiled in. This problem gets a lot worse if all the drivers are loaded as modules without direct symbol dependencies. - Supplier devices like clock providers, interconnect providers, etc need to keep the resources they provide active and at a particular state(s) during boot up even if their current set of consumers don't request the resource to be active. This is because the rest of the consumers might not have probed yet and turning off the resource before all the consumers have probed could lead to a hang or undesired user experience. Some frameworks (Eg: regulator) handle this today by turning off "unused" resources at late_initcall_sync and hoping all the devices have probed by then. This is not a valid assumption for systems with loadable modules. Other frameworks (Eg: clock) just don't handle this due to the lack of a clear signal for when they can turn off resources. This leads to downstream hacks to handle cases like this that can easily be solved in the upstream kernel. By linking devices before they are probed, we give suppliers a clear count of the number of dependent consumers. Once all of the consumers are active, the suppliers can turn off the unused resources without making assumptions about the number of consumers. By default we just add device-links to track "driver presence" (probe succeeded) of the supplier device. If any other functionality provided by device-links are needed, it is left to the consumer/supplier devices to change the link when they probe. kbuild test robot reported clang error about missing const Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20190904211126.47518-4-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-09-04 14:11:22 -07:00
of: property: Improve finding the consumer of a remote-endpoint property We have a more accurate function to find the right consumer of a remote-endpoint property instead of searching for a parent with compatible string property. So, use that instead. While at it, make the code to find the consumer a bit more flexible and based on the property being parsed. Fixes: f7514a663016 ("of: property: fw_devlink: Add support for remote-endpoint") Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20240207011803.2637531-2-saravanak@google.com Signed-off-by: Rob Herring <robh@kernel.org>
2024-02-06 17:18:00 -08:00
of: property: Add fw_devlink support for optional properties Not all DT bindings are mandatory bindings. Add support for optional DT bindings and mark iommus, iommu-map, dmas as optional DT bindings. Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20210205222644.2357303-5-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-02-05 14:26:40 -08:00
of: property: fw_devlink: Add support for "post-init-providers" property Add support for this property so that dependency cycles can be broken and fw_devlink can do better probe/suspend/resume ordering between devices in a dependency cycle. Signed-off-by: Saravana Kannan <saravanak@google.com> Acked-by: "Rafael J. Wysocki" <rafael@kernel.org> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20240305050458.1400667-4-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-03-04 21:04:56 -08:00
of: property: Add functional dependency link from DT bindings Add device links after the devices are created (but before they are probed) by looking at common DT bindings like clocks and interconnects. Automatically adding device links for functional dependencies at the framework level provides the following benefits: - Optimizes device probe order and avoids the useless work of attempting probes of devices that will not probe successfully (because their suppliers aren't present or haven't probed yet). For example, in a commonly available mobile SoC, registering just one consumer device's driver at an initcall level earlier than the supplier device's driver causes 11 failed probe attempts before the consumer device probes successfully. This was with a kernel with all the drivers statically compiled in. This problem gets a lot worse if all the drivers are loaded as modules without direct symbol dependencies. - Supplier devices like clock providers, interconnect providers, etc need to keep the resources they provide active and at a particular state(s) during boot up even if their current set of consumers don't request the resource to be active. This is because the rest of the consumers might not have probed yet and turning off the resource before all the consumers have probed could lead to a hang or undesired user experience. Some frameworks (Eg: regulator) handle this today by turning off "unused" resources at late_initcall_sync and hoping all the devices have probed by then. This is not a valid assumption for systems with loadable modules. Other frameworks (Eg: clock) just don't handle this due to the lack of a clear signal for when they can turn off resources. This leads to downstream hacks to handle cases like this that can easily be solved in the upstream kernel. By linking devices before they are probed, we give suppliers a clear count of the number of dependent consumers. Once all of the consumers are active, the suppliers can turn off the unused resources without making assumptions about the number of consumers. By default we just add device-links to track "driver presence" (probe succeeded) of the supplier device. If any other functionality provided by device-links are needed, it is left to the consumer/supplier devices to change the link when they probe. kbuild test robot reported clang error about missing const Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20190904211126.47518-4-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-09-04 14:11:22 -07:00
of: property: Make it easy to add device links from DT properties Add a DEFINE_SIMPLE_PROP macro to make it easy to add support for simple properties with fixed names that just list phandles and phandle args. Add a DEFINE_SUFFIX_PROP macro to make it easy to add support for properties with fixes suffix that just list phandles and phandle args. Signed-off-by: Saravana Kannan <saravanak@google.com> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20191105065000.50407-3-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-11-04 22:49:59 -08:00
of: property: Add device link support for iommus, mboxes and io-channels Add support for creating device links out of more DT properties. Signed-off-by: Saravana Kannan <saravanak@google.com> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20191105065000.50407-4-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-11-04 22:50:00 -08:00
of: property: fix typo in io-channels The property is io-channels and not io-channel. This was effectively preventing the devlink creation. Fixes: 8e12257dead7 ("of: property: Add device link support for iommus, mboxes and io-channels") Cc: stable@vger.kernel.org Signed-off-by: Nuno Sa <nuno.sa@analog.com> Reviewed-by: Saravana Kannan <saravanak@google.com> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/20240123-iio-backend-v7-1-1bff236b8693@analog.com Signed-off-by: Rob Herring <robh@kernel.org>
2024-01-23 16:14:22 +01:00
of: property: add device link support for io-backends Add support for creating device links out of more DT properties. Signed-off-by: Olivier Moysan <olivier.moysan@foss.st.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Nuno Sa <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20240210-iio-backend-v11-3-f5242a5fb42a@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-02-10 21:57:15 +01:00
of: property: Add device link support for interrupt-parent, dmas and -gpio(s) Add support for creating device links out of more DT properties. Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Vinod Koul <vkoul@kernel.org> Signed-off-by: Saravana Kannan <saravanak@google.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20191120071302.227777-1-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-11-19 23:13:01 -08:00
of: property: Add device link support for power-domains and hwlocks Add support for creating device links out of more DT properties. To: lkml <linux-kernel@vger.kernel.org> To: John Stultz <john.stultz@linaro.org> To: Rob Herring <robh@kernel.org> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Cc: Kevin Hilman <khilman@kernel.org> Cc: Ulf Hansson <ulf.hansson@linaro.org> Cc: Pavel Machek <pavel@ucw.cz> Cc: Len Brown <len.brown@intel.com> Cc: Todd Kjos <tkjos@google.com> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Mark Brown <broonie@kernel.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: linux-pm@vger.kernel.org Signed-off-by: Saravana Kannan <saravanak@google.com> Tested-by: John Stultz <john.stultz@linaro.org> Signed-off-by: Rob Herring <robh@kernel.org>
2020-02-19 21:52:50 -08:00
of: property: Add device link support for extcon Add support for creating device links out of more DT properties. Cc: MyungJoo Ham <myungjoo.ham@samsung.com> Cc: Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by: Saravana Kannan <saravanak@google.com> Signed-off-by: Rob Herring <robh@kernel.org>
2020-04-01 15:52:03 -07:00
of: property: add #nvmem-cell-cells property Bindings describe the new '#nvmem-cell-cells' property. Now that the arguments count property is optional, we just add this property to the nvmem-cells. Signed-off-by: Michael Walle <michael@walle.cc> Tested-by: Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230206134356.839737-12-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-02-06 13:43:45 +00:00
of: property: Add device link support for multiple DT bindings Add support for creating device links out of the following DT bindings: - interrupts-extended - nvmem-cells - phys - wakeup-parent Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20200724234415.1651639-1-saravanak@google.com Signed-off-by: Rob Herring <robh@kernel.org>
2020-07-24 16:44:14 -07:00
of: property: fw_devlink: Add support for "resets" and "pwms" Allows better tracking of dependencies between devices. Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20210805223729.1196047-1-saravanak@google.com Signed-off-by: Rob Herring <robh@kernel.org>
2021-08-05 15:37:29 -07:00
of: property: fw_devlink: Add support for "leds" and "backlight" Allows tracking dependencies between leds/backlights devices and their consumers. Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20210814023132.2729731-2-saravanak@google.com Signed-off-by: Rob Herring <robh@kernel.org>
2021-08-13 19:31:30 -07:00
of: property: fw_devlink: Add a devlink for panel followers Inform fw_devlink of the fact that a panel follower (like a touchscreen) is effectively a consumer of the panel from the purposes of fw_devlink. NOTE: this patch isn't required for correctness but instead optimizes probe order / helps avoid deferrals. Acked-by: Rob Herring <robh@kernel.org> Reviewed-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230727101636.v4.4.Ibf8e1342b5b7906279db2365aca45e6253857bb3@changeid
2023-07-27 10:16:31 -07:00
of: property: Add fw_devlink support for msi-parent This allows fw_devlink to create device links between consumers of a MSI and the supplier of the MSI. Signed-off-by: Anup Patel <apatel@ventanamicro.com> Acked-by: Rob Herring <robh@kernel.org> Reviewed-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20231027154254.355853-3-apatel@ventanamicro.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-10-27 21:12:54 +05:30
of: property: fw_devlink: Add support for "post-init-providers" property Add support for this property so that dependency cycles can be broken and fw_devlink can do better probe/suspend/resume ordering between devices in a dependency cycle. Signed-off-by: Saravana Kannan <saravanak@google.com> Acked-by: "Rafael J. Wysocki" <rafael@kernel.org> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20240305050458.1400667-4-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-03-04 21:04:56 -08:00
of: property: fw_devlink: Add support for "access-controller" Allows tracking dependencies between devices and their access controller. Signed-off-by: Gatien Chevallier <gatien.chevallier@foss.st.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2024-01-05 14:03:57 +01:00
of: property: Add fw_devlink support for pse parent This allows fw_devlink to create device links between consumers of a PSE and the supplier of the PSE. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Kory Maincent <kory.maincent@bootlin.com> Link: https://lore.kernel.org/r/20240414-feature_poe-v8-2-e4bf1e860da5@bootlin.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-04-14 16:21:51 +02:00
of: property: fw_devlink: Add support for "power-supplies" binding Add support for parsing power-supplies binding so that fw_devlink can enforce the dependency. Signed-off-by: Saravana Kannan <saravanak@google.com> Cc: Sebastian Reichel <sre@kernel.org> Link: https://lore.kernel.org/r/20240417200738.1370896-1-saravanak@google.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2024-04-17 13:07:37 -07:00
of: property: fw_devlink: Add support for "mmc-pwrseq" Add support for parsing MMC power sequencing (pwrseq) binding so that fw_devlink can enforce the dependency. Signed-off-by: Francesco Valla <francesco@valla.it> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://patch.msgid.link/20260110-mmc-pwrseq-v1-1-73de9d6456f4@valla.it Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2026-01-10 16:27:59 +01:00
of: property: Make it easy to add device links from DT properties Add a DEFINE_SIMPLE_PROP macro to make it easy to add support for simple properties with fixed names that just list phandles and phandle args. Add a DEFINE_SUFFIX_PROP macro to make it easy to add support for properties with fixes suffix that just list phandles and phandle args. Signed-off-by: Saravana Kannan <saravanak@google.com> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20191105065000.50407-3-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-11-04 22:49:59 -08:00
of: property: Add device link support for interrupt-parent, dmas and -gpio(s) Add support for creating device links out of more DT properties. Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Vinod Koul <vkoul@kernel.org> Signed-off-by: Saravana Kannan <saravanak@google.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20191120071302.227777-1-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-11-19 23:13:01 -08:00
of: property: fw_devlink: do not link ".*,nr-gpios" [<vendor>,]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 "<vendor>," 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 <ilya.lipnitskiy@gmail.com> Cc: Saravana Kannan <saravanak@google.com> 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 <robh@kernel.org>
2021-04-05 15:25:40 -07:00
of: property: stop creating callback for each pinctrl-N property While not a lot in the grand scheme of things, this eliminates 8*2 pointless function calls for almost every property present in the device tree (the exception are the few properties that were already matched). It also seems to reduce .text by about 1.5K - why gcc decides to inline parse_prop_cells() in every instantiation I don't know. Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> Link: https://patch.msgid.link/20251219121811.390988-1-linux@rasmusvillemoes.dk [robh: Drop the commit msg comment that >9 doesn't work as it would] Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2025-12-19 13:18:11 +01:00
of: property: fw_devlink: do not link ".*,nr-gpios" [<vendor>,]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 "<vendor>," 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 <ilya.lipnitskiy@gmail.com> Cc: Saravana Kannan <saravanak@google.com> 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 <robh@kernel.org>
2021-04-05 15:25:40 -07:00
of: replace strcmp_suffix() with strends() string.h now provides strends() which fulfills the same role as the locally implemented strcmp_suffix(). Use it in of/property.c. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://patch.msgid.link/20251217134308.33839-1-bartosz.golaszewski@oss.qualcomm.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2025-12-17 14:43:08 +01:00
of: property: fw_devlink: do not link ".*,nr-gpios" [<vendor>,]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 "<vendor>," 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 <ilya.lipnitskiy@gmail.com> Cc: Saravana Kannan <saravanak@google.com> 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 <robh@kernel.org>
2021-04-05 15:25:40 -07:00
of: property: Make it easy to add device links from DT properties Add a DEFINE_SIMPLE_PROP macro to make it easy to add support for simple properties with fixed names that just list phandles and phandle args. Add a DEFINE_SUFFIX_PROP macro to make it easy to add support for properties with fixes suffix that just list phandles and phandle args. Signed-off-by: Saravana Kannan <saravanak@google.com> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20191105065000.50407-3-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-11-04 22:49:59 -08:00
of: property: Add device link support for "iommu-map" Commit 8e12257dead7 ("of: property: Add device link support for iommus, mboxes and io-channels") added device link support for IOMMU linkages described using the "iommus" property. For PCI devices, this property is not present and instead the "iommu-map" property is used on the host bridge node to map the endpoint RequesterIDs to their corresponding IOMMU instance. Add support for "iommu-map" to the device link supplier bindings so that probing of PCI devices can be deferred until after the IOMMU is available. Cc: Rob Herring <robh@kernel.org> Cc: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Will Deacon <will@kernel.org> Acked-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20191120190028.4722-1-will@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-11-20 19:00:28 +00:00
of: property: Add fw_devlink support for "gpio" and "gpios" binding To provide backward compatibility for boards that use deprecated DT bindings, we need to add fw_devlink support for "gpio" and "gpios". We also need to ignore these properties on nodes with "gpio-hog" property because their gpio[s] are all supplied by the parent node. Fixes: e590474768f1 ("driver core: Set fw_devlink=on by default") Cc: linux-tegra <linux-tegra@vger.kernel.org> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Tested-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20210121225712.1118239-2-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-01-21 14:57:11 -08:00
of: Use preferred of_property_read_* functions Replace instances of of_get_property/of_find_property() with appropriate typed of_property_read_*() functions. Link: https://lore.kernel.org/all/20230215215502.690716-1-robh@kernel.org/ Signed-off-by: Rob Herring <robh@kernel.org>
2023-02-08 17:13:23 -06:00
of: property: Add fw_devlink support for "gpio" and "gpios" binding To provide backward compatibility for boards that use deprecated DT bindings, we need to add fw_devlink support for "gpio" and "gpios". We also need to ignore these properties on nodes with "gpio-hog" property because their gpio[s] are all supplied by the parent node. Fixes: e590474768f1 ("driver core: Set fw_devlink=on by default") Cc: linux-tegra <linux-tegra@vger.kernel.org> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Tested-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20210121225712.1118239-2-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-01-21 14:57:11 -08:00
of: property: Add fw_devlink support for interrupts This allows fw_devlink to create device links between consumers of an interrupt and the supplier of the interrupt. Cc: Marc Zyngier <maz@kernel.org> Cc: Kevin Hilman <khilman@baylibre.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20210121225712.1118239-3-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-01-21 14:57:12 -08:00
of: property: Fix fw_devlink handling of interrupts/interrupts-extended Commit 4104ca776ba3 ("of: property: Add fw_devlink support for interrupts") was not taking interrupt-map into account. Fix that. Fixes: 4104ca776ba3 ("of: property: Add fw_devlink support for interrupts") Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20210209010439.3529036-1-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-02-08 17:04:38 -08:00
of: property: fw_devlink: Ignore interrupts property for some configs When CONFIG_OF_IRQ is not defined, it doesn't make sense to parse interrupts property. Also, parsing and tracking interrupts property breaks some PPC devices[1]. But none of the IRQ drivers in PPC seem ready to be converted to a proper platform (or any bus) driver. So, there's not much of a point in tracking the interrupts property for CONFIG_PPC. So, let's stop parsing interrupts for CONFIG_PPC. [1] - https://lore.kernel.org/lkml/20210213185422.GA195733@roeck-us.net/ Fixes: 4104ca776ba3 ("of: property: Add fw_devlink support for interrupts") Reported-by: Guenter Roeck <linux@roeck-us.net> Tested-by: Guenter Roeck <linux@roeck-us.net> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20210215224258.1231449-1-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-02-15 14:42:58 -08:00
of: property: Fix fw_devlink handling of interrupts/interrupts-extended Commit 4104ca776ba3 ("of: property: Add fw_devlink support for interrupts") was not taking interrupt-map into account. Fix that. Fixes: 4104ca776ba3 ("of: property: Add fw_devlink support for interrupts") Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20210209010439.3529036-1-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-02-08 17:04:38 -08:00
of: property: Add fw_devlink support for interrupts This allows fw_devlink to create device links between consumers of an interrupt and the supplier of the interrupt. Cc: Marc Zyngier <maz@kernel.org> Cc: Kevin Hilman <khilman@baylibre.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20210121225712.1118239-3-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-01-21 14:57:12 -08:00
of: property: Fix fw_devlink handling of interrupts/interrupts-extended Commit 4104ca776ba3 ("of: property: Add fw_devlink support for interrupts") was not taking interrupt-map into account. Fix that. Fixes: 4104ca776ba3 ("of: property: Add fw_devlink support for interrupts") Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20210209010439.3529036-1-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-02-08 17:04:38 -08:00
of: property: Add fw_devlink support for interrupts This allows fw_devlink to create device links between consumers of an interrupt and the supplier of the interrupt. Cc: Marc Zyngier <maz@kernel.org> Cc: Kevin Hilman <khilman@baylibre.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20210121225712.1118239-3-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-01-21 14:57:12 -08:00
of: property: Add fw_devlink support for interrupt-map property Some of the PCI host controllers (such as generic PCI host controller) use "interrupt-map" DT property to describe the mapping between PCI endpoints and PCI interrupt pins. This is the only case where the interrupts are not described in DT. Currently, there is no fw_devlink created based on "interrupt-map" DT property so interrupt controller is not guaranteed to be probed before the PCI host controller. This affects every platform where both PCI host controller and interrupt controllers are probed as regular platform devices. This creates fw_devlink between consumers (PCI host controller) and supplier (interrupt controller) based on "interrupt-map" DT property. Signed-off-by: Anup Patel <apatel@ventanamicro.com> Reviewed-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20240509120820.1430587-1-apatel@ventanamicro.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2024-05-09 17:38:20 +05:30
of: property: Fix fw_devlink handling of interrupt-map 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 <maz@kernel.org> Co-developed-by: Rob Herring (Arm) <robh@kernel.org> Cc: Saravana Kannan <saravanak@google.com> Tested-by: Marc Zyngier <maz@kernel.org> Tested-by: Anup Patel <apatel@ventanamicro.com> Link: https://lore.kernel.org/r/20240529-dt-interrupt-map-fix-v2-2-ef86dc5bcd2a@kernel.org Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2024-05-29 14:59:21 -05:00
of: property: Add fw_devlink support for interrupt-map property Some of the PCI host controllers (such as generic PCI host controller) use "interrupt-map" DT property to describe the mapping between PCI endpoints and PCI interrupt pins. This is the only case where the interrupts are not described in DT. Currently, there is no fw_devlink created based on "interrupt-map" DT property so interrupt controller is not guaranteed to be probed before the PCI host controller. This affects every platform where both PCI host controller and interrupt controllers are probed as regular platform devices. This creates fw_devlink between consumers (PCI host controller) and supplier (interrupt controller) based on "interrupt-map" DT property. Signed-off-by: Anup Patel <apatel@ventanamicro.com> Reviewed-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20240509120820.1430587-1-apatel@ventanamicro.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2024-05-09 17:38:20 +05:30
of: property: Fix fw_devlink handling of interrupt-map 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 <maz@kernel.org> Co-developed-by: Rob Herring (Arm) <robh@kernel.org> Cc: Saravana Kannan <saravanak@google.com> Tested-by: Marc Zyngier <maz@kernel.org> Tested-by: Anup Patel <apatel@ventanamicro.com> Link: https://lore.kernel.org/r/20240529-dt-interrupt-map-fix-v2-2-ef86dc5bcd2a@kernel.org Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2024-05-29 14:59:21 -05:00
of: property: Add fw_devlink support for interrupt-map property Some of the PCI host controllers (such as generic PCI host controller) use "interrupt-map" DT property to describe the mapping between PCI endpoints and PCI interrupt pins. This is the only case where the interrupts are not described in DT. Currently, there is no fw_devlink created based on "interrupt-map" DT property so interrupt controller is not guaranteed to be probed before the PCI host controller. This affects every platform where both PCI host controller and interrupt controllers are probed as regular platform devices. This creates fw_devlink between consumers (PCI host controller) and supplier (interrupt controller) based on "interrupt-map" DT property. Signed-off-by: Anup Patel <apatel@ventanamicro.com> Reviewed-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20240509120820.1430587-1-apatel@ventanamicro.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2024-05-09 17:38:20 +05:30
of: property: Fix fw_devlink handling of interrupt-map 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 <maz@kernel.org> Co-developed-by: Rob Herring (Arm) <robh@kernel.org> Cc: Saravana Kannan <saravanak@google.com> Tested-by: Marc Zyngier <maz@kernel.org> Tested-by: Anup Patel <apatel@ventanamicro.com> Link: https://lore.kernel.org/r/20240529-dt-interrupt-map-fix-v2-2-ef86dc5bcd2a@kernel.org Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2024-05-29 14:59:21 -05:00
of: property: Add fw_devlink support for interrupt-map property Some of the PCI host controllers (such as generic PCI host controller) use "interrupt-map" DT property to describe the mapping between PCI endpoints and PCI interrupt pins. This is the only case where the interrupts are not described in DT. Currently, there is no fw_devlink created based on "interrupt-map" DT property so interrupt controller is not guaranteed to be probed before the PCI host controller. This affects every platform where both PCI host controller and interrupt controllers are probed as regular platform devices. This creates fw_devlink between consumers (PCI host controller) and supplier (interrupt controller) based on "interrupt-map" DT property. Signed-off-by: Anup Patel <apatel@ventanamicro.com> Reviewed-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20240509120820.1430587-1-apatel@ventanamicro.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2024-05-09 17:38:20 +05:30
of: property: Avoiding using uninitialized variable @imaplen in parse_interrupt_map() 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 <quic_zijuhu@quicinc.com> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20250109-of_core_fix-v4-6-db8a72415b8c@quicinc.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2025-01-09 21:26:57 +08:00
of: property: Fix fw_devlink handling of interrupt-map 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 <maz@kernel.org> Co-developed-by: Rob Herring (Arm) <robh@kernel.org> Cc: Saravana Kannan <saravanak@google.com> Tested-by: Marc Zyngier <maz@kernel.org> Tested-by: Anup Patel <apatel@ventanamicro.com> Link: https://lore.kernel.org/r/20240529-dt-interrupt-map-fix-v2-2-ef86dc5bcd2a@kernel.org Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2024-05-29 14:59:21 -05:00
of: property: Add fw_devlink support for interrupt-map property Some of the PCI host controllers (such as generic PCI host controller) use "interrupt-map" DT property to describe the mapping between PCI endpoints and PCI interrupt pins. This is the only case where the interrupts are not described in DT. Currently, there is no fw_devlink created based on "interrupt-map" DT property so interrupt controller is not guaranteed to be probed before the PCI host controller. This affects every platform where both PCI host controller and interrupt controllers are probed as regular platform devices. This creates fw_devlink between consumers (PCI host controller) and supplier (interrupt controller) based on "interrupt-map" DT property. Signed-off-by: Anup Patel <apatel@ventanamicro.com> Reviewed-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20240509120820.1430587-1-apatel@ventanamicro.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2024-05-09 17:38:20 +05:30
of: property: Fix fw_devlink handling of interrupt-map 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 <maz@kernel.org> Co-developed-by: Rob Herring (Arm) <robh@kernel.org> Cc: Saravana Kannan <saravanak@google.com> Tested-by: Marc Zyngier <maz@kernel.org> Tested-by: Anup Patel <apatel@ventanamicro.com> Link: https://lore.kernel.org/r/20240529-dt-interrupt-map-fix-v2-2-ef86dc5bcd2a@kernel.org Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2024-05-29 14:59:21 -05:00
of: property: Add fw_devlink support for interrupt-map property Some of the PCI host controllers (such as generic PCI host controller) use "interrupt-map" DT property to describe the mapping between PCI endpoints and PCI interrupt pins. This is the only case where the interrupts are not described in DT. Currently, there is no fw_devlink created based on "interrupt-map" DT property so interrupt controller is not guaranteed to be probed before the PCI host controller. This affects every platform where both PCI host controller and interrupt controllers are probed as regular platform devices. This creates fw_devlink between consumers (PCI host controller) and supplier (interrupt controller) based on "interrupt-map" DT property. Signed-off-by: Anup Patel <apatel@ventanamicro.com> Reviewed-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20240509120820.1430587-1-apatel@ventanamicro.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2024-05-09 17:38:20 +05:30
of: property: Fix fw_devlink handling of interrupt-map 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 <maz@kernel.org> Co-developed-by: Rob Herring (Arm) <robh@kernel.org> Cc: Saravana Kannan <saravanak@google.com> Tested-by: Marc Zyngier <maz@kernel.org> Tested-by: Anup Patel <apatel@ventanamicro.com> Link: https://lore.kernel.org/r/20240529-dt-interrupt-map-fix-v2-2-ef86dc5bcd2a@kernel.org Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2024-05-29 14:59:21 -05:00
of: property: Add fw_devlink support for interrupt-map property Some of the PCI host controllers (such as generic PCI host controller) use "interrupt-map" DT property to describe the mapping between PCI endpoints and PCI interrupt pins. This is the only case where the interrupts are not described in DT. Currently, there is no fw_devlink created based on "interrupt-map" DT property so interrupt controller is not guaranteed to be probed before the PCI host controller. This affects every platform where both PCI host controller and interrupt controllers are probed as regular platform devices. This creates fw_devlink between consumers (PCI host controller) and supplier (interrupt controller) based on "interrupt-map" DT property. Signed-off-by: Anup Patel <apatel@ventanamicro.com> Reviewed-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20240509120820.1430587-1-apatel@ventanamicro.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2024-05-09 17:38:20 +05:30
of: property: Fix fw_devlink handling of interrupt-map 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 <maz@kernel.org> Co-developed-by: Rob Herring (Arm) <robh@kernel.org> Cc: Saravana Kannan <saravanak@google.com> Tested-by: Marc Zyngier <maz@kernel.org> Tested-by: Anup Patel <apatel@ventanamicro.com> Link: https://lore.kernel.org/r/20240529-dt-interrupt-map-fix-v2-2-ef86dc5bcd2a@kernel.org Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2024-05-29 14:59:21 -05:00
of: property: Add fw_devlink support for interrupt-map property Some of the PCI host controllers (such as generic PCI host controller) use "interrupt-map" DT property to describe the mapping between PCI endpoints and PCI interrupt pins. This is the only case where the interrupts are not described in DT. Currently, there is no fw_devlink created based on "interrupt-map" DT property so interrupt controller is not guaranteed to be probed before the PCI host controller. This affects every platform where both PCI host controller and interrupt controllers are probed as regular platform devices. This creates fw_devlink between consumers (PCI host controller) and supplier (interrupt controller) based on "interrupt-map" DT property. Signed-off-by: Anup Patel <apatel@ventanamicro.com> Reviewed-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20240509120820.1430587-1-apatel@ventanamicro.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2024-05-09 17:38:20 +05:30
of: property: Improve finding the supplier of a remote-endpoint property After commit 4a032827daa8 ("of: property: Simplify of_link_to_phandle()"), remote-endpoint properties created a fwnode link from the consumer device to the supplier endpoint. This is a tiny bit inefficient (not buggy) when trying to create device links or detecting cycles. So, improve this the same way we improved finding the consumer of a remote-endpoint property. Fixes: 4a032827daa8 ("of: property: Simplify of_link_to_phandle()") Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20240207011803.2637531-3-saravanak@google.com Signed-off-by: Rob Herring <robh@kernel.org>
2024-02-06 17:18:01 -08:00
of: property: fw_devlink: Fix stupid bug in remote-endpoint parsing Introduced a stupid bug in commit 782bfd03c3ae ("of: property: Improve finding the supplier of a remote-endpoint property") due to a last minute incorrect edit of "index !=0" into "!index". This patch fixes it to be "index > 0" to match the comment right next to it. Reported-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Link: https://lore.kernel.org/lkml/20240223171849.10f9901d@booty/ Fixes: 782bfd03c3ae ("of: property: Improve finding the supplier of a remote-endpoint property") Signed-off-by: Saravana Kannan <saravanak@google.com> Reviewed-by: Herve Codina <herve.codina@bootlin.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Link: https://lore.kernel.org/r/20240224052436.3552333-1-saravanak@google.com Signed-off-by: Rob Herring <robh@kernel.org>
2024-02-23 21:24:35 -08:00
of: property: Improve finding the supplier of a remote-endpoint property After commit 4a032827daa8 ("of: property: Simplify of_link_to_phandle()"), remote-endpoint properties created a fwnode link from the consumer device to the supplier endpoint. This is a tiny bit inefficient (not buggy) when trying to create device links or detecting cycles. So, improve this the same way we improved finding the consumer of a remote-endpoint property. Fixes: 4a032827daa8 ("of: property: Simplify of_link_to_phandle()") Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20240207011803.2637531-3-saravanak@google.com Signed-off-by: Rob Herring <robh@kernel.org>
2024-02-06 17:18:01 -08:00
of: property: Minor code formatting/style clean ups Better variable and function names. Remove "," after the sentinel in an array initialization list. Signed-off-by: Saravana Kannan <saravanak@google.com> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20191011191521.179614-2-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-10-11 12:15:19 -07:00
of: property: Add functional dependency link from DT bindings Add device links after the devices are created (but before they are probed) by looking at common DT bindings like clocks and interconnects. Automatically adding device links for functional dependencies at the framework level provides the following benefits: - Optimizes device probe order and avoids the useless work of attempting probes of devices that will not probe successfully (because their suppliers aren't present or haven't probed yet). For example, in a commonly available mobile SoC, registering just one consumer device's driver at an initcall level earlier than the supplier device's driver causes 11 failed probe attempts before the consumer device probes successfully. This was with a kernel with all the drivers statically compiled in. This problem gets a lot worse if all the drivers are loaded as modules without direct symbol dependencies. - Supplier devices like clock providers, interconnect providers, etc need to keep the resources they provide active and at a particular state(s) during boot up even if their current set of consumers don't request the resource to be active. This is because the rest of the consumers might not have probed yet and turning off the resource before all the consumers have probed could lead to a hang or undesired user experience. Some frameworks (Eg: regulator) handle this today by turning off "unused" resources at late_initcall_sync and hoping all the devices have probed by then. This is not a valid assumption for systems with loadable modules. Other frameworks (Eg: clock) just don't handle this due to the lack of a clear signal for when they can turn off resources. This leads to downstream hacks to handle cases like this that can easily be solved in the upstream kernel. By linking devices before they are probed, we give suppliers a clear count of the number of dependent consumers. Once all of the consumers are active, the suppliers can turn off the unused resources without making assumptions about the number of consumers. By default we just add device-links to track "driver presence" (probe succeeded) of the supplier device. If any other functionality provided by device-links are needed, it is left to the consumer/supplier devices to change the link when they probe. kbuild test robot reported clang error about missing const Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20190904211126.47518-4-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-09-04 14:11:22 -07:00
of: property: Add fw_devlink support for optional properties Not all DT bindings are mandatory bindings. Add support for optional DT bindings and mark iommus, iommu-map, dmas as optional DT bindings. Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20210205222644.2357303-5-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-02-05 14:26:40 -08:00
of: property: Add device link support for iommus, mboxes and io-channels Add support for creating device links out of more DT properties. Signed-off-by: Saravana Kannan <saravanak@google.com> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20191105065000.50407-4-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-11-04 22:50:00 -08:00
of: property: add device link support for io-backends Add support for creating device links out of more DT properties. Signed-off-by: Olivier Moysan <olivier.moysan@foss.st.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Nuno Sa <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20240210-iio-backend-v11-3-f5242a5fb42a@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-02-10 21:57:15 +01:00
of: property: Add fw_devlink support for optional properties Not all DT bindings are mandatory bindings. Add support for optional DT bindings and mark iommus, iommu-map, dmas as optional DT bindings. Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20210205222644.2357303-5-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-02-05 14:26:40 -08:00
of: property: Add device link support for power-domains and hwlocks Add support for creating device links out of more DT properties. To: lkml <linux-kernel@vger.kernel.org> To: John Stultz <john.stultz@linaro.org> To: Rob Herring <robh@kernel.org> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Cc: Kevin Hilman <khilman@kernel.org> Cc: Ulf Hansson <ulf.hansson@linaro.org> Cc: Pavel Machek <pavel@ucw.cz> Cc: Len Brown <len.brown@intel.com> Cc: Todd Kjos <tkjos@google.com> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Mark Brown <broonie@kernel.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: linux-pm@vger.kernel.org Signed-off-by: Saravana Kannan <saravanak@google.com> Tested-by: John Stultz <john.stultz@linaro.org> Signed-off-by: Rob Herring <robh@kernel.org>
2020-02-19 21:52:50 -08:00
of: property: Add device link support for extcon Add support for creating device links out of more DT properties. Cc: MyungJoo Ham <myungjoo.ham@samsung.com> Cc: Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by: Saravana Kannan <saravanak@google.com> Signed-off-by: Rob Herring <robh@kernel.org>
2020-04-01 15:52:03 -07:00
of: property: Add device link support for multiple DT bindings Add support for creating device links out of the following DT bindings: - interrupts-extended - nvmem-cells - phys - wakeup-parent Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20200724234415.1651639-1-saravanak@google.com Signed-off-by: Rob Herring <robh@kernel.org>
2020-07-24 16:44:14 -07:00
of: property: stop creating callback for each pinctrl-N property While not a lot in the grand scheme of things, this eliminates 8*2 pointless function calls for almost every property present in the device tree (the exception are the few properties that were already matched). It also seems to reduce .text by about 1.5K - why gcc decides to inline parse_prop_cells() in every instantiation I don't know. Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> Link: https://patch.msgid.link/20251219121811.390988-1-linux@rasmusvillemoes.dk [robh: Drop the commit msg comment that >9 doesn't work as it would] Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2025-12-19 13:18:11 +01:00
of: property: Improve finding the consumer of a remote-endpoint property We have a more accurate function to find the right consumer of a remote-endpoint property instead of searching for a parent with compatible string property. So, use that instead. While at it, make the code to find the consumer a bit more flexible and based on the property being parsed. Fixes: f7514a663016 ("of: property: fw_devlink: Add support for remote-endpoint") Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20240207011803.2637531-2-saravanak@google.com Signed-off-by: Rob Herring <robh@kernel.org>
2024-02-06 17:18:00 -08:00
of: property: fw_devlink: Add support for "resets" and "pwms" Allows better tracking of dependencies between devices. Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20210805223729.1196047-1-saravanak@google.com Signed-off-by: Rob Herring <robh@kernel.org>
2021-08-05 15:37:29 -07:00
of: property: fw_devlink: Add support for "leds" and "backlight" Allows tracking dependencies between leds/backlights devices and their consumers. Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20210814023132.2729731-2-saravanak@google.com Signed-off-by: Rob Herring <robh@kernel.org>
2021-08-13 19:31:30 -07:00
of: property: fw_devlink: Add a devlink for panel followers Inform fw_devlink of the fact that a panel follower (like a touchscreen) is effectively a consumer of the panel from the purposes of fw_devlink. NOTE: this patch isn't required for correctness but instead optimizes probe order / helps avoid deferrals. Acked-by: Rob Herring <robh@kernel.org> Reviewed-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230727101636.v4.4.Ibf8e1342b5b7906279db2365aca45e6253857bb3@changeid
2023-07-27 10:16:31 -07:00
of: property: Add fw_devlink support for msi-parent This allows fw_devlink to create device links between consumers of a MSI and the supplier of the MSI. Signed-off-by: Anup Patel <apatel@ventanamicro.com> Acked-by: Rob Herring <robh@kernel.org> Reviewed-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20231027154254.355853-3-apatel@ventanamicro.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-10-27 21:12:54 +05:30
of: property: Add fw_devlink support for pse parent This allows fw_devlink to create device links between consumers of a PSE and the supplier of the PSE. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Kory Maincent <kory.maincent@bootlin.com> Link: https://lore.kernel.org/r/20240414-feature_poe-v8-2-e4bf1e860da5@bootlin.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-04-14 16:21:51 +02:00
of: property: fw_devlink: Add support for "power-supplies" binding Add support for parsing power-supplies binding so that fw_devlink can enforce the dependency. Signed-off-by: Saravana Kannan <saravanak@google.com> Cc: Sebastian Reichel <sre@kernel.org> Link: https://lore.kernel.org/r/20240417200738.1370896-1-saravanak@google.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2024-04-17 13:07:37 -07:00
of: property: fw_devlink: Add support for "mmc-pwrseq" Add support for parsing MMC power sequencing (pwrseq) binding so that fw_devlink can enforce the dependency. Signed-off-by: Francesco Valla <francesco@valla.it> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://patch.msgid.link/20260110-mmc-pwrseq-v1-1-73de9d6456f4@valla.it Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2026-01-10 16:27:59 +01:00
of: property: Add fw_devlink support for "gpio" and "gpios" binding To provide backward compatibility for boards that use deprecated DT bindings, we need to add fw_devlink support for "gpio" and "gpios". We also need to ignore these properties on nodes with "gpio-hog" property because their gpio[s] are all supplied by the parent node. Fixes: e590474768f1 ("driver core: Set fw_devlink=on by default") Cc: linux-tegra <linux-tegra@vger.kernel.org> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Tested-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20210121225712.1118239-2-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-01-21 14:57:11 -08:00
of: property: Add fw_devlink support for interrupts This allows fw_devlink to create device links between consumers of an interrupt and the supplier of the interrupt. Cc: Marc Zyngier <maz@kernel.org> Cc: Kevin Hilman <khilman@baylibre.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20210121225712.1118239-3-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-01-21 14:57:12 -08:00
of: property: Add fw_devlink support for interrupt-map property Some of the PCI host controllers (such as generic PCI host controller) use "interrupt-map" DT property to describe the mapping between PCI endpoints and PCI interrupt pins. This is the only case where the interrupts are not described in DT. Currently, there is no fw_devlink created based on "interrupt-map" DT property so interrupt controller is not guaranteed to be probed before the PCI host controller. This affects every platform where both PCI host controller and interrupt controllers are probed as regular platform devices. This creates fw_devlink between consumers (PCI host controller) and supplier (interrupt controller) based on "interrupt-map" DT property. Signed-off-by: Anup Patel <apatel@ventanamicro.com> Reviewed-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20240509120820.1430587-1-apatel@ventanamicro.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2024-05-09 17:38:20 +05:30
of: property: fw_devlink: Add support for "access-controller" Allows tracking dependencies between devices and their access controller. Signed-off-by: Gatien Chevallier <gatien.chevallier@foss.st.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2024-01-05 14:03:57 +01:00
of: property: Add functional dependency link from DT bindings Add device links after the devices are created (but before they are probed) by looking at common DT bindings like clocks and interconnects. Automatically adding device links for functional dependencies at the framework level provides the following benefits: - Optimizes device probe order and avoids the useless work of attempting probes of devices that will not probe successfully (because their suppliers aren't present or haven't probed yet). For example, in a commonly available mobile SoC, registering just one consumer device's driver at an initcall level earlier than the supplier device's driver causes 11 failed probe attempts before the consumer device probes successfully. This was with a kernel with all the drivers statically compiled in. This problem gets a lot worse if all the drivers are loaded as modules without direct symbol dependencies. - Supplier devices like clock providers, interconnect providers, etc need to keep the resources they provide active and at a particular state(s) during boot up even if their current set of consumers don't request the resource to be active. This is because the rest of the consumers might not have probed yet and turning off the resource before all the consumers have probed could lead to a hang or undesired user experience. Some frameworks (Eg: regulator) handle this today by turning off "unused" resources at late_initcall_sync and hoping all the devices have probed by then. This is not a valid assumption for systems with loadable modules. Other frameworks (Eg: clock) just don't handle this due to the lack of a clear signal for when they can turn off resources. This leads to downstream hacks to handle cases like this that can easily be solved in the upstream kernel. By linking devices before they are probed, we give suppliers a clear count of the number of dependent consumers. Once all of the consumers are active, the suppliers can turn off the unused resources without making assumptions about the number of consumers. By default we just add device-links to track "driver presence" (probe succeeded) of the supplier device. If any other functionality provided by device-links are needed, it is left to the consumer/supplier devices to change the link when they probe. kbuild test robot reported clang error about missing const Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20190904211126.47518-4-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-09-04 14:11:22 -07:00
of: property: Add device link support for interrupt-parent, dmas and -gpio(s) Add support for creating device links out of more DT properties. Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Vinod Koul <vkoul@kernel.org> Signed-off-by: Saravana Kannan <saravanak@google.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20191120071302.227777-1-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-11-19 23:13:01 -08:00
of: property: fw_devlink: Add support for "post-init-providers" property Add support for this property so that dependency cycles can be broken and fw_devlink can do better probe/suspend/resume ordering between devices in a dependency cycle. Signed-off-by: Saravana Kannan <saravanak@google.com> Acked-by: "Rafael J. Wysocki" <rafael@kernel.org> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20240305050458.1400667-4-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-03-04 21:04:56 -08:00
of: property: Minor code formatting/style clean ups Better variable and function names. Remove "," after the sentinel in an array initialization list. Signed-off-by: Saravana Kannan <saravanak@google.com> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20191011191521.179614-2-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-10-11 12:15:19 -07:00
of: property: Add functional dependency link from DT bindings Add device links after the devices are created (but before they are probed) by looking at common DT bindings like clocks and interconnects. Automatically adding device links for functional dependencies at the framework level provides the following benefits: - Optimizes device probe order and avoids the useless work of attempting probes of devices that will not probe successfully (because their suppliers aren't present or haven't probed yet). For example, in a commonly available mobile SoC, registering just one consumer device's driver at an initcall level earlier than the supplier device's driver causes 11 failed probe attempts before the consumer device probes successfully. This was with a kernel with all the drivers statically compiled in. This problem gets a lot worse if all the drivers are loaded as modules without direct symbol dependencies. - Supplier devices like clock providers, interconnect providers, etc need to keep the resources they provide active and at a particular state(s) during boot up even if their current set of consumers don't request the resource to be active. This is because the rest of the consumers might not have probed yet and turning off the resource before all the consumers have probed could lead to a hang or undesired user experience. Some frameworks (Eg: regulator) handle this today by turning off "unused" resources at late_initcall_sync and hoping all the devices have probed by then. This is not a valid assumption for systems with loadable modules. Other frameworks (Eg: clock) just don't handle this due to the lack of a clear signal for when they can turn off resources. This leads to downstream hacks to handle cases like this that can easily be solved in the upstream kernel. By linking devices before they are probed, we give suppliers a clear count of the number of dependent consumers. Once all of the consumers are active, the suppliers can turn off the unused resources without making assumptions about the number of consumers. By default we just add device-links to track "driver presence" (probe succeeded) of the supplier device. If any other functionality provided by device-links are needed, it is left to the consumer/supplier devices to change the link when they probe. kbuild test robot reported clang error about missing const Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20190904211126.47518-4-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-09-04 14:11:22 -07:00
of: property: Update implementation of add_links() to create fwnode links The semantics of add_links() has changed from creating device link between devices to creating fwnode links between fwnodes. So, update the implementation of add_links() to match the new semantics. Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20201121020232.908850-15-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-20 18:02:29 -08:00
of: property: Add functional dependency link from DT bindings Add device links after the devices are created (but before they are probed) by looking at common DT bindings like clocks and interconnects. Automatically adding device links for functional dependencies at the framework level provides the following benefits: - Optimizes device probe order and avoids the useless work of attempting probes of devices that will not probe successfully (because their suppliers aren't present or haven't probed yet). For example, in a commonly available mobile SoC, registering just one consumer device's driver at an initcall level earlier than the supplier device's driver causes 11 failed probe attempts before the consumer device probes successfully. This was with a kernel with all the drivers statically compiled in. This problem gets a lot worse if all the drivers are loaded as modules without direct symbol dependencies. - Supplier devices like clock providers, interconnect providers, etc need to keep the resources they provide active and at a particular state(s) during boot up even if their current set of consumers don't request the resource to be active. This is because the rest of the consumers might not have probed yet and turning off the resource before all the consumers have probed could lead to a hang or undesired user experience. Some frameworks (Eg: regulator) handle this today by turning off "unused" resources at late_initcall_sync and hoping all the devices have probed by then. This is not a valid assumption for systems with loadable modules. Other frameworks (Eg: clock) just don't handle this due to the lack of a clear signal for when they can turn off resources. This leads to downstream hacks to handle cases like this that can easily be solved in the upstream kernel. By linking devices before they are probed, we give suppliers a clear count of the number of dependent consumers. Once all of the consumers are active, the suppliers can turn off the unused resources without making assumptions about the number of consumers. By default we just add device-links to track "driver presence" (probe succeeded) of the supplier device. If any other functionality provided by device-links are needed, it is left to the consumer/supplier devices to change the link when they probe. kbuild test robot reported clang error about missing const Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20190904211126.47518-4-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-09-04 14:11:22 -07:00
of: property: Update implementation of add_links() to create fwnode links The semantics of add_links() has changed from creating device link between devices to creating fwnode links between fwnodes. So, update the implementation of add_links() to match the new semantics. Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20201121020232.908850-15-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-20 18:02:29 -08:00
of: property: Add functional dependency link from DT bindings Add device links after the devices are created (but before they are probed) by looking at common DT bindings like clocks and interconnects. Automatically adding device links for functional dependencies at the framework level provides the following benefits: - Optimizes device probe order and avoids the useless work of attempting probes of devices that will not probe successfully (because their suppliers aren't present or haven't probed yet). For example, in a commonly available mobile SoC, registering just one consumer device's driver at an initcall level earlier than the supplier device's driver causes 11 failed probe attempts before the consumer device probes successfully. This was with a kernel with all the drivers statically compiled in. This problem gets a lot worse if all the drivers are loaded as modules without direct symbol dependencies. - Supplier devices like clock providers, interconnect providers, etc need to keep the resources they provide active and at a particular state(s) during boot up even if their current set of consumers don't request the resource to be active. This is because the rest of the consumers might not have probed yet and turning off the resource before all the consumers have probed could lead to a hang or undesired user experience. Some frameworks (Eg: regulator) handle this today by turning off "unused" resources at late_initcall_sync and hoping all the devices have probed by then. This is not a valid assumption for systems with loadable modules. Other frameworks (Eg: clock) just don't handle this due to the lack of a clear signal for when they can turn off resources. This leads to downstream hacks to handle cases like this that can easily be solved in the upstream kernel. By linking devices before they are probed, we give suppliers a clear count of the number of dependent consumers. Once all of the consumers are active, the suppliers can turn off the unused resources without making assumptions about the number of consumers. By default we just add device-links to track "driver presence" (probe succeeded) of the supplier device. If any other functionality provided by device-links are needed, it is left to the consumer/supplier devices to change the link when they probe. kbuild test robot reported clang error about missing const Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20190904211126.47518-4-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-09-04 14:11:22 -07:00
of: property: Update implementation of add_links() to create fwnode links The semantics of add_links() has changed from creating device link between devices to creating fwnode links between fwnodes. So, update the implementation of add_links() to match the new semantics. Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20201121020232.908850-15-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-20 18:02:29 -08:00
of: property: Add functional dependency link from DT bindings Add device links after the devices are created (but before they are probed) by looking at common DT bindings like clocks and interconnects. Automatically adding device links for functional dependencies at the framework level provides the following benefits: - Optimizes device probe order and avoids the useless work of attempting probes of devices that will not probe successfully (because their suppliers aren't present or haven't probed yet). For example, in a commonly available mobile SoC, registering just one consumer device's driver at an initcall level earlier than the supplier device's driver causes 11 failed probe attempts before the consumer device probes successfully. This was with a kernel with all the drivers statically compiled in. This problem gets a lot worse if all the drivers are loaded as modules without direct symbol dependencies. - Supplier devices like clock providers, interconnect providers, etc need to keep the resources they provide active and at a particular state(s) during boot up even if their current set of consumers don't request the resource to be active. This is because the rest of the consumers might not have probed yet and turning off the resource before all the consumers have probed could lead to a hang or undesired user experience. Some frameworks (Eg: regulator) handle this today by turning off "unused" resources at late_initcall_sync and hoping all the devices have probed by then. This is not a valid assumption for systems with loadable modules. Other frameworks (Eg: clock) just don't handle this due to the lack of a clear signal for when they can turn off resources. This leads to downstream hacks to handle cases like this that can easily be solved in the upstream kernel. By linking devices before they are probed, we give suppliers a clear count of the number of dependent consumers. Once all of the consumers are active, the suppliers can turn off the unused resources without making assumptions about the number of consumers. By default we just add device-links to track "driver presence" (probe succeeded) of the supplier device. If any other functionality provided by device-links are needed, it is left to the consumer/supplier devices to change the link when they probe. kbuild test robot reported clang error about missing const Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20190904211126.47518-4-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-09-04 14:11:22 -07:00
of: property: Update implementation of add_links() to create fwnode links The semantics of add_links() has changed from creating device link between devices to creating fwnode links between fwnodes. So, update the implementation of add_links() to match the new semantics. Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20201121020232.908850-15-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-20 18:02:29 -08:00
of: property: Add functional dependency link from DT bindings Add device links after the devices are created (but before they are probed) by looking at common DT bindings like clocks and interconnects. Automatically adding device links for functional dependencies at the framework level provides the following benefits: - Optimizes device probe order and avoids the useless work of attempting probes of devices that will not probe successfully (because their suppliers aren't present or haven't probed yet). For example, in a commonly available mobile SoC, registering just one consumer device's driver at an initcall level earlier than the supplier device's driver causes 11 failed probe attempts before the consumer device probes successfully. This was with a kernel with all the drivers statically compiled in. This problem gets a lot worse if all the drivers are loaded as modules without direct symbol dependencies. - Supplier devices like clock providers, interconnect providers, etc need to keep the resources they provide active and at a particular state(s) during boot up even if their current set of consumers don't request the resource to be active. This is because the rest of the consumers might not have probed yet and turning off the resource before all the consumers have probed could lead to a hang or undesired user experience. Some frameworks (Eg: regulator) handle this today by turning off "unused" resources at late_initcall_sync and hoping all the devices have probed by then. This is not a valid assumption for systems with loadable modules. Other frameworks (Eg: clock) just don't handle this due to the lack of a clear signal for when they can turn off resources. This leads to downstream hacks to handle cases like this that can easily be solved in the upstream kernel. By linking devices before they are probed, we give suppliers a clear count of the number of dependent consumers. Once all of the consumers are active, the suppliers can turn off the unused resources without making assumptions about the number of consumers. By default we just add device-links to track "driver presence" (probe succeeded) of the supplier device. If any other functionality provided by device-links are needed, it is left to the consumer/supplier devices to change the link when they probe. kbuild test robot reported clang error about missing const Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20190904211126.47518-4-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-09-04 14:11:22 -07:00
of: property: Minor code formatting/style clean ups Better variable and function names. Remove "," after the sentinel in an array initialization list. Signed-off-by: Saravana Kannan <saravanak@google.com> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20191011191521.179614-2-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-10-11 12:15:19 -07:00
of: property: Add functional dependency link from DT bindings Add device links after the devices are created (but before they are probed) by looking at common DT bindings like clocks and interconnects. Automatically adding device links for functional dependencies at the framework level provides the following benefits: - Optimizes device probe order and avoids the useless work of attempting probes of devices that will not probe successfully (because their suppliers aren't present or haven't probed yet). For example, in a commonly available mobile SoC, registering just one consumer device's driver at an initcall level earlier than the supplier device's driver causes 11 failed probe attempts before the consumer device probes successfully. This was with a kernel with all the drivers statically compiled in. This problem gets a lot worse if all the drivers are loaded as modules without direct symbol dependencies. - Supplier devices like clock providers, interconnect providers, etc need to keep the resources they provide active and at a particular state(s) during boot up even if their current set of consumers don't request the resource to be active. This is because the rest of the consumers might not have probed yet and turning off the resource before all the consumers have probed could lead to a hang or undesired user experience. Some frameworks (Eg: regulator) handle this today by turning off "unused" resources at late_initcall_sync and hoping all the devices have probed by then. This is not a valid assumption for systems with loadable modules. Other frameworks (Eg: clock) just don't handle this due to the lack of a clear signal for when they can turn off resources. This leads to downstream hacks to handle cases like this that can easily be solved in the upstream kernel. By linking devices before they are probed, we give suppliers a clear count of the number of dependent consumers. Once all of the consumers are active, the suppliers can turn off the unused resources without making assumptions about the number of consumers. By default we just add device-links to track "driver presence" (probe succeeded) of the supplier device. If any other functionality provided by device-links are needed, it is left to the consumer/supplier devices to change the link when they probe. kbuild test robot reported clang error about missing const Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20190904211126.47518-4-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-09-04 14:11:22 -07:00
of: property: Add fw_devlink support for optional properties Not all DT bindings are mandatory bindings. Add support for optional DT bindings and mark iommus, iommu-map, dmas as optional DT bindings. Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20210205222644.2357303-5-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-02-05 14:26:40 -08:00
of: property: Add functional dependency link from DT bindings Add device links after the devices are created (but before they are probed) by looking at common DT bindings like clocks and interconnects. Automatically adding device links for functional dependencies at the framework level provides the following benefits: - Optimizes device probe order and avoids the useless work of attempting probes of devices that will not probe successfully (because their suppliers aren't present or haven't probed yet). For example, in a commonly available mobile SoC, registering just one consumer device's driver at an initcall level earlier than the supplier device's driver causes 11 failed probe attempts before the consumer device probes successfully. This was with a kernel with all the drivers statically compiled in. This problem gets a lot worse if all the drivers are loaded as modules without direct symbol dependencies. - Supplier devices like clock providers, interconnect providers, etc need to keep the resources they provide active and at a particular state(s) during boot up even if their current set of consumers don't request the resource to be active. This is because the rest of the consumers might not have probed yet and turning off the resource before all the consumers have probed could lead to a hang or undesired user experience. Some frameworks (Eg: regulator) handle this today by turning off "unused" resources at late_initcall_sync and hoping all the devices have probed by then. This is not a valid assumption for systems with loadable modules. Other frameworks (Eg: clock) just don't handle this due to the lack of a clear signal for when they can turn off resources. This leads to downstream hacks to handle cases like this that can easily be solved in the upstream kernel. By linking devices before they are probed, we give suppliers a clear count of the number of dependent consumers. Once all of the consumers are active, the suppliers can turn off the unused resources without making assumptions about the number of consumers. By default we just add device-links to track "driver presence" (probe succeeded) of the supplier device. If any other functionality provided by device-links are needed, it is left to the consumer/supplier devices to change the link when they probe. kbuild test robot reported clang error about missing const Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20190904211126.47518-4-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-09-04 14:11:22 -07:00
of: property: Do some clean up with use of __free() __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 <zhangzekun11@huawei.com> Link: https://lore.kernel.org/r/20240830020626.115933-4-zhangzekun11@huawei.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2024-08-30 10:06:26 +08:00
of: property: fw_devlink: Add support for remote-endpoint remote-endpoint property seems to always come in pairs where two devices point to each other. So, we can't really tell from DT if there is a functional probe order dependency between these two devices. However, there can be other dependencies between two devices that point to each other with remote-endpoint. This non-remote-endpoint dependency combined with one of the remote-endpoint dependency can lead to a cyclic dependency[1]. To avoid this cyclic dependency from incorrectly blocking probes, fw_devlink needs to be made aware of remote-endpoint dependencies even though remote-endpoint dependencies by themselves won't affect probe ordering (because fw_devlink will see the cyclic dependency between remote-endpoint devices and ignore the dependencies that cause the cycle). Also, if a device ever needs to know if a non-probe-blocking remote-endpoint has finished probing, it can now use the sync_state() to figure it out. [1] - https://lore.kernel.org/lkml/CAGETcx9Snf23wrXqjDhJiTok9M3GcoVYDSyNYSMj9QnSRrA=cA@mail.gmail.com/#t Fixes: ea718c699055 ("Revert "Revert "driver core: Set fw_devlink=on by default""") Reported-by: Stephen Boyd <swboyd@chromium.org> Tested-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20210330185056.1022008-1-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-30 11:50:55 -07:00
of: property: Add functional dependency link from DT bindings Add device links after the devices are created (but before they are probed) by looking at common DT bindings like clocks and interconnects. Automatically adding device links for functional dependencies at the framework level provides the following benefits: - Optimizes device probe order and avoids the useless work of attempting probes of devices that will not probe successfully (because their suppliers aren't present or haven't probed yet). For example, in a commonly available mobile SoC, registering just one consumer device's driver at an initcall level earlier than the supplier device's driver causes 11 failed probe attempts before the consumer device probes successfully. This was with a kernel with all the drivers statically compiled in. This problem gets a lot worse if all the drivers are loaded as modules without direct symbol dependencies. - Supplier devices like clock providers, interconnect providers, etc need to keep the resources they provide active and at a particular state(s) during boot up even if their current set of consumers don't request the resource to be active. This is because the rest of the consumers might not have probed yet and turning off the resource before all the consumers have probed could lead to a hang or undesired user experience. Some frameworks (Eg: regulator) handle this today by turning off "unused" resources at late_initcall_sync and hoping all the devices have probed by then. This is not a valid assumption for systems with loadable modules. Other frameworks (Eg: clock) just don't handle this due to the lack of a clear signal for when they can turn off resources. This leads to downstream hacks to handle cases like this that can easily be solved in the upstream kernel. By linking devices before they are probed, we give suppliers a clear count of the number of dependent consumers. Once all of the consumers are active, the suppliers can turn off the unused resources without making assumptions about the number of consumers. By default we just add device-links to track "driver presence" (probe succeeded) of the supplier device. If any other functionality provided by device-links are needed, it is left to the consumer/supplier devices to change the link when they probe. kbuild test robot reported clang error about missing const Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20190904211126.47518-4-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-09-04 14:11:22 -07:00
of: property: fw_devlink: Add support for "post-init-providers" property Add support for this property so that dependency cycles can be broken and fw_devlink can do better probe/suspend/resume ordering between devices in a dependency cycle. Signed-off-by: Saravana Kannan <saravanak@google.com> Acked-by: "Rafael J. Wysocki" <rafael@kernel.org> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20240305050458.1400667-4-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-03-04 21:04:56 -08:00
of: property: Add functional dependency link from DT bindings Add device links after the devices are created (but before they are probed) by looking at common DT bindings like clocks and interconnects. Automatically adding device links for functional dependencies at the framework level provides the following benefits: - Optimizes device probe order and avoids the useless work of attempting probes of devices that will not probe successfully (because their suppliers aren't present or haven't probed yet). For example, in a commonly available mobile SoC, registering just one consumer device's driver at an initcall level earlier than the supplier device's driver causes 11 failed probe attempts before the consumer device probes successfully. This was with a kernel with all the drivers statically compiled in. This problem gets a lot worse if all the drivers are loaded as modules without direct symbol dependencies. - Supplier devices like clock providers, interconnect providers, etc need to keep the resources they provide active and at a particular state(s) during boot up even if their current set of consumers don't request the resource to be active. This is because the rest of the consumers might not have probed yet and turning off the resource before all the consumers have probed could lead to a hang or undesired user experience. Some frameworks (Eg: regulator) handle this today by turning off "unused" resources at late_initcall_sync and hoping all the devices have probed by then. This is not a valid assumption for systems with loadable modules. Other frameworks (Eg: clock) just don't handle this due to the lack of a clear signal for when they can turn off resources. This leads to downstream hacks to handle cases like this that can easily be solved in the upstream kernel. By linking devices before they are probed, we give suppliers a clear count of the number of dependent consumers. Once all of the consumers are active, the suppliers can turn off the unused resources without making assumptions about the number of consumers. By default we just add device-links to track "driver presence" (probe succeeded) of the supplier device. If any other functionality provided by device-links are needed, it is left to the consumer/supplier devices to change the link when they probe. kbuild test robot reported clang error about missing const Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20190904211126.47518-4-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-09-04 14:11:22 -07:00
of: property: Remove unneeded return variable This patch removes unneeded return variables, using only '0' instead. It fixes the following warning detected by coccinelle: ./drivers/of/property.c:1371:5-8: Unneeded variable: "ret". Return "0" on line 1388 Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Yang Li <yang.lee@linux.alibaba.com> Link: https://lore.kernel.org/r/1614676598-105267-1-git-send-email-yang.lee@linux.alibaba.com Signed-off-by: Rob Herring <robh@kernel.org>
2021-03-02 17:16:38 +08:00
of: property: Add functional dependency link from DT bindings Add device links after the devices are created (but before they are probed) by looking at common DT bindings like clocks and interconnects. Automatically adding device links for functional dependencies at the framework level provides the following benefits: - Optimizes device probe order and avoids the useless work of attempting probes of devices that will not probe successfully (because their suppliers aren't present or haven't probed yet). For example, in a commonly available mobile SoC, registering just one consumer device's driver at an initcall level earlier than the supplier device's driver causes 11 failed probe attempts before the consumer device probes successfully. This was with a kernel with all the drivers statically compiled in. This problem gets a lot worse if all the drivers are loaded as modules without direct symbol dependencies. - Supplier devices like clock providers, interconnect providers, etc need to keep the resources they provide active and at a particular state(s) during boot up even if their current set of consumers don't request the resource to be active. This is because the rest of the consumers might not have probed yet and turning off the resource before all the consumers have probed could lead to a hang or undesired user experience. Some frameworks (Eg: regulator) handle this today by turning off "unused" resources at late_initcall_sync and hoping all the devices have probed by then. This is not a valid assumption for systems with loadable modules. Other frameworks (Eg: clock) just don't handle this due to the lack of a clear signal for when they can turn off resources. This leads to downstream hacks to handle cases like this that can easily be solved in the upstream kernel. By linking devices before they are probed, we give suppliers a clear count of the number of dependent consumers. Once all of the consumers are active, the suppliers can turn off the unused resources without making assumptions about the number of consumers. By default we just add device-links to track "driver presence" (probe succeeded) of the supplier device. If any other functionality provided by device-links are needed, it is left to the consumer/supplier devices to change the link when they probe. kbuild test robot reported clang error about missing const Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20190904211126.47518-4-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-09-04 14:11:22 -07:00
device property: Add iomap to fwnode operations Add iomap() fwnode operation to implement fwnode_iomap() through fwnode operations, moving the code in fwnode_iomap() to OF framework. Note that the IS_ENABLED(CONFIG_OF_ADDRESS) && is_of_node(fwnode) check is needed for Sparc that has its own implementation of of_iomap anyway. Let the pre-compiler to handle that check. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-03-31 15:54:49 +03:00
device property: Add irq_get to fwnode operation Add irq_get() fwnode operation to implement fwnode_irq_get() through fwnode operations, moving the code in fwnode_irq_get() to OF and ACPI frameworks. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Acked-by: Rob Herring <robh@kernel.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-03-31 15:54:50 +03:00
of: property: Allow fw_devlink device-tree on x86 PCI drivers can use a device-tree overlay to describe the hardware available on the PCI board. This is the case, for instance, of the LAN966x PCI device driver. Adding some more nodes in the device-tree overlay adds some more consumer/supplier relationship between devices instantiated from this overlay. Those fw_node consumer/supplier relationships are handled by fw_devlink and are created based on the device-tree parsing done by the of_fwnode_add_links() function. Those consumer/supplier links are needed in order to ensure a correct PM runtime management and a correct removal order between devices. For instance, without those links a supplier can be removed before its consumers is removed leading to all kind of issue if this consumer still want the use the already removed supplier. The support for the usage of an overlay from a PCI driver has been added on x86 systems in commit 1f340724419ed ("PCI: of: Create device tree PCI host bridge node"). In the past, support for fw_devlink on x86 had been tried but this support has been removed in commit 4a48b66b3f52 ("of: property: Disable fw_devlink DT support for X86"). Indeed, this support was breaking some x86 systems such as OLPC system and the regression was reported in [0]. Instead of disabling this support for all x86 system, use a finer grain and disable this support only for the possible problematic subset of x86 systems (at least OLPC and CE4100). Those systems use a device-tree to describe their hardware. Identify those systems using key properties in the device-tree. Signed-off-by: Herve Codina <herve.codina@bootlin.com> Link: https://lore.kernel.org/lkml/3c1f2473-92ad-bfc4-258e-a5a08ad73dd0@web.de/ [0] Link: https://patch.msgid.link/20260325143555.451852-18-herve.codina@bootlin.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2026-03-25 15:35:44 +01:00
driver core: Delete pointless parameter in fwnode_operations.add_links The struct device input to add_links() is not used for anything. So delete it. Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20201121020232.908850-18-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-20 18:02:32 -08:00
of: property: Add functional dependency link from DT bindings Add device links after the devices are created (but before they are probed) by looking at common DT bindings like clocks and interconnects. Automatically adding device links for functional dependencies at the framework level provides the following benefits: - Optimizes device probe order and avoids the useless work of attempting probes of devices that will not probe successfully (because their suppliers aren't present or haven't probed yet). For example, in a commonly available mobile SoC, registering just one consumer device's driver at an initcall level earlier than the supplier device's driver causes 11 failed probe attempts before the consumer device probes successfully. This was with a kernel with all the drivers statically compiled in. This problem gets a lot worse if all the drivers are loaded as modules without direct symbol dependencies. - Supplier devices like clock providers, interconnect providers, etc need to keep the resources they provide active and at a particular state(s) during boot up even if their current set of consumers don't request the resource to be active. This is because the rest of the consumers might not have probed yet and turning off the resource before all the consumers have probed could lead to a hang or undesired user experience. Some frameworks (Eg: regulator) handle this today by turning off "unused" resources at late_initcall_sync and hoping all the devices have probed by then. This is not a valid assumption for systems with loadable modules. Other frameworks (Eg: clock) just don't handle this due to the lack of a clear signal for when they can turn off resources. This leads to downstream hacks to handle cases like this that can easily be solved in the upstream kernel. By linking devices before they are probed, we give suppliers a clear count of the number of dependent consumers. Once all of the consumers are active, the suppliers can turn off the unused resources without making assumptions about the number of consumers. By default we just add device-links to track "driver presence" (probe succeeded) of the supplier device. If any other functionality provided by device-links are needed, it is left to the consumer/supplier devices to change the link when they probe. kbuild test robot reported clang error about missing const Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20190904211126.47518-4-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-09-04 14:11:22 -07:00
of: Constify struct property pointers 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 <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20241010-dt-const-v1-4-87a51f558425@kernel.org Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2024-10-10 11:27:17 -05:00
of: property: Update implementation of add_links() to create fwnode links The semantics of add_links() has changed from creating device link between devices to creating fwnode links between fwnodes. So, update the implementation of add_links() to match the new semantics. Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20201121020232.908850-15-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-20 18:02:29 -08:00
of: property: Add functional dependency link from DT bindings Add device links after the devices are created (but before they are probed) by looking at common DT bindings like clocks and interconnects. Automatically adding device links for functional dependencies at the framework level provides the following benefits: - Optimizes device probe order and avoids the useless work of attempting probes of devices that will not probe successfully (because their suppliers aren't present or haven't probed yet). For example, in a commonly available mobile SoC, registering just one consumer device's driver at an initcall level earlier than the supplier device's driver causes 11 failed probe attempts before the consumer device probes successfully. This was with a kernel with all the drivers statically compiled in. This problem gets a lot worse if all the drivers are loaded as modules without direct symbol dependencies. - Supplier devices like clock providers, interconnect providers, etc need to keep the resources they provide active and at a particular state(s) during boot up even if their current set of consumers don't request the resource to be active. This is because the rest of the consumers might not have probed yet and turning off the resource before all the consumers have probed could lead to a hang or undesired user experience. Some frameworks (Eg: regulator) handle this today by turning off "unused" resources at late_initcall_sync and hoping all the devices have probed by then. This is not a valid assumption for systems with loadable modules. Other frameworks (Eg: clock) just don't handle this due to the lack of a clear signal for when they can turn off resources. This leads to downstream hacks to handle cases like this that can easily be solved in the upstream kernel. By linking devices before they are probed, we give suppliers a clear count of the number of dependent consumers. Once all of the consumers are active, the suppliers can turn off the unused resources without making assumptions about the number of consumers. By default we just add device-links to track "driver presence" (probe succeeded) of the supplier device. If any other functionality provided by device-links are needed, it is left to the consumer/supplier devices to change the link when they probe. kbuild test robot reported clang error about missing const Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20190904211126.47518-4-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-09-04 14:11:22 -07:00
of: property: Allow fw_devlink device-tree on x86 PCI drivers can use a device-tree overlay to describe the hardware available on the PCI board. This is the case, for instance, of the LAN966x PCI device driver. Adding some more nodes in the device-tree overlay adds some more consumer/supplier relationship between devices instantiated from this overlay. Those fw_node consumer/supplier relationships are handled by fw_devlink and are created based on the device-tree parsing done by the of_fwnode_add_links() function. Those consumer/supplier links are needed in order to ensure a correct PM runtime management and a correct removal order between devices. For instance, without those links a supplier can be removed before its consumers is removed leading to all kind of issue if this consumer still want the use the already removed supplier. The support for the usage of an overlay from a PCI driver has been added on x86 systems in commit 1f340724419ed ("PCI: of: Create device tree PCI host bridge node"). In the past, support for fw_devlink on x86 had been tried but this support has been removed in commit 4a48b66b3f52 ("of: property: Disable fw_devlink DT support for X86"). Indeed, this support was breaking some x86 systems such as OLPC system and the regression was reported in [0]. Instead of disabling this support for all x86 system, use a finer grain and disable this support only for the possible problematic subset of x86 systems (at least OLPC and CE4100). Those systems use a device-tree to describe their hardware. Identify those systems using key properties in the device-tree. Signed-off-by: Herve Codina <herve.codina@bootlin.com> Link: https://lore.kernel.org/lkml/3c1f2473-92ad-bfc4-258e-a5a08ad73dd0@web.de/ [0] Link: https://patch.msgid.link/20260325143555.451852-18-herve.codina@bootlin.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2026-03-25 15:35:44 +01:00
of: property: Disable fw_devlink DT support for X86 Andre reported fw_devlink=on breaking OLPC XO-1.5 [1]. OLPC XO-1.5 is an X86 system that uses a mix of ACPI and OF to populate devices. The root cause seems to be ISA devices not setting their fwnode field. But trying to figure out how to fix that doesn't seem worth the trouble because the OLPC devicetree is very sparse/limited and fw_devlink only adds the links causing this issue. Considering that there aren't many users of OF in an X86 system, simply fw_devlink DT support for X86. [1] - https://lore.kernel.org/lkml/3c1f2473-92ad-bfc4-258e-a5a08ad73dd0@web.de/ Fixes: ea718c699055 ("Revert "Revert "driver core: Set fw_devlink=on by default""") Signed-off-by: Saravana Kannan <saravanak@google.com> Cc: Andre Muller <andre.muller@web.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Tested-by: Andre Müller <andre.muller@web.de> Link: https://lore.kernel.org/r/20210910011446.3208894-1-saravanak@google.com Signed-off-by: Rob Herring <robh@kernel.org>
2021-09-09 18:14:45 -07:00
of: property: Update implementation of add_links() to create fwnode links The semantics of add_links() has changed from creating device link between devices to creating fwnode links between fwnodes. So, update the implementation of add_links() to match the new semantics. Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20201121020232.908850-15-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-20 18:02:29 -08:00
of: property: Add functional dependency link from DT bindings Add device links after the devices are created (but before they are probed) by looking at common DT bindings like clocks and interconnects. Automatically adding device links for functional dependencies at the framework level provides the following benefits: - Optimizes device probe order and avoids the useless work of attempting probes of devices that will not probe successfully (because their suppliers aren't present or haven't probed yet). For example, in a commonly available mobile SoC, registering just one consumer device's driver at an initcall level earlier than the supplier device's driver causes 11 failed probe attempts before the consumer device probes successfully. This was with a kernel with all the drivers statically compiled in. This problem gets a lot worse if all the drivers are loaded as modules without direct symbol dependencies. - Supplier devices like clock providers, interconnect providers, etc need to keep the resources they provide active and at a particular state(s) during boot up even if their current set of consumers don't request the resource to be active. This is because the rest of the consumers might not have probed yet and turning off the resource before all the consumers have probed could lead to a hang or undesired user experience. Some frameworks (Eg: regulator) handle this today by turning off "unused" resources at late_initcall_sync and hoping all the devices have probed by then. This is not a valid assumption for systems with loadable modules. Other frameworks (Eg: clock) just don't handle this due to the lack of a clear signal for when they can turn off resources. This leads to downstream hacks to handle cases like this that can easily be solved in the upstream kernel. By linking devices before they are probed, we give suppliers a clear count of the number of dependent consumers. Once all of the consumers are active, the suppliers can turn off the unused resources without making assumptions about the number of consumers. By default we just add device-links to track "driver presence" (probe succeeded) of the supplier device. If any other functionality provided by device-links are needed, it is left to the consumer/supplier devices to change the link when they probe. kbuild test robot reported clang error about missing const Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20190904211126.47518-4-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-09-04 14:11:22 -07:00
device property: Move FW type specific functionality to FW specific files The device and fwnode property API supports Devicetree, ACPI and pset properties. The implementation of this functionality for each firmware type was embedded in the fwnode property core. Move it out to firmware type specific locations, making it easier to maintain. Depends-on: ("of: Move OF property and graph API from base.c to property.c") Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-06 12:37:37 +03:00
device property: Introduce fwnode_device_is_available() Add fwnode_device_is_available() to tell whether the device corresponding to a certain fwnode_handle is available for use. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-06 12:37:39 +03:00
OF: properties: Implement get_match_data() callback Now that we have a get_match_data() callback as part of the firmware node, implement the OF specific piece for it. Signed-off-by: Sinan Kaya <okaya@codeaurora.org> Reviewed-by: Rob Herring <robh@kernel.org> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2017-12-13 02:20:50 -05:00
device property: Convert device_{dma_supported,get_dma_attr} to fwnode Make the device_dma_supported and device_get_dma_attr functions to use the fwnode ops, and move the implementation to ACPI and OF frameworks. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Acked-by: Rob Herring <robh@kernel.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-03-31 15:54:47 +03:00
device property: Move FW type specific functionality to FW specific files The device and fwnode property API supports Devicetree, ACPI and pset properties. The implementation of this functionality for each firmware type was embedded in the fwnode property core. Move it out to firmware type specific locations, making it easier to maintain. Depends-on: ("of: Move OF property and graph API from base.c to property.c") Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-06 12:37:37 +03:00
device property: Split property reading bool and presence test ops 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 <gregkh@linuxfoundation.org> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://lore.kernel.org/r/20250109-dt-type-warnings-v1-1-0150e32e716c@kernel.org Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2025-01-09 13:42:05 -06:00
device property: Move FW type specific functionality to FW specific files The device and fwnode property API supports Devicetree, ACPI and pset properties. The implementation of this functionality for each firmware type was embedded in the fwnode property core. Move it out to firmware type specific locations, making it easier to maintain. Depends-on: ("of: Move OF property and graph API from base.c to property.c") Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-06 12:37:37 +03:00
device property: Add fwnode_get_name for returning the name of a node The fwnode framework did not have means to obtain the name of a node. Add that now, in form of the fwnode_get_name() function and a corresponding get_name fwnode op. OF and ACPI support is included. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Acked-by: Rob Herring <robh@kernel.org> (for OF) Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-10-03 15:32:12 +03:00
device property: Add a function to obtain a node's prefix The prefix is used for printing purpose before a node, and it also works as a separator between two nodes. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Acked-by: Rob Herring <robh@kernel.org> (for OF) Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-10-03 15:32:13 +03:00
device property: Move FW type specific functionality to FW specific files The device and fwnode property API supports Devicetree, ACPI and pset properties. The implementation of this functionality for each firmware type was embedded in the fwnode property core. Move it out to firmware type specific locations, making it easier to maintain. Depends-on: ("of: Move OF property and graph API from base.c to property.c") Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-06 12:37:37 +03:00
device property: Introduce fwnode_property_get_reference_args The new fwnode_property_get_reference_args() interface amends the fwnode property API with the functionality of both of_parse_phandle_with_args() and __acpi_node_get_property_reference(). The semantics is slightly different: the cells property is ignored on ACPI as the number of arguments can be explicitly obtained from the firmware interface. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-21 15:11:49 +03:00
device property: Move fwnode graph ops to firmware specific locations Move firmware specific implementations of the fwnode graph operations to firmware specific locations. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-06 12:37:38 +03:00
device property: Add iomap to fwnode operations Add iomap() fwnode operation to implement fwnode_iomap() through fwnode operations, moving the code in fwnode_iomap() to OF framework. Note that the IS_ENABLED(CONFIG_OF_ADDRESS) && is_of_node(fwnode) check is needed for Sparc that has its own implementation of of_iomap anyway. Let the pre-compiler to handle that check. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-03-31 15:54:49 +03:00
device property: Add irq_get to fwnode operation Add irq_get() fwnode operation to implement fwnode_irq_get() through fwnode operations, moving the code in fwnode_irq_get() to OF and ACPI frameworks. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Acked-by: Rob Herring <robh@kernel.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-03-31 15:54:50 +03:00
of: property: Add functional dependency link from DT bindings Add device links after the devices are created (but before they are probed) by looking at common DT bindings like clocks and interconnects. Automatically adding device links for functional dependencies at the framework level provides the following benefits: - Optimizes device probe order and avoids the useless work of attempting probes of devices that will not probe successfully (because their suppliers aren't present or haven't probed yet). For example, in a commonly available mobile SoC, registering just one consumer device's driver at an initcall level earlier than the supplier device's driver causes 11 failed probe attempts before the consumer device probes successfully. This was with a kernel with all the drivers statically compiled in. This problem gets a lot worse if all the drivers are loaded as modules without direct symbol dependencies. - Supplier devices like clock providers, interconnect providers, etc need to keep the resources they provide active and at a particular state(s) during boot up even if their current set of consumers don't request the resource to be active. This is because the rest of the consumers might not have probed yet and turning off the resource before all the consumers have probed could lead to a hang or undesired user experience. Some frameworks (Eg: regulator) handle this today by turning off "unused" resources at late_initcall_sync and hoping all the devices have probed by then. This is not a valid assumption for systems with loadable modules. Other frameworks (Eg: clock) just don't handle this due to the lack of a clear signal for when they can turn off resources. This leads to downstream hacks to handle cases like this that can easily be solved in the upstream kernel. By linking devices before they are probed, we give suppliers a clear count of the number of dependent consumers. Once all of the consumers are active, the suppliers can turn off the unused resources without making assumptions about the number of consumers. By default we just add device-links to track "driver presence" (probe succeeded) of the supplier device. If any other functionality provided by device-links are needed, it is left to the consumer/supplier devices to change the link when they probe. kbuild test robot reported clang error about missing const Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20190904211126.47518-4-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-09-04 14:11:22 -07:00
device property: Move FW type specific functionality to FW specific files The device and fwnode property API supports Devicetree, ACPI and pset properties. The implementation of this functionality for each firmware type was embedded in the fwnode property core. Move it out to firmware type specific locations, making it easier to maintain. Depends-on: ("of: Move OF property and graph API from base.c to property.c") Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-06 12:37:37 +03:00
device property: Get rid of struct fwnode_handle type field Instead of relying on the struct fwnode_handle type field, define fwnode_operations structs for all separate types of fwnodes. To find out the type, compare to the ops field to relevant ops structs. This change has two benefits: 1. it avoids adding the type field to each and every instance of struct fwnode_handle, thus saving memory and 2. makes the ops field the single factor that defines both the types of the fwnode as well as defines the implementation of its operations, decreasing the possibility of bugs when developing code dealing with fwnode internals. Suggested-by: Rob Herring <robh@kernel.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-21 14:39:31 +03:00