Hi Daniel, hi Jean,

some more bits from me.

> Cool. Meaning we may then leave it at a single i2c_smbus_data.block[257]
> declaration in the headers, and i2c_smbus_data can be 255 bytes.

I think we all agree on this one.

> That doesn’t mean we shut the door on 32-byte buffers. After all, backward
> compat requires we maintain support for those. Just that we need not
> bother declaring or promoting dedicated small vs large transfer types
> while noone wants one.

That's how I see it as well.

> This would also mean we’re likely to add an I2C_FUNC_ to indicated smbus3
> support at runtime. It’s probably what you already have in mind.

I suggest I2C_FUNC_SMBUS3_BLOCKSIZE. I have seen the datasheet of one
client device where you could set a bit to select how many bytes should
be sent by the device in a block read (32 or 255). So, you could set
this bit according to the presence of the above FUNC. Also, I suggest to
do it finegrained, because SMBus3 also specifies 32- and 64-bit
transfers. If those are ever implemented, they should also get seperate
FUNC bits. All of them can then be ORed into I2C_FUNC_SMBUS3 if needed.

> We’d probably still prefer to move all kernel/driver buffers to 255 bytes
> unconditionally. However, I2C_FUNC_ presence normally indicates lower level
> driver + hardware support, right? Not just a kernel upgrade. Which makes 
> sense here, too.

Yes. I am all for using 257 byte buffers in-kernel only. a) defensive
programming b) for most I2C controllers only emulating SMBus, it will be
super easy to support the new block size. I expect it to become it kinda
default soon (for bus master drivers, that is).

> I’m just pointing it out because if we want an I2C_FUNC_SMBUS3, and at
> the driver’s discretion, not just indicating kernel + compatibility
> support presence, and if i2c_utils uses that to pick safe size values,
> that again means we’re yet again less likely to actually deprecate the
> old transfer numbers. Some drivers will never be SMBUS3.

Yes, they will stay around. When I said "deprecated", I didn't mean it
in the way of "will be removed" but more in "please use the new ones".

> I2C_FUNC_SMBUS3 is nice to have. I’m not against it, I’m for it.
> For i2c-tools and all clients, it can be valuable to confirm conflicts.
> 
> Still, one can keep it indicative only, and not synthesize faults 
> because of a perceived client/adapter/device feature mismatch. 

That's always been the case for I2C_FUNC_*. It helps people not to shoot
in their feet, but when ignored things happen.

> I’m not even sure if my new -EMSGSIZE condition in i2c-dev.c is such
> a good idea.

I'd need to see this in a new patch to comment on it. For me, it is
really easier to talk over code. But we are not right there yet, or?

Kind regards,

   Wolfram