On Monday 12 May 2008, Jean Delvare wrote: > > > But it looks like a case of bundling faults into one bit, ergo > > my comment. ONLY that case with QUICK is special cased per your > > heuristic. That other case isn't special cased... it could well > > be exposing some *other* and more significant error. > > Just to make sure it's clear: the Quick command case isn't special as > far as the returned error value is concerned. If nobody acks a Quick > command, that's still -ENXIO. > > What is special about the Quick command is that we don't want to log the > error in this case, because it's used for detection purposes so it > happens frequently and it isn't something the user should worry about.
Close... The desired out come is that whenever the first address doesn't get ACKed, we report ENXIO. Arguably the same should be true of the address byte after all repeated START bits too ... but then we run into other error reporting problems. Logging is orthogonal. We don't want to log probing errors, as a rule, and Quick is (for our purposes) basically about probing. Then there's also the "what does this hardware bit mean" issue. In this case, absent hardware docs, we're guessing in all cases except for the QUICK case. With only a few bits to report all faults, it's clear there's some degree of fault bundling. Ergo my caution: I didn't restructure all fault paths in that driver to treat that one bit as if it only means "no address ACK", only the one where it's clear that was how the driver interpreted it. - Dave _______________________________________________ i2c mailing list [email protected] http://lists.lm-sensors.org/mailman/listinfo/i2c
