> > +static int fallback_set_params(struct eeprom_data_req_info *request,
> > + struct ethtool_modinfo *modinfo,
> > + struct ethtool_eeprom *eeprom) {
>
> This is translating the new data structure into the old. Hence, I assume we
> have i2c_addr, page, bank, offset, len to work with, and we should use
> all of them.
Nope. We actually have none of them. The old API just asked the driver
to give me the data in the SFP. And the driver gets to decide what it
returns, following a well known layout. The driver can decide to give
just the first 1/2 page, or any number of multiple 1/2 pages in a well
known linear way, which ethtool knows how to decode.
So when mapping the new KAPI onto the old driver API, you need to call
the old API, and see if what is returned can be used to fulfil the
KAPI request. If the bytes are there, great, return them, otherwise
EOPNOTSUPP.
And we also need to consider the other way around. The old KAPI is
used, and the MAC driver only supports the new driver API. Since the
linear layout is well know, you need to make a number of calls into
the driver to read the 1/2 pages, and them glue them together and
return them.
I've not reviewed this code in detail yet, so i've no idea how it
actually works. But i would like to see as much compatibility as
possible. That has been the approach with moving from IOCTL to netlink
with ethool. Everything the old KAPI can do, netlink should also be
able to, plus there can be additional features.
> > + switch (modinfo->type) {
> > + case ETH_MODULE_SFF_8079:
> > + if (request->page > 1)
> > + return -EINVAL;
> > + break;
> > + case ETH_MODULE_SFF_8472:
> > + if (request->page > 3)
>
> Not sure this is needed, there can be pages higher than 3.
Not with the old KAPI call. As far as i remember, it stops at three
pages. But i need to check the ethtool(1) sources to be sure.
Andrew
