[i2c] [patch 2.6.24-rc1-git] i2c-algo-bit, don't yield()

David Brownell david-b at pacbell.net
Mon Nov 19 03:11:51 CET 2007


On Sunday 18 November 2007, Jean Delvare wrote:
> > > Just kill try_address and call i2c_outb() directly?
> > 
> > Not at this time.  This is the natural place to put that
> > information about how I2C and SMBus have different rules,
> > which arguably merits a programming abstraction in its own
> > right...
> 
> Arguably, this difference between I2C and SMBus is not specific to
> i2c-algo-bit so this documentation doesn't really belong to that file.

Doesn't hurt to have it there, though.  Plus, I find myself thinking
that algo-bit is the best bet for a reference implementation, and is
accordingly appropriate for being commented a bit better than most
other i2c adapter code.  No other code is going to have any kind of
close match to the bits-on-the-wire, and that's a very useful level
at which to understand I2C.


> But if you insist on including it here (which is fine with me), I fail
> to see why the same comment shouldn't go right before bit_doAddress.

Because bit_doAddress() calls try_address() to do its dirty work,
and thus doesn't need another comment.  ;)

 
> > Remove i2c_adapter->retries support from i2c-algo-pcf ... this compiles,
> > but is untested.  The paths for ten bit addressing look especially broken;
> > they were also the only ones which would actually use those values.
> 
> Same code as in i2c-algo-bit, and equally broken. That's one of the
> reasons why I wanted to kill 10-bit addressing support some times ago.
> 
> Oh, on second look, I have to agree with you... even more broken than
> i2c-algo-bit.

Yep ... especially broken, and not the same code at all.


> At this level of brokenness, I'd suggest that we plain 
> kill 10-bit addressing support from this driver; this happens to also
> solve the retries issue, so all good.

So you want an updated patch scrubbing both mechanisms from algo-pcf?
And not from algo-bit?  Or separate patches?

- Dave



More information about the i2c mailing list