netdev - Re: PHY VSC8531 MDIO data not reflected in ethernet/ sub-module

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: <9fbcac7f-9d12-4a42-9f2f-345c37585ff4@lunn.ch>
Date: Fri, 12 May 2023 04:47:56 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Ron Eggler <ron.eggler@...tywest.com>
Cc: netdev@...r.kernel.org
Subject: Re: PHY VSC8531 MDIO data not reflected in ethernet/ sub-module

> I don't see it being invoked every Seconds but it gets invoked on boot, I
> added debug logs and see the following:

What should happen is when the MAC driver call phy_start(), it either
starts polling the PHY or it enabled interrupts. If it is not polling,
then is sounds like you have interrupts setup for the PHY. Scatter
some more debug prints around and about and see which is true.

> state = UP which means it's ready to start auto negotiation(in
> phy_state_machine())  but instead in phy_check_link_status(), phydev->state
> should be set to  PHY_RUNNING but it only can get set to PHY_RUNNING when
> phydev->link is 1 (in phy_check_link_status()):

Yep. Either via polling, or interrupts, the state machine will change
to state RUNNING.

> 
> >    phy_read_status()->
> >      phydev->drv->read_status()
> > or
> >      genphy_read_status()
> > 
> > Check what these are doing, why do they think the link is down.
> 
> Yes, so in phy_read_status, phydev->drv->read_status appears to be set but I
> cannot figure out where it gets set. (I obviously need to find the function
> to find why the link isn't read correctly).

Since this is a microchip PHY, i would expect vsc85xx_read_status().

> I temporarily set phydev->drv->read_status to 0 to force invocation of
> genphy_read_status() function to see how that would work.
> 
> genphy_update_link(0 is called from genphy_read_status() and I get the below
> data:
> 
> [    6.795480] DEBUG: in genphy_update_link(), after phy_read() bmcr 4160
> [    6.805225] DEBUG: in genphy_update_link(), bmcr 0x1040 & 0x200
> [    6.815730] DEBUG: in genphy_read_status(), genphy_update_link() 0
> phydev->autoneg 1, phydev->link 0
> 
> 
> Could it be that the link needs a second to come up when when the network
> drivers get started and hence I should make sure that the polling once a
> second works (which currently doesn't appear to be the case)? Am I missing a
> configuration option?

auto-neg takes a little over 1 second. Polling does not care, if it is
not up this time, it might be the next. If you are using interrupts,
then you need to ensure the interrupt actually fires when auto-neg is
complete.

	Andrew