[PATCH 0/3] net-next: stmmac: support future possible different internal phy mode

[PATCH 0/3] net-next: stmmac: support future possible different internal phy mode

[Corentin Labbe]

Hello

The current way to find if the phy is internal is to compare DT phy-mode
and emac_variant/internal_phy.
But it will negate a possible future SoC where an external PHY use the
same phy mode than the internal one.

This patchs series adds a new way to find if the PHY is internal, via its
compatible.

Corentin Labbe (3):
  dt-bindings: net: add compatible for internal sun8i-h3/sun8i-v3s PHYs
  ARM: sunxi: h3/h5: Add sun8i-h3-ephy compatible
  net-next: stmmac: dwmac-sun8i: choose internal PHY via compatible

 Documentation/devicetree/bindings/net/dwmac-sun8i.txt |  4 ++--
 arch/arm/boot/dts/sunxi-h3-h5.dtsi                    |  3 ++-
 drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c     | 16 ++++++++++------
 3 files changed, 14 insertions(+), 9 deletions(-)

-- 
2.13.0

[PATCH 1/3] dt-bindings: net: add compatible for internal sun8i-h3/sun8i-v3s PHYs

[Corentin Labbe]

The internal PHYs for H3 ans V3S now need to have their own compatible.
This patch rename them in the binding documentation.

Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
 Documentation/devicetree/bindings/net/dwmac-sun8i.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/dwmac-sun8i.txt b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
index 725f3b187886..851e89052424 100644
--- a/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
+++ b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
@@ -49,8 +49,8 @@ The device node referenced by "phy" or "phy-handle" should be a child node
 of the mdio node. See phy.txt for the generic PHY bindings.
 
 Required properties of the phy node with the following compatibles:
-  - "allwinner,sun8i-h3-emac",
-  - "allwinner,sun8i-v3s-emac":
+  - "allwinner,sun8i-h3-ephy",
+  - "allwinner,sun8i-v3s-ephy":
 - clocks: a phandle to the reference clock for the EPHY
 - resets: a phandle to the reset control for the EPHY
 
-- 
2.13.0

[PATCH 2/3] ARM: sunxi: h3/h5: Add sun8i-h3-ephy compatible

[Corentin Labbe]

This patch adds the sun8i-h3-ephy compatible to the internal PHY.

Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
 arch/arm/boot/dts/sunxi-h3-h5.dtsi | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
index 4b599b5d26f6..7aaa837c2388 100644
--- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
+++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
@@ -421,7 +421,8 @@
 				#address-cells = <1>;
 				#size-cells = <0>;
 				int_mii_phy: ethernet-phy at 1 {
-					compatible = "ethernet-phy-ieee802.3-c22";
+					compatible = "allwinner,sun8i-h3-ephy",
+							"ethernet-phy-ieee802.3-c22";
 					reg = <1>;
 					clocks = <&ccu CLK_BUS_EPHY>;
 					resets = <&ccu RST_BUS_EPHY>;
-- 
2.13.0

[PATCH 2/3] ARM: sunxi: h3/h5: Add sun8i-h3-ephy compatible

[Chen-Yu Tsai]

On Fri, Jul 28, 2017 at 5:28 PM, Corentin Labbe
<clabbe.montjoie@gmail.com> wrote:
> This patch adds the sun8i-h3-ephy compatible to the internal PHY.
>
> Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> ---
>  arch/arm/boot/dts/sunxi-h3-h5.dtsi | 3 ++-

To avoid repeating the past, this patch, if approved, will be merged
through the sunxi tree, not netdev nor net-next.

>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> index 4b599b5d26f6..7aaa837c2388 100644
> --- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> +++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> @@ -421,7 +421,8 @@
>                                 #address-cells = <1>;
>                                 #size-cells = <0>;
>                                 int_mii_phy: ethernet-phy at 1 {
> -                                       compatible = "ethernet-phy-ieee802.3-c22";
> +                                       compatible = "allwinner,sun8i-h3-ephy",
> +                                                       "ethernet-phy-ieee802.3-c22";

Are you expecting people to override this properly?

As it currently is, any external phy at address 1 will simply
reuse the same device node. And if they don't override the
property correctly, the driver will end up trying to use
the internal phy, while the user is expecting the external
one to be used.

Maybe you could move this to some other address, maybe the last
valid one, or second last valid one?

ChenYu

>                                         reg = <1>;
>                                         clocks = <&ccu CLK_BUS_EPHY>;
>                                         resets = <&ccu RST_BUS_EPHY>;
> --
> 2.13.0
>

[PATCH 2/3] ARM: sunxi: h3/h5: Add sun8i-h3-ephy compatible

[Icenowy Zheng]

? 2017?7?28? GMT+08:00 ??5:44:51, Chen-Yu Tsai <wens@csie.org> ??:
>On Fri, Jul 28, 2017 at 5:28 PM, Corentin Labbe
><clabbe.montjoie@gmail.com> wrote:
>> This patch adds the sun8i-h3-ephy compatible to the internal PHY.
>>
>> Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
>> ---
>>  arch/arm/boot/dts/sunxi-h3-h5.dtsi | 3 ++-
>
>To avoid repeating the past, this patch, if approved, will be merged
>through the sunxi tree, not netdev nor net-next.
>
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
>b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
>> index 4b599b5d26f6..7aaa837c2388 100644
>> --- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
>> +++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
>> @@ -421,7 +421,8 @@
>>                                 #address-cells = <1>;
>>                                 #size-cells = <0>;
>>                                 int_mii_phy: ethernet-phy at 1 {
>> -                                       compatible =
>"ethernet-phy-ieee802.3-c22";
>> +                                       compatible =
>"allwinner,sun8i-h3-ephy",
>> +                                                      
>"ethernet-phy-ieee802.3-c22";
>
>Are you expecting people to override this properly?
>
>As it currently is, any external phy at address 1 will simply
>reuse the same device node. And if they don't override the
>property correctly, the driver will end up trying to use
>the internal phy, while the user is expecting the external
>one to be used.
>
>Maybe you could move this to some other address, maybe the last
>valid one, or second last valid one?

Some board designers may use other address.

For example, on Nano Pi NEO2 the PHY is attached at address 0x7.

>
>ChenYu
>
>>                                         reg = <1>;
>>                                         clocks = <&ccu CLK_BUS_EPHY>;
>>                                         resets = <&ccu RST_BUS_EPHY>;
>> --
>> 2.13.0
>>

[PATCH 3/3] net-next: stmmac: dwmac-sun8i: choose internal PHY via compatible

[Corentin Labbe]

The current way to find if the phy is internal is to compare DT phy-mode
and emac_variant/internal_phy.
But it will negate a possible future SoC where an external PHY use the
same phy mode than the internal one.

This patch adds a new way to find if the PHY is internal, via its
compatible.

Since the phy_mode of the internal PHY does need to be know, the
variant internal_phy member is converted to a boolean.

Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index fffd6d5fc907..04f7ddd802b0 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -48,7 +48,7 @@
  */
 struct emac_variant {
 	u32 default_syscon_value;
-	int internal_phy;
+	bool internal_phy;
 	bool support_mii;
 	bool support_rmii;
 	bool support_rgmii;
@@ -75,7 +75,7 @@ struct sunxi_priv_data {
 
 static const struct emac_variant emac_variant_h3 = {
 	.default_syscon_value = 0x58000,
-	.internal_phy = PHY_INTERFACE_MODE_MII,
+	.internal_phy = true,
 	.support_mii = true,
 	.support_rmii = true,
 	.support_rgmii = true
@@ -83,20 +83,20 @@ static const struct emac_variant emac_variant_h3 = {
 
 static const struct emac_variant emac_variant_v3s = {
 	.default_syscon_value = 0x38000,
-	.internal_phy = PHY_INTERFACE_MODE_MII,
+	.internal_phy = true,
 	.support_mii = true
 };
 
 static const struct emac_variant emac_variant_a83t = {
 	.default_syscon_value = 0,
-	.internal_phy = 0,
+	.internal_phy = false,
 	.support_mii = true,
 	.support_rgmii = true
 };
 
 static const struct emac_variant emac_variant_a64 = {
 	.default_syscon_value = 0,
-	.internal_phy = 0,
+	.internal_phy = false,
 	.support_mii = true,
 	.support_rmii = true,
 	.support_rgmii = true
@@ -889,6 +889,10 @@ static int sun8i_dwmac_probe(struct platform_device *pdev)
 	struct sunxi_priv_data *gmac;
 	struct device *dev = &pdev->dev;
 	int ret;
+	static const struct of_device_id internal_phys[] = {
+		{ .compatible = "allwinner,sun8i-h3-ephy" },
+		{ .compatible = "allwinner,sun8i-v3s-ephy" },
+	};
 
 	ret = stmmac_get_platform_resources(pdev, &stmmac_res);
 	if (ret)
@@ -932,7 +936,7 @@ static int sun8i_dwmac_probe(struct platform_device *pdev)
 	}
 
 	plat_dat->interface = of_get_phy_mode(dev->of_node);
-	if (plat_dat->interface == gmac->variant->internal_phy) {
+	if (of_match_node(internal_phys, plat_dat->phy_node)) {
 		dev_info(&pdev->dev, "Will use internal PHY\n");
 		gmac->use_internal_phy = true;
 		gmac->ephy_clk = of_clk_get(plat_dat->phy_node, 0);
-- 
2.13.0

[PATCH 3/3] net-next: stmmac: dwmac-sun8i: choose internal PHY via compatible

[Chen-Yu Tsai]

On Fri, Jul 28, 2017 at 5:28 PM, Corentin Labbe
<clabbe.montjoie@gmail.com> wrote:
> The current way to find if the phy is internal is to compare DT phy-mode
> and emac_variant/internal_phy.
> But it will negate a possible future SoC where an external PHY use the
> same phy mode than the internal one.
>
> This patch adds a new way to find if the PHY is internal, via its
> compatible.
>
> Since the phy_mode of the internal PHY does need to be know, the
> variant internal_phy member is converted to a boolean.
>
> Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> ---
>  drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 16 ++++++++++------
>  1 file changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
> index fffd6d5fc907..04f7ddd802b0 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
> @@ -48,7 +48,7 @@
>   */
>  struct emac_variant {
>         u32 default_syscon_value;
> -       int internal_phy;
> +       bool internal_phy;

Nit: please add a verb to the name, like "has_internal_phy",
or even "soc_has_internal_phy". This makes it clear what this
property represents.

ChenYu

[PATCH 3/3] net-next: stmmac: dwmac-sun8i: choose internal PHY via compatible

[Corentin Labbe]

On Fri, Jul 28, 2017 at 05:49:55PM +0800, Chen-Yu Tsai wrote:
> On Fri, Jul 28, 2017 at 5:28 PM, Corentin Labbe
> <clabbe.montjoie@gmail.com> wrote:
> > The current way to find if the phy is internal is to compare DT phy-mode
> > and emac_variant/internal_phy.
> > But it will negate a possible future SoC where an external PHY use the
> > same phy mode than the internal one.
> >
> > This patch adds a new way to find if the PHY is internal, via its
> > compatible.
> >
> > Since the phy_mode of the internal PHY does need to be know, the
> > variant internal_phy member is converted to a boolean.
> >
> > Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> > ---
> >  drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 16 ++++++++++------
> >  1 file changed, 10 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
> > index fffd6d5fc907..04f7ddd802b0 100644
> > --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
> > +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
> > @@ -48,7 +48,7 @@
> >   */
> >  struct emac_variant {
> >         u32 default_syscon_value;
> > -       int internal_phy;
> > +       bool internal_phy;
> 
> Nit: please add a verb to the name, like "has_internal_phy",
> or even "soc_has_internal_phy". This makes it clear what this
> property represents.
> 
> ChenYu

I will use soc_has_internal_phy

Thanks

[PATCH 0/3] net-next: stmmac: support future possible different internal phy mode

[Chen-Yu Tsai]

On Fri, Jul 28, 2017 at 5:28 PM, Corentin Labbe
<clabbe.montjoie@gmail.com> wrote:
> Hello
>
> The current way to find if the phy is internal is to compare DT phy-mode
> and emac_variant/internal_phy.
> But it will negate a possible future SoC where an external PHY use the
> same phy mode than the internal one.
>
> This patchs series adds a new way to find if the PHY is internal, via its
> compatible.

You've already joined in on the discussion for the patch "net: stmmac:
dwmac-rk: Add internal phy support". It is pretty much the same issue.
Please wait for it to come to a proper conclusion. At least then we can
agree on something so different platforms with the same problem don't
have diverging solutions.

ChenYu

>
> Corentin Labbe (3):
>   dt-bindings: net: add compatible for internal sun8i-h3/sun8i-v3s PHYs
>   ARM: sunxi: h3/h5: Add sun8i-h3-ephy compatible
>   net-next: stmmac: dwmac-sun8i: choose internal PHY via compatible
>
>  Documentation/devicetree/bindings/net/dwmac-sun8i.txt |  4 ++--
>  arch/arm/boot/dts/sunxi-h3-h5.dtsi                    |  3 ++-
>  drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c     | 16 ++++++++++------
>  3 files changed, 14 insertions(+), 9 deletions(-)
>
> --
> 2.13.0
>

[PATCH 0/3] net-next: stmmac: support future possible different internal phy mode

[Andrew Lunn]

On Fri, Jul 28, 2017 at 05:53:40PM +0800, Chen-Yu Tsai wrote:
> On Fri, Jul 28, 2017 at 5:28 PM, Corentin Labbe
> <clabbe.montjoie@gmail.com> wrote:
> > Hello
> >
> > The current way to find if the phy is internal is to compare DT phy-mode
> > and emac_variant/internal_phy.
> > But it will negate a possible future SoC where an external PHY use the
> > same phy mode than the internal one.
> >
> > This patchs series adds a new way to find if the PHY is internal, via its
> > compatible.
> 
> You've already joined in on the discussion for the patch "net: stmmac:
> dwmac-rk: Add internal phy support". It is pretty much the same issue.
> Please wait for it to come to a proper conclusion. At least then we can
> agree on something so different platforms with the same problem don't
> have diverging solutions.

Yes, this is important.

     Andrew

[PATCH 0/3] net-next: stmmac: support future possible different internal phy mode

[Andrew Lunn]

On Fri, Jul 28, 2017 at 11:28:15AM +0200, Corentin Labbe wrote:
> Hello
> 
> The current way to find if the phy is internal is to compare DT phy-mode
> and emac_variant/internal_phy.
> But it will negate a possible future SoC where an external PHY use the
> same phy mode than the internal one.
> 
> This patchs series adds a new way to find if the PHY is internal, via its
> compatible.

http://elixir.free-electrons.com/linux/latest/source/drivers/of/of_mdio.c#L144

Since you also have "ethernet-phy-ieee802.3-c22", you won't get the
warning. But still, your device tree gives the wrong idea.

I've probably asked this before: Does the internal PHY use a different
PHY ID in registers 2 and 3?

    Andrew

[PATCH 0/3] net-next: stmmac: support future possible different internal phy mode

[Corentin Labbe]

On Fri, Jul 28, 2017 at 03:55:44PM +0200, Andrew Lunn wrote:
> On Fri, Jul 28, 2017 at 11:28:15AM +0200, Corentin Labbe wrote:
> > Hello
> > 
> > The current way to find if the phy is internal is to compare DT phy-mode
> > and emac_variant/internal_phy.
> > But it will negate a possible future SoC where an external PHY use the
> > same phy mode than the internal one.
> > 
> > This patchs series adds a new way to find if the PHY is internal, via its
> > compatible.
> 
> http://elixir.free-electrons.com/linux/latest/source/drivers/of/of_mdio.c#L144
> 
> Since you also have "ethernet-phy-ieee802.3-c22", you won't get the
> warning. But still, your device tree gives the wrong idea.
> 
> I've probably asked this before: Does the internal PHY use a different
> PHY ID in registers 2 and 3?
> 

yes

reg2: 0x0044
reg3: 0X1500

Regards

[PATCH 0/3] net-next: stmmac: support future possible different internal phy mode

[Andrew Lunn]

> > I've probably asked this before: Does the internal PHY use a different
> > PHY ID in registers 2 and 3?
> > 
> 
> yes
> 
> reg2: 0x0044
> reg3: 0X1500

So this is not about loading the correct PHY driver. You can already
do this based on the PHY IDs...

This is about selecting which PHY to use. Internal or External?	

     Andrew

[PATCH 0/3] net-next: stmmac: support future possible different internal phy mode

[Corentin Labbe]

On Fri, Jul 28, 2017 at 04:36:00PM +0200, Andrew Lunn wrote:
> > > I've probably asked this before: Does the internal PHY use a different
> > > PHY ID in registers 2 and 3?
> > > 
> > 
> > yes
> > 
> > reg2: 0x0044
> > reg3: 0X1500

Copy/paste error, its 1400

> 
> So this is not about loading the correct PHY driver. You can already
> do this based on the PHY IDs...
> 
> This is about selecting which PHY to use. Internal or External?	
> 
>      Andrew

It is too late when we know the PHY ID.
We need to set a syscon for choosing external/internal PHY.
So we can rely only on DT.

[PATCH 0/3] net-next: stmmac: support future possible different internal phy mode

[Andrew Lunn]

> It is too late when we know the PHY ID.
> We need to set a syscon for choosing external/internal PHY.
> So we can rely only on DT.

The point is, its not a property of the PHY. It is a syscon or a MAC
property. Having it as a MAC property would be more generic.

   Andrew

[PATCH 0/3] net-next: stmmac: support future possible different internal phy mode

[Florian Fainelli]

On 07/28/2017 07:44 AM, Corentin Labbe wrote:
> On Fri, Jul 28, 2017 at 04:36:00PM +0200, Andrew Lunn wrote:
>>>> I've probably asked this before: Does the internal PHY use a different
>>>> PHY ID in registers 2 and 3?
>>>>
>>>
>>> yes
>>>
>>> reg2: 0x0044
>>> reg3: 0X1500
> 
> Copy/paste error, its 1400
> 
>>
>> So this is not about loading the correct PHY driver. You can already
>> do this based on the PHY IDs...
>>
>> This is about selecting which PHY to use. Internal or External?	
>>
>>      Andrew
> 
> It is too late when we know the PHY ID.

> We need to set a syscon for choosing external/internal PHY.
> So we can rely only on DT.

Since the Device Tree needs to be correct to identify which PHY to use
(internal or external), if you use the standard compatible string for
the PHY that contains its OUI, e.g:

compatible = "ethernet-phy-id0044.1400", "ethernet-phy-ieee802.3-c22"

then you can have your Ethernet MAC identify whether this is an internal
PHY by having a list of compatible strings to match against.

Corentin, can you make sure you copy netdev, Andrew and myself on the
next submissions so we don't have to keep track of seemingly identical
threads (this one + the rockchip dwmac changes) and we can work towards
one solution?

Thanks
-- 
Florian

[PATCH 0/3] net-next: stmmac: support future possible different internal phy mode

[Corentin Labbe]

On Fri, Jul 28, 2017 at 10:54:30AM -0700, Florian Fainelli wrote:
> On 07/28/2017 07:44 AM, Corentin Labbe wrote:
> > On Fri, Jul 28, 2017 at 04:36:00PM +0200, Andrew Lunn wrote:
> >>>> I've probably asked this before: Does the internal PHY use a different
> >>>> PHY ID in registers 2 and 3?
> >>>>
> >>>
> >>> yes
> >>>
> >>> reg2: 0x0044
> >>> reg3: 0X1500
> > 
> > Copy/paste error, its 1400
> > 
> >>
> >> So this is not about loading the correct PHY driver. You can already
> >> do this based on the PHY IDs...
> >>
> >> This is about selecting which PHY to use. Internal or External?	
> >>
> >>      Andrew
> > 
> > It is too late when we know the PHY ID.
> 
> > We need to set a syscon for choosing external/internal PHY.
> > So we can rely only on DT.
> 
> Since the Device Tree needs to be correct to identify which PHY to use
> (internal or external), if you use the standard compatible string for
> the PHY that contains its OUI, e.g:
> 
> compatible = "ethernet-phy-id0044.1400", "ethernet-phy-ieee802.3-c22"
> 
> then you can have your Ethernet MAC identify whether this is an internal
> PHY by having a list of compatible strings to match against.

So basicly, I replace sun8i-h3-ephy by ethernet-phy-id0044.1400 and it is good ?

> 
> Corentin, can you make sure you copy netdev, Andrew and myself on the
> next submissions so we don't have to keep track of seemingly identical
> threads (this one + the rockchip dwmac changes) and we can work towards
> one solution?

Ok

Thanks
Corentin Labbe

[PATCH 0/3] net-next: stmmac: support future possible different internal phy mode

[Chen-Yu Tsai]

On Sat, Jul 29, 2017 at 2:48 PM, Corentin Labbe
<clabbe.montjoie@gmail.com> wrote:
> On Fri, Jul 28, 2017 at 10:54:30AM -0700, Florian Fainelli wrote:
>> On 07/28/2017 07:44 AM, Corentin Labbe wrote:
>> > On Fri, Jul 28, 2017 at 04:36:00PM +0200, Andrew Lunn wrote:
>> >>>> I've probably asked this before: Does the internal PHY use a different
>> >>>> PHY ID in registers 2 and 3?
>> >>>>
>> >>>
>> >>> yes
>> >>>
>> >>> reg2: 0x0044
>> >>> reg3: 0X1500
>> >
>> > Copy/paste error, its 1400
>> >
>> >>
>> >> So this is not about loading the correct PHY driver. You can already
>> >> do this based on the PHY IDs...
>> >>
>> >> This is about selecting which PHY to use. Internal or External?
>> >>
>> >>      Andrew
>> >
>> > It is too late when we know the PHY ID.
>>
>> > We need to set a syscon for choosing external/internal PHY.
>> > So we can rely only on DT.
>>
>> Since the Device Tree needs to be correct to identify which PHY to use
>> (internal or external), if you use the standard compatible string for
>> the PHY that contains its OUI, e.g:
>>
>> compatible = "ethernet-phy-id0044.1400", "ethernet-phy-ieee802.3-c22"
>>
>> then you can have your Ethernet MAC identify whether this is an internal
>> PHY by having a list of compatible strings to match against.
>
> So basicly, I replace sun8i-h3-ephy by ethernet-phy-id0044.1400 and it is good ?

IIRC you mentioned some time ago the PHY in the AC200 also has this ID?
Do you remember if this is true?

If someone were crazy enough to hook that up to the H3, then we still
wouldn't be able to tell if it's the internal or external one.

ChenYu

>
>>
>> Corentin, can you make sure you copy netdev, Andrew and myself on the
>> next submissions so we don't have to keep track of seemingly identical
>> threads (this one + the rockchip dwmac changes) and we can work towards
>> one solution?
>
> Ok
>
> Thanks
> Corentin Labbe

[PATCH 0/3] net-next: stmmac: support future possible different internal phy mode

[Corentin Labbe]

On Mon, Jul 31, 2017 at 08:19:40PM +0800, Chen-Yu Tsai wrote:
> On Sat, Jul 29, 2017 at 2:48 PM, Corentin Labbe
> <clabbe.montjoie@gmail.com> wrote:
> > On Fri, Jul 28, 2017 at 10:54:30AM -0700, Florian Fainelli wrote:
> >> On 07/28/2017 07:44 AM, Corentin Labbe wrote:
> >> > On Fri, Jul 28, 2017 at 04:36:00PM +0200, Andrew Lunn wrote:
> >> >>>> I've probably asked this before: Does the internal PHY use a different
> >> >>>> PHY ID in registers 2 and 3?
> >> >>>>
> >> >>>
> >> >>> yes
> >> >>>
> >> >>> reg2: 0x0044
> >> >>> reg3: 0X1500
> >> >
> >> > Copy/paste error, its 1400
> >> >
> >> >>
> >> >> So this is not about loading the correct PHY driver. You can already
> >> >> do this based on the PHY IDs...
> >> >>
> >> >> This is about selecting which PHY to use. Internal or External?
> >> >>
> >> >>      Andrew
> >> >
> >> > It is too late when we know the PHY ID.
> >>
> >> > We need to set a syscon for choosing external/internal PHY.
> >> > So we can rely only on DT.
> >>
> >> Since the Device Tree needs to be correct to identify which PHY to use
> >> (internal or external), if you use the standard compatible string for
> >> the PHY that contains its OUI, e.g:
> >>
> >> compatible = "ethernet-phy-id0044.1400", "ethernet-phy-ieee802.3-c22"
> >>
> >> then you can have your Ethernet MAC identify whether this is an internal
> >> PHY by having a list of compatible strings to match against.
> >
> > So basicly, I replace sun8i-h3-ephy by ethernet-phy-id0044.1400 and it is good ?
> 
> IIRC you mentioned some time ago the PHY in the AC200 also has this ID?
> Do you remember if this is true?

Yes it's certainly a AC200 PHY in the H3.

> 
> If someone were crazy enough to hook that up to the H3, then we still
> wouldn't be able to tell if it's the internal or external one.
> 

Why someone would put the same external PHY than the internal one ?
Yeah its totally crazy and I think we are safe by saying "it's not supported".

Regards