On 2018-10-02 09:27, Wolfram Sang wrote: > Hi, > >>>> We got confirmation from HW team about 4 byte read limitation. There >>>> has to be a STOP after every single read cycle. One read cycle >>>> supports maximum of >>>> 4 byte burst. I will update the patches with a comment on this. >>> >>> Could it be that this is more an SMBus controller than an I2C controller? >>> I haven't looked at the specs but maybe populating smbus_xfer instead of >>> master_xfer is an option here? >> I think its more of i2c controller and we do mention " .max_read_len = 4" in >> " struct i2c_adapter_quirks". Do you still see something missing here? > > Well, if there has to be STOP after a read, then you can't do a transfer > containing "write-read-write", or? So, I wondered if this controller is > of the type which can mainly do "write-then-read" transfers only (check > I2C_AQ_COMB* quirk flags). And for some of those controller types, it > might be even easier to drop generic I2C transfers and only handle the > SMBUS calls. > > I didn't check this driver closely yet, so I can't tell if/what it needs > from the above. I wanted to give this input already, though. I don't think SMBus is an option in this case since the intended client (Cypress something in patch 2/2) does xfers that would need 16-bit commands and I think they are always 8-bit in SMBus, no? Cheers, Peter
