Winbond chips - design questions
khali at linux-fr.org
Wed Oct 22 20:49:22 CEST 2003
> OK, new subject anyway...
> What is the benefit of having all of the Winbond drivers in two files?
Benefit is obvious. It is because, hmmm... well... well you know, it's
obviously obvious ;)
> And related - what is the benefit of recycling feature tables etc.
> between all the Winbond types in lib/chips.c and prog/sensors/chips.c?
Almost as obvious as above ;)
> I can tell you the downside, for sure: I'm afraid to touch any of it
> for fear of breaking one of the other 5 chips that I *don't* have and
> *can't* test. Sure it's free software and I don't have any
> obligation... but right now those particular bits are nigh
I definitely agree with you on that point. Likewise, the adm1021 driver
has become a complete mess.
> I guess I'm asking for permission (and help!) in refactoring the
> Winbond drivers. The NatSemi (lm??) drivers are closer to where I
> think we should go: two (or at most, three) related chips per file...
> and only if they are trivially different or one has a subset of
> features of the other, etc.
That's what I'd call a good objective. That's how I intend to make
things in drivers I wrote or maintain (lm83, lm90, adm1025).
> Also, what (kinds of) changes in libsensors will cause an ABI change?
> Is it absolutely limited to the contents of lib/sensors.h?
Good question. Someone here, can't remember who, once said we would have
to change the library's version with each release. So I guess that the
ABI is likely to change that often. I don't quite understand what
exactly cause incompatibilities, nor what our numbering policy should
be. If someone is willing to explain that in details, that would be
More information about the lm-sensors