Hi Wolfram, > > > > > > Can we get the working set in while the issues is being debugged? > > > > > > > > > > I'm not the one making the decision, and I don't even know if > > > > > this is going through the i2c or the usb tree? If it's going > > > > > through the i2c tree you need a tag from the usb people (Greg?) > > > > > on patch 2/2, and if it's going through the usb tree, you need a > > > > > tag from Wolfram on patch 1/2. As I said, I'm not involved with > > > > > that part, I'm just reviewing these patches because I felt like it. > > > > > > > > > > The remaining issue that bothers me is the looping reads, and > > > > > your email address reveals that you should be in a very good > > > > > position to work out why they do not work, and fix it or let us > > > > > know why they don't. > > > I am working with different teams to debug this and I think it may > > > take some time to know the root cause. > > 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? Thanks Ajay --nvpublic
