From patchwork Wed Dec 1 12:59:29 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sakari Ailus X-Patchwork-Id: 519383 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 59ADAC43219 for ; Wed, 1 Dec 2021 12:58:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349438AbhLANCC (ORCPT ); Wed, 1 Dec 2021 08:02:02 -0500 Received: from mga03.intel.com ([134.134.136.65]:14072 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349437AbhLANCA (ORCPT ); Wed, 1 Dec 2021 08:02:00 -0500 X-IronPort-AV: E=McAfee;i="6200,9189,10184"; a="236395263" X-IronPort-AV: E=Sophos;i="5.87,278,1631602800"; d="scan'208";a="236395263" Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Dec 2021 04:58:37 -0800 X-IronPort-AV: E=Sophos;i="5.87,278,1631602800"; d="scan'208";a="512008570" Received: from paasikivi.fi.intel.com ([10.237.72.42]) by fmsmga007-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Dec 2021 04:58:36 -0800 Received: from punajuuri.localdomain (punajuuri.localdomain [192.168.240.130]) by paasikivi.fi.intel.com (Postfix) with ESMTP id 8945820830; Wed, 1 Dec 2021 14:58:34 +0200 (EET) Received: from sailus by punajuuri.localdomain with local (Exim 4.94.2) (envelope-from ) id 1msPCw-003vl4-QR; Wed, 01 Dec 2021 14:59:34 +0200 From: Sakari Ailus To: linux-acpi@vger.kernel.org Cc: andriy.shevchenko@linux.intel.com, heikki.krogerus@linux.intel.com, rafael@kernel.org Subject: [PATCH v2 1/7] device property: Fix fwnode_graph_devcon_match() fwnode leak Date: Wed, 1 Dec 2021 14:59:29 +0200 Message-Id: <20211201125934.936953-2-sakari.ailus@linux.intel.com> X-Mailer: git-send-email 2.30.2 In-Reply-To: <20211201125934.936953-1-sakari.ailus@linux.intel.com> References: <20211201125934.936953-1-sakari.ailus@linux.intel.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org For each endpoint it encounters, fwnode_graph_devcon_match() checks whether the endpoint's remote port parent device is available. If it is not, it ignores the endpoint but does not put the reference to the remote endpoint port parent fwnode. For available devices the fwnode handle reference is put as expected. Put the reference for unavailable devices now. Fixes: 637e9e52b185 ("device connection: Find device connections also from device graphs") Cc: stable@vger.kernel.org # for 5.1 and later Signed-off-by: Sakari Ailus Reviewed-by: Andy Shevchenko --- drivers/base/property.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/base/property.c b/drivers/base/property.c index f1f35b48ab8b9..6df99e526ab0f 100644 --- a/drivers/base/property.c +++ b/drivers/base/property.c @@ -1206,8 +1206,10 @@ fwnode_graph_devcon_match(struct fwnode_handle *fwnode, const char *con_id, fwnode_graph_for_each_endpoint(fwnode, ep) { node = fwnode_graph_get_remote_port_parent(ep); - if (!fwnode_device_is_available(node)) + if (!fwnode_device_is_available(node)) { + fwnode_handle_put(node); continue; + } ret = match(node, con_id, data); fwnode_handle_put(node); From patchwork Wed Dec 1 12:59:32 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sakari Ailus X-Patchwork-Id: 519384 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1EFC6C433F5 for ; Wed, 1 Dec 2021 12:58:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349443AbhLANCA (ORCPT ); Wed, 1 Dec 2021 08:02:00 -0500 Received: from mga11.intel.com ([192.55.52.93]:52084 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349436AbhLANCA (ORCPT ); Wed, 1 Dec 2021 08:02:00 -0500 X-IronPort-AV: E=McAfee;i="6200,9189,10184"; a="233954097" X-IronPort-AV: E=Sophos;i="5.87,278,1631602800"; d="scan'208";a="233954097" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Dec 2021 04:58:38 -0800 X-IronPort-AV: E=Sophos;i="5.87,278,1631602800"; d="scan'208";a="576263590" Received: from paasikivi.fi.intel.com ([10.237.72.42]) by fmsmga004-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Dec 2021 04:58:36 -0800 Received: from punajuuri.localdomain (punajuuri.localdomain [192.168.240.130]) by paasikivi.fi.intel.com (Postfix) with ESMTP id C6706209CC; Wed, 1 Dec 2021 14:58:34 +0200 (EET) Received: from sailus by punajuuri.localdomain with local (Exim 4.94.2) (envelope-from ) id 1msPCx-003vlD-0L; Wed, 01 Dec 2021 14:59:35 +0200 From: Sakari Ailus To: linux-acpi@vger.kernel.org Cc: andriy.shevchenko@linux.intel.com, heikki.krogerus@linux.intel.com, rafael@kernel.org Subject: [PATCH v2 4/7] Documentation: ACPI: Update references Date: Wed, 1 Dec 2021 14:59:32 +0200 Message-Id: <20211201125934.936953-5-sakari.ailus@linux.intel.com> X-Mailer: git-send-email 2.30.2 In-Reply-To: <20211201125934.936953-1-sakari.ailus@linux.intel.com> References: <20211201125934.936953-1-sakari.ailus@linux.intel.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org Update references for the ACPI _DSD documentation. In particular: - Substitute _DSD property and hierarchical data extension documents with the newer DSD guide that replaces both, and use its HTML form. - Refer to the latest ACPI spec. - Add data node reference documentation reference to graph documentation. Signed-off-by: Sakari Ailus Reviewed-by: Andy Shevchenko --- .../acpi/dsd/data-node-references.rst | 18 ++++----- .../firmware-guide/acpi/dsd/graph.rst | 40 +++++++++---------- .../firmware-guide/acpi/dsd/leds.rst | 40 +++++++++---------- Documentation/firmware-guide/acpi/dsd/phy.rst | 28 +++++++------ 4 files changed, 58 insertions(+), 68 deletions(-) diff --git a/Documentation/firmware-guide/acpi/dsd/data-node-references.rst b/Documentation/firmware-guide/acpi/dsd/data-node-references.rst index 8b65b32e6e40e..8d8b53e96bcfe 100644 --- a/Documentation/firmware-guide/acpi/dsd/data-node-references.rst +++ b/Documentation/firmware-guide/acpi/dsd/data-node-references.rst @@ -13,9 +13,9 @@ Hierarchical data extension nodes may not be referred to directly, hence this document defines a scheme to implement such references. A reference consist of the device object name followed by one or more -hierarchical data extension [1] keys. Specifically, the hierarchical data -extension node which is referred to by the key shall lie directly under the -parent object i.e. either the device object or another hierarchical data +hierarchical data extension [dsd-guide] keys. Specifically, the hierarchical +data extension node which is referred to by the key shall lie directly under +the parent object i.e. either the device object or another hierarchical data extension node. The keys in the hierarchical data nodes shall consist of the name of the node, @@ -33,7 +33,7 @@ extension key. Example ======= -In the ASL snippet below, the "reference" _DSD property [2] contains a +In the ASL snippet below, the "reference" _DSD property contains a device object reference to DEV0 and under that device object, a hierarchical data extension key "node@1" referring to the NOD1 object and lastly, a hierarchical data extension key "anothernode" referring to @@ -91,10 +91,6 @@ Documentation/firmware-guide/acpi/dsd/graph.rst. References ========== -[1] Hierarchical Data Extension UUID For _DSD. -, -referenced 2018-07-17. - -[2] Device Properties UUID For _DSD. -, -referenced 2016-10-04. +[dsd-guide] DSD Guide. + https://github.com/UEFI/DSD-Guide/blob/main/dsd-guide.adoc, referenced + 2021-11-30. diff --git a/Documentation/firmware-guide/acpi/dsd/graph.rst b/Documentation/firmware-guide/acpi/dsd/graph.rst index 0ced07cb1be31..b9dbfc73ed25b 100644 --- a/Documentation/firmware-guide/acpi/dsd/graph.rst +++ b/Documentation/firmware-guide/acpi/dsd/graph.rst @@ -7,11 +7,11 @@ Graphs _DSD ==== -_DSD (Device Specific Data) [7] is a predefined ACPI device +_DSD (Device Specific Data) [dsd-guide] is a predefined ACPI device configuration object that can be used to convey information on hardware features which are not specifically covered by the ACPI -specification [1][6]. There are two _DSD extensions that are relevant -for graphs: property [4] and hierarchical data extensions [5]. The +specification [acpi]. There are two _DSD extensions that are relevant +for graphs: property [dsd-guide] and hierarchical data extensions. The property extension provides generic key-value pairs whereas the hierarchical data extension supports nodes with references to other nodes, forming a tree. The nodes in the tree may contain properties as @@ -36,8 +36,9 @@ Ports and endpoints =================== The port and endpoint concepts are very similar to those in Devicetree -[3]. A port represents an interface in a device, and an endpoint -represents a connection to that interface. +[devicetree, graph-bindings]. A port represents an interface in a device, and +an endpoint represents a connection to that interface. Also see [data-node-ref] +for generic data node references. All port nodes are located under the device's "_DSD" node in the hierarchical data extension tree. The data extension related to each port node must begin @@ -153,25 +154,20 @@ the "ISP" device and vice versa. References ========== -[1] _DSD (Device Specific Data) Implementation Guide. - https://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel-1_1.htm, - referenced 2016-10-03. +[acpi] Advanced Configuration and Power Interface Specification. + https://uefi.org/specifications/ACPI/6.4/, referenced 2021-11-30. -[2] Devicetree. https://www.devicetree.org, referenced 2016-10-03. +[data-node-ref] Documentation/firmware-guide/acpi/dsd/data-node-references.rst -[3] Documentation/devicetree/bindings/graph.txt +[devicetree] Devicetree. https://www.devicetree.org, referenced 2016-10-03. -[4] Device Properties UUID For _DSD. - https://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf, - referenced 2016-10-04. +[dsd-guide] DSD Guide. + https://github.com/UEFI/DSD-Guide/blob/main/dsd-guide.adoc, referenced + 2021-11-30. -[5] Hierarchical Data Extension UUID For _DSD. - https://www.uefi.org/sites/default/files/resources/_DSD-hierarchical-data-extension-UUID-v1.1.pdf, - referenced 2016-10-04. - -[6] Advanced Configuration and Power Interface Specification. - https://www.uefi.org/sites/default/files/resources/ACPI_6_1.pdf, - referenced 2016-10-04. - -[7] _DSD Device Properties Usage Rules. +[dsd-rules] _DSD Device Properties Usage Rules. Documentation/firmware-guide/acpi/DSD-properties-rules.rst + +[graph-bindings] Common bindings for device graphs (Devicetree). + https://github.com/devicetree-org/dt-schema/blob/main/schemas/graph.yaml, + referenced 2021-11-30. diff --git a/Documentation/firmware-guide/acpi/dsd/leds.rst b/Documentation/firmware-guide/acpi/dsd/leds.rst index b99fff8e06f28..93db592c93c71 100644 --- a/Documentation/firmware-guide/acpi/dsd/leds.rst +++ b/Documentation/firmware-guide/acpi/dsd/leds.rst @@ -5,19 +5,20 @@ Describing and referring to LEDs in ACPI ======================================== -Individual LEDs are described by hierarchical data extension [6] nodes under the +Individual LEDs are described by hierarchical data extension [5] nodes under the device node, the LED driver chip. The "reg" property in the LED specific nodes tells the numerical ID of each individual LED output to which the LEDs are -connected. [3] The hierarchical data nodes are named "led@X", where X is the +connected. [leds] The hierarchical data nodes are named "led@X", where X is the number of the LED output. -Referring to LEDs in Device tree is documented in [4], in "flash-leds" property -documentation. In short, LEDs are directly referred to by using phandles. +Referring to LEDs in Device tree is documented in [video-interfaces], in +"flash-leds" property documentation. In short, LEDs are directly referred to by +using phandles. -While Device tree allows referring to any node in the tree[1], in ACPI -references are limited to device nodes only [2]. For this reason using the same -mechanism on ACPI is not possible. A mechanism to refer to non-device ACPI nodes -is documented in [7]. +While Device tree allows referring to any node in the tree [devicetree], in +ACPI references are limited to device nodes only [acpi]. For this reason using +the same mechanism on ACPI is not possible. A mechanism to refer to non-device +ACPI nodes is documented in [data-node-ref]. ACPI allows (as does DT) using integer arguments after the reference. A combination of the LED driver device reference and an integer argument, @@ -90,22 +91,17 @@ where References ========== -[1] Device tree. https://www.devicetree.org, referenced 2019-02-21. +[acpi] Advanced Configuration and Power Interface Specification. + https://uefi.org/specifications/ACPI/6.4/, referenced 2021-11-30. -[2] Advanced Configuration and Power Interface Specification. - https://uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf, - referenced 2019-02-21. +[data-node-ref] Documentation/firmware-guide/acpi/dsd/data-node-references.rst -[3] Documentation/devicetree/bindings/leds/common.txt +[devicetree] Devicetree. https://www.devicetree.org, referenced 2019-02-21. -[4] Documentation/devicetree/bindings/media/video-interfaces.txt +[dsd-guide] DSD Guide. + https://github.com/UEFI/DSD-Guide/blob/main/dsd-guide.adoc, referenced + 2021-11-30. -[5] Device Properties UUID For _DSD. - https://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf, - referenced 2019-02-21. +[leds] Documentation/devicetree/bindings/leds/common.yaml -[6] Hierarchical Data Extension UUID For _DSD. - https://www.uefi.org/sites/default/files/resources/_DSD-hierarchical-data-extension-UUID-v1.1.pdf, - referenced 2019-02-21. - -[7] Documentation/firmware-guide/acpi/dsd/data-node-references.rst +[video-interfaces] Documentation/devicetree/bindings/media/video-interfaces.yaml diff --git a/Documentation/firmware-guide/acpi/dsd/phy.rst b/Documentation/firmware-guide/acpi/dsd/phy.rst index 680ad179e5f9d..673ac374f92ac 100644 --- a/Documentation/firmware-guide/acpi/dsd/phy.rst +++ b/Documentation/firmware-guide/acpi/dsd/phy.rst @@ -4,17 +4,17 @@ MDIO bus and PHYs in ACPI ========================= -The PHYs on an MDIO bus [1] are probed and registered using +The PHYs on an MDIO bus [phy] are probed and registered using fwnode_mdiobus_register_phy(). Later, for connecting these PHYs to their respective MACs, the PHYs registered on the MDIO bus have to be referenced. This document introduces two _DSD properties that are to be used -for connecting PHYs on the MDIO bus [3] to the MAC layer. +for connecting PHYs on the MDIO bus [dsd-properties-rules] to the MAC layer. These properties are defined in accordance with the "Device -Properties UUID For _DSD" [2] document and the +Properties UUID For _DSD" [dsd-guide] document and the daffd814-6eba-4d8c-8a91-bc9bbf4aa301 UUID must be used in the Device Data Descriptors containing them. @@ -48,22 +48,22 @@ as device object references (e.g. \_SB.MDI0.PHY1). phy-mode -------- The "phy-mode" _DSD property is used to describe the connection to -the PHY. The valid values for "phy-mode" are defined in [4]. +the PHY. The valid values for "phy-mode" are defined in [ethernet-controller]. managed ------- Optional property, which specifies the PHY management type. -The valid values for "managed" are defined in [4]. +The valid values for "managed" are defined in [ethernet-controller]. fixed-link ---------- The "fixed-link" is described by a data-only subnode of the MAC port, which is linked in the _DSD package via hierarchical data extension (UUID dbb8e3e6-5886-4ba6-8795-1319f52a966b -in accordance with [5] "_DSD Implementation Guide" document). +in accordance with [dsd-guide] "_DSD Implementation Guide" document). The subnode should comprise a required property ("speed") and possibly the optional ones - complete list of parameters and -their values are specified in [4]. +their values are specified in [ethernet-controller]. The following ASL example illustrates the usage of these properties. @@ -188,12 +188,14 @@ MAC node example with a "fixed-link" subnode. References ========== -[1] Documentation/networking/phy.rst +[phy] Documentation/networking/phy.rst -[2] https://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf +[dsd-properties-rules] + Documentation/firmware-guide/acpi/DSD-properties-rules.rst -[3] Documentation/firmware-guide/acpi/DSD-properties-rules.rst +[ethernet-controller] + Documentation/devicetree/bindings/net/ethernet-controller.yaml -[4] Documentation/devicetree/bindings/net/ethernet-controller.yaml - -[5] https://github.com/UEFI/DSD-Guide/blob/main/dsd-guide.pdf +[dsd-guide] DSD Guide. + https://github.com/UEFI/DSD-Guide/blob/main/dsd-guide.adoc, referenced + 2021-11-30. From patchwork Wed Dec 1 12:59:33 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sakari Ailus X-Patchwork-Id: 519382 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B5BFAC4321E for ; Wed, 1 Dec 2021 12:58:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349449AbhLANCD (ORCPT ); Wed, 1 Dec 2021 08:02:03 -0500 Received: from mga01.intel.com ([192.55.52.88]:57001 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349447AbhLANCC (ORCPT ); Wed, 1 Dec 2021 08:02:02 -0500 X-IronPort-AV: E=McAfee;i="6200,9189,10184"; a="260426455" X-IronPort-AV: E=Sophos;i="5.87,278,1631602800"; d="scan'208";a="260426455" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Dec 2021 04:58:41 -0800 X-IronPort-AV: E=Sophos;i="5.87,278,1631602800"; d="scan'208";a="460017249" Received: from paasikivi.fi.intel.com ([10.237.72.42]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Dec 2021 04:58:39 -0800 Received: from punajuuri.localdomain (punajuuri.localdomain [192.168.240.130]) by paasikivi.fi.intel.com (Postfix) with ESMTP id DE029209F3; Wed, 1 Dec 2021 14:58:34 +0200 (EET) Received: from sailus by punajuuri.localdomain with local (Exim 4.94.2) (envelope-from ) id 1msPCx-003vlH-4c; Wed, 01 Dec 2021 14:59:35 +0200 From: Sakari Ailus To: linux-acpi@vger.kernel.org Cc: andriy.shevchenko@linux.intel.com, heikki.krogerus@linux.intel.com, rafael@kernel.org Subject: [PATCH v2 5/7] device property: Implement fwnode_graph_get_endpoint_count() Date: Wed, 1 Dec 2021 14:59:33 +0200 Message-Id: <20211201125934.936953-6-sakari.ailus@linux.intel.com> X-Mailer: git-send-email 2.30.2 In-Reply-To: <20211201125934.936953-1-sakari.ailus@linux.intel.com> References: <20211201125934.936953-1-sakari.ailus@linux.intel.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org Add fwnode_graph_get_endpoint_count() function to provide generic implementation of of_graph_get_endpoint_count(). The former by default only counts endpoints to available devices which is consistent with the rest of the fwnode graph API. By providing FWNODE_GRAPH_DEVICE_DISABLED flag, also unconnected endpoints and endpoints to disabled devices are counted. Signed-off-by: Sakari Ailus Reviewed-by: Andy Shevchenko --- drivers/base/property.c | 49 ++++++++++++++++++++++++++++++++-------- include/linux/property.h | 2 ++ 2 files changed, 41 insertions(+), 10 deletions(-) diff --git a/drivers/base/property.c b/drivers/base/property.c index ecc4e2eb10678..90075c051dccf 100644 --- a/drivers/base/property.c +++ b/drivers/base/property.c @@ -1097,6 +1097,18 @@ fwnode_graph_get_remote_node(const struct fwnode_handle *fwnode, u32 port_id, } EXPORT_SYMBOL_GPL(fwnode_graph_get_remote_node); +static bool fwnode_graph_remote_available(struct fwnode_handle *ep) +{ + struct fwnode_handle *dev_node; + bool available; + + dev_node = fwnode_graph_get_remote_port_parent(ep); + available = fwnode_device_is_available(dev_node); + fwnode_handle_put(dev_node); + + return available; +} + /** * fwnode_graph_get_endpoint_by_id - get endpoint by port and endpoint numbers * @fwnode: parent fwnode_handle containing the graph @@ -1130,16 +1142,8 @@ fwnode_graph_get_endpoint_by_id(const struct fwnode_handle *fwnode, struct fwnode_endpoint fwnode_ep = { 0 }; int ret; - if (enabled_only) { - struct fwnode_handle *dev_node; - bool available; - - dev_node = fwnode_graph_get_remote_port_parent(ep); - available = fwnode_device_is_available(dev_node); - fwnode_handle_put(dev_node); - if (!available) - continue; - } + if (enabled_only && !fwnode_graph_remote_available(ep)) + continue; ret = fwnode_graph_parse_endpoint(ep, &fwnode_ep); if (ret < 0) @@ -1172,6 +1176,31 @@ fwnode_graph_get_endpoint_by_id(const struct fwnode_handle *fwnode, } EXPORT_SYMBOL_GPL(fwnode_graph_get_endpoint_by_id); +/** + * fwnode_graph_get_endpoint_count - Count endpoints on a device node + * @fwnode: The node related to a device + * @flags: fwnode lookup flags + * Count endpoints in a device node. + * + * If FWNODE_GRAPH_DEVICE_DISABLED flag is specified, also unconnected endpoints + * and endpoints connected to disabled devices are counted. + */ +unsigned int fwnode_graph_get_endpoint_count(struct fwnode_handle *fwnode, + unsigned long flags) +{ + struct fwnode_handle *ep; + unsigned int count = 0; + + fwnode_graph_for_each_endpoint(fwnode, ep) { + if (flags & FWNODE_GRAPH_DEVICE_DISABLED || + fwnode_graph_remote_available(ep)) + count++; + } + + return count; +} +EXPORT_SYMBOL_GPL(fwnode_graph_get_endpoint_count); + /** * fwnode_graph_parse_endpoint - parse common endpoint node properties * @fwnode: pointer to endpoint fwnode_handle diff --git a/include/linux/property.h b/include/linux/property.h index af5a7e512c86f..e32b95f42c9db 100644 --- a/include/linux/property.h +++ b/include/linux/property.h @@ -427,6 +427,8 @@ static inline bool fwnode_graph_is_endpoint(struct fwnode_handle *fwnode) struct fwnode_handle * fwnode_graph_get_endpoint_by_id(const struct fwnode_handle *fwnode, u32 port, u32 endpoint, unsigned long flags); +unsigned int fwnode_graph_get_endpoint_count(struct fwnode_handle *fwnode, + unsigned long flags); #define fwnode_graph_for_each_endpoint(fwnode, child) \ for (child = NULL; \ From patchwork Wed Dec 1 13:01:15 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sakari Ailus X-Patchwork-Id: 519381 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4B9BEC4332F for ; Wed, 1 Dec 2021 13:00:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349454AbhLANDm (ORCPT ); Wed, 1 Dec 2021 08:03:42 -0500 Received: from mga03.intel.com ([134.134.136.65]:14213 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349377AbhLANDk (ORCPT ); Wed, 1 Dec 2021 08:03:40 -0500 X-IronPort-AV: E=McAfee;i="6200,9189,10184"; a="236395544" X-IronPort-AV: E=Sophos;i="5.87,278,1631602800"; d="scan'208";a="236395544" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Dec 2021 05:00:19 -0800 X-IronPort-AV: E=Sophos;i="5.87,278,1631602800"; d="scan'208";a="609542469" Received: from paasikivi.fi.intel.com ([10.237.72.42]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Dec 2021 05:00:17 -0800 Received: from punajuuri.localdomain (punajuuri.localdomain [192.168.240.130]) by paasikivi.fi.intel.com (Postfix) with ESMTP id 6062C2036B; Wed, 1 Dec 2021 15:00:15 +0200 (EET) Received: from sailus by punajuuri.localdomain with local (Exim 4.94.2) (envelope-from ) id 1msPEZ-003vmX-MH; Wed, 01 Dec 2021 15:01:15 +0200 From: Sakari Ailus To: linux-acpi@vger.kernel.org Cc: andriy.shevchenko@linux.intel.com, heikki.krogerus@linux.intel.com, rafael@kernel.org, Thierry Reding , Jonathan Hunter , Sowjanya Komatineni , linux-tegra@vger.kernel.org, linux-media@vger.kernel.org Subject: [PATCH v2 7/7] device property: Drop fwnode_graph_get_remote_node() Date: Wed, 1 Dec 2021 15:01:15 +0200 Message-Id: <20211201130115.937052-1-sakari.ailus@linux.intel.com> X-Mailer: git-send-email 2.30.2 In-Reply-To: <20211201125934.936953-1-sakari.ailus@linux.intel.com> References: <20211201125934.936953-1-sakari.ailus@linux.intel.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org fwnode_graph_get_remote_node() is only used by the tegra-video driver. Convert it to use newer fwnode_graph_get_endpoint_by_id() and drop now-unused fwnode_graph_get_remote_node(). Signed-off-by: Sakari Ailus Reviewed-by: Andy Shevchenko --- drivers/base/property.c | 38 -------------------------- drivers/staging/media/tegra-video/vi.c | 12 +++++--- include/linux/property.h | 3 -- 3 files changed, 8 insertions(+), 45 deletions(-) diff --git a/drivers/base/property.c b/drivers/base/property.c index 78106192babb8..a7086e5526445 100644 --- a/drivers/base/property.c +++ b/drivers/base/property.c @@ -1059,44 +1059,6 @@ fwnode_graph_get_remote_endpoint(const struct fwnode_handle *fwnode) } EXPORT_SYMBOL_GPL(fwnode_graph_get_remote_endpoint); -/** - * fwnode_graph_get_remote_node - get remote parent node for given port/endpoint - * @fwnode: pointer to parent fwnode_handle containing graph port/endpoint - * @port_id: identifier of the parent port node - * @endpoint_id: identifier of the endpoint node - * - * Return: Remote fwnode handle associated with remote endpoint node linked - * to @node. Use fwnode_node_put() on it when done. - */ -struct fwnode_handle * -fwnode_graph_get_remote_node(const struct fwnode_handle *fwnode, u32 port_id, - u32 endpoint_id) -{ - struct fwnode_handle *endpoint; - - fwnode_graph_for_each_endpoint(fwnode, endpoint) { - struct fwnode_endpoint fwnode_ep; - struct fwnode_handle *remote; - int ret; - - ret = fwnode_graph_parse_endpoint(endpoint, &fwnode_ep); - if (ret < 0) - continue; - - if (fwnode_ep.port != port_id || fwnode_ep.id != endpoint_id) - continue; - - remote = fwnode_graph_get_remote_port_parent(endpoint); - if (!remote) - return NULL; - - return fwnode_device_is_available(remote) ? remote : NULL; - } - - return NULL; -} -EXPORT_SYMBOL_GPL(fwnode_graph_get_remote_node); - static bool fwnode_graph_remote_available(struct fwnode_handle *ep) { struct fwnode_handle *dev_node; diff --git a/drivers/staging/media/tegra-video/vi.c b/drivers/staging/media/tegra-video/vi.c index 69d9787d53384..d1f43f465c224 100644 --- a/drivers/staging/media/tegra-video/vi.c +++ b/drivers/staging/media/tegra-video/vi.c @@ -1845,7 +1845,6 @@ static int tegra_vi_graph_init(struct tegra_vi *vi) struct tegra_vi_channel *chan; struct fwnode_handle *fwnode = dev_fwnode(vi->dev); int ret; - struct fwnode_handle *remote = NULL; /* * Walk the links to parse the full graph. Each channel will have @@ -1857,11 +1856,16 @@ static int tegra_vi_graph_init(struct tegra_vi *vi) * next channels. */ list_for_each_entry(chan, &vi->vi_chans, list) { - remote = fwnode_graph_get_remote_node(fwnode, chan->portnos[0], - 0); - if (!remote) + struct fwnode_handle *ep, *remote; + + ep = fwnode_graph_get_endpoint_by_id(fwnode, + chan->portnos[0], 0, 0); + if (!ep) continue; + remote = fwnode_graph_get_remote_port_parent(ep); + fwnode_handle_put(ep); + ret = tegra_vi_graph_parse_one(chan, remote); fwnode_handle_put(remote); if (ret < 0 || list_empty(&chan->notifier.asd_list)) diff --git a/include/linux/property.h b/include/linux/property.h index e32b95f42c9db..3a31765895c11 100644 --- a/include/linux/property.h +++ b/include/linux/property.h @@ -401,9 +401,6 @@ struct fwnode_handle *fwnode_graph_get_remote_port( const struct fwnode_handle *fwnode); struct fwnode_handle *fwnode_graph_get_remote_endpoint( const struct fwnode_handle *fwnode); -struct fwnode_handle * -fwnode_graph_get_remote_node(const struct fwnode_handle *fwnode, u32 port, - u32 endpoint); static inline bool fwnode_graph_is_endpoint(struct fwnode_handle *fwnode) {