On Mon, 14 Feb 2011 19:40:14 +0000, Matthew Garrett wrote: > On Mon, Feb 14, 2011 at 11:33:55AM -0800, Guenter Roeck wrote: > > On Mon, Feb 14, 2011 at 02:05:57PM -0500, Matthew Garrett wrote: > > > The kernel has generic support for thermal management. Making it work > > > for any device is just a matter of a driver generating the appropriate > > > thermal and cooling devices and associating them. ACPI already works > > > this way. > > > > > Not sure what you suggest here. Thermal devices register as hwmon devices > > if so configured, so having hwmon devices register as thermal devices > > would not work, at least not without some serious thought to prevent > > registration loops. > > That's really an implementation detail - the worst case at present is > that you'd end up with the same sensor providing data twice, but that's > fixable. I agree. I tend to believe that this approach would be superior to the initial proposal for the problem at hand. The few required hwmon drivers would simply register their temperature sensors as thermal zones, and their fan control outputs as cooling devices, to the thermal subsystem. This requires no change to the hwmon core, nor to all other individual hwmon drivers. > > If you are looking for thermal device support, maybe the drivers in question > > should be implemented as thermal device drivers and provide hwmon functionality > > through the thermal subsystem. Did you consider that option ? > > We could definitely change the existing hwmon drivers to be thermal > drivers instead, but not everything they do fits into that model. Not instead. Additionally. > > Do you plan to use/utilize the thermal subsystem, or do you plan to duplicate > > that functionality in the GPU driver(s) ? Guess that was one of the reasons > > why Jean asked for a use case of the proposed API. > > Use the thermal subsystem. That's why I made the ACPI thermal code > generic in the first place. This sounds good. > > If you plan to use the thermal subsystem without having to rewrite hwmon drivers, > > did you consider means to interconnect the hwmon subsystem with the thermal subsystem, > > eg by creating a means for hwmon devices to register as thermal devices ? > > As I said, we could rework the hwmon drivers into thermal devices > instead, but we'd still need a mechanism for providing the thermal > device back to the registering device. Correct. > > > Because hardware control is the kernel's job, not userspace's. Having > > > hardware melt just because userspace fell off a cliff isn't acceptable. > > > > > The same argument would apply to system fan control, doesn't it ? > > Yes, which is why it belongs in the kernel. The truth is IMHO more complex than this. I tend to believe that fan speed control (or more generally thermal management) can be implemented at different levels. Think about it, it's just like CPU frequency scaling. You have kernel governors and one user-space governor for people unhappy about the in-kernel ones and/or for hardware which can't be supported by these. Ideally, thermal management would be implemented by the hardware, and neither the kernel drivers nor user-space should have to care. Less ideally, the kernel driver has to care, but has enough knowledge to do this by itself without user intervention. The worse case is where the kernel doesn't know and the user has to configure everything manually. This is the case of many PC motherboards out there, for which users rely on the user-space fancontrol script (or anything similar.) It can be pretty useful, but I still avoid when I can. And I definitely wouldn't recommend this approach for GPUs. So I can envision a similarly layered thermal management logic, where the kernel drivers take care of what they have to and can handle, and leave the rest to user-space (as is already the case today.) In other words, please let me be clear that I have no objection to what Matthew and Martin are trying to achieve. My objections relate to the implementation and the way to submit it for review. -- Jean Delvare _______________________________________________ lm-sensors mailing list lm-sensors@xxxxxxxxxxxxxx http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
