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

[Jean Delvare]

Hi Al,

On Mon, 14 May 2007 17:14:23 -0700, Al Borchers wrote:
> Jean Delvare wrote:
> > Note that you are simply not supposed to do that in the first place.
> > SMBus block transactions should only be run on "registers" which expect
> > them.
> 
> But such a mistake should only generate an error from the hardware/driver,
> not hang the I2C host controller.

Go tell nVidia, not me :(

>                                    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.

> > On top of that, the fact is that there are almost no users of SMBus
> > block transactions in the kernel anyway, so we really had no reason to
> > bother. Do you need these yourself?
> 
> We use smbus block transfers to read larger values and update firmware on
> our devices--so we depend on them.

Firmware of what device?

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_*().

-- 
Jean Delvare