Messages in this thread | | | Date | Mon, 13 Jun 2022 16:56:37 +0200 | From | Andrew Lunn <> | Subject | Re: [PATCH net-next v1 1/1] net: phy: add remote fault support |
| |
> If I see it correctly, there is no way to notify about remote fault when > the link is up. The remote fault bit is transferred withing Link Code > Word as part of FLP burst. At least in this part of specification.
Thanks for looking at the specification. So ksetting does seem like the right API.
Sorry, i won't have time to look at the specification until tomorrow. The next question is, is it a separate value, or as more link mode bits? Or a mixture of both? Is there a capability bit somewhere to indicate this PHY can advertise a remote fault? That would suggest we want a ETHTOOL_LINK_MODE_REMOTE_FAULT_BIT, which we can set in supported and maybe see in lpa? Set it in advertising when indicating a fault. The actual fault value could then be in a separate value which gets written to the extended page? Does 802.3 allow a remote fault to be indicated but without the reason?
> So receiving remote fault information via linkstate and send remote fault via > ksetting?
We could also just broadcast the results of a ksetting get to userspace?
I don't have easy access to a machine at the moment. What does
ip monitor all
show when a link is configured up, but autoneg fails? And when autoneg is successful but indicates a remote fault? Are there any existing messages sent to userspace?
> The next logical question is, if a remote fault is RX'ed (potentially with a > reason) who will react on this. There might be different policies on how to > react on same reason.
Policy goes in userspace, is the general rule.
The only exception might be, if we decide to make use of one of these to silence the link to allow cabling testing. We probably want the kernel to try to do that.
Andrew
| |