lkml.org 
[lkml]   [2020]   [Feb]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH net-next v2] net: phy: dp83867: Add speed optimization feature
On Fri, Feb 14, 2020 at 12:31:52PM -0600, Dan Murphy wrote:
> Grygorii
>
> On 2/14/20 12:32 PM, Grygorii Strashko wrote:
> > I think it's good idea to have this message as just wrong cable might be
> > used.
> >
> > But this notifier make no sense in it current form - it will produce
> > noise in case of forced 100m/10M.
> >
> > FYI. PHY sequence to update link:
> > phy_state_machine()
> > |-phy_check_link_status()
> >   |-phy_link_down/up()
> >     |- .phy_link_change()->phy_link_change()
> >     |-adjust_link() ----> netdev callback
> > |-phydev->drv->link_change_notify(phydev);
> >
> > So, log output has to be done or in .read_status() or
> > some info has to be saved in .read_status() and then re-used in
> > .link_change_notify().
> >
> OK I will try to find a way to give some sort of message.

How do you know the speed that the PHY downshifted to?

If the speed and duplex are available in some PHY specific status
register, then one way you can detect downshift is to decode the
negotiated speed/duplex from the advertisements (specifically the LPA
read from the registers and the advertisement that we should be
advertising - some PHYs modify their registers when downshifting) and
check whether it matches the negotiated parameters in the PHY
specific status register.

Alternatively, if the PHY modifies the advertisement register on
downshift, comparing the advertisement register with what it should
be will tell you if downshift has occurred.

Note, however, that if both ends of the link are capable of
downshift, and they downshift at the same time, it can be difficult
to reliably tell whether the downshift was performed by the local
PHY or the remote PHY - even if the local PHY gives you status bits
for downshift, you won't know if the remote end downshifted instead.

It's a bit like auto MDI/MDIX - if pairswap is needed, either end
may do it, and which end does it may change each time the link comes
up.

So, reporting downshift in the kernel log may not be all that useful,
it may be more suited to being reported through a future ethtool
interface just like MDI/MDIX.

--
RMK's Patch system: https://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

\
 
 \ /
  Last update: 2020-02-18 17:26    [W:0.093 / U:1.496 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site