[PATCH v2 0/4] Increase SMBus max block size to 255

[PATCH v2 0/4] Increase SMBus max block size to 255

[Matt Johnston]

Hi,

I've taken another look at smbus v3 255-byte changes. This series combines
Daniel's previous i2c-dev patch with my i2c core patch.

Bus drivers remain opt-in to 255-byte block size, the I2C_FUNC_SMBUS3_BLOCKSIZE
flag indicates to i2c-core that the driver has been audited to handle 255
byte buffers OK. They can be added as drivers are tested with 255 byte
protocols/applications.

Drivers without that flag will be limited to 32 bytes by the I2C core. This
will take care of in-kernel compatibility issues with the increased
I2C_SMBUS_BLOCK_MAX for drivers.

The flag can also be used by userspace/drivers to warn if a driver is
non-smbus3 which would prevent a particular application from working.
Otherwise the change should be transparent to users.

The i2c-dev changes will remain compatible with these cases:

* Existing binaries, new kernel
  Will pass the old transaction type values, i2c-dev will limit
  transfers to 32 bytes

* Binaries compiled with new uapi, new kernel
  Will pass new transaction type values, i2c-dev will allow 255 bytes.
  Userspace i2c_smbus_data has sufficient space for 255 byte blocks

It won't however work with new uapi+old kernel, the new transaction types are
unknown. I wonder if it would be better to keep current constants as-is, and
let userspace opt in to 255 byte sizes with an IOCTL_SMBUS3 and
'union i2c_smbus3_data' (just for userspace, the kernel keeps using 255 byte
i2c_smbus_data everywhere). It wouldn't be necessary to look at the
I2C_FUNC_SMBUS3_BLOCKSIZE flag, just make a single first attempt with IOCTL_SMBUS3
and if that returns -ENOTTY fall back to IOCTL_SMBUS as before.
Are there any other kernel mechanisms for indicating feature support?

That would also be safer for existing userspace that may be out in the wild.
It's possible there might be libraries currently using 'union i2c_smbus_data'
in their ABI - changing its size would break library users if programs were
recompiled with new uapi headers.

I can take a look at making IOCTL_SMBUS3 changes for i2c-dev, though my main
focus here is getting the kernel side changes working (I've only been doing
hardware testing with in-kernel code).

Cheers,
Matt

--
v2:
 - i2c-dev patch based (with modifications) on
   https://lore.kernel.org/linux-i2c/20200729203658.411-1-daniel.stodden@gmail.com/
 - Rename constants to _SMBUS3_ instead of previous _V3_

Previous version part of MCTP series, i2c-core/adapter changes taken from that:
https://lore.kernel.org/all/20211115024926.205385-2-matt@codeconstruct.com.au/

v1 i2c RFC:
https://lore.kernel.org/all/20210602044113.1581347-1-matt@codeconstruct.com.au/



Daniel Stodden (1):
  i2c: dev: Support smbus3 block size of 255 bytes

Matt Johnston (3):
  i2c: core: Allow 255 byte transfers for SMBus 3.x
  i2c: aspeed: Allow 255 byte block transfers
  i2c: npcm7xx: Allow 255 byte block SMBus transfers

 drivers/i2c/busses/i2c-aspeed.c  |  5 +-
 drivers/i2c/busses/i2c-npcm7xx.c |  3 +-
 drivers/i2c/i2c-core-smbus.c     | 20 ++++---
 drivers/i2c/i2c-dev.c            | 91 +++++++++++++++++++++++++++-----
 include/uapi/linux/i2c.h         | 16 ++++--
 5 files changed, 106 insertions(+), 29 deletions(-)

-- 
2.32.0

Re: [PATCH v2 0/4] Increase SMBus max block size to 255

[James R T]

Hi folks,

Replying to the cover letter since this email refers to the whole patch series.

We were looking into support for SMBus v3.0 in Linux and found this
patch series. Could we kindly check if there has been any progress on
this?

From what I understand so far, a previous version of this patch series
was applied to netdev/net-next.git (master) but it was reverted via
commit 2f6a470d6545 due to concerns over ABI backward compatibility
from Wolfram. Then, Matt submitted this v2 patch series which has gone
unnoticed. It has been more than 2 years and there seems to have been
no responses to the series so far. I would like to gently bump up this
patch series so that we can hopefully move it forward.

Thank you.

Best regards,
James Raphael Tiovalen

Re: [PATCH v2 0/4] Increase SMBus max block size to 255

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 1363 bytes --]

Hi James,

> We were looking into support for SMBus v3.0 in Linux and found this
> patch series. Could we kindly check if there has been any progress on
> this?

Well, on the drawing board level, yes. I gave two talks about how to
tackle this issue. The latest one being here, but, sorry, it is in
German only. Maybe you can get an idea out of the slides:

https://chemnitzer.linux-tage.de/2024/en/programm/beitrag/252

> From what I understand so far, a previous version of this patch series
> was applied to netdev/net-next.git (master) but it was reverted via
> commit 2f6a470d6545 due to concerns over ABI backward compatibility
> from Wolfram. Then, Matt submitted this v2 patch series which has gone
> unnoticed. It has been more than 2 years and there seems to have been
> no responses to the series so far. I would like to gently bump up this
> patch series so that we can hopefully move it forward.

True, it looks like it went unnoticed, but it wasn't. I need to update
the status of this series in Patchwork to 'Rejected' sadly. Renaming the
old transaction types in the UAPI header is a no-go and will break newer
userspace with older kernels. The new SMBus sizes need to be opt-in
completely.

Like I said, I have sketched this but both demand and work time have
been limited, so no actual implementation happened so far.

All the best,

   Wolfram


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]