On 11/25/2020 4:18 PM, Andrew Lunn wrote:
External email: Use caution opening links or attachments
OK, we will add API options to select bank and page to read any specific
page the user selects. So advanced user will use it get the optional pages
he needs, but what about non advanced user who wants to use the current API
with a current script for DSFP EEPROM. Isn't it better that he will get the
5 mandatory pages then keep it not supported ?
Users using ethtool will not see a difference. They get a dump of what
ethtool knows how to decode. It should try the netlink API first, and
then fall back to the old ioctl interface.
Yes, it makes sense that whenever command not supported by netlink API
it falls back to old ioctl interface. As I see it we want here to add
bank and page options to netlink API to get data from specific page.
If i was implementing the ethtool side of it, i would probably do some
sort of caching system. We know page 0 should always exist, so
pre-load that into the cache. Try the netlink API first. If that
fails, use the ioctl interface. If the ioctl is used, put everything
returned into the cache.
I am not sure what you mean by cache here. Don't you want to read page 0
once you got the ethtool command to read from the module ? If not, then
at what stage ?
The decoder can then start decoding, see what
bits are set indicating other pages should be available. Ask for them
from the cache. The netlink API can go fetch them and load them into
the cache. If they cannot be loaded return ENODEV, and the decoder has
to skip what it wanted to decode.
So the decoder should read page 0 and check according to page 0 and
specification which pages should be present, right ?
What about the global offset that we currently got when user doesn't
specify a page, do you mean that this global offset goes through the
optional and non optional pages that exist and skip the ones that are
missing according to the specific EEPROM ?
If you do it correctly, the decoder
should not care about ioctl vs netlink.
I can do a follow up patch for the generic SFP code in
drivers/net/phy, once you have done the first implementation. But i
only have a limited number of SFPs and most are 1G only. Russell King
can hopefully test with his collection.
Andrew
