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
| ||
|
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.
Powered by blists - more mailing lists