It's my doing so I can answer your questions. There's not much good reason for the monster w83781d driver. I'm not defending it, just explaining how we got here. Generally I would start supporting a new chip by simply recognizing the ID and treating it like an old chip. Later (maybe much later) when a datasheet was available, when the unique parts of the new chip were known, the driver was enhanced with more if statements to support the new chip better. Recently, I stopped the madness and started a new driver, w83627hf, specifically to support the super i/o chips. The old driver works for the super i/o chips only when their i2c address has been set by the bios or when their isa address is 0x290. It does not include super i/o access or detection mechanisms. The new driver is isa-only and includes super i/o detection, so that the isa address is always discovered. This makes the new driver much better at finding a chip. You could make the argument that I should have removed 627hf/697hf support from the w83781d driver at the same time. But I didn't want to disrupt people that were using that driver (see below). And remember the new driver is isa-only. So if you want i2c access for whatever reason you have to use the old driver. Why recycle stuff in libsensors? just laziness. It's a pain to retype all that stuff. Plus if the #defines are different then you need a whole different print function in prog/sensors/chips.c. For big chips like the winbonds that's a _lot_ of extra work to add support. I would claim the w83627hf driver is in good shape but I'm open to suggestions. If you do want to tackle a w83781d rewrite it's fine w/ me. You should decide whether you want to do it in 2.4 or 2.6. But a couple of warnings. You should have a good sample of boards with these chips to test with. And you should be careful. A _huge_ number of people have chips supported by the w83781d driver. When a release takes a step backwards or changes something in that driver we get a ton of mail. It's not fun. Not to mention the whole undocumented as99127f chip which is, historically, probably our #1 chip for complaints. mds "Mark M. Hoffman" wrote: > > * Mark M. Hoffman <mhoffman at lightlink.com> [2003-10-21 21:51:13 -0400]: > > OK, I committed a partial fix - go ahead and try it. I already see that > > sensors doesn't report fan3 (which corresponds to "Power Fan" in P4C800 > > BIOS.) I will start another thread on the mailing list about that... > > OK, new subject anyway... > > What is the benefit of having all of the Winbond drivers in two files? > > 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? > > 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 unmaintainable. > > 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. > > Also, what (kinds of) changes in libsensors will cause an ABI change? Is > it absolutely limited to the contents of lib/sensors.h? > > Regards, > > -- > Mark M. Hoffman > mhoffman at lightlink.com
