Thread (19 messages) 19 messages, 6 authors, 2021-01-04

Re: [PATCH net-next v2 0/2] Add support for DSFP transceiver type

From: Andrew Lunn <andrew@lunn.ch>
Date: 2020-11-27 15:57:02

OK, but if the caching system is checking one time netlink and one time
ioctl, it means this cache should be in user space, or did you mean to have
this cache in kernel ?
This is all in userspace, in the ethtool code.
quoted
quoted
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 ?
ethtool -m|--dump-module-eeprom|--module-info devname [raw on|off] [hex on|off] [offset N] [length N]

So you mean [offset N] [length N].

Yes, that's the current options and we can either try coding new
implementation for that or just call the current ioctl implementation. The
new code can be triggered once options [bank N] and [Page N] are used.
You cannot rely on the ioctl being available. New drivers won't
implement it, if they have the netlink code. Drivers will convert from
get_module_info to whatever new ndo call you add for netlink.
OK, if I got it right on current API [offset N] [length N] just call ioctl
current implementation, while using the option [raw on] will call new
implementation for new SFPs (CMIS 4). Also using [bank N] and [page N] will
call new implementation for new SFPs.
Not just CMIS. All SFPs.

    Andrew
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help