Re: [PATCH v5 05/11] i2c: rtl9300: check if xfer length is valid

[Sven Eckelmann <sven@narfation.org>]

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

On Sunday, 10 August 2025 07:51:12 CEST Wolfram Sang wrote:
> On Sat, Aug 09, 2025 at 10:07:06PM +0000, Jonas Jelonek wrote:
> > Add an explicit check for the xfer length to 'rtl9300_i2c_config_xfer'
> > to make sure a length < 1 or > 16 isn't accepted. While there shouldn't
> > be a length > 16 because this is specified in the i2c_adapter_quirks, a
> > length of 0 may be passed.
> 
> There is another quirk for this: I2C_AQ_NO_ZERO_LEN
> 
> With that, you shouldn't need the code here.

I am a little bit lost here. Let us assume that i2c_smbus_write_byte_data() is 
called - for example by an in-kernel driver. We would then have following call 
chain:

* i2c_smbus_write_byte_data
* i2c_smbus_xfer
* __i2c_smbus_xfer
* adapter->algo->smbus_xfer (aka rtl9300_i2c_smbus_xfer)

But the quirk is only checked in i2c_check_for_quirks - and then on 
`struct i2c_msg` and not `union i2c_smbus_data`. And this is only called by 
__i2c_transfer (which is called by i2c_transfer, i2c_smbus_xfer_emulated, 
...). But on first glance, it didn't look like it will be called when using 
i2c_smbus_write_byte_data - unless __i2c_smbus_xfer fails and must fall back 
to i2c_smbus_xfer_emulated. I most likely missed something when doing a quick 
check of the source code. Maybe you can point it out.

And I might have to point out that I am currently not next to the actual HW to 
check if my statement that adapter->algo->smbus_xfer == rtl9300_i2c_smbus_xfer 
is really true.

Kind regards,
	Sven

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 228 bytes --]