Messages in this thread | | | Date | Wed, 15 Jun 2022 22:07:34 +0200 | From | Andrew Lunn <> | Subject | Re: [PATCH net-next v1 1/1] net: phy: add remote fault support |
| |
On Tue, Jun 14, 2022 at 10:09:48PM -0700, Jakub Kicinski wrote: > On Wed, 15 Jun 2022 05:37:46 +0200 Andrew Lunn wrote: > > > Does this dovetail well with ETHTOOL_A_LINKSTATE_EXT_STATE / > > > ETHTOOL_A_LINKSTATE_EXT_SUBSTATE ? > > > > > > That's where people who read extended link state out of FW put it > > > (and therefore it's read only now). > > > > I did wonder about that. But this is to do with autoneg which is part > > of ksetting. Firmware hindered MAC drivers also support ksetting > > set/get. This patchset is also opening the door to more information > > which is passed via autoneg. It can also contain the ID the link peer > > PHY, etc. This is all part of 802.3, where as > > ETHTOOL_A_LINKSTATE_EXT_STATE tends to be whatever the firmware > > offers, not something covered by a standard. > > I see, yeah, I think you're right. > > But I'm missing the bigger picture. I'm unclear on who is supposed > to be setting the fault user space or kernel / device?
It is also a bit unclear, but at the moment, i think user space. However, i can see the kernel making use of maybe RF TEST to ask the link peer to go quiet in order to perform a cable test.
Oleksij, what are your use cases? Maybe add something to patch 0/X indicating how you plan to make use of this?
Andrew
| |