[i2c] [patch 2.6.23-rc5 2/2] i2c-algo-bit read block data bugfix

[Jean Delvare]

On Fri, 07 Sep 2007 14:10:20 -0700, David Brownell wrote:
> > * I2C_M_TEN is standard and might be needed someday, but at the moment
> > it's essentially broken and unused. I would get rid of it if people
> > didn't keep stating that they'll need it soon.
> 
> Alternatively, just fix it.  ;)

I'm not wasting my time on something nobody uses at the moment. I think
I'm already nice to leave the current (broken) support in place just
because I have been told that there would soon be drivers needing it.
That was months ago and I'm still waiting. Whoever really needs 10-bit
address support will have to do the work.

As a side note, we have a problem with 10-bit addresses: a given 7-bit
address is also a valid 10-bit address. This means that our current bus
ID scheme for I2C devices will lead to a collision, unless we either
add some arbitrary offset to 10-bit addresses, or change the naming
scheme at least for 10-bit addresses.

> Though it was interesting to note that SMBus 2.0 removed all the
> text about 10 bit addressing found in the SMBus 1.1 spec... I'd
> guess that's partly because it now has that SMBus ARP mechanism.

ARP mechanism which is essentially unused. My personal take on 10-bit
addresses is that they were never needed. Address collisions do not
exist in practice, as most chips have selectable addresses through
power-up pin level latching. The over 100 possible addresses of the
7-bit address space are more than sufficient, I don't remember seeing
more than ~15 I2C chips on a bus segment. And if really needed, you can
also have more segments, either through additional buses, or
multiplexers.

> > * I2C_M_RECV_LEN is standard and useful and properly implemented
> > (except for this bug you just found, that is.)
> 
> ... in the only adapter implementing that mechanism.  :(

i2c-algo-bit is more than one adapter, it's more like 2 or 3 dozens.
And it's no longer broken, so all is well.

> (...)
> Ah, but the linkage between I2C_M_* and I2C_FUNC_PROTOCOL_MANGLING
> was far from self-evident.  I'll send a doc patch correcting that,
> and also calling out I2C_FUNC_SMBUS_READ_BLOCK_DATA.

Agreed, thanks.

> (...)
> On the other hand, arbitrary protocol limits (like "32 bytes" in
> SMBus, where the inherent limit is actually 255 bytes) usually prove
> to be "we guarantee future headaches for you!" situations.

This is also a way to make the hardware smaller/cheaper, so it's not
all bad.

> The I2C stack would have been better off if "i2c_msg" included both
> a "len" (caller provides) and an "actual_len" (reported by adapter).
> That way for block RX the caller could provide as much (or as little)
> as it needed but the actual length would still be reported ... and
> for multibyte TX you'd be able to tell if the device choked before
> accepting all the bytes you were trying to feed it.

True.

-- 
Jean Delvare