On Mon, Jun 10, 2019 at 03:40:10PM +0200, Heiner Kallweit wrote: > On 06.06.2019 20:36, Andrew Lunn wrote: > > 65;5402;1c> I don't like too much state changes outside control of the > > state machine, > >> like in phy_start / phy_stop / phy_error. I think it would be better > >> if a state change request is sent to the state machine, and the state > >> machine decides whether the requested transition is allowed. > > > > Hi Heiner > > > > I initially though that phy_error() would be a good way to do what > > Russell wants. But the locks get in the way. Maybe add an unlocked > > version which PHY drivers can use to indicate something fatal has > > happened? > > > phy_error() switches to PHY_HALTED, therefore phy_start() would start > another attempt to bring up the PHY. Maybe some new state like > PHY_PERMANENT_FAILURE could be helpful. Or do we need a temporary > failure state? > > After a recent patch from Russell the probe callback returns -ENODEV > if no firmware is loaded. With the patch starting this discussion > this would have changed to not failing in probe but preventing the > PHY from coming up. The commit message missed an explanation what we > gain with this behavior change.
As previously discussed, it is to allow access to the MDIO bus, and therefore to allow a userspace tool to program the flash via the MII ioctls. At least two people have already independently created such a tool. -- 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
