[PATCH 1/7] device property: Fix fwnode_graph_devcon_match() fwnode leak

[PATCH 1/7] device property: Fix fwnode_graph_devcon_match() fwnode leak

[Sakari Ailus]

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 <sakari.ailus@linux.intel.com>
---
 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);
-- 
2.30.2

[PATCH 2/7] device property: Fix documentation for FWNODE_GRAPH_DEVICE_DISABLED

[Sakari Ailus]

FWNODE_GRAPH_DEVICE_DISABLED flag was meant for also returning endpoints
connected to disabled devices, but it also may return endpoints that are
not connected. Fix this in documentation. Also
fwnode_graph_get_endpoint_by_id() was affeced by this.

Also improve the language a little bit.

Fixes: 0fcc2bdc8aff ("device property: Add fwnode_graph_get_endpoint_by_id()")
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
---
 drivers/base/property.c  | 4 ++--
 include/linux/property.h | 3 ++-
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/base/property.c b/drivers/base/property.c
index 6df99e526ab0f..ecc4e2eb10678 100644
--- a/drivers/base/property.c
+++ b/drivers/base/property.c
@@ -1111,8 +1111,8 @@ EXPORT_SYMBOL_GPL(fwnode_graph_get_remote_node);
  * has not been found, look for the closest endpoint ID greater than the
  * specified one and return the endpoint that corresponds to it, if present.
  *
- * Do not return endpoints that belong to disabled devices, unless
- * FWNODE_GRAPH_DEVICE_DISABLED is passed in @flags.
+ * Does not return endpoints that belong to disabled devices or endpoints that
+ * are unconnected, unless FWNODE_GRAPH_DEVICE_DISABLED is passed in @flags.
  *
  * The returned endpoint needs to be released by calling fwnode_handle_put() on
  * it when it is not needed any more.
diff --git a/include/linux/property.h b/include/linux/property.h
index 88fa726a76df7..af5a7e512c86f 100644
--- a/include/linux/property.h
+++ b/include/linux/property.h
@@ -418,7 +418,8 @@ static inline bool fwnode_graph_is_endpoint(struct fwnode_handle *fwnode)
  *				one.
  * @FWNODE_GRAPH_DEVICE_DISABLED: That the device to which the remote
  *				  endpoint of the given endpoint belongs to,
- *				  may be disabled.
+ *				  may be disabled, or that the endpoint is not
+ *				  connected.
  */
 #define FWNODE_GRAPH_ENDPOINT_NEXT	BIT(0)
 #define FWNODE_GRAPH_DEVICE_DISABLED	BIT(1)
-- 
2.30.2

[PATCH 3/7] Documentation: ACPI: Fix data node reference documentation

[Sakari Ailus]

The data node reference documentation was missing a package that must
contain the property values, instead property name and multiple values
being present in a single package. This is not aligned with the _DSD spec.
Fix it by adding the package for the values.

Also add the missing "reg" properties to two numbered nodes.

Fixes: b10134a3643d ("ACPI: property: Document hierarchical data extension references")
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
---
 .../firmware-guide/acpi/dsd/data-node-references.rst      | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/Documentation/firmware-guide/acpi/dsd/data-node-references.rst b/Documentation/firmware-guide/acpi/dsd/data-node-references.rst
index b7ad47df49de0..166bf9a944bc8 100644
--- a/Documentation/firmware-guide/acpi/dsd/data-node-references.rst
+++ b/Documentation/firmware-guide/acpi/dsd/data-node-references.rst
@@ -5,7 +5,7 @@
 Referencing hierarchical data nodes
 ===================================
 
-:Copyright: |copy| 2018 Intel Corporation
+:Copyright: |copy| 2018, 2021 Intel Corporation
 :Author: Sakari Ailus <sakari.ailus@linux.intel.com>
 
 ACPI in general allows referring to device objects in the tree only.
@@ -52,12 +52,14 @@ the ANOD object which is also the final target node of the reference.
 	    Name (NOD0, Package() {
 		ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
 		Package () {
+		    Package () { "reg", 0 },
 		    Package () { "random-property", 3 },
 		}
 	    })
 	    Name (NOD1, Package() {
 		ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
 		Package () {
+		    Package () { "reg", 1 },
 		    Package () { "anothernode", "ANOD" },
 		}
 	    })
@@ -74,7 +76,9 @@ the ANOD object which is also the final target node of the reference.
 	    Name (_DSD, Package () {
 		ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
 		Package () {
-		    Package () { "reference", ^DEV0, "node@1", "anothernode" },
+		    Package () { "reference",
+				 Package () { ^DEV0,
+					      "node@1", "anothernode" } },
 		}
 	    })
 	}
-- 
2.30.2

Re: [PATCH 3/7] Documentation: ACPI: Fix data node reference documentation

[Andy Shevchenko]

On Tue, Nov 30, 2021 at 05:32:46PM +0200, Sakari Ailus wrote:
> The data node reference documentation was missing a package that must
> contain the property values, instead property name and multiple values
> being present in a single package. This is not aligned with the _DSD spec.
> Fix it by adding the package for the values.
> 
> Also add the missing "reg" properties to two numbered nodes.
> 
> Fixes: b10134a3643d ("ACPI: property: Document hierarchical data extension references")
> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
> ---
>  .../firmware-guide/acpi/dsd/data-node-references.rst      | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/firmware-guide/acpi/dsd/data-node-references.rst b/Documentation/firmware-guide/acpi/dsd/data-node-references.rst
> index b7ad47df49de0..166bf9a944bc8 100644
> --- a/Documentation/firmware-guide/acpi/dsd/data-node-references.rst
> +++ b/Documentation/firmware-guide/acpi/dsd/data-node-references.rst
> @@ -5,7 +5,7 @@
>  Referencing hierarchical data nodes
>  ===================================
>  
> -:Copyright: |copy| 2018 Intel Corporation
> +:Copyright: |copy| 2018, 2021 Intel Corporation
>  :Author: Sakari Ailus <sakari.ailus@linux.intel.com>
>  
>  ACPI in general allows referring to device objects in the tree only.
> @@ -52,12 +52,14 @@ the ANOD object which is also the final target node of the reference.
>  	    Name (NOD0, Package() {
>  		ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
>  		Package () {
> +		    Package () { "reg", 0 },
>  		    Package () { "random-property", 3 },
>  		}
>  	    })
>  	    Name (NOD1, Package() {
>  		ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
>  		Package () {
> +		    Package () { "reg", 1 },
>  		    Package () { "anothernode", "ANOD" },
>  		}
>  	    })
> @@ -74,7 +76,9 @@ the ANOD object which is also the final target node of the reference.
>  	    Name (_DSD, Package () {
>  		ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
>  		Package () {
> -		    Package () { "reference", ^DEV0, "node@1", "anothernode" },

> +		    Package () { "reference",
> +				 Package () { ^DEV0,
> +					      "node@1", "anothernode" } },

Can it be rather this

		    Package () {
		        "reference", Package () { ^DEV0, "node@1", "anothernode" }
		    },

or this way

		    Package () {
		        "reference", Package () {
			   ^DEV0, "node@1", "anothernode"
			}
		    },

?

>  		}
>  	    })
>  	}
> -- 
> 2.30.2
> 

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 3/7] Documentation: ACPI: Fix data node reference documentation

[Sakari Ailus]

On Tue, Nov 30, 2021 at 05:55:52PM +0200, Andy Shevchenko wrote:
> On Tue, Nov 30, 2021 at 05:32:46PM +0200, Sakari Ailus wrote:
> > The data node reference documentation was missing a package that must
> > contain the property values, instead property name and multiple values
> > being present in a single package. This is not aligned with the _DSD spec.
> > Fix it by adding the package for the values.
> > 
> > Also add the missing "reg" properties to two numbered nodes.
> > 
> > Fixes: b10134a3643d ("ACPI: property: Document hierarchical data extension references")
> > Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
> > ---
> >  .../firmware-guide/acpi/dsd/data-node-references.rst      | 8 ++++++--
> >  1 file changed, 6 insertions(+), 2 deletions(-)
> > 
> > diff --git a/Documentation/firmware-guide/acpi/dsd/data-node-references.rst b/Documentation/firmware-guide/acpi/dsd/data-node-references.rst
> > index b7ad47df49de0..166bf9a944bc8 100644
> > --- a/Documentation/firmware-guide/acpi/dsd/data-node-references.rst
> > +++ b/Documentation/firmware-guide/acpi/dsd/data-node-references.rst
> > @@ -5,7 +5,7 @@
> >  Referencing hierarchical data nodes
> >  ===================================
> >  
> > -:Copyright: |copy| 2018 Intel Corporation
> > +:Copyright: |copy| 2018, 2021 Intel Corporation
> >  :Author: Sakari Ailus <sakari.ailus@linux.intel.com>
> >  
> >  ACPI in general allows referring to device objects in the tree only.
> > @@ -52,12 +52,14 @@ the ANOD object which is also the final target node of the reference.
> >  	    Name (NOD0, Package() {
> >  		ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> >  		Package () {
> > +		    Package () { "reg", 0 },
> >  		    Package () { "random-property", 3 },
> >  		}
> >  	    })
> >  	    Name (NOD1, Package() {
> >  		ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
> >  		Package () {
> > +		    Package () { "reg", 1 },
> >  		    Package () { "anothernode", "ANOD" },
> >  		}
> >  	    })
> > @@ -74,7 +76,9 @@ the ANOD object which is also the final target node of the reference.
> >  	    Name (_DSD, Package () {
> >  		ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> >  		Package () {
> > -		    Package () { "reference", ^DEV0, "node@1", "anothernode" },
> 
> > +		    Package () { "reference",
> > +				 Package () { ^DEV0,
> > +					      "node@1", "anothernode" } },
> 
> Can it be rather this
> 
> 		    Package () {
> 		        "reference", Package () { ^DEV0, "node@1", "anothernode" }
> 		    },
> 
> or this way
> 
> 		    Package () {
> 		        "reference", Package () {
> 			   ^DEV0, "node@1", "anothernode"
> 			}
> 		    },
> 
> ?

How about:

		    Package () {
		        "reference",
		        Package () { ^DEV0, "node@1", "anothernode" },
		    },

-- 
Sakari Ailus

Re: [PATCH 3/7] Documentation: ACPI: Fix data node reference documentation

[Rafael J. Wysocki]

On Tue, Nov 30, 2021 at 9:42 PM Sakari Ailus
<sakari.ailus@linux.intel.com> wrote:
>
> On Tue, Nov 30, 2021 at 05:55:52PM +0200, Andy Shevchenko wrote:
> > On Tue, Nov 30, 2021 at 05:32:46PM +0200, Sakari Ailus wrote:
> > > The data node reference documentation was missing a package that must
> > > contain the property values, instead property name and multiple values
> > > being present in a single package. This is not aligned with the _DSD spec.
> > > Fix it by adding the package for the values.
> > >
> > > Also add the missing "reg" properties to two numbered nodes.
> > >
> > > Fixes: b10134a3643d ("ACPI: property: Document hierarchical data extension references")
> > > Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
> > > ---
> > >  .../firmware-guide/acpi/dsd/data-node-references.rst      | 8 ++++++--
> > >  1 file changed, 6 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/Documentation/firmware-guide/acpi/dsd/data-node-references.rst b/Documentation/firmware-guide/acpi/dsd/data-node-references.rst
> > > index b7ad47df49de0..166bf9a944bc8 100644
> > > --- a/Documentation/firmware-guide/acpi/dsd/data-node-references.rst
> > > +++ b/Documentation/firmware-guide/acpi/dsd/data-node-references.rst
> > > @@ -5,7 +5,7 @@
> > >  Referencing hierarchical data nodes
> > >  ===================================
> > >
> > > -:Copyright: |copy| 2018 Intel Corporation
> > > +:Copyright: |copy| 2018, 2021 Intel Corporation
> > >  :Author: Sakari Ailus <sakari.ailus@linux.intel.com>
> > >
> > >  ACPI in general allows referring to device objects in the tree only.
> > > @@ -52,12 +52,14 @@ the ANOD object which is also the final target node of the reference.
> > >         Name (NOD0, Package() {
> > >             ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> > >             Package () {
> > > +               Package () { "reg", 0 },
> > >                 Package () { "random-property", 3 },
> > >             }
> > >         })
> > >         Name (NOD1, Package() {
> > >             ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
> > >             Package () {
> > > +               Package () { "reg", 1 },
> > >                 Package () { "anothernode", "ANOD" },
> > >             }
> > >         })
> > > @@ -74,7 +76,9 @@ the ANOD object which is also the final target node of the reference.
> > >         Name (_DSD, Package () {
> > >             ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> > >             Package () {
> > > -               Package () { "reference", ^DEV0, "node@1", "anothernode" },
> >
> > > +               Package () { "reference",
> > > +                            Package () { ^DEV0,
> > > +                                         "node@1", "anothernode" } },
> >
> > Can it be rather this
> >
> >                   Package () {
> >                       "reference", Package () { ^DEV0, "node@1", "anothernode" }
> >                   },
> >
> > or this way
> >
> >                   Package () {
> >                       "reference", Package () {
> >                          ^DEV0, "node@1", "anothernode"
> >                       }
> >                   },
> >
> > ?
>
> How about:
>
>                     Package () {
>                         "reference",
>                         Package () { ^DEV0, "node@1", "anothernode" },
>                     },
>

Please keep "reference" and the following Package () on the same line.

[PATCH 4/7] Documentation: ACPI: Update references

[Sakari Ailus]

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 <sakari.ailus@linux.intel.com>
---
 .../acpi/dsd/data-node-references.rst         | 11 ++----
 .../firmware-guide/acpi/dsd/graph.rst         | 39 ++++++++-----------
 .../firmware-guide/acpi/dsd/leds.rst          | 24 +++++-------
 Documentation/firmware-guide/acpi/dsd/phy.rst | 21 +++++-----
 4 files changed, 39 insertions(+), 56 deletions(-)

diff --git a/Documentation/firmware-guide/acpi/dsd/data-node-references.rst b/Documentation/firmware-guide/acpi/dsd/data-node-references.rst
index 166bf9a944bc8..87012dbd0a456 100644
--- a/Documentation/firmware-guide/acpi/dsd/data-node-references.rst
+++ b/Documentation/firmware-guide/acpi/dsd/data-node-references.rst
@@ -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
@@ -89,10 +89,5 @@ Documentation/firmware-guide/acpi/dsd/graph.rst.
 References
 ==========
 
-[1] Hierarchical Data Extension UUID For _DSD.
-<https://www.uefi.org/sites/default/files/resources/_DSD-hierarchical-data-extension-UUID-v1.1.pdf>,
-referenced 2018-07-17.
-
-[2] Device Properties UUID For _DSD.
-<https://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf>,
-referenced 2016-10-04.
+[1] 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..5d27cd10b53ba 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) [3] 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 [4]. There are two _DSD extensions that are relevant
+for graphs: property [3] 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.
+[1, 2]. A port represents an interface in a device, and an endpoint
+represents a connection to that interface. Also see [6] 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,19 @@ 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.
+[1] Devicetree. https://www.devicetree.org, referenced 2016-10-03.
 
-[2] Devicetree. https://www.devicetree.org, referenced 2016-10-03.
+[2] Common bindings for device graphs (Devicetree).
+    https://github.com/devicetree-org/dt-schema/blob/main/schemas/graph.yaml,
+    referenced 2021-11-30.
 
-[3] Documentation/devicetree/bindings/graph.txt
+[3] DSD Guide. https://github.com/UEFI/DSD-Guide/blob/main/dsd-guide.adoc,
+    referenced 2021-11-30.
 
-[4] Device Properties UUID For _DSD.
-    https://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf,
-    referenced 2016-10-04.
+[4] Advanced Configuration and Power Interface Specification.
+    https://uefi.org/specifications/ACPI/6.4/, 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.
+[5] _DSD Device Properties Usage Rules.
     Documentation/firmware-guide/acpi/DSD-properties-rules.rst
+
+[6] Documentation/firmware-guide/acpi/dsd/data-node-references.rst
diff --git a/Documentation/firmware-guide/acpi/dsd/leds.rst b/Documentation/firmware-guide/acpi/dsd/leds.rst
index b99fff8e06f28..d7c8b605eba39 100644
--- a/Documentation/firmware-guide/acpi/dsd/leds.rst
+++ b/Documentation/firmware-guide/acpi/dsd/leds.rst
@@ -5,7 +5,7 @@
 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
@@ -17,7 +17,7 @@ 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].
+is documented in [6].
 
 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 +90,16 @@ where
 References
 ==========
 
-[1] Device tree. https://www.devicetree.org, referenced 2019-02-21.
+[1] Devicetree. https://www.devicetree.org, referenced 2019-02-21.
 
 [2] Advanced Configuration and Power Interface Specification.
-    https://uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf,
-    referenced 2019-02-21.
+    https://uefi.org/specifications/ACPI/6.4/, referenced 2021-11-30.
 
-[3] Documentation/devicetree/bindings/leds/common.txt
+[3] Documentation/devicetree/bindings/leds/common.yaml
 
-[4] Documentation/devicetree/bindings/media/video-interfaces.txt
+[4] Documentation/devicetree/bindings/media/video-interfaces.yaml
 
-[5] Device Properties UUID For _DSD.
-    https://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf,
-    referenced 2019-02-21.
+[5] DSD Guide. https://github.com/UEFI/DSD-Guide/blob/main/dsd-guide.adoc,
+    referenced 2021-11-30.
 
-[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
+[6] Documentation/firmware-guide/acpi/dsd/data-node-references.rst
diff --git a/Documentation/firmware-guide/acpi/dsd/phy.rst b/Documentation/firmware-guide/acpi/dsd/phy.rst
index 680ad179e5f9d..c22f25012848d 100644
--- a/Documentation/firmware-guide/acpi/dsd/phy.rst
+++ b/Documentation/firmware-guide/acpi/dsd/phy.rst
@@ -11,10 +11,10 @@ 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 [2] 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" [4] 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 [3].
 
 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 [3].
 
 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 [4] "_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 [3].
 
 The following ASL example illustrates the usage of these properties.
 
@@ -190,10 +190,9 @@ References
 
 [1] Documentation/networking/phy.rst
 
-[2] https://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf
+[2] Documentation/firmware-guide/acpi/DSD-properties-rules.rst
 
-[3] Documentation/firmware-guide/acpi/DSD-properties-rules.rst
+[3] 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
+[4] DSD Guide. https://github.com/UEFI/DSD-Guide/blob/main/dsd-guide.adoc,
+    referenced 2021-11-30.
-- 
2.30.2

Re: [PATCH 4/7] Documentation: ACPI: Update references

[Andy Shevchenko]

On Tue, Nov 30, 2021 at 05:32:47PM +0200, Sakari Ailus wrote:
> 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.

...

> -[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.
> +[1] Devicetree. https://www.devicetree.org, referenced 2016-10-03.
>  
> -[2] Devicetree. https://www.devicetree.org, referenced 2016-10-03.
> +[2] Common bindings for device graphs (Devicetree).
> +    https://github.com/devicetree-org/dt-schema/blob/main/schemas/graph.yaml,
> +    referenced 2021-11-30.
>  
> -[3] Documentation/devicetree/bindings/graph.txt
> +[3] DSD Guide. https://github.com/UEFI/DSD-Guide/blob/main/dsd-guide.adoc,
> +    referenced 2021-11-30.
>  
> -[4] Device Properties UUID For _DSD.
> -    https://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf,
> -    referenced 2016-10-04.
> +[4] Advanced Configuration and Power Interface Specification.
> +    https://uefi.org/specifications/ACPI/6.4/, 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.
> +[5] _DSD Device Properties Usage Rules.
>      Documentation/firmware-guide/acpi/DSD-properties-rules.rst
> +
> +[6] Documentation/firmware-guide/acpi/dsd/data-node-references.rst

To make this patch shorter and any improvements cleaner in the future can you
use labeled references instead of numbered? This will reduce a lot of churn.

-- 
With Best Regards,
Andy Shevchenko

[PATCH 5/7] device property: Implement fwnode_graph_get_endpoint_count()

[Sakari Ailus]

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 <sakari.ailus@linux.intel.com>
---
 drivers/base/property.c  | 51 ++++++++++++++++++++++++++++++++--------
 include/linux/property.h |  2 ++
 2 files changed, 43 insertions(+), 10 deletions(-)

diff --git a/drivers/base/property.c b/drivers/base/property.c
index ecc4e2eb10678..248034553005f 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,33 @@ 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))
+			continue;
+
+		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;						\
-- 
2.30.2

Re: [PATCH 5/7] device property: Implement fwnode_graph_get_endpoint_count()

[Andy Shevchenko]

On Tue, Nov 30, 2021 at 05:32:48PM +0200, Sakari Ailus wrote:
> 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.

...

> +	fwnode_graph_for_each_endpoint(fwnode, ep) {
> +		if (!(flags & FWNODE_GRAPH_DEVICE_DISABLED) &&
> +		    !fwnode_graph_remote_available(ep))
> +			continue;

> +		count++;

Can't it be more straightforward to write it as

		if (flags & FWNODE_GRAPH_DEVICE_DISABLED ||
		    fwnode_graph_remote_available(ep))
			count++;

?

> +	}

-- 
With Best Regards,
Andy Shevchenko

[PATCH 6/7] device property: Use fwnode_graph_for_each_endpoint() macro

[Sakari Ailus]

Now that we have fwnode_graph_for_each_endpoint() macro, use it instead of
calling fwnode_graph_get_next_endpoint() directly. It manages the iterator
variable for the user without manual intervention.

Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
---
 drivers/base/property.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/base/property.c b/drivers/base/property.c
index 248034553005f..ba35d16e7f1f2 100644
--- a/drivers/base/property.c
+++ b/drivers/base/property.c
@@ -1072,9 +1072,9 @@ struct fwnode_handle *
 fwnode_graph_get_remote_node(const struct fwnode_handle *fwnode, u32 port_id,
 			     u32 endpoint_id)
 {
-	struct fwnode_handle *endpoint = NULL;
+	struct fwnode_handle *endpoint;
 
-	while ((endpoint = fwnode_graph_get_next_endpoint(fwnode, endpoint))) {
+	fwnode_graph_for_each_endpoint(fwnode, endpoint) {
 		struct fwnode_endpoint fwnode_ep;
 		struct fwnode_handle *remote;
 		int ret;
@@ -1133,12 +1133,12 @@ struct fwnode_handle *
 fwnode_graph_get_endpoint_by_id(const struct fwnode_handle *fwnode,
 				u32 port, u32 endpoint, unsigned long flags)
 {
-	struct fwnode_handle *ep = NULL, *best_ep = NULL;
+	struct fwnode_handle *ep, *best_ep = NULL;
 	unsigned int best_ep_id = 0;
 	bool endpoint_next = flags & FWNODE_GRAPH_ENDPOINT_NEXT;
 	bool enabled_only = !(flags & FWNODE_GRAPH_DEVICE_DISABLED);
 
-	while ((ep = fwnode_graph_get_next_endpoint(fwnode, ep))) {
+	fwnode_graph_for_each_endpoint(fwnode, ep) {
 		struct fwnode_endpoint fwnode_ep = { 0 };
 		int ret;
 
-- 
2.30.2

[PATCH 7/7] device property: Drop fwnode_graph_get_remote_node()

[Sakari Ailus]

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 <sakari.ailus@linux.intel.com>
---
 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 ba35d16e7f1f2..afe61263daa9d 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)
 {
-- 
2.30.2

Re: [PATCH 7/7] device property: Drop fwnode_graph_get_remote_node()

[Andy Shevchenko]

On Tue, Nov 30, 2021 at 05:32:50PM +0200, Sakari Ailus wrote:
> 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().

...

> -		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);

What makes you to move portnos to the next line? It's pretty much under 80.

> +		if (!ep)
>  			continue;
>  
> +		remote = fwnode_graph_get_remote_port_parent(ep);
> +		fwnode_handle_put(ep);

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 7/7] device property: Drop fwnode_graph_get_remote_node()

[Sakari Ailus]

Hi Andy,

On Tue, Nov 30, 2021 at 06:05:29PM +0200, Andy Shevchenko wrote:
> On Tue, Nov 30, 2021 at 05:32:50PM +0200, Sakari Ailus wrote:
> > 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().
> 
> ...
> 
> > -		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);
> 
> What makes you to move portnos to the next line? It's pretty much under 80.

It is. But the endpoint, the following argument, is closely related to the
port number. For that reason I'd prefer to keep it as-is.

-- 
Sakari Ailus

Re: [PATCH 1/7] device property: Fix fwnode_graph_devcon_match() fwnode leak

[Andy Shevchenko]

On Tue, Nov 30, 2021 at 05:32:44PM +0200, Sakari Ailus wrote:
> 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.

I like the series, thanks!
For non-commented you may take my
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

The rest can gain it if you are okay with my proposals.

Also, please fix Cc list, it has fancy address in the Cc list.

> 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 <sakari.ailus@linux.intel.com>
> ---
>  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);
> -- 
> 2.30.2
> 

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 1/7] device property: Fix fwnode_graph_devcon_match() fwnode leak

[Sakari Ailus]

Hi Andy,

Thanks for the comments.

On Tue, Nov 30, 2021 at 06:07:26PM +0200, Andy Shevchenko wrote:
> On Tue, Nov 30, 2021 at 05:32:44PM +0200, Sakari Ailus wrote:
> > 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.
> 
> I like the series, thanks!
> For non-commented you may take my
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

Thanks!

> 
> The rest can gain it if you are okay with my proposals.
> 
> Also, please fix Cc list, it has fancy address in the Cc list.

I forgot to write one more e-mail address before pressing enter...

-- 
Regards,

Sakari Ailus

Re: [PATCH 1/7] device property: Fix fwnode_graph_devcon_match() fwnode leak

[Sakari Ailus]

On Tue, Nov 30, 2021 at 06:07:26PM +0200, Andy Shevchenko wrote:
> On Tue, Nov 30, 2021 at 05:32:44PM +0200, Sakari Ailus wrote:
> > 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.
> 
> I like the series, thanks!
> For non-commented you may take my
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> 
> The rest can gain it if you are okay with my proposals.
> 
> Also, please fix Cc list, it has fancy address in the Cc list.

Just sent v2, with your acks:

<URL:https://lore.kernel.org/linux-acpi/20211201125934.936953-1-sakari.ailus@linux.intel.com/T/#t>

-- 
Sakari Ailus