Apple MFi programs have this i2c based chipsets like MFI343S00176 which are the authentication co-processor for MFi certified products. On a Linux based system with this chipset, what would be preferred way to communicate with the chip? An I2C Linux device driver OR a user-space program that uses the I2C_CHARDEV interface /dev/i2c-X? There are some quirks with the MFi chip that are (the details are in the datasheet which isn't public but available on signing into the MFi program), - Each read of register involves a write of the register address, then wait for ACK, if a NAK is received then wait for 500uS, then try again. Sending the I2C stop sequence & a start sequence before we perform the read. So, essentially, the read and writes are split up by a i2c stop-start. - This quirk means, we cannot use the i2c_smbus_read_byte/_write kind of routines in the driver nor the i2c_transfer & involves usage of i2c_master_send & i2c_master_recv. I have not identified a way to include a i2c stop & start in between the write and read using i2c_smbus_* & i2c_transfer routines. - It is also because of this quirk, i2c tools (i2cget & i2cset) do not work out of box & involves a simpler program that does open/ioctl/read & write on the fd of /dev/i2c-0 interface. Single byte register read get lucky, However, larger registers that read certificates aren't successful using i2cget (which internally uses SMB like transactions). Based on above observations, what is preferred way of communicating with the chipset? An i2c peripheral device driver that uses i2c_master_send/_recv or a user-space program that does read/write on the i2c-X file-descriptor? Thanks, Pavan
