> How about i2c_smbus_xfer_emulated() ? The tricky part will be to handle the > I2C adapters that implement .smbus_xfer(), as those won't go through > i2c_smbus_xfer_emulated(). i2c_smbus_xfer_emulated() relies on i2c_transfer(), > which itself relies on the I2C adapter's .master_xfer() operation. We're thus > only concerned about the drivers that implement both .smbus_xfer() and > master_xfer(), and there's only 4 of them (i2c-opal, i2c-pasemi, i2c-powermac > and i2c-zx2967). Maybe the simplest solution would be to force the emulation > path if I2C_CLIENT_SCCB && !I2C_FUNC_PROTOCOL_MANGLING && ->master_xfer != > NULL ? > > Wolfram, what do you think ? I think it is a mess :) Further: I don't think we will ever see an SMBus controller which allows mangling. SMBus is way more precisely defined than I2C, so HW can then do much more things automatically. They will always do a REP_START, so I don't think you can connect SCCB devices to SMBus. As a result, we shouldn't do SMBus calls for SCCB. Maybe we should introduce sccb_byte_read? SCCB didn't specify much more than byte read IIRC, or? The implementation here with two seperate messages makes much sense to me then. I could argue that the sccb_* helpers should live in drivers/media since it is probably only Omnivision trying to work around I2C licensing here? But if it is not too heavy, maybe we could take it into i2c as well. Makes sense or did I miss something?
Attachment:
signature.asc
Description: PGP signature
