Re: [PATCH net-next v2 1/2] net: phy: sfp: Add support for SMBus module access

[Maxime Chevallier <maxime.chevallier@bootlin.com>]

Hi Andrew,

> > -static int sfp_i2c_configure(struct sfp *sfp, struct i2c_adapter *i2c)
> > +static int sfp_smbus_read(struct sfp *sfp, bool a2, u8 dev_addr, void *buf,  
> 
> Maybe call this sfp_smbus_byte_read(), leaving space for
> sfp_smbus_word_read() in the future.

Good idea, I'll do that :)

> > +			  size_t len)
> >  {
> > -	if (!i2c_check_functionality(i2c, I2C_FUNC_I2C))
> > -		return -EINVAL;
> > +	u8 bus_addr = a2 ? 0x51 : 0x50;
> > +	union i2c_smbus_data smbus_data;
> > +	u8 *data = buf;
> > +	int ret;
> > +
> > +	while (len) {
> > +		ret = i2c_smbus_xfer(sfp->i2c, bus_addr, 0,
> > +				     I2C_SMBUS_READ, dev_addr,
> > +				     I2C_SMBUS_BYTE_DATA, &smbus_data);
> > +		if (ret < 0)
> > +			return ret;  
> 
> Isn't this the wrong order? You should do the upper byte first, then
> the lower?

You might be correct. As I have been running that code out-of-tree for
a while, I was thinking that surely I'd have noticed if this was
wrong, however there are only a few cases where we actually write to
SFP :

 - sfp_modify_u8(...) => one-byte write
 - in sfp_cotsworks_fixup_check(...) there are 2 writes : one 1-byte
write and a 3-bytes write.

As I don't have any cotsworks SFP, then it looks like having the writes
mis-ordered would have stayed un-noticed on my side as I only
stressed the 1 byte write path...

So, good catch :) Let me triple-check and see if I can find any
conceivable way of testing that...

Thanks,

Maxime