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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200319135800.GE25745@shell.armlinux.org.uk>
Date:   Thu, 19 Mar 2020 13:58:00 +0000
From:   Russell King - ARM Linux admin <linux@...linux.org.uk>
To:     Andrew Lunn <andrew@...n.ch>
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 Thu, Mar 19, 2020 at 02:04:29PM +0100, Andrew Lunn wrote:
> > The only time that this helps is if PHY drivers implement reading a
> > vendor register to report the actual link speed, and the PHY specific
> > driver is used.
> 
> So maybe we either need to implement this reading of the vendor
> register as a driver op, or we have a flag indicating the driver is
> returning the real speed, not the negotiated speed?

I'm not sure it's necessary to have another driver op.  How about
this for an idea:

- add a flag to struct phy_device which indicates the status of
  downshift.
- on link-up, check the flag and report whether a downshift occurred,
  printing whether a downshift occurred in phy_print_status() and
  similar places.  (Yes, I know that there are some network drivers
  that don't use phy_print_status().)

The downshift flag could be made tristate - "unknown", "not downshifted"
and "downshifted" - which would enable phy_print_status() to indicate
whether there is downshift supported (and hence whether we need to pay
more attention to what is going on when there is a slow-link report.)

Something like:

For no downshift:
	Link is Up - 1Gbps/Full - flow control off
For downshift:
	Link is Up - 100Mbps/Full (downshifted) - flow control off
For unknown:
	Link is Up - 1Gbps/Full (unknown downshift) - flow control off

which has the effect of being immediately obvious if the driver lacks
support.

We may wish to consider PHYs which support no downshift ability as
well, which should probably set the status to "not downshifted" or
maybe an "unsupported" state.

This way, if we fall back to the generic PHY driver, we'd get the
"unknown" state.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up