[i2c] [patch 2.6.23-rc5 2/2] i2c-algo-bit read block data bugfix
david-b at pacbell.net
Sun Sep 9 19:02:05 CEST 2007
> > > * 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.
Right -- ergo the smiley.
> > 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.
... so far, and at least on Linux. It certainly looks a lot more
complicated than I'd expect any hardware-only device to support;
and in fact it's complicated enough that I suspect a lot of the
firmware-based devices take a long time to get it right!
So I suspect there are communities of devices that are using ARP,
but they just don't impact mass market products much at all. As
soon as an ARP firmware library exists, it's trivial to roll out
more custom devices using it.
> My personal take on 10-bit addresses is that they were never needed.
Maybe not, but if so that's because people were using other solutions.
The ten-bit one certainly hasn't caught on very well!
> Address collisions do not
> exist in practice, as most chips have selectable addresses through
> power-up pin level latching.
PMBus devices seem to take this a step further; the pins aren't just
encoding latchable binary values. Presumably you've seen devices that
have tristate address pins, 1/0/float, so that two pins can encode
nine different values. I've also seen chips using spare ADC capacity
with resistor ladders to encode three or four bits per pin.
> > 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.
Sure; it's just not all-good either. Engineering == Tradeoffs;
that one seems to favor logic in gates rather than in firmware.
More information about the i2c