> So what we really have is a single slave i2c host sort of. At least > we could model it like that. The host could be told which address to > listen to (and which single i2c write to do to init the pmic) through > devicetree and then all the differences would be hidden in the host > driver, ie we would check the slave-address and if it is not the single > one we support, we just return the appropriate error for a device not > acking, and everything should work as a regular i2c host which > only supports i2c_smbus_read_byte and i2c_smbus_write_byte. I'd think we need a new message flag like I2C_M_PUSHPULL which says that this message has only the direction bit instead of the address and needs a parity bit afterwards. In addition to that, we need a new functionality flag I2C_FUNC_PUSHPULL which means the host driver can handle those messages. So, the PMIC driver could query support for I2C_FUNC_SMBUS_BYTE | I2C_FUNC_PUSHPULL and if successful send messages using smbus functions with the new flag set. Not sure about the I2C-to-PushPull switch: Is it 100% host configuration or does it also depend on the one slave attached? Are there some datasheets available?
Attachment:
signature.asc
Description: Digital signature
