On Thu, Jun 06, 2019 at 08:36:11PM +0200, 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?
I think a way better solution would be if the phy_start() and
phy_stop() calls were forwarded to the PHY driver so that it has
an opportunity to:
(1) refuse a phy_start() if the PHY is not able to operate correctly,
which would mean ip link set dev X up fails.
(2) for fiber capable PHYs, pass on to the SFP layer whether the
network device is up or not.
I seem to remember from the original report that the problem with
the PHY without firmware is that the link apparently comes up
(despite the MMDs reporting that they are in reset) but the
negotiation results are incorrect and no data is able to pass -
but don't quote me on that, and we've now lost a reporter to test
this.
--
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
