> > > +Request contents:
> > > +
> > > + ===================================== ======
> > > ==========================
> > > + ``ETHTOOL_A_EEPROM_DATA_HEADER`` nested request header
> > > + ``ETHTOOL_A_EEPROM_DATA_OFFSET`` u32 offset within a page
> > > + ``ETHTOOL_A_EEPROM_DATA_LENGTH`` u32 amount of bytes to read
> > I wonder if offset and length should be u8. At most, we should only be
> > returning a 1/2 page, so 128 bytes. We don't need a u32.
>
>
> That's right when page is given, but user may have commands that
> used to work on the ioctl KAPI with offset higher than one page.
CMIS section 5.4.1 says:
The slave maintains an internal current byte address counter
containing the byte address accessed during the latest read or write
operation incremented by one with roll-over as follows: The current
byte address counter rolls-over after a read or write operation at
the last byte address of the current 128-byte memory page (127 or
255) to the first byte address (0 or 128) of the same 128-byte
memory page.
This wrapping is somewhat unexpected. If the user access is for a read
starting at 120 and a length of 20, they get bytes 120-127 followed by
0-11. The user is more likely to be expecting 120-139.
We have two ways to address this:
1) We limit reads to a maximum of a 1/2 page, and the start and end
point needs to be within that 1/2 page.
2) We detect that the read is going to go across a 1/2 page boarder,
and perform two reads to the MAC driver, and glue the data back
together again in the ethtool core.
What i don't want is to leave the individual drivers to solve this,
because i expect some of them will get it wrong.
Andrew
