Re: [PATCH net-next v4] net: sfp: add SMBus I2C block support

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

Hi Jonas,

On 09/01/2026 17:48, Jonas Jelonek wrote:
> Hi Maxime,
> 
> On 09.01.26 16:51, Maxime Chevallier wrote:
>> Hi,
>>
>> On 09/01/2026 11:13, Jonas Jelonek wrote:
>>> Commit 7662abf4db94 ("net: phy: sfp: Add support for SMBus module access")
>>> added support for SMBus-only controllers for module access. However,
>>> this is restricted to single-byte accesses and has the implication that
>>> hwmon is disabled (due to missing atomicity of 16-bit accesses) and
>>> warnings are printed.
>>>
>>> There are probably a lot of SMBus-only I2C controllers out in the wild
>>> which support block reads. Right now, they don't work with SFP modules.
>>> This applies - amongst others - to I2C/SMBus-only controllers in Realtek
>>> longan and mango SoCs.
>>>
>>> Downstream in OpenWrt, a patch similar to the abovementioned patch is
>>> used for current LTS kernel 6.12. However, this uses byte-access for all
>>> kinds of access and thus disregards the atomicity for wider access.
>>>
>>> Introduce read/write SMBus I2C block operations to support SMBus-only
>>> controllers with appropriate support for block read/write. Those
>>> operations are used for all accesses if supported, otherwise the
>>> single-byte operations will be used. With block reads, atomicity for
>>> 16-bit reads as required by hwmon is preserved and thus, hwmon can be
>>> used.
>>>
>>> The implementation requires the I2C_FUNC_SMBUS_I2C_BLOCK to be
>>> supported as it relies on reading a pre-defined amount of bytes.
>>> This isn't intended by the official SMBus Block Read but supported by
>>> several I2C controllers/drivers.
>>>
>>> Support for word access is not implemented due to issues regarding
>>> endianness.
>> This patch should probably be accompanied with a similar addition to the
>> mdio-i2c driver. for now, we only support full-featured I2C adapters, or
>> single-byte smbus, nothing in-between :(
>>
>> Do you have something like this in the pipe ? not that this blocks this
>> particular patch, however I think that Russell's suggestion of making
>> this generic is the way to go.
> 
> I agree to Russell's suggestion and will work on that. Apart from that, I haven't
> considered a similar change for mdio-i2c yet. No issue to deal with that but 
> I think I have no way to test this properly.

ACK, I'll gladly help with testing. This should actually be easily
achievable with a board that has a real i2c interface connected to the
SFP cage, as there's a i2c smbus emulation layer. The SMBus helpers will
work with a true I2C adapter, you may have to tweak the code though.

This is relevant for modules that have a built-in PHY that you can
access, if you don't have any I can run some tests here, I have more
than enough modules...

If you don't have time at all for that, I may give this a shot at some
point, but my time is a bit scarce right now :'(

Maxime



>> Maxime
> 
> Best,
> Jonas