> I think you are right that the controller does not seem to support > additional I2C features in addition to SMBUS. > > However, my concern of switching to the smbus_xfer API is: > > 1) Some customers might have used I2C_RDWR based API from i2cdev. Changing > from master_xfer to smbus_xfer may break the existing applications that are > already developed. Well, given that you add new quirks in the original patch here, you are kind of breaking it already. Most transfers which are not SMBus-alike transfers would now be rejected. For SMBus-alike transfers which are sent via I2C_RDWR (which is ugly), I have to think about it. > 2) The sound subsystem I2C regmap based implementation seems to be using > i2c_ based API instead of smbus_ based API. Does this mean this will also > break most of the audio codec drivers with I2C regmap API based usage? I don't think so. If you check regmap_get_i2c_bus() then it checks the adapter functionality and chooses the best transfer option then. I may be missing something but I would wonder if the sound system does something special and different.
Attachment:
signature.asc
Description: PGP signature
