Re: [RFC PATCH V3 net-next 1/5] ethtool: Allow network drivers to dump arbitrary EEPROM data

[Andrew Lunn <andrew@lunn.ch>]

> > > +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