From: Russell King - ARM Linux <linux@armlinux.org.uk>
To: Yunsheng Lin <linyunsheng@huawei.com>
Cc: Andrew Lunn <andrew@lunn.ch>,
Florian Fainelli <f.fainelli@gmail.com>,
"davem@davemloft.net" <davem@davemloft.net>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
Weiwei Deng <dengweiwei@huawei.com>,
"Yisen.Zhuang@huawei.com" <Yisen.Zhuang@huawei.com>,
"huangdaode@hisilicon.com" <huangdaode@hisilicon.com>,
"lipeng321@huawei.com" <lipeng321@huawei.com>,
"salil.mehta@huawei.com" <salil.mehta@huawei.com>,
lijianhua 00216010 <lijianhua@huawei.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: Question: pause mode disabled for marvell 88e151x phy
Date: Tue, 18 Dec 2018 10:08:30 +0000 [thread overview]
Message-ID: <20181218100830.GK26090@n2100.armlinux.org.uk> (raw)
In-Reply-To: <35342e11-cfb9-00ab-0abd-448054bd7564@huawei.com>
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
next prev parent reply other threads:[~2018-12-18 10:08 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-15 8:07 Question: pause mode disabled for marvell 88e151x phy Yunsheng Lin
2018-12-15 10:37 ` Russell King - ARM Linux
2018-12-17 9:42 ` Yunsheng Lin
2018-12-17 14:36 ` Russell King - ARM Linux
2018-12-18 9:34 ` Yunsheng Lin
2018-12-18 10:08 ` Russell King - ARM Linux [this message]
2019-01-05 3:28 ` Yunsheng Lin
2019-01-23 22:41 ` Russell King - ARM Linux admin
2019-01-24 12:28 ` Yunsheng Lin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181218100830.GK26090@n2100.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=Yisen.Zhuang@huawei.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=dengweiwei@huawei.com \
--cc=f.fainelli@gmail.com \
--cc=huangdaode@hisilicon.com \
--cc=lijianhua@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linyunsheng@huawei.com \
--cc=lipeng321@huawei.com \
--cc=netdev@vger.kernel.org \
--cc=salil.mehta@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox