Hi Peter, > > 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. Thanks, -- heikki
