On Fri, 11 Apr 2008 09:18:24 +0200, Hans de Goede wrote: > Jean Delvare wrote: > > I don't like the current approach either. In fact it seems that every > > new developer finds it odd at first, and in the end we only keep doing > > it because it has been so from the beginning of the lm-sensors project. > > The fact is that our drivers would perform much better if we did not > > repeatedly read from registers which aren't supposed to change. Some > > drivers mitigate the performance penalty by reading from these > > registers less frequently, but then it somewhat misses the original > > point of always reflecting the current register state. > > > > But on the other hand, anything that helps spot conflicts with ACPI or > > SMM is welcome, as these issues can be very hard to investigate - in > > particular for SMBus-based chips or chips with index/data pair I/O port > > access, where simultaneous access can result in data corruption. Thomas > > Renninger and myself proposed something that should help for ACPI in > > some cases but Linus rejected our approach. Removing the extra reads > > from our drivers would be one less way to spot that kind of problem. Of > > course we can look at the registers directly using i2cdump or isadump > > in most cases, but users are less likely to do that, while they usually > > do notice when limits change mysteriously. > > > > So all in all I have to admit that I don't really know what to do. > > Maybe the extra reads should be made a compilation-time or (probably > > better) a run-time option, so we leave the decision to the user? > > I think given the slowness of reading these registers (esp in the i2c / smbus > case) making it an option is a good idea, I think we should combine this with > when this option is activated (it should be default off) actually checking if > things were changed and if so complain. > > Then when we suspect faulplay by acpi/smm we can ask the user to turn on the > option. > > Does that sound like a plan? Fine with me, as long as this is a run-time option and not a build-time option. Rebuilding a kernel module is not an option for many users. -- Jean Delvare
