On Sun, 11 May 2008 10:13:25 -0700, David Brownell wrote:
> On Saturday 10 May 2008, you wrote:
> > >
> > > static int ali1563_block_start(struct i2c_adapter * a)
> > > @@ -170,7 +170,7 @@ static int ali1563_block_start(struct i2
> > > data & HST_STS_BUSERR ? "No response or Bus Collision " :
> > > "",
> > > data & HST_STS_DEVERR ? "Device Error " : "",
> > > !(data & HST_STS_DONE) ? "Transaction Never Finished " :
> > > "");
> > > - return -1;
> > > + return -EIO;
> > > }
> >
> > And same here. That's a little more work, admittedly.
>
> Returning ENXIO for BUSERR/no-response doesn't follow your
> heuristic of trusting the logspam-eliminators ... plus, it's
> not clear that's not a different failure mode on that path.
Elsewhere in this driver there is:
/* device error - no response, ignore the autodetection case */
if ((data & HST_STS_DEVERR) && (size != HST_CNTL2_QUICK)) {
dev_err(&a->dev, "Device error!\n");
}
which makes it clear to me that HST_STS_DEVERR is what you get when no
device acks a transaction. So returning -ENODEV would make sense.
> NVidia seems to not have ALI 1563 specs on line (sigh) so
> for now I'll just stick to your heuristic.
Not sure why nVidia would host ALi datasheets in the first place? Let
alone the fact that nVidia is notoriously known to _not_ publish
datasheets anyway :(
> I did make the "timeout" fault unique there, since that
> fault was clearly distinguishable.
Agreed.
--
Jean Delvare
_______________________________________________
i2c mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/i2c
