Hi Jean: * Jean Delvare <khali at linux-fr.org> [2004-08-11 22:26:16 +0200]: > > I think these should be named e.g. pwm1_auto_channels to make clear > > the distinction between a tacho input (fanX) and a pwm output (pwmX). > > > > (/me goes off to look at 2.6 sysfs_interface doc again) > > > > Oh dear. I'm sorry I wasn't paying attention to this sooner, but I > > think our interface needs revision again. All of the fan[nr]_pwm* > > files should really just be pwm[nr]*. > > > > The association between tacho input and pwm output is arbitrary and > > depends on mainboard maker. E.g. our script prog/pwm/pwmconfig is > > made to discover the relationships. > > > > Would anyone object to such a patch for 2.6 kernel drivers? > > I wish someone noticed that *before* I did the change the other way > around back in version 2.6.5... > > I'm not sure I agree with you. Old chips clearly had PWM outputs and > tachometers unlinked, but newer chips (Analog ADM1031, SMSC LPC47M1xx, > National PC8736x) clearly assume that pwmN and fanN refer to the same > physical fan. Of course, some motherboard manufacturers will ignore that > recommendation, but they are to blame. For example, the SMSC LPC47M1xx > chips will stop monitoring fan1 when pwm1 is enabled and has a duty > cycle of 0%. Thus the driver has to force fan1 to 0 in this case. If the > manufacturer used fan1 and pwm1 for different fans, then the monitored > fan cannot be monitored anymore when the controlled fan is turned off. > > Are there examples of recent chips which obviously don't consider that > pwmN and fanN are linked? For example chips having a different count of > tachometers and PWM outputs? Yeah, LM93... four tachos, two PWM outputs. Odd, but it seems like one anticipated configuration is to drive fans 1-2 (tacho's 1-2) *both* from pwm1. I could be wrong about that though. > If fanN and pwmN match like 90% of the time and the trend is to increase > that rate even more, then changing the names again now doesn't make much > sense (IMHO). But since I am the one who broke the interface in the > first place, I guess that my opinion doesn't really matter here. Well, it is just a name, so I don't feel too strongly about it. > > This also seems like a good time to introduce an idea that Khali > > and I discussed on IRC some days ago, actually, a rule-of-thumb: > > > > Any patch to the 2.6 kernel which changes/breaks some part of the > > documented sysfs interface must be accompanied by a patch to > > libsensors. The libsensors patch must preserve backwards compat. > > to the sysfs interface as it existed in every kernel.org kernel > > from 2.6.5-rc1 to present. > > > > I'm not suggesting we support forward-compat... nobody should > > complain if, after upgrading to a newer kernel, they are asked > > to upgrade to a newer libsensors. > > > > We've had sort of a honeymoon period where we could change the 2.6 > > kernel interface at will, and not support older ones with our current > > libsensors. That pissed some people off, and now that distros are > > releasing not-quite-current 2.6 kernels, it's a real PIA all around. > > So, let's declare the honeymoon over. > > Agreed. If you failed to notice, I've already added the needed code in > libsensors. Basically it lets you define 2 sysfs files instead of 1 for > each symbol. Both files are tried in turn, and the operation fails if > both files are missing. I have not defined an alternate magnitude yet, > because I doubt we'll need it, but this could be added if needed. I did notice - thanks, btw. > This change in libsensors isn't exactly elegant, but the previous code > wasn't either, and it was actually less complex that I first feared. > > I've already included the in0_ref <-> cpu0_vid compatibility, although > the 2.6 drivers have not been updated yet. The in0_ref name was one > other unnoticed mistake I made back in version 2.6.5 or so. And this > time I definitely agree that we can never say which "in" channel will be > used for vcore monitoring, since even on recent chips the motherboard > manufacturers don't follow the recommendations. > > There's also a lm83-specific compatibility rule for critical temperature > - driver update has already been sent to Greg. Regards, -- Mark M. Hoffman mhoffman at lightlink.com
