Messages in this thread | | | Date | Tue, 18 Feb 2020 16:25:22 +0000 | From | Russell King - ARM Linux admin <> | 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
| |