On Thu, Jan 22, 2015 at 08:18:34PM +0300, Dmitry Osipenko wrote: > 22.01.2015 19:06, Dmitry Osipenko пишет: > >22.01.2015 18:22, Dmitry Osipenko пишет: > >>22.01.2015 10:55, Alexandre Courbot пишет: > >>>On Thu, Jan 22, 2015 at 4:40 PM, Thierry Reding > >>><thierry.reding@xxxxxxxxx> wrote: > >>>> > >>>>Should this not technically be le32_to_cpu() since the data originates > >>>>from the I2C controller? > >> > >>No, i2c_readl returns value in CPU endianness, so it's correct. But for > >>i2c_writel should be used le32_to_cpu(), since it takes value in CPU endianness. > >>It's my overlook, V2 is coming. > >> > >>>> > >>>>Why does this have to be initialized to 0 now? > >>> > >>>I suspect this is because we are going to memcpy less than 4 bytes > >>>into it, but I cannot figure out how that memcpy if guaranteed to > >>>produce the expected result for both endiannesses. > >>> > >>That's correct. Memcpy is working with bytes, so it doesn't care about > >>endianness and produces expected result, since I2C message is char array. > >> > >I'll spend some more time reviewing, to see if nullifying should go as separate > >patch. > > > Well, I2C_FIFO_STATUS returns 8-bit value. The rest of bits very likely to > be RAZ, however I don't see anything on it in documentation. In that case it > won't cause any problems with LE value and nullifying is only needed for BE > mode. What does I2C_FIFO_STATUS have to do with anything? My point was more that we already tell hardware how much data is to be transferred (via the packet header in tegra_i2c_xfer_msg()), hence the hardware shouldn't care whether the FIFO is padded with random data or zeros. Thierry
Attachment:
pgpM3K0qLI6GI.pgp
Description: PGP signature
