net: qcom/emac: add shared mdio bus support

This property copy from "ibm,emac.txt" to describe a shared MIDO bus. Since emac include MDIO, so If the motherboard has more than one PHY connected to an MDIO bus, this property will point to the MAC device that has the MDIO bus.

Signed-off-by Wang Dongsheng <[email protected]>

---
V2: s/Since QDF2400 emac/Since emac/

---
 Documentation/devicetree/bindings/net/qcom-emac.txt | 4 ++++
 1 file changed, 4 insertions(+)

Documentation/devicetree/bindings/net/qcom-emac.txt +0 -0

index 346e6c7f47b7..50db71771358 100644

Quoted 20 lines · Wang Dongsheng

This property copy from "ibm,emac.txt" to describe a shared MIDO bus. Since emac include MDIO, so If the motherboard has more than one PHY connected to an MDIO bus, this property will point to the MAC device that has the MDIO bus.

Signed-off-by Wang Dongsheng <[email protected]>

---
V2: s/Since QDF2400 emac/Since emac/

---
 Documentation/devicetree/bindings/net/qcom-emac.txt | 4 ++++
 1 file changed, 4 insertions(+)

Documentation/devicetree/bindings/net/qcom-emac.txt +0 -0

index 346e6c7f47b7..50db71771358 100644
@@ -24,6 +24,9 @@ Internal PHY node:
 The external phy child node:
 - reg : The phy address
 

Documentation/devicetree/bindings/net/qcom-emac.txt Internal PHY node: · line 28

Quoted 2 lines

Documentation/devicetree/bindings/net/qcom-emac.txt +2 -0

+Optional properties:
+- mdio-device : Shared MIDO bus.

Hi Dongsheng

I don't see why you need this property. The ethernet interface has a phy-handle which points to a PHY. That is all you need to find the PHY.

        emac0: ethernet@feb20000 {
                compatible = "qcom,fsm9900-emac";
                reg = <0xfeb20000 0x10000>,
                      <0xfeb36000 0x1000>;
                interrupts = <76>;

                clocks = <&gcc 0>, <&gcc 1>, <&gcc 3>, <&gcc 4>, <&gcc 5>,
                        <&gcc 6>, <&gcc 7>;
                clock-names = "axi_clk", "cfg_ahb_clk", "high_speed_clk",
                        "mdio_clk", "tx_clk", "rx_clk", "sys_clk";

                internal-phy = <&emac_sgmii>;

                phy-handle = <&phy0>;

                #address-cells = <1>;
                #size-cells = <0>;

                phy0: ethernet-phy@0 {
                        reg = <0>;
                };

                phy1: ethernet-phy@1 {
                        reg = <1>;
                };

                pinctrl-names = "default";
                pinctrl-0 = <&mdio_pins_a>;
        };

        emac1: ethernet@38900000 {
                compatible = "qcom,fsm9900-emac";
		...
		...

                phy-handle = <&phy1>;
	};

	Andrew

Quoted 21 lines · Andrew Lunn

Quoted 20 lines · Wang Dongsheng

This property copy from "ibm,emac.txt" to describe a shared MIDO bus. Since emac include MDIO, so If the motherboard has more than one PHY connected to an MDIO bus, this property will point to the MAC device that has the MDIO bus.

Signed-off-by Wang Dongsheng <[email protected]>

---
V2: s/Since QDF2400 emac/Since emac/

---
 Documentation/devicetree/bindings/net/qcom-emac.txt | 4 ++++
 1 file changed, 4 insertions(+)

Documentation/devicetree/bindings/net/qcom-emac.txt +0 -0

index 346e6c7f47b7..50db71771358 100644
@@ -24,6 +24,9 @@ Internal PHY node:
 The external phy child node:
 - reg : The phy address
 

Quoted 6 lines

Documentation/devicetree/bindings/net/qcom-emac.txt Internal PHY node: · line 28

Quoted 2 lines

Documentation/devicetree/bindings/net/qcom-emac.txt +2 -0

+Optional properties:
+- mdio-device : Shared MIDO bus.

Hi Dongsheng

I don't see why you need this property. The ethernet interface has a phy-handle which points to a PHY. That is all you need to find the PHY.

phy-handle is description PHY address. This property is describing an MDIO controller.
Each QCOM emac include an MDIO controller, normally each emac only connect one
PHY device, but when all of the PHY devices mdio lines connect one MDIO controller
that is included in EMAC, we need to share this MDIO controller for others EMAC.

Quoted 28 lines · Dongsheng

Quoted 21 lines · Andrew Lunn

Quoted 20 lines · Wang Dongsheng

This property copy from "ibm,emac.txt" to describe a shared MIDO bus. Since emac include MDIO, so If the motherboard has more than one PHY connected to an MDIO bus, this property will point to the MAC device that has the MDIO bus.

Signed-off-by Wang Dongsheng <[email protected]>

---
V2: s/Since QDF2400 emac/Since emac/

---
 Documentation/devicetree/bindings/net/qcom-emac.txt | 4 ++++
 1 file changed, 4 insertions(+)

Documentation/devicetree/bindings/net/qcom-emac.txt +0 -0

index 346e6c7f47b7..50db71771358 100644
@@ -24,6 +24,9 @@ Internal PHY node:
 The external phy child node:
 - reg : The phy address
 

Quoted 6 lines

Documentation/devicetree/bindings/net/qcom-emac.txt Internal PHY node: · line 28

Quoted 2 lines

Documentation/devicetree/bindings/net/qcom-emac.txt +2 -0

+Optional properties:
+- mdio-device : Shared MIDO bus.

Hi Dongsheng

I don't see why you need this property. The ethernet interface has a phy-handle which points to a PHY. That is all you need to find the PHY.

Quoted 8 lines

phy-handle is description PHY address. This property is describing an MDIO controller.
Each QCOM emac include an MDIO controller, normally each emac only connect one
PHY device, but when all of the PHY devices mdio lines connect one MDIO controller
that is included in EMAC, we need to share this MDIO controller for others EMAC.

If you want to describe the MDIO controller, then you embed a mdio subnode into your Ethernet MAC node:

 emac0: ethernet@feb20000 {
	mdio {
		#address-cells = <1>;
		#size-cells = <0>;

		phy0: ethernet-phy@0 {
			reg = <0>;
		};
	};
};

And then each Ethernet MAC controller refers to their appropriate PHY device tree node using a phy-handle property to point to either their own MDIO controller, or another MAC's MDIO controller.

The IBM Emac is a old (not to say bad) example and it does not use the PHY library and the standard Device Tree node property, please don't use it as a reference.

Quoted 14 lines

If you want to describe the MDIO controller, then you embed a mdio subnode into your Ethernet MAC node:

 emac0: ethernet@feb20000 {
	mdio {
		#address-cells = <1>;
		#size-cells = <0>;

		phy0: ethernet-phy@0 {
			reg = <0>;
		};
	};
};

Quoted 3 lines

And then each Ethernet MAC controller refers to their appropriate PHY device tree node using a phy-handle property to point to either their own MDIO controller, or another MAC's MDIO controller.

Sorry, I do not understand how phy-handle point to MDIO controller, because phy-handle is defined to point to a phy.

Quoted 14 lines

Quoted 14 lines

If you want to describe the MDIO controller, then you embed a mdio subnode into your Ethernet MAC node:

 emac0: ethernet@feb20000 {
	mdio {
		#address-cells = <1>;
		#size-cells = <0>;

		phy0: ethernet-phy@0 {
			reg = <0>;
		};
	};
};

Quoted 5 lines

Quoted 3 lines

And then each Ethernet MAC controller refers to their appropriate PHY device tree node using a phy-handle property to point to either their own MDIO controller, or another MAC's MDIO controller.

Sorry, I do not understand how phy-handle point to MDIO controller, because phy-handle is defined to point to a phy.

The MAC driver does not care what MDIO controller a PHY is on. All you need to do to register the PHY is:

	phy_node = of_parse_phandle(np, "phy-handle", 0);
	phy_interface = of_get_phy_mode(np);
	phydev = of_phy_connect(dev, phy_node,
                                &handle_link_change, 0,
                                phy_interface);

	Andrew

Quoted 14 lines · Andrew Lunn

Quoted 14 lines

Quoted 14 lines

If you want to describe the MDIO controller, then you embed a mdio subnode into your Ethernet MAC node:

 emac0: ethernet@feb20000 {
	mdio {
		#address-cells = <1>;
		#size-cells = <0>;

		phy0: ethernet-phy@0 {
			reg = <0>;
		};
	};
};

Quoted 7 lines

Quoted 5 lines

Quoted 3 lines

And then each Ethernet MAC controller refers to their appropriate PHY device tree node using a phy-handle property to point to either their own MDIO controller, or another MAC's MDIO controller.

Sorry, I do not understand how phy-handle point to MDIO controller, because phy-handle is defined to point to a phy.

The MAC driver does not care what MDIO controller a PHY is on. All you need to do to register the PHY is:

Yes, these are all things that must be done, and emac driver will connect phy when mac up.
If we had a separate MDIO controller, the MAC would not care about MDIO bus. But MDIO is integrated within the EMAC, and emac driver maintains the mdio.

Each EMAC do their mdio register/unregister. But in the shared scenario, the EMACs that use the shared bus do not need to create an MDIO and cannot release the Shared bus.

But ACPI environment my understand is this:

I will rework this patchset and maybe patches will be a delay for a few days.

ACPI is completely separate and should not affect the DT binding. I've not yet looked at the ACPI changes you added.

The focus of any patches for the EMAC should be ACPI, not DT. If anything, ACPI support should come first. No one should be writing or reviewing DT code before ACPI code.

I suspect that is not going to be easy. Last time i looked, the ACPI standard had nothing about MDIO busses or PHYs. Marcin Wojtas did some work in this area a while back for the mvpp2, but if i remember correctly, he worked around this by simply not having a PHY when using ACPI, and making use of a MAC interrupt which indicated when there was link.

Whoever implements this first needs to be an ACPI expert and probably needs to write it up and submit it as an amendment to the ACPI standard.

Use "phy-handle" to porint an internal MDIO device port.

Quoted 1 line · Wang Dongsheng

Use "phy-handle" to porint an internal MDIO device port.

Hi Dongsheng

You are basically defining how all future ACPI based MAC drivers get access to their PHY. This needs to become part of the ACPI standard, etc.

This code should not be hidden away in the emac driver. It needs to be placed somewhere public so other drivers can use it. And it needs good documentation, including an example of what needs to go into the ACPI tables, etc.

Thanks
Andrew

But when I was reading Documentation/acpi/DSD-properties-rules.txt, my understanding is we should try to conform to DT bindings. So maybe ACPI doesn't have such a document, just DT bindings.

Quoted 3 lines · Dongsheng

But when I was reading Documentation/acpi/DSD-properties-rules.txt, my understanding is we should try to conform to DT bindings. So maybe ACPI doesn't have such a document, just DT bindings.

There was an attempt to document DSDs, but it was abandoned after a while.

https://github.com/ahs3/dsd

Quoted 4 lines · Timur Tabi

Quoted 3 lines · Dongsheng

But when I was reading Documentation/acpi/DSD-properties-rules.txt, my understanding is we should try to conform to DT bindings. So maybe ACPI doesn't have such a document, just DT bindings.

Quoted 4 lines

There was an attempt to document DSDs, but it was abandoned after a while.

https://github.com/ahs3/dsd

Yes, here's a database concept, and I asked some Intel guys, the answer I got was there is no such database or document. :(

Quoted 9 lines · Dongsheng

Quoted 8 lines · Timur Tabi

Quoted 3 lines · Dongsheng

But when I was reading Documentation/acpi/DSD-properties-rules.txt, my understanding is we should try to conform to DT bindings. So maybe ACPI doesn't have such a document, just DT bindings.

There was an attempt to document DSDs, but it was abandoned after a while.

https://github.com/ahs3/dsd

Quoted 2 lines

Yes, here's a database concept, and I asked some Intel guys, the answer I got was there is no such database or document. :(

Hi Dongsheng

If there is no clear documentation for ACPI, it becomes even more important that the xgene code is refactored into a central location, and you make use of it. We really need to avoid every ACPI ethernet driver doing its own thing.

Quoted 10 lines · Andrew Lunn

Quoted 9 lines · Dongsheng

Quoted 8 lines · Timur Tabi

Quoted 3 lines · Dongsheng

But when I was reading Documentation/acpi/DSD-properties-rules.txt, my understanding is we should try to conform to DT bindings. So maybe ACPI doesn't have such a document, just DT bindings.

There was an attempt to document DSDs, but it was abandoned after a while.

https://github.com/ahs3/dsd

Quoted 8 lines

Quoted 2 lines

Yes, here's a database concept, and I asked some Intel guys, the answer I got was there is no such database or document. :(

Hi Dongsheng

If there is no clear documentation for ACPI, it becomes even more important that the xgene code is refactored into a central location, and you make use of it. We really need to avoid every ACPI ethernet driver doing its own thing.

However, without a document specifying MDIO and phy-handle, it is almost difficult for us to do this. Because maybe the ACPI device or property corresponding to each platform is different.
Just like APM looks different to us. APM's MDIO adev doesn't describe the concept of port, and our platform does. Besides, I cannot get the ACPI table of APM or other manufacturers.
The table of ACPI cannot be obtained from kernel source as easily as DT. We can't know without a platform to do ACPI dump. Unless some of the manufacturers have pushed the table to upstream.
So I think we might have a hard time doing this without a document. And it's likely that this work involves code modifications by BIOS vendors.

Quoted 19 lines · Dongsheng

Quoted 10 lines · Andrew Lunn

Quoted 9 lines · Dongsheng

Quoted 8 lines · Timur Tabi

Quoted 3 lines · Dongsheng

But when I was reading Documentation/acpi/DSD-properties-rules.txt, my understanding is we should try to conform to DT bindings. So maybe ACPI doesn't have such a document, just DT bindings.

There was an attempt to document DSDs, but it was abandoned after a while.

https://github.com/ahs3/dsd

Quoted 8 lines

Quoted 2 lines

Yes, here's a database concept, and I asked some Intel guys, the answer I got was there is no such database or document. :(

Hi Dongsheng

If there is no clear documentation for ACPI, it becomes even more important that the xgene code is refactored into a central location, and you make use of it. We really need to avoid every ACPI ethernet driver doing its own thing.

Quoted 11 lines

However, without a document specifying MDIO and phy-handle, it is almost difficult for us to do this. Because maybe the ACPI device or property corresponding to each platform is different.
Just like APM looks different to us. APM's MDIO adev doesn't describe the concept of port, and our platform does. Besides, I cannot get the ACPI table of APM or other manufacturers.
The table of ACPI cannot be obtained from kernel source as easily as DT. We can't know without a platform to do ACPI dump. Unless some of the manufacturers have pushed the table to upstream.
So I think we might have a hard time doing this without a document. And it's likely that this work involves code modifications by BIOS vendors.

Hi Dongsheng

There are two different options here.

1) Everybody does their own thing, ignoring what everybody else has done, and invents their own wheel. There is no shared code, no shared description, everybody has their own bugs, etc. ACPI as a standard is pointless for Ethernet MDIOs and PHYs because it is not a standard, everybody does something different.

2) Somebody takes the time to design a concept for Ethernet PHYs and MDIO busses using ACPI. They implement the common code, try to modify any existing users if possible, and submit the whole thing to become part of ACPI 6.3.

I would really prefer we go the second route here. It is more initial effort, but in the long run, everybody benefits.

Andrew

Add support for parsing the ACPI data node for PHY devices on an MDIO bus. The current implementation depend on mdio bus scan.
With _DSD device properties we can finally do this:

    Device (MDIO) {
        Name (_DSD, Package () {
            ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
            Package () { Package () { "ethernet-phy@0", PHY0 }, }
        })
        Name (PHY0, Package() {
            ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
            Package () { Package () { "reg", 0x0 }, }
        })
    }

    Device (MACO) {
        Name (_DSD, Package () {
            ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
            Package () { Package () { "phy-handle", \_SB.MDIO, "ethernet-phy@0" }, }
        })
    }

Documentations:
The DT "phy-handle" binding that we reuse for ACPI is documented in Documentation/devicetree/bindings/phy/phy-bindings.txt

Documentation/acpi/dsd/data-node-references.txt Documentation/acpi/dsd/graph.txt

Signed-off-by Wang Dongsheng <[email protected]>

---
 drivers/acpi/Kconfig       |   6 ++
 drivers/acpi/Makefile      |   1 +
 drivers/acpi/acpi_mdio.c   | 167 +++++++++++++++++++++++++++++++++++++
 drivers/net/phy/mdio_bus.c |   3 +
 include/linux/acpi_mdio.h  |  82 ++++++++++++++++++
 5 files changed, 259 insertions(+)

drivers/acpi/Kconfig +6 -0

index 9705fc986da9..0fefa3410ce9 100644
@@ -252,6 +252,12 @@ config ACPI_PROCESSOR_IDLE
 config ACPI_MCFG
 	bool
 
+config ACPI_MDIO
+	def_tristate PHYLIB
+	depends on PHYLIB
+	help
+	  ACPI MDIO bus (Ethernet PHY) accessors
+
 config ACPI_CPPC_LIB
 	bool
 	depends on ACPI_PROCESSOR

drivers/acpi/Makefile +1 -0

index 6d59aa109a91..ec7461a064fc 100644
@@ -41,6 +41,7 @@ acpi-y				+= ec.o
 acpi-$(CONFIG_ACPI_DOCK)	+= dock.o
 acpi-y				+= pci_root.o pci_link.o pci_irq.o
 obj-$(CONFIG_ACPI_MCFG)		+= pci_mcfg.o
+acpi-$(CONFIG_ACPI_MDIO)	+= acpi_mdio.o
 acpi-y				+= acpi_lpss.o acpi_apd.o
 acpi-y				+= acpi_platform.o
 acpi-y				+= acpi_pnp.o

drivers/acpi/acpi_mdio.c new file +0 -0

new file mode 100644
index 000000000000..293bf9a63197

Quoted 68 lines · CET Wang Dongsheng

Add support for parsing the ACPI data node for PHY devices on an MDIO bus. The current implementation depend on mdio bus scan.
With _DSD device properties we can finally do this:

    Device (MDIO) {
        Name (_DSD, Package () {
            ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
            Package () { Package () { "ethernet-phy@0", PHY0 }, }
        })
        Name (PHY0, Package() {
            ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
            Package () { Package () { "reg", 0x0 }, }
        })
    }

    Device (MACO) {
        Name (_DSD, Package () {
            ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
            Package () { Package () { "phy-handle", \_SB.MDIO, "ethernet-phy@0" }, }
        })
    }

Documentations:
The DT "phy-handle" binding that we reuse for ACPI is documented in Documentation/devicetree/bindings/phy/phy-bindings.txt

Documentation/acpi/dsd/data-node-references.txt Documentation/acpi/dsd/graph.txt

Signed-off-by Wang Dongsheng <[email protected]>

---
 drivers/acpi/Kconfig       |   6 ++
 drivers/acpi/Makefile      |   1 +
 drivers/acpi/acpi_mdio.c   | 167 +++++++++++++++++++++++++++++++++++++
 drivers/net/phy/mdio_bus.c |   3 +
 include/linux/acpi_mdio.h  |  82 ++++++++++++++++++
 5 files changed, 259 insertions(+)

drivers/acpi/Kconfig +6 -0

index 9705fc986da9..0fefa3410ce9 100644
@@ -252,6 +252,12 @@ config ACPI_PROCESSOR_IDLE
 config ACPI_MCFG
 	bool
 
+config ACPI_MDIO
+	def_tristate PHYLIB
+	depends on PHYLIB
+	help
+	  ACPI MDIO bus (Ethernet PHY) accessors
+
 config ACPI_CPPC_LIB
 	bool
 	depends on ACPI_PROCESSOR

drivers/acpi/Makefile +1 -0

index 6d59aa109a91..ec7461a064fc 100644
@@ -41,6 +41,7 @@ acpi-y				+= ec.o
 acpi-$(CONFIG_ACPI_DOCK)	+= dock.o
 acpi-y				+= pci_root.o pci_link.o pci_irq.o
 obj-$(CONFIG_ACPI_MCFG)		+= pci_mcfg.o
+acpi-$(CONFIG_ACPI_MDIO)	+= acpi_mdio.o
 acpi-y				+= acpi_lpss.o acpi_apd.o
 acpi-y				+= acpi_platform.o
 acpi-y				+= acpi_pnp.o

drivers/acpi/acpi_mdio.c +0 -0

drivers/acpi/acpi_mdio.c line 2

Quoted 7 lines

new file mode 100644
index 000000000000..293bf9a63197

drivers/acpi/acpi_mdio.c new file +2 -0

@@ -0,0 +1,167 @@
+// SPDX-License-Identifier: GPL-2.0+
+// Lots of code in this file is copy from drivers/of/of_mdio.c

Would it be possible to re-factor that code and share it instead?

Thanks,
Rafael

Quoted 69 lines · Rafael J. Wysocki

Quoted 68 lines · CET Wang Dongsheng

Add support for parsing the ACPI data node for PHY devices on an MDIO bus. The current implementation depend on mdio bus scan.
With _DSD device properties we can finally do this:

    Device (MDIO) {
        Name (_DSD, Package () {
            ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
            Package () { Package () { "ethernet-phy@0", PHY0 }, }
        })
        Name (PHY0, Package() {
            ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
            Package () { Package () { "reg", 0x0 }, }
        })
    }

    Device (MACO) {
        Name (_DSD, Package () {
            ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
            Package () { Package () { "phy-handle", \_SB.MDIO, "ethernet-phy@0" }, }
        })
    }

Documentations:
The DT "phy-handle" binding that we reuse for ACPI is documented in Documentation/devicetree/bindings/phy/phy-bindings.txt

Documentation/acpi/dsd/data-node-references.txt Documentation/acpi/dsd/graph.txt

Signed-off-by Wang Dongsheng <[email protected]>

---
 drivers/acpi/Kconfig       |   6 ++
 drivers/acpi/Makefile      |   1 +
 drivers/acpi/acpi_mdio.c   | 167 +++++++++++++++++++++++++++++++++++++
 drivers/net/phy/mdio_bus.c |   3 +
 include/linux/acpi_mdio.h  |  82 ++++++++++++++++++
 5 files changed, 259 insertions(+)

drivers/acpi/Kconfig +6 -0

index 9705fc986da9..0fefa3410ce9 100644
@@ -252,6 +252,12 @@ config ACPI_PROCESSOR_IDLE
 config ACPI_MCFG
 	bool
 
+config ACPI_MDIO
+	def_tristate PHYLIB
+	depends on PHYLIB
+	help
+	  ACPI MDIO bus (Ethernet PHY) accessors
+
 config ACPI_CPPC_LIB
 	bool
 	depends on ACPI_PROCESSOR

drivers/acpi/Makefile +1 -0

index 6d59aa109a91..ec7461a064fc 100644
@@ -41,6 +41,7 @@ acpi-y				+= ec.o
 acpi-$(CONFIG_ACPI_DOCK)	+= dock.o
 acpi-y				+= pci_root.o pci_link.o pci_irq.o
 obj-$(CONFIG_ACPI_MCFG)		+= pci_mcfg.o
+acpi-$(CONFIG_ACPI_MDIO)	+= acpi_mdio.o
 acpi-y				+= acpi_lpss.o acpi_apd.o
 acpi-y				+= acpi_platform.o
 acpi-y				+= acpi_pnp.o

drivers/acpi/acpi_mdio.c +0 -0

Quoted 8 lines

drivers/acpi/acpi_mdio.c line 2

Quoted 7 lines

new file mode 100644
index 000000000000..293bf9a63197

drivers/acpi/acpi_mdio.c new file +2 -0

@@ -0,0 +1,167 @@
+// SPDX-License-Identifier: GPL-2.0+
+// Lots of code in this file is copy from drivers/of/of_mdio.c

Would it be possible to re-factor that code and share it instead?

I thought about it, we can actually do it with fwnode.

But I don't have a lot of concentrate to do this. I'm going to focus on a few other things...:(

Maybe in the second half of 2019 I can re-factor them if there is no one re-factor them.

Add support for parsing the ACPI data node for PHY devices on an MDIO bus. The current implementation depend on mdio bus scan.
With _DSD device properties we can finally do this:

    Device (MDIO) {
        Name (_DSD, Package () {
            ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
            Package () { Package () { "ethernet-phy@0", PHY0 }, }
        })
        Name (PHY0, Package() {
            ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
            Package () { Package () { "reg", 0x0 }, }
        })
    }

    Device (MACO) {
        Name (_DSD, Package () {
            ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
            Package () { Package () { "phy-handle", \_SB.MDIO, "ethernet-phy@0" }, }
        })
    }

Documentations:
The DT "phy-handle" binding that we reuse for ACPI is documented in Documentation/devicetree/bindings/phy/phy-bindings.txt

Documentation/acpi/dsd/data-node-references.txt Documentation/acpi/dsd/graph.txt

Signed-off-by Wang Dongsheng <[email protected]>

---
 drivers/acpi/Kconfig       |   6 ++
 drivers/acpi/Makefile      |   1 +
 drivers/acpi/acpi_mdio.c   | 167 +++++++++++++++++++++++++++++++++++++
 drivers/net/phy/mdio_bus.c |   3 +
 include/linux/acpi_mdio.h  |  82 ++++++++++++++++++
 5 files changed, 259 insertions(+)

drivers/acpi/Kconfig +6 -0

index 9705fc986da9..0fefa3410ce9 100644
@@ -252,6 +252,12 @@ config ACPI_PROCESSOR_IDLE
 config ACPI_MCFG
 	bool
 
+config ACPI_MDIO
+	def_tristate PHYLIB
+	depends on PHYLIB
+	help
+	  ACPI MDIO bus (Ethernet PHY) accessors
+
 config ACPI_CPPC_LIB
 	bool
 	depends on ACPI_PROCESSOR

drivers/acpi/Makefile +1 -0

index 6d59aa109a91..ec7461a064fc 100644
@@ -41,6 +41,7 @@ acpi-y				+= ec.o
 acpi-$(CONFIG_ACPI_DOCK)	+= dock.o
 acpi-y				+= pci_root.o pci_link.o pci_irq.o
 obj-$(CONFIG_ACPI_MCFG)		+= pci_mcfg.o
+acpi-$(CONFIG_ACPI_MDIO)	+= acpi_mdio.o
 acpi-y				+= acpi_lpss.o acpi_apd.o
 acpi-y				+= acpi_platform.o
 acpi-y				+= acpi_pnp.o

drivers/acpi/acpi_mdio.c new file +1 -1

new file mode 100644
index 000000000000..293bf9a63197
--- /dev/null
 
+++ b/drivers/acpi/acpi_mdio.c

Originally I just push "phy-handle" support for ACPI on the QCOM QDF2400 platform. After some discussion and following Andrew's advice, I send out with a generic version of ACPI.

Current there is no clear documentation about MDIO/PHY for ACPI, so when I reading some documents about ACPI [1], I think we just need to reuse the DT binding in the ACPI.[2]. However, this series of patches are not fully compatible with all contents specified in DT binding.

The most important thing about this iseries is link the phy device and fwnode of acpi. Besides, we need to carry out bus scan at the mdio register. Therefore, I am not compatible with more DT binding properties in this series of patches. More support will be in the follow-up patches support, or some people do the support.

Example:
Based on ACPI doc:
Documentation/acpi/dsd/data-node-references.txt Documentation/acpi/dsd/graph.txt
With _DSD device properties we can finally do this:

    Device (MDIO) {
        Name (_DSD, Package () {
            ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
            Package () { Package () { "ethernet-phy@0", PHY0 }, }
        })
        Name (PHY0, Package() {
            ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
            Package () { Package () { "reg", 0x0 }, }
        })

I don't know much about ACPI. I do know DT. MDIO busses can have multiple PHYs on them. Is the following valid to list two PHYs?

      Device (MDIO) {
          Name (_DSD, Package () {
              ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
              Package () { Package () { "ethernet-phy@0", PHY0 }, }
          })
          Name (PHY0, Package() {
              ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
              Package () { Package () { "reg", 0x0 }, }
          })
          Name (_DSD, Package () {

              ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
              Package () { Package () { "ethernet-phy@10", PHY1 }, }
          })
          Name (PHY1, Package() {
              ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
              Package () { Package () { "reg", 0x10 }, }
          })
      }

Quoted 20 lines · Wang Dongsheng

Originally I just push "phy-handle" support for ACPI on the QCOM QDF2400 platform. After some discussion and following Andrew's advice, I send out with a generic version of ACPI.

Current there is no clear documentation about MDIO/PHY for ACPI, so when I reading some documents about ACPI [1], I think we just need to reuse the DT binding in the ACPI.[2]. However, this series of patches are not fully compatible with all contents specified in DT binding.

The most important thing about this iseries is link the phy device and fwnode of acpi. Besides, we need to carry out bus scan at the mdio register. Therefore, I am not compatible with more DT binding properties in this series of patches. More support will be in the follow-up patches support, or some people do the support.

Example:
Based on ACPI doc:
Documentation/acpi/dsd/data-node-references.txt Documentation/acpi/dsd/graph.txt
With _DSD device properties we can finally do this:

Quoted 9 lines

    Device (MDIO) {
        Name (_DSD, Package () {
            ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
            Package () { Package () { "ethernet-phy@0", PHY0 }, }
        })
        Name (PHY0, Package() {
            ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
            Package () { Package () { "reg", 0x0 }, }
        })

I don't know much about ACPI. I do know DT. MDIO busses can have multiple PHYs on them. Is the following valid to list two PHYs?

     Device (MDIO) {
         Name (_DSD, Package () {
             ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
             Package () { Package () { "ethernet-phy@0", PHY0 }, }
         })
         Name (PHY0, Package() {
             ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
             Package () { Package () { "reg", 0x0 }, }
         })
         Name (_DSD, Package () {

             ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
             Package () { Package () { "ethernet-phy@10", PHY1 }, }
         })
         Name (PHY1, Package() {
             ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
             Package () { Package () { "reg", 0x10 }, }
         })
     }

An MDIO bus can also have more than PHYs on them. There can be Ethernet switches. Broadcom also have some with generic PHY devices on them, and other odd things. That means whatever is on an MDIO bus is a device in the Linux device model. How does that work? Do we need some form Device (PHY) {}?

     Device (MDIO) {
         Device (PHY) {
             Name (_DSD, Package () {
                 ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
                 Package () { Package () { "ethernet-phy@0", PHY0 }, }
             })
             Name (PHY0, Package() {
                 ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
                 Package () { Package () { "reg", 0x0 }, }
             })
         }
         Device (PHY) {
             Name (_DSD, Package () {
                 ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
                 Package () { Package () { "ethernet-phy@10", PHY1 }, }
             })
             Name (PHY1, Package() {
                 ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
                 Package () { Package () { "reg", 0x10 }, }
             })
         Device (SWITCH) {
             Name (_DSD, Package () {

                 ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
                 Package () { Package () { "switch@11", SWITCH0 }, }
             })
             Name (SWITCH0, Package() {
                 ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
                 Package () { Package () { "reg", 0x11 }, }
             })
         }

      }

I'm just trying to ensure whatever is defined is flexible enough that we really can later support everything which DT does. We have PHYs on MDIO busses, inside switches, which are on MDIO busses, which are inside Ethernet interfaces, etc.

An MDIO bus is very similar to an i2c bus. How is that described in ACPI? Anything we can learn from that?

Quoted 4 lines

I'm just trying to ensure whatever is defined is flexible enough that we really can later support everything which DT does. We have PHYs on MDIO busses, inside switches, which are on MDIO busses, which are inside Ethernet interfaces, etc.

I think it can be satisfied. See the table I'm using above.

Quoted 5 lines

Quoted 4 lines

I'm just trying to ensure whatever is defined is flexible enough that we really can later support everything which DT does. We have PHYs on MDIO busses, inside switches, which are on MDIO busses, which are inside Ethernet interfaces, etc.

I think it can be satisfied. See the table I'm using above.

Hi Dongsheng

Since i don't know anything better, i think i have to trust you have this correct.

It would be good to document this, so that the next person who needs to add ACPI support for a PHY has some documentation to look at. Could you add something to Documentation/acpi/dsd?

I'm just trying to ensure whatever is defined is flexible enough that we really can later support everything which DT does. We have PHYs on MDIO busses, inside switches, which are on MDIO busses, which are inside Ethernet interfaces, etc.

An MDIO bus is very similar to an i2c bus. How is that described in ACPI? Anything we can learn from that?

Quoted 2 lines · Andrew Lunn

ACPI is completely separate and should not affect the DT binding. I've not yet looked at the ACPI changes you added.

Just FYI, there is no device tree platform on which the upstream EMAC driver works. All of the DT code in the driver is theoretical. It worked once on a prototype platform, when I originally wrote the code, but since then DT support is mostly a guess.

The focus of any patches for the EMAC should be ACPI, not DT. If anything, ACPI support should come first. No one should be writing or reviewing DT code before ACPI code.

The upstream EMAC driver is only known to work on the QDF2400, which is an ACPI-only chip. I feel like I've been repeating this too often.