netdev - Re: [PATCH net-next 1/3] net: phy: add and use phy_check

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: <20200319090640.GB20761@lunn.ch>
Date:   Thu, 19 Mar 2020 10:06:40 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Russell King - ARM Linux admin <linux@...linux.org.uk>
Cc:     Heiner Kallweit <hkallweit1@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        David Miller <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next 1/3] net: phy: add and use phy_check_downshift

On Wed, Mar 18, 2020 at 11:21:59PM +0000, Russell King - ARM Linux admin wrote:
> On Wed, Mar 18, 2020 at 10:29:01PM +0100, Heiner Kallweit wrote:
> > So far PHY drivers have to check whether a downshift occurred to be
> > able to notify the user. To make life of drivers authors a little bit
> > easier move the downshift notification to phylib. phy_check_downshift()
> > compares the highest mutually advertised speed with the actual value
> > of phydev->speed (typically read by the PHY driver from a
> > vendor-specific register) to detect a downshift.
> 
> My personal position on this is that reporting a downshift will be
> sporadic at best, even when the link has negotiated slower.
> 
> The reason for this is that either end can decide to downshift.  If
> the remote partner downshifts, then the local side has no idea that
> a downshift occurred, and can't report that the link was downshifted.
> 
> So, is it actually useful to report these events?

It is better than nothing.

We get one end reporting a downshift, and the peer reporting a slower
than expected negotiated link speed. Combined that gives a good clue.

I also want to start merging cable diagnostics soon. There is enough
of netlink ethtool in place to allow this.

And the same netlink ethool will allow us to extend the API and report
downshift in the ethtool output, not just a kernel message.

	  Andrew