LinuxLists.cc - [PATCH 0/6] arm64: add ethernet to orange pi 3

[permalink] [raw]

Subject: [PATCH 4/6] ARM: dts: sunxi: move phy regulator in PHY node

Now that PHY core can handle regulators, move regulator handle in PHY
node.

Signed-off-by: Corentin Labbe <[email protected]>
---
arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts | 2 +-
arch/arm/boot/dts/sun8i-a83t-cubietruck-plus.dts | 2 +-
arch/arm/boot/dts/sun8i-h3-nanopi-m1-plus.dts | 2 +-
arch/arm/boot/dts/sun8i-h3-nanopi-r1.dts | 2 +-
arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts | 2 +-
arch/arm/boot/dts/sun8i-h3-orangepi-plus2e.dts | 2 +-
arch/arm/boot/dts/sun8i-h3-zeropi.dts | 2 +-
arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts | 2 +-
arch/arm/boot/dts/sun8i-r40-oka40i-c.dts | 2 +-
arch/arm/boot/dts/sun8i-v40-bananapi-m2-berry.dts | 2 +-
arch/arm/boot/dts/sun9i-a80-cubieboard4.dts | 2 +-
arch/arm/boot/dts/sun9i-a80-optimus.dts | 2 +-
arch/arm/boot/dts/sunxi-bananapi-m2-plus.dtsi | 2 +-
13 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
index 5a7e1bd5f825..b450be0a45ed 100644
--- a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
+++ b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
@@ -129,7 +129,6 @@ &ehci0 {
&emac {
pinctrl-names = "default";
pinctrl-0 = <&emac_rgmii_pins>;
- phy-supply = <&reg_sw>;
phy-handle = <&rgmii_phy>;
phy-mode = "rgmii-id";
allwinner,rx-delay-ps = <700>;
@@ -151,6 +150,7 @@ &mdio {
rgmii_phy: ethernet-phy@1 {
compatible = "ethernet-phy-ieee802.3-c22";
reg = <1>;
+ phy-supply = <&reg_sw>;
};
};

diff --git a/arch/arm/boot/dts/sun8i-a83t-cubietruck-plus.dts b/arch/arm/boot/dts/sun8i-a83t-cubietruck-plus.dts
index 870993393fc2..fe70b350cdbb 100644
--- a/arch/arm/boot/dts/sun8i-a83t-cubietruck-plus.dts
+++ b/arch/arm/boot/dts/sun8i-a83t-cubietruck-plus.dts
@@ -181,7 +181,6 @@ &ehci1 {
&emac {
pinctrl-names = "default";
pinctrl-0 = <&emac_rgmii_pins>;
- phy-supply = <&reg_dldo4>;
phy-handle = <&rgmii_phy>;
phy-mode = "rgmii-id";
status = "okay";
@@ -201,6 +200,7 @@ &mdio {
rgmii_phy: ethernet-phy@1 {
compatible = "ethernet-phy-ieee802.3-c22";
reg = <1>;
+ phy-supply = <&reg_dldo4>;
};
};

diff --git a/arch/arm/boot/dts/sun8i-h3-nanopi-m1-plus.dts b/arch/arm/boot/dts/sun8i-h3-nanopi-m1-plus.dts
index a2f2ef2b0092..c393612f44c6 100644
--- a/arch/arm/boot/dts/sun8i-h3-nanopi-m1-plus.dts
+++ b/arch/arm/boot/dts/sun8i-h3-nanopi-m1-plus.dts
@@ -103,7 +103,6 @@ &ehci2 {
&emac {
pinctrl-names = "default";
pinctrl-0 = <&emac_rgmii_pins>;
- phy-supply = <&reg_gmac_3v3>;
phy-handle = <&ext_rgmii_phy>;
phy-mode = "rgmii";

@@ -114,6 +113,7 @@ &external_mdio {
ext_rgmii_phy: ethernet-phy@1 {
compatible = "ethernet-phy-ieee802.3-c22";
reg = <7>;
+ phy-supply = <&reg_gmac_3v3>;
};
};

diff --git a/arch/arm/boot/dts/sun8i-h3-nanopi-r1.dts b/arch/arm/boot/dts/sun8i-h3-nanopi-r1.dts
index 26e2e6172e0d..70bde396856b 100644
--- a/arch/arm/boot/dts/sun8i-h3-nanopi-r1.dts
+++ b/arch/arm/boot/dts/sun8i-h3-nanopi-r1.dts
@@ -80,7 +80,6 @@ &ehci2 {
&emac {
pinctrl-names = "default";
pinctrl-0 = <&emac_rgmii_pins>;
- phy-supply = <&reg_gmac_3v3>;
phy-handle = <&ext_rgmii_phy>;
phy-mode = "rgmii-id";
status = "okay";
@@ -90,6 +89,7 @@ &external_mdio {
ext_rgmii_phy: ethernet-phy@7 {
compatible = "ethernet-phy-ieee802.3-c22";
reg = <7>;
+ phy-supply = <&reg_gmac_3v3>;
};
};

diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts b/arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts
index d05fa679dcd3..c6dcf1af3298 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts
@@ -83,7 +83,6 @@ &ehci3 {
&emac {
pinctrl-names = "default";
pinctrl-0 = <&emac_rgmii_pins>;
- phy-supply = <&reg_gmac_3v3>;
phy-handle = <&ext_rgmii_phy>;
phy-mode = "rgmii-id";

@@ -94,6 +93,7 @@ &external_mdio {
ext_rgmii_phy: ethernet-phy@1 {
compatible = "ethernet-phy-ieee802.3-c22";
reg = <0>;
+ phy-supply = <&reg_gmac_3v3>;
};
};

diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-plus2e.dts b/arch/arm/boot/dts/sun8i-h3-orangepi-plus2e.dts
index b6ca45d18e51..61eb8c003186 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-plus2e.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-plus2e.dts
@@ -65,7 +65,6 @@ reg_gmac_3v3: gmac-3v3 {
&emac {
pinctrl-names = "default";
pinctrl-0 = <&emac_rgmii_pins>;
- phy-supply = <&reg_gmac_3v3>;
phy-handle = <&ext_rgmii_phy>;
phy-mode = "rgmii-id";
status = "okay";
@@ -75,5 +74,6 @@ &external_mdio {
ext_rgmii_phy: ethernet-phy@1 {
compatible = "ethernet-phy-ieee802.3-c22";
reg = <1>;
+ phy-supply = <&reg_gmac_3v3>;
};
};
diff --git a/arch/arm/boot/dts/sun8i-h3-zeropi.dts b/arch/arm/boot/dts/sun8i-h3-zeropi.dts
index 7d3e7323b661..54174ef18823 100644
--- a/arch/arm/boot/dts/sun8i-h3-zeropi.dts
+++ b/arch/arm/boot/dts/sun8i-h3-zeropi.dts
@@ -65,13 +65,13 @@ &external_mdio {
ext_rgmii_phy: ethernet-phy@7 {
compatible = "ethernet-phy-ieee802.3-c22";
reg = <7>;
+ phy-supply = <&reg_gmac_3v3>;
};
};

&emac {
pinctrl-names = "default";
pinctrl-0 = <&emac_rgmii_pins>;
- phy-supply = <&reg_gmac_3v3>;
phy-handle = <&ext_rgmii_phy>;
phy-mode = "rgmii-id";

diff --git a/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts b/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
index a6a1087a0c9b..b1f269bbd479 100644
--- a/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
+++ b/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
@@ -130,7 +130,6 @@ &gmac {
pinctrl-0 = <&gmac_rgmii_pins>;
phy-handle = <&phy1>;
phy-mode = "rgmii-id";
- phy-supply = <&reg_dc1sw>;
status = "okay";
};

@@ -138,6 +137,7 @@ &gmac_mdio {
phy1: ethernet-phy@1 {
compatible = "ethernet-phy-ieee802.3-c22";
reg = <1>;
+ phy-supply = <&reg_dc1sw>;
};
};

diff --git a/arch/arm/boot/dts/sun8i-r40-oka40i-c.dts b/arch/arm/boot/dts/sun8i-r40-oka40i-c.dts
index 0bd1336206b8..c43476b426df 100644
--- a/arch/arm/boot/dts/sun8i-r40-oka40i-c.dts
+++ b/arch/arm/boot/dts/sun8i-r40-oka40i-c.dts
@@ -93,7 +93,6 @@ &gmac {
pinctrl-0 = <&gmac_rgmii_pins>;
phy-handle = <&phy1>;
phy-mode = "rgmii-id";
- phy-supply = <&reg_dcdc1>;
status = "okay";
};

@@ -101,6 +100,7 @@ &gmac_mdio {
phy1: ethernet-phy@1 {
compatible = "ethernet-phy-ieee802.3-c22";
reg = <1>;
+ phy-supply = <&reg_dcdc1>;
};
};

diff --git a/arch/arm/boot/dts/sun8i-v40-bananapi-m2-berry.dts b/arch/arm/boot/dts/sun8i-v40-bananapi-m2-berry.dts
index 47954551f573..050a649d7bda 100644
--- a/arch/arm/boot/dts/sun8i-v40-bananapi-m2-berry.dts
+++ b/arch/arm/boot/dts/sun8i-v40-bananapi-m2-berry.dts
@@ -121,7 +121,6 @@ &gmac {
pinctrl-0 = <&gmac_rgmii_pins>;
phy-handle = <&phy1>;
phy-mode = "rgmii-id";
- phy-supply = <&reg_dc1sw>;
status = "okay";
};

@@ -129,6 +128,7 @@ &gmac_mdio {
phy1: ethernet-phy@1 {
compatible = "ethernet-phy-ieee802.3-c22";
reg = <1>;
+ phy-supply = <&reg_dc1sw>;
};
};

diff --git a/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts b/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
index c8ca8cb7f5c9..ab9bf4bf7343 100644
--- a/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
+++ b/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
@@ -130,7 +130,6 @@ &gmac {
pinctrl-0 = <&gmac_rgmii_pins>;
phy-handle = <&phy1>;
phy-mode = "rgmii-id";
- phy-supply = <&reg_cldo1>;
status = "okay";
};

@@ -142,6 +141,7 @@ &i2c3 {

&mdio {
phy1: ethernet-phy@1 {
+ phy-supply = <&reg_cldo1>;
reg = <1>;
};
};
diff --git a/arch/arm/boot/dts/sun9i-a80-optimus.dts b/arch/arm/boot/dts/sun9i-a80-optimus.dts
index 5c3580d712e4..48219b8049b1 100644
--- a/arch/arm/boot/dts/sun9i-a80-optimus.dts
+++ b/arch/arm/boot/dts/sun9i-a80-optimus.dts
@@ -125,13 +125,13 @@ &gmac {
pinctrl-0 = <&gmac_rgmii_pins>;
phy-handle = <&phy1>;
phy-mode = "rgmii-id";
- phy-supply = <&reg_cldo1>;
status = "okay";
};

&mdio {
phy1: ethernet-phy@1 {
reg = <1>;
+ phy-supply = <&reg_cldo1>;
};
};

diff --git a/arch/arm/boot/dts/sunxi-bananapi-m2-plus.dtsi b/arch/arm/boot/dts/sunxi-bananapi-m2-plus.dtsi
index d03f5853ef7b..65f0a3c2af3f 100644
--- a/arch/arm/boot/dts/sunxi-bananapi-m2-plus.dtsi
+++ b/arch/arm/boot/dts/sunxi-bananapi-m2-plus.dtsi
@@ -125,7 +125,6 @@ &ehci2 {
&emac {
pinctrl-names = "default";
pinctrl-0 = <&emac_rgmii_pins>;
- phy-supply = <&reg_gmac_3v3>;
phy-handle = <&ext_rgmii_phy>;
phy-mode = "rgmii-id";

@@ -136,6 +135,7 @@ &external_mdio {
ext_rgmii_phy: ethernet-phy@1 {
compatible = "ethernet-phy-ieee802.3-c22";
reg = <1>;
+ phy-supply = <&reg_gmac_3v3>;
};
};

--
2.35.1

2022-05-09 10:34:57

[permalink] [raw]

Subject: [PATCH 3/6] dt-bindings: net: Add documentation for phy-supply

Add entries for the 2 new phy-supply and phy-io-supply.

Signed-off-by: Corentin Labbe <[email protected]>
---
.../devicetree/bindings/net/ethernet-phy.yaml | 10 ++++++++++
1 file changed, 10 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/ethernet-phy.yaml b/Documentation/devicetree/bindings/net/ethernet-phy.yaml
index ed1415a4381f..2a6b45ddf010 100644
--- a/Documentation/devicetree/bindings/net/ethernet-phy.yaml
+++ b/Documentation/devicetree/bindings/net/ethernet-phy.yaml
@@ -153,6 +153,16 @@ properties:
used. The absence of this property indicates the muxers
should be configured so that the external PHY is used.

+ phy-supply:
+ description:
+ Phandle to a regulator that provides power to the PHY. This
+ regulator will be managed during the PHY power on/off sequence.
+
+ phy-io-supply:
+ description:
+ Phandle to a regulator that provides power to the PHY. This
+ regulator will be managed during the PHY power on/off sequence.
+
resets:
maxItems: 1

--
2.35.1

2022-05-09 11:47:55

by Andre Przywara

[permalink] [raw]

Subject: Re: [PATCH 4/6] ARM: dts: sunxi: move phy regulator in PHY node

On Mon, 9 May 2022 07:48:55 +0000
Corentin Labbe <[email protected]> wrote:

Hi!

> Now that PHY core can handle regulators, move regulator handle in PHY
> node.

Other than this is somewhat more "correct", is it really needed for those
boards? Because it breaks compatibility with older kernels, so when we
update the DTs in U-Boot, we run into problems (again).

IIUC this series is about the OPi3 & friends, which didn't work with older
kernels anyway, so can we just skip this patch (and 5/6), to just enable
the boards that didn't work before?

Cheers,
Andre

>
> Signed-off-by: Corentin Labbe <[email protected]>
> ---
> arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts | 2 +-
> arch/arm/boot/dts/sun8i-a83t-cubietruck-plus.dts | 2 +-
> arch/arm/boot/dts/sun8i-h3-nanopi-m1-plus.dts | 2 +-
> arch/arm/boot/dts/sun8i-h3-nanopi-r1.dts | 2 +-
> arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts | 2 +-
> arch/arm/boot/dts/sun8i-h3-orangepi-plus2e.dts | 2 +-
> arch/arm/boot/dts/sun8i-h3-zeropi.dts | 2 +-
> arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts | 2 +-
> arch/arm/boot/dts/sun8i-r40-oka40i-c.dts | 2 +-
> arch/arm/boot/dts/sun8i-v40-bananapi-m2-berry.dts | 2 +-
> arch/arm/boot/dts/sun9i-a80-cubieboard4.dts | 2 +-
> arch/arm/boot/dts/sun9i-a80-optimus.dts | 2 +-
> arch/arm/boot/dts/sunxi-bananapi-m2-plus.dtsi | 2 +-
> 13 files changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
> index 5a7e1bd5f825..b450be0a45ed 100644
> --- a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
> +++ b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
> @@ -129,7 +129,6 @@ &ehci0 {
> &emac {
> pinctrl-names = "default";
> pinctrl-0 = <&emac_rgmii_pins>;
> - phy-supply = <&reg_sw>;
> phy-handle = <&rgmii_phy>;
> phy-mode = "rgmii-id";
> allwinner,rx-delay-ps = <700>;
> @@ -151,6 +150,7 @@ &mdio {
> rgmii_phy: ethernet-phy@1 {
> compatible = "ethernet-phy-ieee802.3-c22";
> reg = <1>;
> + phy-supply = <&reg_sw>;
> };
> };
>
> diff --git a/arch/arm/boot/dts/sun8i-a83t-cubietruck-plus.dts b/arch/arm/boot/dts/sun8i-a83t-cubietruck-plus.dts
> index 870993393fc2..fe70b350cdbb 100644
> --- a/arch/arm/boot/dts/sun8i-a83t-cubietruck-plus.dts
> +++ b/arch/arm/boot/dts/sun8i-a83t-cubietruck-plus.dts
> @@ -181,7 +181,6 @@ &ehci1 {
> &emac {
> pinctrl-names = "default";
> pinctrl-0 = <&emac_rgmii_pins>;
> - phy-supply = <&reg_dldo4>;
> phy-handle = <&rgmii_phy>;
> phy-mode = "rgmii-id";
> status = "okay";
> @@ -201,6 +200,7 @@ &mdio {
> rgmii_phy: ethernet-phy@1 {
> compatible = "ethernet-phy-ieee802.3-c22";
> reg = <1>;
> + phy-supply = <&reg_dldo4>;
> };
> };
>
> diff --git a/arch/arm/boot/dts/sun8i-h3-nanopi-m1-plus.dts b/arch/arm/boot/dts/sun8i-h3-nanopi-m1-plus.dts
> index a2f2ef2b0092..c393612f44c6 100644
> --- a/arch/arm/boot/dts/sun8i-h3-nanopi-m1-plus.dts
> +++ b/arch/arm/boot/dts/sun8i-h3-nanopi-m1-plus.dts
> @@ -103,7 +103,6 @@ &ehci2 {
> &emac {
> pinctrl-names = "default";
> pinctrl-0 = <&emac_rgmii_pins>;
> - phy-supply = <&reg_gmac_3v3>;
> phy-handle = <&ext_rgmii_phy>;
> phy-mode = "rgmii";
>
> @@ -114,6 +113,7 @@ &external_mdio {
> ext_rgmii_phy: ethernet-phy@1 {
> compatible = "ethernet-phy-ieee802.3-c22";
> reg = <7>;
> + phy-supply = <&reg_gmac_3v3>;
> };
> };
>
> diff --git a/arch/arm/boot/dts/sun8i-h3-nanopi-r1.dts b/arch/arm/boot/dts/sun8i-h3-nanopi-r1.dts
> index 26e2e6172e0d..70bde396856b 100644
> --- a/arch/arm/boot/dts/sun8i-h3-nanopi-r1.dts
> +++ b/arch/arm/boot/dts/sun8i-h3-nanopi-r1.dts
> @@ -80,7 +80,6 @@ &ehci2 {
> &emac {
> pinctrl-names = "default";
> pinctrl-0 = <&emac_rgmii_pins>;
> - phy-supply = <&reg_gmac_3v3>;
> phy-handle = <&ext_rgmii_phy>;
> phy-mode = "rgmii-id";
> status = "okay";
> @@ -90,6 +89,7 @@ &external_mdio {
> ext_rgmii_phy: ethernet-phy@7 {
> compatible = "ethernet-phy-ieee802.3-c22";
> reg = <7>;
> + phy-supply = <&reg_gmac_3v3>;
> };
> };
>
> diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts b/arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts
> index d05fa679dcd3..c6dcf1af3298 100644
> --- a/arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts
> +++ b/arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts
> @@ -83,7 +83,6 @@ &ehci3 {
> &emac {
> pinctrl-names = "default";
> pinctrl-0 = <&emac_rgmii_pins>;
> - phy-supply = <&reg_gmac_3v3>;
> phy-handle = <&ext_rgmii_phy>;
> phy-mode = "rgmii-id";
>
> @@ -94,6 +93,7 @@ &external_mdio {
> ext_rgmii_phy: ethernet-phy@1 {
> compatible = "ethernet-phy-ieee802.3-c22";
> reg = <0>;
> + phy-supply = <&reg_gmac_3v3>;
> };
> };
>
> diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-plus2e.dts b/arch/arm/boot/dts/sun8i-h3-orangepi-plus2e.dts
> index b6ca45d18e51..61eb8c003186 100644
> --- a/arch/arm/boot/dts/sun8i-h3-orangepi-plus2e.dts
> +++ b/arch/arm/boot/dts/sun8i-h3-orangepi-plus2e.dts
> @@ -65,7 +65,6 @@ reg_gmac_3v3: gmac-3v3 {
> &emac {
> pinctrl-names = "default";
> pinctrl-0 = <&emac_rgmii_pins>;
> - phy-supply = <&reg_gmac_3v3>;
> phy-handle = <&ext_rgmii_phy>;
> phy-mode = "rgmii-id";
> status = "okay";
> @@ -75,5 +74,6 @@ &external_mdio {
> ext_rgmii_phy: ethernet-phy@1 {
> compatible = "ethernet-phy-ieee802.3-c22";
> reg = <1>;
> + phy-supply = <&reg_gmac_3v3>;
> };
> };
> diff --git a/arch/arm/boot/dts/sun8i-h3-zeropi.dts b/arch/arm/boot/dts/sun8i-h3-zeropi.dts
> index 7d3e7323b661..54174ef18823 100644
> --- a/arch/arm/boot/dts/sun8i-h3-zeropi.dts
> +++ b/arch/arm/boot/dts/sun8i-h3-zeropi.dts
> @@ -65,13 +65,13 @@ &external_mdio {
> ext_rgmii_phy: ethernet-phy@7 {
> compatible = "ethernet-phy-ieee802.3-c22";
> reg = <7>;
> + phy-supply = <&reg_gmac_3v3>;
> };
> };
>
> &emac {
> pinctrl-names = "default";
> pinctrl-0 = <&emac_rgmii_pins>;
> - phy-supply = <&reg_gmac_3v3>;
> phy-handle = <&ext_rgmii_phy>;
> phy-mode = "rgmii-id";
>
> diff --git a/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts b/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
> index a6a1087a0c9b..b1f269bbd479 100644
> --- a/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
> +++ b/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
> @@ -130,7 +130,6 @@ &gmac {
> pinctrl-0 = <&gmac_rgmii_pins>;
> phy-handle = <&phy1>;
> phy-mode = "rgmii-id";
> - phy-supply = <&reg_dc1sw>;
> status = "okay";
> };
>
> @@ -138,6 +137,7 @@ &gmac_mdio {
> phy1: ethernet-phy@1 {
> compatible = "ethernet-phy-ieee802.3-c22";
> reg = <1>;
> + phy-supply = <&reg_dc1sw>;
> };
> };
>
> diff --git a/arch/arm/boot/dts/sun8i-r40-oka40i-c.dts b/arch/arm/boot/dts/sun8i-r40-oka40i-c.dts
> index 0bd1336206b8..c43476b426df 100644
> --- a/arch/arm/boot/dts/sun8i-r40-oka40i-c.dts
> +++ b/arch/arm/boot/dts/sun8i-r40-oka40i-c.dts
> @@ -93,7 +93,6 @@ &gmac {
> pinctrl-0 = <&gmac_rgmii_pins>;
> phy-handle = <&phy1>;
> phy-mode = "rgmii-id";
> - phy-supply = <&reg_dcdc1>;
> status = "okay";
> };
>
> @@ -101,6 +100,7 @@ &gmac_mdio {
> phy1: ethernet-phy@1 {
> compatible = "ethernet-phy-ieee802.3-c22";
> reg = <1>;
> + phy-supply = <&reg_dcdc1>;
> };
> };
>
> diff --git a/arch/arm/boot/dts/sun8i-v40-bananapi-m2-berry.dts b/arch/arm/boot/dts/sun8i-v40-bananapi-m2-berry.dts
> index 47954551f573..050a649d7bda 100644
> --- a/arch/arm/boot/dts/sun8i-v40-bananapi-m2-berry.dts
> +++ b/arch/arm/boot/dts/sun8i-v40-bananapi-m2-berry.dts
> @@ -121,7 +121,6 @@ &gmac {
> pinctrl-0 = <&gmac_rgmii_pins>;
> phy-handle = <&phy1>;
> phy-mode = "rgmii-id";
> - phy-supply = <&reg_dc1sw>;
> status = "okay";
> };
>
> @@ -129,6 +128,7 @@ &gmac_mdio {
> phy1: ethernet-phy@1 {
> compatible = "ethernet-phy-ieee802.3-c22";
> reg = <1>;
> + phy-supply = <&reg_dc1sw>;
> };
> };
>
> diff --git a/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts b/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
> index c8ca8cb7f5c9..ab9bf4bf7343 100644
> --- a/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
> +++ b/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
> @@ -130,7 +130,6 @@ &gmac {
> pinctrl-0 = <&gmac_rgmii_pins>;
> phy-handle = <&phy1>;
> phy-mode = "rgmii-id";
> - phy-supply = <&reg_cldo1>;
> status = "okay";
> };
>
> @@ -142,6 +141,7 @@ &i2c3 {
>
> &mdio {
> phy1: ethernet-phy@1 {
> + phy-supply = <&reg_cldo1>;
> reg = <1>;
> };
> };
> diff --git a/arch/arm/boot/dts/sun9i-a80-optimus.dts b/arch/arm/boot/dts/sun9i-a80-optimus.dts
> index 5c3580d712e4..48219b8049b1 100644
> --- a/arch/arm/boot/dts/sun9i-a80-optimus.dts
> +++ b/arch/arm/boot/dts/sun9i-a80-optimus.dts
> @@ -125,13 +125,13 @@ &gmac {
> pinctrl-0 = <&gmac_rgmii_pins>;
> phy-handle = <&phy1>;
> phy-mode = "rgmii-id";
> - phy-supply = <&reg_cldo1>;
> status = "okay";
> };
>
> &mdio {
> phy1: ethernet-phy@1 {
> reg = <1>;
> + phy-supply = <&reg_cldo1>;
> };
> };
>
> diff --git a/arch/arm/boot/dts/sunxi-bananapi-m2-plus.dtsi b/arch/arm/boot/dts/sunxi-bananapi-m2-plus.dtsi
> index d03f5853ef7b..65f0a3c2af3f 100644
> --- a/arch/arm/boot/dts/sunxi-bananapi-m2-plus.dtsi
> +++ b/arch/arm/boot/dts/sunxi-bananapi-m2-plus.dtsi
> @@ -125,7 +125,6 @@ &ehci2 {
> &emac {
> pinctrl-names = "default";
> pinctrl-0 = <&emac_rgmii_pins>;
> - phy-supply = <&reg_gmac_3v3>;
> phy-handle = <&ext_rgmii_phy>;
> phy-mode = "rgmii-id";
>
> @@ -136,6 +135,7 @@ &external_mdio {
> ext_rgmii_phy: ethernet-phy@1 {
> compatible = "ethernet-phy-ieee802.3-c22";
> reg = <1>;
> + phy-supply = <&reg_gmac_3v3>;
> };
> };
>

2022-05-09 12:00:13

[permalink] [raw]

Subject: Re: [PATCH 4/6] ARM: dts: sunxi: move phy regulator in PHY node

Le Mon, May 09, 2022 at 11:55:33AM +0100, Andre Przywara a ?crit :
> On Mon, 9 May 2022 07:48:55 +0000
> Corentin Labbe <[email protected]> wrote:
>
> Hi!
>
> > Now that PHY core can handle regulators, move regulator handle in PHY
> > node.
>
> Other than this is somewhat more "correct", is it really needed for those
> boards? Because it breaks compatibility with older kernels, so when we
> update the DTs in U-Boot, we run into problems (again).
>
> IIUC this series is about the OPi3 & friends, which didn't work with older
> kernels anyway, so can we just skip this patch (and 5/6), to just enable
> the boards that didn't work before?
>
> Cheers,
> Andre
>

We could have a situation where stmmac handle phy for older boards, and PHY core handle them for new boards.
Up to maintainers to see if they want a split situation or not.

2022-05-09 12:42:11

[permalink] [raw]

Subject: Re: [PATCH 0/6] arm64: add ethernet to orange pi 3

On Mon, May 09, 2022 at 07:48:51AM +0000, Corentin Labbe wrote:
> Hello
>
> 2 sunxi board still does not have ethernet working, orangepi 1+ and
> orangepi 3.
> This is due to the fact thoses boards have a PHY which need 2 regulators.

Why PHY make/module is it which is causing problems?

Andrew

2022-05-09 12:44:06

[permalink] [raw]

Subject: Re: [PATCH 3/6] dt-bindings: net: Add documentation for phy-supply

On Mon, May 09, 2022 at 07:48:54AM +0000, Corentin Labbe wrote:
> Add entries for the 2 new phy-supply and phy-io-supply.
>
> Signed-off-by: Corentin Labbe <[email protected]>
> ---
> .../devicetree/bindings/net/ethernet-phy.yaml | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/ethernet-phy.yaml b/Documentation/devicetree/bindings/net/ethernet-phy.yaml
> index ed1415a4381f..2a6b45ddf010 100644
> --- a/Documentation/devicetree/bindings/net/ethernet-phy.yaml
> +++ b/Documentation/devicetree/bindings/net/ethernet-phy.yaml
> @@ -153,6 +153,16 @@ properties:
> used. The absence of this property indicates the muxers
> should be configured so that the external PHY is used.
>
> + phy-supply:
> + description:
> + Phandle to a regulator that provides power to the PHY. This
> + regulator will be managed during the PHY power on/off sequence.
> +
> + phy-io-supply:
> + description:
> + Phandle to a regulator that provides power to the PHY. This
> + regulator will be managed during the PHY power on/off sequence.

If you need two differently named regulators, you need to make it clear
how they differ. My _guess_ would be, you only need the io variant in
order to talk to the PHY registers. However, to talk to a link
partner, you need the other one enabled as well. Which means handling
that regulator probably should be in the PHY driver, so it is enabled
only when the interface is configured up.

Andrew

2022-05-09 13:38:18

[permalink] [raw]

Subject: Re: [PATCH 0/6] arm64: add ethernet to orange pi 3

Le Mon, May 09, 2022 at 02:20:07PM +0200, Andrew Lunn a ?crit :
> On Mon, May 09, 2022 at 07:48:51AM +0000, Corentin Labbe wrote:
> > Hello
> >
> > 2 sunxi board still does not have ethernet working, orangepi 1+ and
> > orangepi 3.
> > This is due to the fact thoses boards have a PHY which need 2 regulators.
>
> Why PHY make/module is it which is causing problems?
>

The problem was stmmac support only one regulator for PHY.

2022-05-09 13:38:19

[permalink] [raw]

Subject: Re: [PATCH 3/6] dt-bindings: net: Add documentation for phy-supply

Le Mon, May 09, 2022 at 02:17:27PM +0200, Andrew Lunn a ?crit :
> On Mon, May 09, 2022 at 07:48:54AM +0000, Corentin Labbe wrote:
> > Add entries for the 2 new phy-supply and phy-io-supply.
> >
> > Signed-off-by: Corentin Labbe <[email protected]>
> > ---
> > .../devicetree/bindings/net/ethernet-phy.yaml | 10 ++++++++++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/net/ethernet-phy.yaml b/Documentation/devicetree/bindings/net/ethernet-phy.yaml
> > index ed1415a4381f..2a6b45ddf010 100644
> > --- a/Documentation/devicetree/bindings/net/ethernet-phy.yaml
> > +++ b/Documentation/devicetree/bindings/net/ethernet-phy.yaml
> > @@ -153,6 +153,16 @@ properties:
> > used. The absence of this property indicates the muxers
> > should be configured so that the external PHY is used.
> >
> > + phy-supply:
> > + description:
> > + Phandle to a regulator that provides power to the PHY. This
> > + regulator will be managed during the PHY power on/off sequence.
> > +
> > + phy-io-supply:
> > + description:
> > + Phandle to a regulator that provides power to the PHY. This
> > + regulator will be managed during the PHY power on/off sequence.
>
> If you need two differently named regulators, you need to make it clear
> how they differ. My _guess_ would be, you only need the io variant in
> order to talk to the PHY registers. However, to talk to a link
> partner, you need the other one enabled as well. Which means handling
> that regulator probably should be in the PHY driver, so it is enabled
> only when the interface is configured up.
>

If I enable only the IO one, stmmac fail to reset, so both are needed to be up.
I tried also to keep the "phy" one handled by stmmac (by removing patch 2), this lead to the PHY to not be found by MDIO scan.
Proably because stmmac enable the "phy" before the "phy-io".

For the difference between the 2, according to my basic read (I am bad a it) of the shematic
https://linux-sunxi.org/images/5/50/OrangePi_3_Schematics_v1.5.pdf
phy-io(ephy-vdd25) seems to (at least) power MDIO bus.

2022-05-09 15:25:04

[permalink] [raw]

Subject: Re: [PATCH 0/6] arm64: add ethernet to orange pi 3

On Mon, May 09, 2022 at 03:27:30PM +0200, LABBE Corentin wrote:
> Le Mon, May 09, 2022 at 02:20:07PM +0200, Andrew Lunn a ?crit :
> > On Mon, May 09, 2022 at 07:48:51AM +0000, Corentin Labbe wrote:
> > > Hello
> > >
> > > 2 sunxi board still does not have ethernet working, orangepi 1+ and
> > > orangepi 3.
> > > This is due to the fact thoses boards have a PHY which need 2 regulators.
> >
> > Why PHY make/module is it which is causing problems?
> >
>
> The problem was stmmac support only one regulator for PHY.

I'm trying to understand the differences between the two different
regulators. If you tell me what the PHY is, i might be able to find
the data sheet, and then understand why two regulators are needed and
if one needs to be controlled by the PHY driver, not the MDIO bus
driver.

Andrew

2022-05-09 15:30:55

[permalink] [raw]

Subject: Re: [PATCH 0/6] arm64: add ethernet to orange pi 3

Le Mon, May 09, 2022 at 05:19:16PM +0200, Andrew Lunn a ?crit :
> On Mon, May 09, 2022 at 03:27:30PM +0200, LABBE Corentin wrote:
> > Le Mon, May 09, 2022 at 02:20:07PM +0200, Andrew Lunn a ?crit :
> > > On Mon, May 09, 2022 at 07:48:51AM +0000, Corentin Labbe wrote:
> > > > Hello
> > > >
> > > > 2 sunxi board still does not have ethernet working, orangepi 1+ and
> > > > orangepi 3.
> > > > This is due to the fact thoses boards have a PHY which need 2 regulators.
> > >
> > > Why PHY make/module is it which is causing problems?
> > >
> >
> > The problem was stmmac support only one regulator for PHY.
>
> I'm trying to understand the differences between the two different
> regulators. If you tell me what the PHY is, i might be able to find
> the data sheet, and then understand why two regulators are needed and
> if one needs to be controlled by the PHY driver, not the MDIO bus
> driver.

The schematic for the board is https://linux-sunxi.org/images/5/50/OrangePi_3_Schematics_v1.5.pdf
Which show a RTL8211E.

2022-05-09 16:02:17

[permalink] [raw]

Subject: Re: [PATCH 0/6] arm64: add ethernet to orange pi 3

On Mon, May 09, 2022 at 05:24:26PM +0200, LABBE Corentin wrote:
> Le Mon, May 09, 2022 at 05:19:16PM +0200, Andrew Lunn a ?crit :

> > I'm trying to understand the differences between the two different
> > regulators. If you tell me what the PHY is, i might be able to find
> > the data sheet, and then understand why two regulators are needed and
> > if one needs to be controlled by the PHY driver, not the MDIO bus
> > driver.

> The schematic for the board is https://linux-sunxi.org/images/5/50/OrangePi_3_Schematics_v1.5.pdf
> Which show a RTL8211E.

Most hardware will want all the regulators for the device turned on or
off en masse (possibly in a specific sequence) - it's rare for devices
to support only having some of their supplies enabled for extended
periods, I'd be surprised if something like a PHY did that.

Attachments:

(No filename) (842.00 B)
signature.asc (499.00 B)
Download all attachments

2022-05-09 16:08:58

[permalink] [raw]

Subject: Re: [PATCH 3/6] dt-bindings: net: Add documentation for phy-supply

On Mon, May 09, 2022 at 03:26:47PM +0200, LABBE Corentin wrote:
> Le Mon, May 09, 2022 at 02:17:27PM +0200, Andrew Lunn a ?crit :
> > On Mon, May 09, 2022 at 07:48:54AM +0000, Corentin Labbe wrote:
> > > Add entries for the 2 new phy-supply and phy-io-supply.
> > >
> > > Signed-off-by: Corentin Labbe <[email protected]>
> > > ---
> > > .../devicetree/bindings/net/ethernet-phy.yaml | 10 ++++++++++
> > > 1 file changed, 10 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/net/ethernet-phy.yaml b/Documentation/devicetree/bindings/net/ethernet-phy.yaml
> > > index ed1415a4381f..2a6b45ddf010 100644
> > > --- a/Documentation/devicetree/bindings/net/ethernet-phy.yaml
> > > +++ b/Documentation/devicetree/bindings/net/ethernet-phy.yaml
> > > @@ -153,6 +153,16 @@ properties:
> > > used. The absence of this property indicates the muxers
> > > should be configured so that the external PHY is used.
> > >
> > > + phy-supply:
> > > + description:
> > > + Phandle to a regulator that provides power to the PHY. This
> > > + regulator will be managed during the PHY power on/off sequence.
> > > +
> > > + phy-io-supply:
> > > + description:
> > > + Phandle to a regulator that provides power to the PHY. This
> > > + regulator will be managed during the PHY power on/off sequence.
> >
> > If you need two differently named regulators, you need to make it clear
> > how they differ. My _guess_ would be, you only need the io variant in
> > order to talk to the PHY registers. However, to talk to a link
> > partner, you need the other one enabled as well. Which means handling
> > that regulator probably should be in the PHY driver, so it is enabled
> > only when the interface is configured up.
> >
>
> If I enable only the IO one, stmmac fail to reset, so both are needed to be up.
> I tried also to keep the "phy" one handled by stmmac (by removing patch 2), this lead to the PHY to not be found by MDIO scan.
> Proably because stmmac enable the "phy" before the "phy-io".
>
> For the difference between the 2, according to my basic read (I am bad a it) of the shematic
> https://linux-sunxi.org/images/5/50/OrangePi_3_Schematics_v1.5.pdf
> phy-io(ephy-vdd25) seems to (at least) power MDIO bus.

So there is nothing in the data sheet of the RTL8211E to suggest you
can uses these different power supplies independently. The naming
'phy-io-supply' is very specific to RTL8211E, but you are defining a
generic binding here. I don't know the regulator binding, it is
possible to make phy-supply a list?

Andrew

2022-05-09 16:17:06

[permalink] [raw]

Subject: Re: [PATCH 3/6] dt-bindings: net: Add documentation for phy-supply

On Mon, May 09, 2022 at 06:02:55PM +0200, Andrew Lunn wrote:
> On Mon, May 09, 2022 at 03:26:47PM +0200, LABBE Corentin wrote:

> > For the difference between the 2, according to my basic read (I am bad a it) of the shematic
> > https://linux-sunxi.org/images/5/50/OrangePi_3_Schematics_v1.5.pdf
> > phy-io(ephy-vdd25) seems to (at least) power MDIO bus.

> So there is nothing in the data sheet of the RTL8211E to suggest you
> can uses these different power supplies independently. The naming
> 'phy-io-supply' is very specific to RTL8211E, but you are defining a
> generic binding here. I don't know the regulator binding, it is
> possible to make phy-supply a list?

No, that's not a thing - the supplies are individual, named properties
and even if there were a list we'd still want them to be named so it's
clear what's going on.

Attachments:

(No filename) (852.00 B)
signature.asc (499.00 B)
Download all attachments

2022-05-09 16:44:58

[permalink] [raw]

Subject: Re: [PATCH 3/6] dt-bindings: net: Add documentation for phy-supply

> No, that's not a thing - the supplies are individual, named properties
> and even if there were a list we'd still want them to be named so it's
> clear what's going on.

So we have a collection of regulators, varying in numbers between
different PHYs, with different vendor names and purposes. In general,
they all should be turned on. Yet we want them named so it is clear
what is going on.

Is there a generic solution here so that the phylib core can somehow
enumerate them and turn them on, without actually knowing what they
are called because they have vendor specific names in order to be
clear what they are?

There must be a solution to this, phylib cannot be the first subsystem
to have this requirement, so if you could point to an example, that
would be great.

Thanks
Andrew

2022-05-09 17:06:58

[permalink] [raw]

Subject: Re: [PATCH 3/6] dt-bindings: net: Add documentation for phy-supply

On Mon, May 09, 2022 at 06:38:05PM +0200, Andrew Lunn wrote:

> So we have a collection of regulators, varying in numbers between
> different PHYs, with different vendor names and purposes. In general,
> they all should be turned on. Yet we want them named so it is clear
> what is going on.

> Is there a generic solution here so that the phylib core can somehow
> enumerate them and turn them on, without actually knowing what they
> are called because they have vendor specific names in order to be
> clear what they are?

> There must be a solution to this, phylib cannot be the first subsystem
> to have this requirement, so if you could point to an example, that
> would be great.

No, it's not really come up much before - generally things with
regulator control that have generic drivers tend not to be sophisticated
enough to have more than one supply, or to be on an enumerable bus where
the power is part of the bus specification so have the power specified
as part of the bus. You'd need to extend the regulator bindings to
support parallel array of phandles and array of names properties like
clocks have as an option like you were asking for, which would doubtless
be fun for validation but is probably the thing here.

Attachments:

(No filename) (1.23 kB)
signature.asc (499.00 B)
Download all attachments

2022-05-11 09:58:45

[permalink] [raw]

Subject: Re: [PATCH 3/6] dt-bindings: net: Add documentation for phy-supply

Le Mon, May 09, 2022 at 05:56:34PM +0100, Mark Brown a ?crit :
> On Mon, May 09, 2022 at 06:38:05PM +0200, Andrew Lunn wrote:
>
> > So we have a collection of regulators, varying in numbers between
> > different PHYs, with different vendor names and purposes. In general,
> > they all should be turned on. Yet we want them named so it is clear
> > what is going on.
>
> > Is there a generic solution here so that the phylib core can somehow
> > enumerate them and turn them on, without actually knowing what they
> > are called because they have vendor specific names in order to be
> > clear what they are?
>
> > There must be a solution to this, phylib cannot be the first subsystem
> > to have this requirement, so if you could point to an example, that
> > would be great.
>
> No, it's not really come up much before - generally things with
> regulator control that have generic drivers tend not to be sophisticated
> enough to have more than one supply, or to be on an enumerable bus where
> the power is part of the bus specification so have the power specified
> as part of the bus. You'd need to extend the regulator bindings to
> support parallel array of phandles and array of names properties like
> clocks have as an option like you were asking for, which would doubtless
> be fun for validation but is probably the thing here.

Does you mean something like this:
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 1e54a833f2cf..404f5b874b59 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -351,6 +351,32 @@ static void regulator_lock_dependent(struct regulator_dev *rdev,
mutex_unlock(&regulator_list_mutex);
}

+/**
+ * of_get_regulator_from_list - get a regulator device node based on supply name
+ * from a DT regulators list
+ * @dev: Device pointer for the consumer (of regulator) device
+ * @supply: regulator supply name
+ *
+ * Extract the regulator device node corresponding to the supply name.
+ * returns the device node corresponding to the regulator if found, else
+ * returns NULL.
+ */
+static struct device_node *of_get_regulator_from_list(struct device *dev,
+ struct device_node *np,
+ const char *supply)
+{
+ int index, ret;
+ struct of_phandle_args regspec;
+
+ index = of_property_match_string(np, "regulator-names", supply);
+ if (index >= 0) {
+ ret = of_parse_phandle_with_args(np, "regulators", NULL, index, &regspec);
+ if (ret == 0)
+ return regspec.np;
+ }
+ return NULL;
+}
+
/**
* of_get_child_regulator - get a child regulator device node
* based on supply name
@@ -362,17 +388,23 @@ static void regulator_lock_dependent(struct regulator_dev *rdev,
* returns the device node corresponding to the regulator if found, else
* returns NULL.
*/
-static struct device_node *of_get_child_regulator(struct device_node *parent,
- const char *prop_name)
+static struct device_node *of_get_child_regulator(struct device *dev,
+ struct device_node *parent,
+ const char *supply)
{
struct device_node *regnode = NULL;
struct device_node *child = NULL;
+ char prop_name[64]; /* 64 is max size of property name */

+ snprintf(prop_name, 64, "%s-supply", supply);
for_each_child_of_node(parent, child) {
+ regnode = of_get_regulator_from_list(dev, child, supply);
+ if (regnode)
+ return regnode;
regnode = of_parse_phandle(child, prop_name, 0);

if (!regnode) {
- regnode = of_get_child_regulator(child, prop_name);
+ regnode = of_get_child_regulator(dev, child, prop_name);
if (regnode)
goto err_node_put;
} else {
@@ -401,12 +433,15 @@ static struct device_node *of_get_regulator(struct device *dev, const char *supp
char prop_name[64]; /* 64 is max size of property name */

dev_dbg(dev, "Looking up %s-supply from device tree\n", supply);
+ regnode = of_get_regulator_from_list(dev, dev->of_node, supply);
+ if (regnode)
+ return regnode;

snprintf(prop_name, 64, "%s-supply", supply);
regnode = of_parse_phandle(dev->of_node, prop_name, 0);

if (!regnode) {
- regnode = of_get_child_regulator(dev->of_node, prop_name);
+ regnode = of_get_child_regulator(dev, dev->of_node, supply);
if (regnode)
return regnode;

And then for our case, a regulator_get_bulk will be needed.
Does I well understood what you mean ?

2022-05-12 09:32:15