Re: [PATCH ethtool-next 0/4] Extend module EEPROM API

[Andrew Lunn <andrew@lunn.ch>]

> There are routine functions to configure the devices that require writing
> appropriate values to various registers.  Byte 26 allows software control of
> low power mode, squelch and software reset.  Page 10h is full of Lane and
> Data Path Control registers.

These all sounds like foot canons when in user space control. I would
expect the MAC and or SFP driver to make use of these features, no
need to export them to user space, at least not in a raw format. I
could however imagine ethtool commands to manipulate specific
features, passing the request to the MAC to perform, so it knows what
is going on.
 
> Beyond the spec, but allowed by the spec, there are vendor specific
> capabilities like firmware download that require bulk write (up to 128 bytes
> per write).

This one is not so easy. Since it is vendor specific, we need to
consider how to actually make it vendor generic from Ethtool, or maybe
devlink. Maybe code in the kernel which matches on the vendor string
in the SFP EEPROM, and provides a standardized API towards ethtool,
and does whatever magic is needed towards the SFP. But it gets messy
when you don't have direct access to the SFP, there is a layer of
firmware in the middle, which is often the case.

	 Andrew