driver design question

[khali@linux-fr.org (Jean Delvare)]

> >Reading some code today, I noticed that most of our drivers, if not
> >all, read the current values and the limit values when updated. Why
> >that? I would have read the current values only. We set the limits
> >ourself(either at init time or through procfs/sysfs) so they are
> >unlikely to have changed. Looks like an overhead we could easily get
> >rid of. Is there something obvious I am missing?
> 
> I think we should try to read and report what we know.  If we don't
> read the limits, we probably shouldn't report them either (i.e. make
> them write-only).  Reducing overhead by introducing assumptions in the
> code (like that limits won't change), is a bad idea, imho.

I think I understand your point. You want us to play it safe and you
must be right. However, what could make the limits change? The chip
(refering to ADM1025 here, since it's the one I'm working on right now)
doesn't change them on his own unless it is power-cycled (a case we
don't handle anyway, and I believe we are right to do so). The only way
the limits can be changed is through our driver, and in this case we can
store it on-the-fly instead of reading it back on every update.

One may object that this doesn't allow us to check wether a round-trip
from userspace to the registers and back again is OK (we assume that the
right value was written to the register). However, we are never sure the
register value is right, even if we read the values back. The two
conversions formula can be bad but compensate each other, and it's
transparent from user's point of view. Anyway, a compromise is to read
the limits back once (at the time we write them) so we don't loose this
is-the-conversion-OK information.

Another compromise is to read the limits but not on every update. This
would however require to have two "last update" values recorded into the
driver. Not very clean IMHO.

Is there any way values can be written to the driver's register without
telling us?

> At least, I think this is more important at the driver level than 
> the user-space apps.

Not sure I get you there, is there a similar problematic with user-space
apps?

> Are we having problems with performance and overhead issues?

No (at least none I am aware of). But I don't like the idea of our
driver doing something that could be avoided with no drawback. Please
realize that for each update, which can occur typically as often as once
every 1.5 second, 1/3 of the work is for the current values, which is
legitimate, and 2/3 of the work is for limits, which 100% of the time
AFAIK did not change. Multiplying the amount of work by three is more
than just overhead, isn't it?

Thus my question, and I ask it again, maybe more clearly than the first
time. How could the chip's register be changed without using our driver?

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/