[PATCH] net: ethernet: fec: Add missing SPEED_

[PATCH] net: ethernet: fec: Add missing SPEED_

[Corentin Labbe]

Since commit 58056c1e1b0e ("net: ethernet: Use phy_set_max_speed() to limit advertised speed"), the fec driver is unable to get any link.
This is due to missing SPEED_.

Fixes: 58056c1e1b0e ("net: ethernet: Use phy_set_max_speed() to limit advertised speed")
Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
---
 drivers/net/ethernet/freescale/fec_main.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index a17cc97..75fd7c9 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -1946,7 +1946,7 @@ static int fec_enet_mii_probe(struct net_device *ndev)
 
 	/* mask with MAC supported features */
 	if (fep->quirks & FEC_QUIRK_HAS_GBIT) {
-		phy_set_max_speed(phy_dev, 1000);
+		phy_set_max_speed(phy_dev, SPEED_1000);
 		phy_remove_link_mode(phy_dev,
 				     ETHTOOL_LINK_MODE_1000baseT_Half_BIT);
 #if !defined(CONFIG_M5272)
@@ -1954,7 +1954,7 @@ static int fec_enet_mii_probe(struct net_device *ndev)
 #endif
 	}
 	else
-		phy_set_max_speed(phy_dev, 100);
+		phy_set_max_speed(phy_dev, SPEED_100);
 
 	fep->link = 0;
 	fep->full_duplex = 0;
-- 
2.7.4

Re: [PATCH] net: ethernet: fec: Add missing SPEED_

[Florian Fainelli]

On 10/18/2018 08:05 AM, Corentin Labbe wrote:
> Since commit 58056c1e1b0e ("net: ethernet: Use phy_set_max_speed() to limit advertised speed"), the fec driver is unable to get any link.
> This is due to missing SPEED_.

But SPEED_1000 is defined in include/uapi/linux/ethtool.h as 1000, so
surely this would amount to the same code paths being taken or am I
missing something here?

> 
> Fixes: 58056c1e1b0e ("net: ethernet: Use phy_set_max_speed() to limit advertised speed")
> Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
> ---
>  drivers/net/ethernet/freescale/fec_main.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
> index a17cc97..75fd7c9 100644
> --- a/drivers/net/ethernet/freescale/fec_main.c
> +++ b/drivers/net/ethernet/freescale/fec_main.c
> @@ -1946,7 +1946,7 @@ static int fec_enet_mii_probe(struct net_device *ndev)
>  
>  	/* mask with MAC supported features */
>  	if (fep->quirks & FEC_QUIRK_HAS_GBIT) {
> -		phy_set_max_speed(phy_dev, 1000);
> +		phy_set_max_speed(phy_dev, SPEED_1000);
>  		phy_remove_link_mode(phy_dev,
>  				     ETHTOOL_LINK_MODE_1000baseT_Half_BIT);
>  #if !defined(CONFIG_M5272)
> @@ -1954,7 +1954,7 @@ static int fec_enet_mii_probe(struct net_device *ndev)
>  #endif
>  	}
>  	else
> -		phy_set_max_speed(phy_dev, 100);
> +		phy_set_max_speed(phy_dev, SPEED_100);
>  
>  	fep->link = 0;
>  	fep->full_duplex = 0;
> 


-- 
Florian

Re: [PATCH] net: ethernet: fec: Add missing SPEED_

[LABBE Corentin]

On Thu, Oct 18, 2018 at 11:39:24AM -0700, Florian Fainelli wrote:
> On 10/18/2018 08:05 AM, Corentin Labbe wrote:
> > Since commit 58056c1e1b0e ("net: ethernet: Use phy_set_max_speed() to limit advertised speed"), the fec driver is unable to get any link.
> > This is due to missing SPEED_.
> 
> But SPEED_1000 is defined in include/uapi/linux/ethtool.h as 1000, so
> surely this would amount to the same code paths being taken or am I
> missing something here?

The bisect session pointed your patch, reverting it fix the issue.
BUT since the fix seemed trivial I sent the patch without more test then compile it.
Sorry, I have just found some minutes ago that it didnt fix the issue.

But your patch is still the cause for sure.

Re: [PATCH] net: ethernet: fec: Add missing SPEED_

[Florian Fainelli]

On 10/18/2018 11:47 AM, LABBE Corentin wrote:
> On Thu, Oct 18, 2018 at 11:39:24AM -0700, Florian Fainelli wrote:
>> On 10/18/2018 08:05 AM, Corentin Labbe wrote:
>>> Since commit 58056c1e1b0e ("net: ethernet: Use phy_set_max_speed() to limit advertised speed"), the fec driver is unable to get any link.
>>> This is due to missing SPEED_.
>>
>> But SPEED_1000 is defined in include/uapi/linux/ethtool.h as 1000, so
>> surely this would amount to the same code paths being taken or am I
>> missing something here?
> 
> The bisect session pointed your patch, reverting it fix the issue.
> BUT since the fix seemed trivial I sent the patch without more test then compile it.
> Sorry, I have just found some minutes ago that it didnt fix the issue.
> 
> But your patch is still the cause for sure.
> 

What you are writing is really lowering the confidence level, first
Andrew is the author of that patch, and second "just compiling" and
pretending this fixes a problem when it does not is not quite what I
would expect.

I don't have a problem helping you find the solution or the right fix
though, even if it is not my patch, but please get the author and actual
problem right so we can move forward in confidence, thanks!
-- 
Florian

Re: [PATCH] net: ethernet: fec: Add missing SPEED_

[LABBE Corentin]

On Thu, Oct 18, 2018 at 11:55:49AM -0700, Florian Fainelli wrote:
> On 10/18/2018 11:47 AM, LABBE Corentin wrote:
> > On Thu, Oct 18, 2018 at 11:39:24AM -0700, Florian Fainelli wrote:
> >> On 10/18/2018 08:05 AM, Corentin Labbe wrote:
> >>> Since commit 58056c1e1b0e ("net: ethernet: Use phy_set_max_speed() to limit advertised speed"), the fec driver is unable to get any link.
> >>> This is due to missing SPEED_.
> >>
> >> But SPEED_1000 is defined in include/uapi/linux/ethtool.h as 1000, so
> >> surely this would amount to the same code paths being taken or am I
> >> missing something here?
> > 
> > The bisect session pointed your patch, reverting it fix the issue.
> > BUT since the fix seemed trivial I sent the patch without more test then compile it.
> > Sorry, I have just found some minutes ago that it didnt fix the issue.
> > 
> > But your patch is still the cause for sure.
> > 
> 
> What you are writing is really lowering the confidence level, first
> Andrew is the author of that patch, and second "just compiling" and
> pretending this fixes a problem when it does not is not quite what I
> would expect.
> 
> I don't have a problem helping you find the solution or the right fix
> though, even if it is not my patch, but please get the author and actual
> problem right so we can move forward in confidence, thanks!

Sorry again, I wanted to acknoledge my error but I did it too fast and late.
And sorry to have confound you with Andrew.

Re: [PATCH] net: ethernet: fec: Add missing SPEED_

[Florian Fainelli]

On 10/18/2018 12:16 PM, LABBE Corentin wrote:
> On Thu, Oct 18, 2018 at 11:55:49AM -0700, Florian Fainelli wrote:
>> On 10/18/2018 11:47 AM, LABBE Corentin wrote:
>>> On Thu, Oct 18, 2018 at 11:39:24AM -0700, Florian Fainelli wrote:
>>>> On 10/18/2018 08:05 AM, Corentin Labbe wrote:
>>>>> Since commit 58056c1e1b0e ("net: ethernet: Use phy_set_max_speed() to limit advertised speed"), the fec driver is unable to get any link.
>>>>> This is due to missing SPEED_.
>>>>
>>>> But SPEED_1000 is defined in include/uapi/linux/ethtool.h as 1000, so
>>>> surely this would amount to the same code paths being taken or am I
>>>> missing something here?
>>>
>>> The bisect session pointed your patch, reverting it fix the issue.
>>> BUT since the fix seemed trivial I sent the patch without more test then compile it.
>>> Sorry, I have just found some minutes ago that it didnt fix the issue.
>>>
>>> But your patch is still the cause for sure.
>>>
>>
>> What you are writing is really lowering the confidence level, first
>> Andrew is the author of that patch, and second "just compiling" and
>> pretending this fixes a problem when it does not is not quite what I
>> would expect.
>>
>> I don't have a problem helping you find the solution or the right fix
>> though, even if it is not my patch, but please get the author and actual
>> problem right so we can move forward in confidence, thanks!
> 
> Sorry again, I wanted to acknoledge my error but I did it too fast and late.
> And sorry to have confound you with Andrew.

No worries, here to help, let us know what your bisection points to. THanks
-- 
Florian

Re: [PATCH] net: ethernet: fec: Add missing SPEED_

[LABBE Corentin]

On Thu, Oct 18, 2018 at 12:38:32PM -0700, Florian Fainelli wrote:
> On 10/18/2018 12:16 PM, LABBE Corentin wrote:
> > On Thu, Oct 18, 2018 at 11:55:49AM -0700, Florian Fainelli wrote:
> >> On 10/18/2018 11:47 AM, LABBE Corentin wrote:
> >>> On Thu, Oct 18, 2018 at 11:39:24AM -0700, Florian Fainelli wrote:
> >>>> On 10/18/2018 08:05 AM, Corentin Labbe wrote:
> >>>>> Since commit 58056c1e1b0e ("net: ethernet: Use phy_set_max_speed() to limit advertised speed"), the fec driver is unable to get any link.
> >>>>> This is due to missing SPEED_.
> >>>>
> >>>> But SPEED_1000 is defined in include/uapi/linux/ethtool.h as 1000, so
> >>>> surely this would amount to the same code paths being taken or am I
> >>>> missing something here?
> >>>
> >>> The bisect session pointed your patch, reverting it fix the issue.
> >>> BUT since the fix seemed trivial I sent the patch without more test then compile it.
> >>> Sorry, I have just found some minutes ago that it didnt fix the issue.
> >>>
> >>> But your patch is still the cause for sure.
> >>>
> >>
> >> What you are writing is really lowering the confidence level, first
> >> Andrew is the author of that patch, and second "just compiling" and
> >> pretending this fixes a problem when it does not is not quite what I
> >> would expect.
> >>
> >> I don't have a problem helping you find the solution or the right fix
> >> though, even if it is not my patch, but please get the author and actual
> >> problem right so we can move forward in confidence, thanks!
> > 
> > Sorry again, I wanted to acknoledge my error but I did it too fast and late.
> > And sorry to have confound you with Andrew.
> 
> No worries, here to help, let us know what your bisection points to. THanks

I have added printing of phydev->supported
My working kernel (on top of 58056c1e1b0e + revert patch) got:
[    5.550838] fec_enet_mii_probe 2ff (gbit features)
[    5.555848] fec_enet_mii_probe 2ef (without 1000baseT_Half)
[    5.561620] fec_enet_mii_probe 22ef final (after pause)
[    5.566914] Micrel KSZ9021 Gigabit PHY 2188000.ethernet-1:06: attached PHY driver [Micrel KSZ9021 Gigabit PHY] (mii_bus:phy_addr=2188000.ethernet-1:06, irq=POLL)
[    8.730751] fec 2188000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[    8.788311] Sending DHCP requests ., OK
[    8.832357] IP-Config: Got DHCP answer from 192.168.66.1, my address is 192.168.66.58

the non-working kernel (next-20181015)
[    7.308917] fec_enet_mii_probe 62ff after phy_set_max_speed
[    7.314545] fec_enet_mii_probe 62ef after phy_remove_link_mode
[    7.320418] fec_enet_mii_probe 62ef after pause
and then no link

So it seems that phy_set_max_speed adds bit 14 (ETHTOOL_LINK_MODE_Asym_Pause_BIT)

I have patched by adding:
phy_remove_link_mode(phy_dev, ETHTOOL_LINK_MODE_Asym_Pause_BIT);
and got:
[    7.310559] fec_enet_mii_probe 62ff after phy_set_max_speed
[    7.316221] fec_enet_mii_probe 22ef after phy_remove_link_mode
[    7.322128] fec_enet_mii_probe 22ef after pause
[    7.326681] Micrel KSZ9021 Gigabit PHY 2188000.ethernet-1:06: attached PHY driver [Micrel KSZ9021 Gigabit PHY] (mii_bus:phy_addr=2188000.ethernet-1:06, irq=POLL)
[    7.611276] Waiting up to 3 more seconds for network.
[    7.881278] Waiting up to 2 more seconds for network.
[    8.131277] Waiting up to 2 more seconds for network.
[    8.401169] Waiting up to 2 more seconds for network.
[    8.671269] Waiting up to 2 more seconds for network.
[    8.941274] Waiting up to 1 more seconds for network.
[    9.211181] Waiting up to 1 more seconds for network.
[    9.481274] Waiting up to 1 more seconds for network.
[    9.751275] Waiting up to 1 more seconds for network.
[   10.021281] Waiting up to 0 more seconds for network.
[   10.291274] Waiting up to 0 more seconds for network.
[   10.381282] Sending DHCP requests .
[   10.473000] fec 2188000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[   12.861267] ., OK
[   12.903405] IP-Config: Got DHCP answer from 192.168.66.1, my address is 192.168.66.58

So at least I got a link, but the link is still late to got

Regards

Re: [PATCH] net: ethernet: fec: Add missing SPEED_

[Florian Fainelli]

On 10/18/2018 12:59 PM, LABBE Corentin wrote:
> On Thu, Oct 18, 2018 at 12:38:32PM -0700, Florian Fainelli wrote:
>> On 10/18/2018 12:16 PM, LABBE Corentin wrote:
>>> On Thu, Oct 18, 2018 at 11:55:49AM -0700, Florian Fainelli wrote:
>>>> On 10/18/2018 11:47 AM, LABBE Corentin wrote:
>>>>> On Thu, Oct 18, 2018 at 11:39:24AM -0700, Florian Fainelli wrote:
>>>>>> On 10/18/2018 08:05 AM, Corentin Labbe wrote:
>>>>>>> Since commit 58056c1e1b0e ("net: ethernet: Use phy_set_max_speed() to limit advertised speed"), the fec driver is unable to get any link.
>>>>>>> This is due to missing SPEED_.
>>>>>>
>>>>>> But SPEED_1000 is defined in include/uapi/linux/ethtool.h as 1000, so
>>>>>> surely this would amount to the same code paths being taken or am I
>>>>>> missing something here?
>>>>>
>>>>> The bisect session pointed your patch, reverting it fix the issue.
>>>>> BUT since the fix seemed trivial I sent the patch without more test then compile it.
>>>>> Sorry, I have just found some minutes ago that it didnt fix the issue.
>>>>>
>>>>> But your patch is still the cause for sure.
>>>>>
>>>>
>>>> What you are writing is really lowering the confidence level, first
>>>> Andrew is the author of that patch, and second "just compiling" and
>>>> pretending this fixes a problem when it does not is not quite what I
>>>> would expect.
>>>>
>>>> I don't have a problem helping you find the solution or the right fix
>>>> though, even if it is not my patch, but please get the author and actual
>>>> problem right so we can move forward in confidence, thanks!
>>>
>>> Sorry again, I wanted to acknoledge my error but I did it too fast and late.
>>> And sorry to have confound you with Andrew.
>>
>> No worries, here to help, let us know what your bisection points to. THanks
> 
> I have added printing of phydev->supported
> My working kernel (on top of 58056c1e1b0e + revert patch) got:
> [    5.550838] fec_enet_mii_probe 2ff (gbit features)
> [    5.555848] fec_enet_mii_probe 2ef (without 1000baseT_Half)
> [    5.561620] fec_enet_mii_probe 22ef final (after pause)
> [    5.566914] Micrel KSZ9021 Gigabit PHY 2188000.ethernet-1:06: attached PHY driver [Micrel KSZ9021 Gigabit PHY] (mii_bus:phy_addr=2188000.ethernet-1:06, irq=POLL)
> [    8.730751] fec 2188000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
> [    8.788311] Sending DHCP requests ., OK
> [    8.832357] IP-Config: Got DHCP answer from 192.168.66.1, my address is 192.168.66.58
> 
> the non-working kernel (next-20181015)
> [    7.308917] fec_enet_mii_probe 62ff after phy_set_max_speed
> [    7.314545] fec_enet_mii_probe 62ef after phy_remove_link_mode
> [    7.320418] fec_enet_mii_probe 62ef after pause
> and then no link
> 
> So it seems that phy_set_max_speed adds bit 14 (ETHTOOL_LINK_MODE_Asym_Pause_BIT)

It's not masking it so it must be coming from phy_probe().

> 
> I have patched by adding:
> phy_remove_link_mode(phy_dev, ETHTOOL_LINK_MODE_Asym_Pause_BIT);
> and got:
> [    7.310559] fec_enet_mii_probe 62ff after phy_set_max_speed
> [    7.316221] fec_enet_mii_probe 22ef after phy_remove_link_mode
> [    7.322128] fec_enet_mii_probe 22ef after pause
> [    7.326681] Micrel KSZ9021 Gigabit PHY 2188000.ethernet-1:06: attached PHY driver [Micrel KSZ9021 Gigabit PHY] (mii_bus:phy_addr=2188000.ethernet-1:06, irq=POLL)
> [    7.611276] Waiting up to 3 more seconds for network.
> [    7.881278] Waiting up to 2 more seconds for network.
> [    8.131277] Waiting up to 2 more seconds for network.
> [    8.401169] Waiting up to 2 more seconds for network.
> [    8.671269] Waiting up to 2 more seconds for network.
> [    8.941274] Waiting up to 1 more seconds for network.
> [    9.211181] Waiting up to 1 more seconds for network.
> [    9.481274] Waiting up to 1 more seconds for network.
> [    9.751275] Waiting up to 1 more seconds for network.
> [   10.021281] Waiting up to 0 more seconds for network.
> [   10.291274] Waiting up to 0 more seconds for network.
> [   10.381282] Sending DHCP requests .
> [   10.473000] fec 2188000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
> [   12.861267] ., OK
> [   12.903405] IP-Config: Got DHCP answer from 192.168.66.1, my address is 192.168.66.58
> 
> So at least I got a link, but the link is still late to got

The delay is likely something entirely different, it could be some of
Heiner's recent changes to PHYLIB, Heiner do you have access to a system
that polls the PHY?
-- 
Florian

Re: [PATCH] net: ethernet: fec: Add missing SPEED_

[Heiner Kallweit]

On 18.10.2018 22:10, Florian Fainelli wrote:
> On 10/18/2018 12:59 PM, LABBE Corentin wrote:
>> On Thu, Oct 18, 2018 at 12:38:32PM -0700, Florian Fainelli wrote:
>>> On 10/18/2018 12:16 PM, LABBE Corentin wrote:
>>>> On Thu, Oct 18, 2018 at 11:55:49AM -0700, Florian Fainelli wrote:
>>>>> On 10/18/2018 11:47 AM, LABBE Corentin wrote:
>>>>>> On Thu, Oct 18, 2018 at 11:39:24AM -0700, Florian Fainelli wrote:
>>>>>>> On 10/18/2018 08:05 AM, Corentin Labbe wrote:
>>>>>>>> Since commit 58056c1e1b0e ("net: ethernet: Use phy_set_max_speed() to limit advertised speed"), the fec driver is unable to get any link.
>>>>>>>> This is due to missing SPEED_.
>>>>>>>
>>>>>>> But SPEED_1000 is defined in include/uapi/linux/ethtool.h as 1000, so
>>>>>>> surely this would amount to the same code paths being taken or am I
>>>>>>> missing something here?
>>>>>>
>>>>>> The bisect session pointed your patch, reverting it fix the issue.
>>>>>> BUT since the fix seemed trivial I sent the patch without more test then compile it.
>>>>>> Sorry, I have just found some minutes ago that it didnt fix the issue.
>>>>>>
>>>>>> But your patch is still the cause for sure.
>>>>>>
>>>>>
>>>>> What you are writing is really lowering the confidence level, first
>>>>> Andrew is the author of that patch, and second "just compiling" and
>>>>> pretending this fixes a problem when it does not is not quite what I
>>>>> would expect.
>>>>>
>>>>> I don't have a problem helping you find the solution or the right fix
>>>>> though, even if it is not my patch, but please get the author and actual
>>>>> problem right so we can move forward in confidence, thanks!
>>>>
>>>> Sorry again, I wanted to acknoledge my error but I did it too fast and late.
>>>> And sorry to have confound you with Andrew.
>>>
>>> No worries, here to help, let us know what your bisection points to. THanks
>>
>> I have added printing of phydev->supported
>> My working kernel (on top of 58056c1e1b0e + revert patch) got:
>> [    5.550838] fec_enet_mii_probe 2ff (gbit features)
>> [    5.555848] fec_enet_mii_probe 2ef (without 1000baseT_Half)
>> [    5.561620] fec_enet_mii_probe 22ef final (after pause)
>> [    5.566914] Micrel KSZ9021 Gigabit PHY 2188000.ethernet-1:06: attached PHY driver [Micrel KSZ9021 Gigabit PHY] (mii_bus:phy_addr=2188000.ethernet-1:06, irq=POLL)
>> [    8.730751] fec 2188000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
>> [    8.788311] Sending DHCP requests ., OK
>> [    8.832357] IP-Config: Got DHCP answer from 192.168.66.1, my address is 192.168.66.58
>>
>> the non-working kernel (next-20181015)
>> [    7.308917] fec_enet_mii_probe 62ff after phy_set_max_speed
>> [    7.314545] fec_enet_mii_probe 62ef after phy_remove_link_mode
>> [    7.320418] fec_enet_mii_probe 62ef after pause
>> and then no link
>>
>> So it seems that phy_set_max_speed adds bit 14 (ETHTOOL_LINK_MODE_Asym_Pause_BIT)
> 
> It's not masking it so it must be coming from phy_probe().
> 
See df8ed346d4a8 ("net: phy: fix flag masking in __set_phy_supported").
phy_set_max_speed() used to (unintentionally) mask the pause bits
and it seems that the fec driver used this bug as a feature.

>>
>> I have patched by adding:
>> phy_remove_link_mode(phy_dev, ETHTOOL_LINK_MODE_Asym_Pause_BIT);

Instead of programmatically removing the feature bit it should be
possible to do this in the PHY driver configuration. See also
this part of phy_probe().

	if (phydrv->features & (SUPPORTED_Pause | SUPPORTED_Asym_Pause)) {
		phydev->supported &= ~(SUPPORTED_Pause | SUPPORTED_Asym_Pause);
		phydev->supported |= phydrv->features &
				     (SUPPORTED_Pause | SUPPORTED_Asym_Pause);
	} else {
		phydev->supported |= SUPPORTED_Pause | SUPPORTED_Asym_Pause;
	}

>> and got:
>> [    7.310559] fec_enet_mii_probe 62ff after phy_set_max_speed
>> [    7.316221] fec_enet_mii_probe 22ef after phy_remove_link_mode
>> [    7.322128] fec_enet_mii_probe 22ef after pause
>> [    7.326681] Micrel KSZ9021 Gigabit PHY 2188000.ethernet-1:06: attached PHY driver [Micrel KSZ9021 Gigabit PHY] (mii_bus:phy_addr=2188000.ethernet-1:06, irq=POLL)
>> [    7.611276] Waiting up to 3 more seconds for network.
>> [    7.881278] Waiting up to 2 more seconds for network.
>> [    8.131277] Waiting up to 2 more seconds for network.
>> [    8.401169] Waiting up to 2 more seconds for network.
>> [    8.671269] Waiting up to 2 more seconds for network.
>> [    8.941274] Waiting up to 1 more seconds for network.
>> [    9.211181] Waiting up to 1 more seconds for network.
>> [    9.481274] Waiting up to 1 more seconds for network.
>> [    9.751275] Waiting up to 1 more seconds for network.
>> [   10.021281] Waiting up to 0 more seconds for network.
>> [   10.291274] Waiting up to 0 more seconds for network.
>> [   10.381282] Sending DHCP requests .
>> [   10.473000] fec 2188000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
>> [   12.861267] ., OK
>> [   12.903405] IP-Config: Got DHCP answer from 192.168.66.1, my address is 192.168.66.58
>>
>> So at least I got a link, but the link is still late to got
> 
> The delay is likely something entirely different, it could be some of
> Heiner's recent changes to PHYLIB, Heiner do you have access to a system
> that polls the PHY?
> 
I don't think there's anything wrong with phylib. Time difference
between the fec_enet_mii_probe messages and the "link up" message
is little bit more than 3s in both cases.
For a reason not visible here the fec_enet_mii_probe messages
come 2s later in the second case.
What happens after the "link up" message is out of control of phylib.

RE: [PATCH] net: ethernet: fec: Add missing SPEED_

[Andy Duan]

From: Heiner Kallweit <hkallweit1@gmail.com> Sent: 2018年10月19日 4:41
> On 18.10.2018 22:10, Florian Fainelli wrote:
> > On 10/18/2018 12:59 PM, LABBE Corentin wrote:
> >> On Thu, Oct 18, 2018 at 12:38:32PM -0700, Florian Fainelli wrote:
> >>> On 10/18/2018 12:16 PM, LABBE Corentin wrote:
> >>>> On Thu, Oct 18, 2018 at 11:55:49AM -0700, Florian Fainelli wrote:
> >>>>> On 10/18/2018 11:47 AM, LABBE Corentin wrote:
> >>>>>> On Thu, Oct 18, 2018 at 11:39:24AM -0700, Florian Fainelli
> wrote:
> >>>>>>> On 10/18/2018 08:05 AM, Corentin Labbe wrote:
> >>>>>>>> Since commit 58056c1e1b0e ("net: ethernet: Use
> phy_set_max_speed() to limit advertised speed"), the fec driver is unable
> to get any link.
> >>>>>>>> This is due to missing SPEED_.
> >>>>>>>
> >>>>>>> But SPEED_1000 is defined in include/uapi/linux/ethtool.h as
> >>>>>>> 1000, so surely this would amount to the same code paths being
> >>>>>>> taken or am I missing something here?
> >>>>>>
> >>>>>> The bisect session pointed your patch, reverting it fix the issue.
> >>>>>> BUT since the fix seemed trivial I sent the patch without more test
> then compile it.
> >>>>>> Sorry, I have just found some minutes ago that it didnt fix the
> issue.
> >>>>>>
> >>>>>> But your patch is still the cause for sure.
> >>>>>>
> >>>>>
> >>>>> What you are writing is really lowering the confidence level,
> >>>>> first Andrew is the author of that patch, and second "just
> >>>>> compiling" and pretending this fixes a problem when it does not is
> >>>>> not quite what I would expect.
> >>>>>
> >>>>> I don't have a problem helping you find the solution or the right
> >>>>> fix though, even if it is not my patch, but please get the author
> >>>>> and actual problem right so we can move forward in confidence,
> thanks!
> >>>>
> >>>> Sorry again, I wanted to acknoledge my error but I did it too fast and
> late.
> >>>> And sorry to have confound you with Andrew.
> >>>
> >>> No worries, here to help, let us know what your bisection points to.
> >>> THanks
> >>
> >> I have added printing of phydev->supported My working kernel (on top
> >> of 58056c1e1b0e + revert patch) got:
> >> [    5.550838] fec_enet_mii_probe 2ff (gbit features)
> >> [    5.555848] fec_enet_mii_probe 2ef (without 1000baseT_Half)
> >> [    5.561620] fec_enet_mii_probe 22ef final (after pause)
> >> [    5.566914] Micrel KSZ9021 Gigabit PHY 2188000.ethernet-1:06:
> attached PHY driver [Micrel KSZ9021 Gigabit PHY]
> (mii_bus:phy_addr=2188000.ethernet-1:06, irq=POLL)
> >> [    8.730751] fec 2188000.ethernet eth0: Link is Up - 1Gbps/Full -
> flow control rx/tx
> >> [    8.788311] Sending DHCP requests ., OK
> >> [    8.832357] IP-Config: Got DHCP answer from 192.168.66.1, my
> address is 192.168.66.58
> >>
> >> the non-working kernel (next-20181015)
> >> [    7.308917] fec_enet_mii_probe 62ff after phy_set_max_speed
> >> [    7.314545] fec_enet_mii_probe 62ef after
> phy_remove_link_mode
> >> [    7.320418] fec_enet_mii_probe 62ef after pause
> >> and then no link
> >>
> >> So it seems that phy_set_max_speed adds bit 14
> >> (ETHTOOL_LINK_MODE_Asym_Pause_BIT)
> >
> > It's not masking it so it must be coming from phy_probe().
> >
> See df8ed346d4a8 ("net: phy: fix flag masking in __set_phy_supported").
> phy_set_max_speed() used to (unintentionally) mask the pause bits and it
> seems that the fec driver used this bug as a feature.
> 
> >>
> >> I have patched by adding:
> >> phy_remove_link_mode(phy_dev,
> ETHTOOL_LINK_MODE_Asym_Pause_BIT);
> 
> Instead of programmatically removing the feature bit it should be possible
> to do this in the PHY driver configuration. See also this part of
> phy_probe().
> 
> 	if (phydrv->features & (SUPPORTED_Pause |
> SUPPORTED_Asym_Pause)) {
> 		phydev->supported &= ~(SUPPORTED_Pause |
> SUPPORTED_Asym_Pause);
> 		phydev->supported |= phydrv->features &
> 				     (SUPPORTED_Pause | SUPPORTED_Asym_Pause);
> 	} else {
> 		phydev->supported |= SUPPORTED_Pause |
> SUPPORTED_Asym_Pause;
> 	}

The ksz9021 phy driver don't set Pause feature,  then the phylib enable "SUPPORTED_Pause" and " SUPPORTED_Asym_Pause" in both.
Micrel.c:
        .phy_id         = PHY_ID_KSZ9021,
        .phy_id_mask    = 0x000ffffe,
        .name           = "Micrel KSZ9021 Gigabit PHY",
        .features       = PHY_GBIT_FEATURES,

From @LABBE Corentin debug,  it seem ksz9021 cannot advertise Pause and Asym pause in both, otherwise it cannot link up.
From ksz9021 datasheet description as below,  Symmetric & Asymmetric PAUSE is for local device,  I don't understand its mean.  
4.11:10 Pause
[0,0] = No PAUSE
[1,0] = Asymmetric PAUSE (link partner)
[0,1] = Symmetric PAUSE
[1,1] = Symmetric & Asymmetric PAUSE (local device)

@ LABBE Corentin, you can try this:
Micrel.c:
        .phy_id         = PHY_ID_KSZ9021,
        .phy_id_mask    = 0x000ffffe,
        .name           = "Micrel KSZ9021 Gigabit PHY",
        .features       = PHY_GBIT_FEATURES | SUPPORTED_Pause,


In fact,  I test net tree without any change with AR8031 and there has no link problem.


Andy

Re: [PATCH] net: ethernet: fec: Add missing SPEED_

[Andrew Lunn]

> >> I have patched by adding:
> >> phy_remove_link_mode(phy_dev, ETHTOOL_LINK_MODE_Asym_Pause_BIT);
> 
> Instead of programmatically removing the feature bit it should be
> possible to do this in the PHY driver configuration. See also
> this part of phy_probe().
> 
> 	if (phydrv->features & (SUPPORTED_Pause | SUPPORTED_Asym_Pause)) {
> 		phydev->supported &= ~(SUPPORTED_Pause | SUPPORTED_Asym_Pause);
> 		phydev->supported |= phydrv->features &
> 				     (SUPPORTED_Pause | SUPPORTED_Asym_Pause);
> 	} else {
> 		phydev->supported |= SUPPORTED_Pause | SUPPORTED_Asym_Pause;
> 	}

Sorry for the late reply. Been on vacation.

I need to check the datasheet, but it seems like the KSZ9021 does not
support asym pause. Using the above code is the correct way to solve
this problem. Look at the bcm63xx.c:bcm63xx_config_init() which does
this.

I will cook up a patch.

  Andrew

Re: [PATCH] net: ethernet: fec: Add missing SPEED_

[Heiner Kallweit]

On 20.10.2018 17:39, Andrew Lunn wrote:
>>>> I have patched by adding:
>>>> phy_remove_link_mode(phy_dev, ETHTOOL_LINK_MODE_Asym_Pause_BIT);
>>
>> Instead of programmatically removing the feature bit it should be
>> possible to do this in the PHY driver configuration. See also
>> this part of phy_probe().
>>
>> 	if (phydrv->features & (SUPPORTED_Pause | SUPPORTED_Asym_Pause)) {
>> 		phydev->supported &= ~(SUPPORTED_Pause | SUPPORTED_Asym_Pause);
>> 		phydev->supported |= phydrv->features &
>> 				     (SUPPORTED_Pause | SUPPORTED_Asym_Pause);
>> 	} else {
>> 		phydev->supported |= SUPPORTED_Pause | SUPPORTED_Asym_Pause;
>> 	}
> 
> Sorry for the late reply. Been on vacation.
> 
> I need to check the datasheet, but it seems like the KSZ9021 does not
> support asym pause. Using the above code is the correct way to solve
> this problem. Look at the bcm63xx.c:bcm63xx_config_init() which does
> this.
> 
I dare to dispute here ;) Above code snippet from phy_probe() will
(try to) set also SUPPORTED_Asym_Pause, because phydrv->features
doesn't include any of the two pause flags.
The statement in bcm63xx_config_init you refer to seems to be a
no-op to me therefore.

I'd say the correct way is to change the PHY config like this:
.features	= PHY_BASIC_FEATURES | SUPPORTED_Pause;
It's exactly the use case the code snippet above covers.

I think the bcm63xx driver would need to be changed.

> I will cook up a patch.
> 
>   Andrew
> 

Re: [PATCH] net: ethernet: fec: Add missing SPEED_

[Andrew Lunn]

> I dare to dispute here ;) Above code snippet from phy_probe() will
> (try to) set also SUPPORTED_Asym_Pause, because phydrv->features
> doesn't include any of the two pause flags.
> The statement in bcm63xx_config_init you refer to seems to be a
> no-op to me therefore.
> 
> I'd say the correct way is to change the PHY config like this:
> .features	= PHY_BASIC_FEATURES | SUPPORTED_Pause;
> It's exactly the use case the code snippet above covers.

Yes, you are correct.

But it is no longer possible to just do PHY_BASIC_FEATURES |
SUPPORTED_Pause because .features is no loner a u32 but a linux
bitmap.

We need to keep the same idea, allow the PHY driver to indicate it
supports a subset of Pause, and if not, enable pause by default.

Maybe the easiest way is to move this chunk of code to after the probe
function is called.

	 Andrew

Re: [PATCH] net: ethernet: fec: Add missing SPEED_

[Heiner Kallweit]

On 20.10.2018 20:59, Andrew Lunn wrote:
>> I dare to dispute here ;) Above code snippet from phy_probe() will
>> (try to) set also SUPPORTED_Asym_Pause, because phydrv->features
>> doesn't include any of the two pause flags.
>> The statement in bcm63xx_config_init you refer to seems to be a
>> no-op to me therefore.
>>
>> I'd say the correct way is to change the PHY config like this:
>> .features	= PHY_BASIC_FEATURES | SUPPORTED_Pause;
>> It's exactly the use case the code snippet above covers.
> 
> Yes, you are correct.
> 
> But it is no longer possible to just do PHY_BASIC_FEATURES |
> SUPPORTED_Pause because .features is no loner a u32 but a linux
> bitmap.
> 
Ahh, missed that.

> We need to keep the same idea, allow the PHY driver to indicate it
> supports a subset of Pause, and if not, enable pause by default.
> 
Could the PHY driver define its own bitmap instead of pointing to
one of the predefined ones?

> Maybe the easiest way is to move this chunk of code to after the probe
> function is called.
> 
> 	 Andrew
> 

Re: [PATCH] net: ethernet: fec: Add missing SPEED_

[Andrew Lunn]

> > Yes, you are correct.
> > 
> > But it is no longer possible to just do PHY_BASIC_FEATURES |
> > SUPPORTED_Pause because .features is no loner a u32 but a linux
> > bitmap.
> > 
> Ahh, missed that.

Yes, easy to miss, since it is still work in progress. The next
patchset completes the migration, making phydev->advertise and
phydev->supported bitmaps.

> > We need to keep the same idea, allow the PHY driver to indicate it
> > supports a subset of Pause, and if not, enable pause by default.
> > 
> Could the PHY driver define its own bitmap instead of pointing to
> one of the predefined ones?

I'm actually just adding a few more pre-defined ones. I suspect they
will get used by more than one driver. These changed have uncovered a
few bugs with pause, and i would not be surprised to find there are
more still to be found.

     Andrew

Re: [PATCH] net: ethernet: fec: Add missing SPEED_

[Andrew Lunn]

On Thu, Oct 18, 2018 at 09:59:09PM +0200, LABBE Corentin wrote:
> On Thu, Oct 18, 2018 at 12:38:32PM -0700, Florian Fainelli wrote:
> > On 10/18/2018 12:16 PM, LABBE Corentin wrote:
> > > On Thu, Oct 18, 2018 at 11:55:49AM -0700, Florian Fainelli wrote:
> > >> On 10/18/2018 11:47 AM, LABBE Corentin wrote:
> > >>> On Thu, Oct 18, 2018 at 11:39:24AM -0700, Florian Fainelli wrote:
> > >>>> On 10/18/2018 08:05 AM, Corentin Labbe wrote:
> > >>>>> Since commit 58056c1e1b0e ("net: ethernet: Use phy_set_max_speed() to limit advertised speed"), the fec driver is unable to get any link.
> > >>>>> This is due to missing SPEED_.
> > >>>>
> > >>>> But SPEED_1000 is defined in include/uapi/linux/ethtool.h as 1000, so
> > >>>> surely this would amount to the same code paths being taken or am I
> > >>>> missing something here?
> > >>>
> > >>> The bisect session pointed your patch, reverting it fix the issue.
> > >>> BUT since the fix seemed trivial I sent the patch without more test then compile it.
> > >>> Sorry, I have just found some minutes ago that it didnt fix the issue.
> > >>>
> > >>> But your patch is still the cause for sure.
> > >>>
> > >>
> > >> What you are writing is really lowering the confidence level, first
> > >> Andrew is the author of that patch, and second "just compiling" and
> > >> pretending this fixes a problem when it does not is not quite what I
> > >> would expect.
> > >>
> > >> I don't have a problem helping you find the solution or the right fix
> > >> though, even if it is not my patch, but please get the author and actual
> > >> problem right so we can move forward in confidence, thanks!
> > > 
> > > Sorry again, I wanted to acknoledge my error but I did it too fast and late.
> > > And sorry to have confound you with Andrew.
> > 
> > No worries, here to help, let us know what your bisection points to. THanks
> 
> I have added printing of phydev->supported
> My working kernel (on top of 58056c1e1b0e + revert patch) got:
> [    5.550838] fec_enet_mii_probe 2ff (gbit features)
> [    5.555848] fec_enet_mii_probe 2ef (without 1000baseT_Half)
> [    5.561620] fec_enet_mii_probe 22ef final (after pause)
> [    5.566914] Micrel KSZ9021 Gigabit PHY 2188000.ethernet-1:06: attached PHY driver [Micrel KSZ9021 Gigabit PHY] (mii_bus:phy_addr=2188000.ethernet-1:06, irq=POLL)

I just looked at the datasheet for the KSZ9021. It supports Pause and
ASym Pause. So i would expect these bits to be set. However, the FEC
MAC is unable to support Asym pause, it only supports Pause. So it is
the MAC drivers responsibility to clear Asym Pause.

        /* mask with MAC supported features */
	if (fep->quirks & FEC_QUIRK_HAS_GBIT) {
                phy_set_max_speed(phy_dev, 1000);
                phy_remove_link_mode(phy_dev,
                                     ETHTOOL_LINK_MODE_1000baseT_Half_BIT);
#if !defined(CONFIG_M5272)
	phy_support_sym_pause(phy_dev);
#endif
        }
        else
                phy_set_max_speed(phy_dev, 100);

I think we just need to take this #if !defined out, so always
indicating that sym_pause is supported. And we want
phy_support_sym_pause() to clear the asym_pause bit, if set.

	Andrew

Re: [PATCH] net: ethernet: fec: Add missing SPEED_

[LABBE Corentin]

On Thu, Oct 18, 2018 at 12:38:32PM -0700, Florian Fainelli wrote:
> On 10/18/2018 12:16 PM, LABBE Corentin wrote:
> > On Thu, Oct 18, 2018 at 11:55:49AM -0700, Florian Fainelli wrote:
> >> On 10/18/2018 11:47 AM, LABBE Corentin wrote:
> >>> On Thu, Oct 18, 2018 at 11:39:24AM -0700, Florian Fainelli wrote:
> >>>> On 10/18/2018 08:05 AM, Corentin Labbe wrote:
> >>>>> Since commit 58056c1e1b0e ("net: ethernet: Use phy_set_max_speed() to limit advertised speed"), the fec driver is unable to get any link.
> >>>>> This is due to missing SPEED_.
> >>>>
> >>>> But SPEED_1000 is defined in include/uapi/linux/ethtool.h as 1000, so
> >>>> surely this would amount to the same code paths being taken or am I
> >>>> missing something here?
> >>>
> >>> The bisect session pointed your patch, reverting it fix the issue.
> >>> BUT since the fix seemed trivial I sent the patch without more test then compile it.
> >>> Sorry, I have just found some minutes ago that it didnt fix the issue.
> >>>
> >>> But your patch is still the cause for sure.
> >>>
> >>
> >> What you are writing is really lowering the confidence level, first
> >> Andrew is the author of that patch, and second "just compiling" and
> >> pretending this fixes a problem when it does not is not quite what I
> >> would expect.
> >>
> >> I don't have a problem helping you find the solution or the right fix
> >> though, even if it is not my patch, but please get the author and actual
> >> problem right so we can move forward in confidence, thanks!
> > 
> > Sorry again, I wanted to acknoledge my error but I did it too fast and late.
> > And sorry to have confound you with Andrew.
> 
> No worries, here to help, let us know what your bisection points to. THanks
> -- 

So I can now confirm that adding "phy_remove_link_mode(phy_dev, ETHTOOL_LINK_MODE_Asym_Pause_BIT);" fix the issue cause by 58056c1e1b0e.
The second problem (long time to got link) was due to my change of CONF_CARRIER_TIMEOUT.
I still dont understand why setting it to 3s (instead of 120) caused that.

I will send fixed patchs soon.

Regards