Re: [PATCH net-next v2 1/2] net: phy: sfp: Add support for SMBus module access
From: Maxime Chevallier
Date: Tue Feb 25 2025 - 09:01:01 EST
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