[RFC PATCH] bq27000_battery. Retains old value in ETIME error

[Werner Almesberger]

Michael Trimarchi wrote:
> >Is there some explanation on why these timeouts happen and how long
> >they can last?
> I can't answer to theese question because I have no idea of the
> hardware.

I think there are two questions:

- did you observe just isolated timeouts, or do they come in large
  bursts ?

- can we imagine a scenario where you would get a lot of timeouts in
  a row ?

You also mentioned on IRC that, sometimes, HDQ just reads back an
invalid value, so you have to do a plausibility check, discard the
bad value, and try again (or complain).

All this seems to point in the direction of needing a filter complex
enough to justify a little user space library. Particularly the
decision of what constitutes a plausible value isn't one the kernel
should be asked to make.

Do we have some sort of library for such things already ? There are
many things that are better done in user space than in the kernel,
so it would be good to have a default location for them. In the
absence of such a library, people will just pick the next best
"default location" and try to put all the device-specific hacks
into the kernel.

The API would then be a C function, not a sysfs file. It would be
extra-nice to also have some simple command-line wrapper that
comes with the library that would also let scripts and such easily
benefit from the library.

With the filtering in the library, the kernel could just return an
error if it detects a problem, and leave the proper policy (i.e.,
keep the old value, extrapolate, pass the error to the application,
etc.) to the library.

- Werner