[i2c] i2c-nforce patch adding a check for read/writes of >=31 bytes

[Al Borchers]

Jean Delvare wrote:
> Go tell nVidia, not me :(

Yeah--we are stuck with the hardware.
> 
>>                                   Unfortunately, the MCP51 I2C host controller
>>does hang if the device responds to a block read with a length of more than
>>32 bytes.  The driver can save us from that--though it is a question
>>whether working around this hardware bug risks worse side effects.
> 
> 
> The driver cannot actually save us from that with guaranteed success.
> Hans-Frieder's workaround was based on the assumption that an SMBus
> block read at a given address always returns the same size. This might
> not be the case.
> 
> Anyway, I don't expect it to happen in practice. That would be a bug in
> the target SMBus chip that would make it effectively no longer SMBus
> compliant. So the MCP51 implementation still looks better than what the
> nForce2-4 had, even if it's still not perfect.

This bug hurts us frequently in development when debugging new device
firmware.

Our devices use fixed block lengths--so that is not a problem for us,
anyway.

> The SMBus specification is pretty clear that blocks larger than 32
> bytes aren't supported, so it is expected that the nForce SMBus master
> doesn't support greater values. The Linux implementation sized its
> structures in consequence, so we wouldn't support that either.
> 
> If you want to transfer larger blocks at once, then you're out of the
> SMBus scope and back to the I2C realm. That it, use i2c_transfer() and
> an I2C-compliant bus, instead of i2c_smbus_*().

We follow the SMBus spec and transfer 32 bytes or less at a time.  We use
block transfers for strings, 4 byte values, and firmware images
(in 32 byte chunks).

My point is that there are people who use SMBus block transfers and
want to see support for it in the I2C drivers.

-- Al