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] [day] [month] [year] [list]

Message-ID: <b007c778-03ee-23b1-e1b7-106e77819623@mistywest.com>
Date: Sat, 20 May 2023 14:52:12 -0700
From: Ron Eggler <ron.eggler@...tywest.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: netdev@...r.kernel.org
Subject: Re: PHY VSC8531 MDIO data not reflected in ethernet/ sub-module

I should follow up on this Thread and send out a Thank you for everybody 
that has pitched in. I've got the two Ethernet interfaces working fine 
now after I set "phy-mode" to "rgmii-id" and removed the "interrupts" 
and "interrupt-parent" attributes to trigger the polling of the PHY.
Both changes were made in the device tree.

Thanks again!
Ron


On 2023-05-11 19:47, Andrew Lunn wrote:
>> 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
-- 
Ron -- Ron Eggler Senior Firmware Developer 778 230 9442 
www.mistywest.com __________________________________________________ 
About MistyWest We are a Research & Engineering firm composed of 
engineers and physicists with a focus on solving hard problems across a 
number of technology verticals. We specifically target projects that 
have the potential for high-impact, whether it's improving the human 
condition, impacting sustainability in a positive way, or otherwise 
moving us collectively to an inclusively abundant future.