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

[David Brownell]

On Sunday 18 November 2007, Jean Delvare wrote:
> On Fri, 16 Nov 2007 10:42:41 -0800, David Brownell wrote:
> > > 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.

Ergo "yet" ... :)


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

The codes aren't part of any on-the-wire protocol, they're just
in the programming interface.  That's why I suggested a new file.

Another option being Documentation/DocBook/kernel-api.tmpl in the
i2c-specific section.  That has distinct advantages, although for
some reason many people seem to overlook that documentation.


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

OK.  Of course, auditing drivers to make sure they report the right
values there will take quite a long time.  One place to start would
be making sure these codes aren't used to mean something different.

That's something Mr. Grep could help us with; it'd be a bit easier
to make be sure of that than to be sure that for example ENODEV
comes back from a probe failure despite convoluted error paths.

- Dave