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
Attachment:
signature.asc
Description: PGP signature
