linux-kernel - Re: Question: pause mode disabled for marvell 88e151x phy

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20181218100830.GK26090@n2100.armlinux.org.uk>
Date:   Tue, 18 Dec 2018 10:08:30 +0000
From:   Russell King - ARM Linux <linux@...linux.org.uk>
To:     Yunsheng Lin <linyunsheng@...wei.com>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Weiwei Deng <dengweiwei@...wei.com>,
        "Yisen.Zhuang@...wei.com" <Yisen.Zhuang@...wei.com>,
        "huangdaode@...ilicon.com" <huangdaode@...ilicon.com>,
        "lipeng321@...wei.com" <lipeng321@...wei.com>,
        "salil.mehta@...wei.com" <salil.mehta@...wei.com>,
        lijianhua 00216010 <lijianhua@...wei.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Question: pause mode disabled for marvell 88e151x phy

On Tue, Dec 18, 2018 at 05:34:27PM +0800, Yunsheng Lin wrote:
> On 2018/12/17 22:36, Russell King - ARM Linux wrote:
> > As I've previously stated, the behaviour I've seen is _both_ pause bits
> > clear:
> > 
> > If I set bit 10 (pause), and read back to confirm:
> > 
> >   MII PHY #0 transceiver registers:
> >    1000 796d 0141 0dd1 05e1 c5e1 000d 2001
> >                        ^^^^
> >    4806 0200 3800 0000 0000 0003 0000 3000
> >    3060 af48 0000 7c40 0020 0000 0000 0000
> >    0000 0000 0040 0000 0000 0000 0000 0000.
> > 
> > Now if I trigger a renegotiation of any kind, and read-back the registers:
> > 
> >  MII PHY #0 transceiver registers:
> >    1000 7949 0141 0dd1 01e1 0000 0004 2001
> >                        ^^^^
> >    0000 0200 0000 0000 0000 0003 0000 3000
> >    3060 8000 0000 0040 0020 0000 0000 0000
> >    0000 0000 0040 0000 0000 0000 0000 0000.
> > ...
> >  MII PHY #0 transceiver registers:
> >    1000 796d 0141 0dd1 01e1 c5e1 000d 2001
> >                        ^^^^
> >    4806 0200 3800 0000 0000 0003 0000 3000
> >    3060 af48 0000 7c40 0020 0000 0000 0000
> >    0000 0000 0040 0000 0000 0000 0000 0000.
> > 
> > See that register 4 now has the pause bit cleared.
> 
> I wonder when the the pause bit was clear, is it during negotiation
> process or after negotiation? if the partner phy see the pause bit before
> the pause bit is clear?

As was stated in the original commit:

    While these bits may be correctly conveyed to the link partner on the
    first negotiation, a subsequent negotiation (eg, due to negotiation
    restart by the link partner, or reconnection of the cable) will result
    in the link partner seeing these bits as zero, while the kernel
    believes that it has advertised pause modes.

To state in a different way:

    On the _first_ negotiation, the pause bits as seen by the link partner
    will be what we wrote into the register.  However, during that
    negotiation the bits in the register clear _after_ the base page has
    been sent to the link partner.

    A subsequent negotiation will send the now-clear pause bits to the
    link partner.

I hope that's now clear.

> Also, it seems the phy driver always set the pause bit back before
> begining a negotiation. But I am not sure it makes a difference here.

There is a world of difference between asking the kernel to do a
renegotiation, and unplugging/replugging the cable, or asking the
link partner to do a renegotiation.

In the former case, yes, the kernel will reprogram the advertisement
register.  In the latter two cases, the kernel does not and this is
where the problem occurs.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up