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

[Jean Delvare]

On Fri, 16 Nov 2007 10:42:41 -0800, David Brownell wrote:
> On Friday 16 November 2007, Jean Delvare wrote:
> > 
> > Two more things. First, the good news: with your patch applied,
> > "modprobe eeprom" is down from 5.2 s to 1.4 s on my system. That's just
> > an example of the performance boost brought by your patch. The
> > difference is admittedly magnified by the fact that one of my
> > (radeonfb) i2c adapters is broken and all transactions timeout there,
> > but the principle still applies to the general case.
> 
> Yeah, I noticed it as extra delays responding to SMBALERT# ...
> not such large delays, but needless ones nonetheless.
> 
> 
> > Second, about the returned error code: we are deleting the retry
> > mechanism from bus drivers on the basis that it's a chip-specific
> > attribute whether retries make sense or not.
> 
> I think you mean a "slave-specific" attribute..  Plus let's not
> overlook "mechanism not implemented correctly or uniformly"!
> 
> 
> > If so, shouldn't we give 
> > chip drivers a way to differentiate between a slave not acking its
> > address and other transaction errors? I think that i2c-algo-bit (and
> > other bus drivers) should return a unique error code (-ENODEV?) for the
> > former case. What do you think?
> 
> Not that error codes are reliably passed up through the stack yet,
> even starting at the lowest levels ... ;)

Sure, but we have to fix it piece after piece, otherwise it will be
broken forever.

> I think an -ENODEV for that purpose would make sense, and it might
> be a good value to add to a new Documentation/i2c/... file.  That

Might also fit in i2c-protocol, but I don't really care either way.

> seems compatible with the driver model probe code, where both that
> and -ENXIO are treated as "normal" errors not worthy of diagnostics.
> 
> Likewise, a standard code is needed for arbitration lost.  It could
> be reported any time master transmit mode is used, not just in the
> send-an-address stage.  Maybe -EAGAIN would suit, it already has
> the right kind of message; or -EBUSY, or -EALREADY.

I think -EAGAIN is more suitable, as it is a temporary error, while
-EBUSY suggests a permanent one.

-- 
Jean Delvare