Hi Heikki, > > > I still didn't understand why can't this just be taken care of in > > > your I2C host driver? Why can't you just read 4 bytes at a time in > > > your master_xfer hook until you have received as much as the message > > > is asking, and only after that return? > > > > The I2C host hardware *cannot* read more than 4 bytes in any one xfer > > according to the HW designers. Seriously broken crap, that piece of > > hardware... (If that assertion from the HW designers is indeed true? > > I suspect that it can be made to work, but the docs are closed and I > > don't have HW to experiment with, so it remains a suspicion...) > > > > And the I2C host driver *cannot* be expected to know exactly how any > > one client device needs to split xfers into many when the 4 byte limit > > is getting in the way, and neither can the I2C core. Because I bet > > there are devices where it's not even possible to split xfers while > > keeping semantics equivalent... > > > > So, every client driver will need to adjust to this quirk if they are > > to operate with this worthless I2C host (or others with similar > > limitations, if there are any?). Fortunately, most client drivers > > don't read in bulk. Unfortunately, many do... > > OK, thanks for the explanation. > > I think I'm repeating these questions. You guys already went through this, so > sorry for the noise. I will go ahead and post new set. Thank you Peter for explanation! Thanks Ajay --nvpublic > > > Thanks, > > -- > heikki
