Messages in this thread | | | Date | Thu, 16 Jun 2022 11:34:51 +0200 | From | Oleksij Rempel <> | Subject | Re: [PATCH net-next v1 1/1] net: phy: add remote fault support |
| |
On Wed, Jun 15, 2022 at 10:07:34PM +0200, Andrew Lunn wrote: > 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?
Currently I was thinking only about diagnostic: - request transmit pause for cable testing - request remote loopback for selftest. In this case I will need to use vendor specific NextPage to request something like this.
> Maybe add something to patch 0/X indicating how you plan to make use of this?
I can move it from first patch if needed.
-- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
| |