[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <bd0a636c351b05e0faa1b9009cb09334bc72cee4.camel@st.com>
Date: Tue, 24 Nov 2020 18:00:46 +0100
From: Antonio Borneo <antonio.borneo@...com>
To: Russell King - ARM Linux admin <linux@...linux.org.uk>,
Willy Liu <willy.liu@...ltek.com>,
Heiner Kallweit <hkallweit1@...il.com>
CC: Andrew Lunn <andrew@...n.ch>,
"David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>, <netdev@...r.kernel.org>,
Yonglong Liu <liuyonglong@...wei.com>,
<stable@...r.kernel.org>, <linuxarm@...wei.com>,
Salil Mehta <salil.mehta@...wei.com>,
<linux-stm32@...md-mailman.stormreply.com>,
<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] net: phy: fix auto-negotiation in case of 'down-shift'
On Tue, 2020-11-24 at 15:37 +0000, Russell King - ARM Linux admin wrote:
> On Tue, Nov 24, 2020 at 04:17:42PM +0100, Antonio Borneo wrote:
> > On Tue, 2020-11-24 at 14:56 +0000, Russell King - ARM Linux admin wrote:
> > > Userspace doesn't expect the advertising mask to change beneath it.
> > > Since updates from userspace are done using a read-modify-write of
> > > the ksettings, this can have the undesired effect of removing 1G
> > > from the configured advertising mask.
> > >
> > > We've had other PHYs have this behaviour; the correct solution is for
> > > the PHY driver to implement reading the resolution from the PHY rather
> > > than relying on the generic implementation if it can down-shift
> >
> > If it's already upstream, could you please point to one of the phy driver
> > that already implements this properly?
>
> Reading the resolved information is PHY specific as it isn't
> standardised.
Digging in the info you have provided, I realized that another Realtek PHY
has some specific code already upstream to deal with downshift.
The PHY specific code is added by Heiner in d445dff2df60 ("net: phy:
realtek: read actual speed to detect downshift").
This code reads the actual speed from page 0xa43 address 0x12, that is not
reported in the datasheet of rtl8211f.
But I checked the register content in rtl8211f and it works at the same way
too!
I have added Willy in copy; maybe he can confirm that we can use page 0xa43
address 0x12 on rtl8211f to read the actual speed after negotiation.
In such case the fix for rtl8211f requires just adding the same custom
read_status().
Antonio
Powered by blists - more mailing lists