linux-kernel - Re: [PATCH net-next v2] net: phy: dp83867: Add speed optimization feature

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]

Date:   Tue, 18 Feb 2020 16:25:22 +0000
From:   Russell King - ARM Linux admin <linux@...linux.org.uk>
To:     Dan Murphy <dmurphy@...com>
Cc:     Grygorii Strashko <grygorii.strashko@...com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Heiner Kallweit <hkallweit1@...il.com>, andrew@...n.ch,
        davem@...emloft.net, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [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