Re: [Bugme-new] [Bug 15147] New: phylib: no re-negotiation after link partner abilities changed

Re: [Bugme-new] [Bug 15147] New: phylib: no re-negotiation after link partner abilities changed

[Andrew Morton]

(switched to email.  Please respond via emailed reply-to-all, not via the
bugzilla web interface).

On Tue, 26 Jan 2010 16:24:35 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:

> http://bugzilla.kernel.org/show_bug.cgi?id=15147
> 
>            Summary: phylib: no re-negotiation after link partner abilities
>                     changed
>            Product: Drivers
>            Version: 2.5
>           Platform: All
>         OS/Version: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: normal
>           Priority: P1
>          Component: Network
>         AssignedTo: drivers_network@kernel-bugs.osdl.org
>         ReportedBy: dannybaumann@web.de
>         Regression: No
> 
> 
> E.g. with the macb driver, which uses phylib, there is no link anymore when the
> link partner changes its abilities. This is because no autonegotiation is done
> again on link changes and hence the LPA register is not updated.
> 
> Steps for reproduction:
> - Connect a 10/100 device to a 10/100 switch, configure switch port to 100Full
> - Enable interface, link will be present
> - Configure device to 10Full, link will be lost
> - Configure switch to 10Full
> 
> Result:
> Link should be present at that point, but isn't ... debug messages in
> genphy_read_status show that lpa is still at 0x4101 (100Full).
> 
> Note that all that is on an AT91SAM9G20 board (hence macb driver) with a
> Dawicom 9161 PHY connected to its Ethernet port, but AFAICT all phylib enabled
> drivers should suffer from this.
> 

>From the above it appears that this is a regression.

Can you tell us which kernel version(s) were OK and which are not?

Thanks.

Re: [Bugme-new] [Bug 15147] New: phylib: no re-negotiation after link partner abilities changed

[Danny Baumann]

Hi,

> >            Summary: phylib: no re-negotiation after link partner abilities
> >                     changed

[...]

> >          Component: Network
> >         AssignedTo: drivers_network@kernel-bugs.osdl.org
> >         ReportedBy: dannybaumann@web.de
> >         Regression: No
            ^^^^^^^^^^^^^^

;-)

> > E.g. with the macb driver, which uses phylib, there is no link anymore when the
> > link partner changes its abilities. This is because no autonegotiation is done
> > again on link changes and hence the LPA register is not updated.
> > 
> > Steps for reproduction:
> > - Connect a 10/100 device to a 10/100 switch, configure switch port to 100Full
> > - Enable interface, link will be present
> > - Configure device to 10Full, link will be lost
> > - Configure switch to 10Full
> > 
> > Result:
> > Link should be present at that point, but isn't ... debug messages in
> > genphy_read_status show that lpa is still at 0x4101 (100Full).
> > 
> > Note that all that is on an AT91SAM9G20 board (hence macb driver) with a
> > Dawicom 9161 PHY connected to its Ethernet port, but AFAICT all phylib enabled
> > drivers should suffer from this.
> > 
> 
> From the above it appears that this is a regression.
> 
> Can you tell us which kernel version(s) were OK and which are not?

As far as I am aware of, this is not a regression, at least not in
phylib (if any, it's a regression for drivers that were converted to
phylib). A code part that does re-negotiation when link is down after
link was up for some time has never been present in the state machine.
In the PHY_NOLINK state, all that has ever been done is doing
phy_read_status and checking the new link state calculated from there.

Unfortunately, I don't have a good idea what would be the best thing to
do there. As far as I can tell from the basic MII PHY registers, there
is no way to distinct the "no link and no carrier = no cable connected"
and the "no link, but carrier = negotiation failed" states. If there was
such a way, the fix probably would involve re-negotiating when going
from state 1 to state 2 (or regularly using a timer when staying in
state 2). But maybe I am missing something.

Regards,

Danny