Hi: (btw: Please use an email client that doesn't completely butcher the text to which you're replying. Thanks.)
> > > > On Sun, 2008-02-03 at 10:26 +0800, Henrique de Moraes Holschuh > > > > wrote: > > > > > And the two sysfs ABIs are incompatible. The ACPI one uses > > > > > low-precision units, (temperature in 10^0 degrees Celcius), while > > > > > the hwmon ABI uses medium precision units (10^-3 degrees Celcius), > > > > > for example. There is also no tachometer feedback for fans, etc. > > > * Zhang Rui <[EMAIL PROTECTED]> [2008-02-03 17:31:12 +0800]: > > > > Yes, currently ACPI is the only user of the thermal sysfs I/F. We > > > > can add new sys I/F if someone really need it. * Henrique de Moraes Holschuh <[EMAIL PROTECTED]>: > > I would really appreciate if the thermal zone ABI used a subset of the > > hwmon ABI. There is absolutely no reason to have one return data in > > 10^-3 C while the other returns data in 10^0 C, for example. IMO, if > > both ABIs need thermal readings, both should use the same attribute, > > defined in the same way. The same goes for other attributes in the two > > interfaces that share a common concept. * Thomas, Sujith <[EMAIL PROTECTED]> [2008-02-05 15:44:19 +0530]: > 1)Hwmon interface have other sensors for voltage and current measurement > as well in addition to thermal sensors. Though this interface is generic > from a "monitoring" perspective, it lacks some hierarchy representation. > For eg. it lacks folder structure to store the list of devices > associated with a thermal sensor. This hierarchy information is very > much required by application to make an intelligent decision. It's not there now. It could be added. > 2) It is missing interfaces for passive device control.(CPU- T > states,LCD,Memory controller, etc..) Ditto. > 3) The solution should work on any ACPI based system or any other > thermal model for that matter which follows the basic concept. (The > model being : There are devices associated with sensors and if we > "control" the device, the temperature of the sensor will come down). The "association" bit is difficult for most hwmon drivers. There are 10k different mainboards, all wired differently, with no way to query them to determine e.g. which PWM output is associated with which temp sensor. So, we are forced to punt the assocation to userspace. You won't have that problem w/ ACPI - lucky you. ;) That still doesn't mean that this info can't or shouldn't be exposed in hwmon when it *is* available. > 4)What I have understood is that Hwmon supports only Smbus and I2C based > sensors. It doesn't have support for EC based sensors at this point of > time. Incorrect. We support devices with a variety of hardware interfaces in addition to the I2C/SMBus. Did you even look? > 5)If I am not wrong, Hwmon lacks support for programming AUX trip points > and trigger events based on that. You keep saying "hwmon lacks support for"... the hwmon sysfs interface supports exactly what the hardware can do. If your hardware can do something new or unique, you extend the interface to support it. There are numerous examples of this. > These were all the facts which lead us to take a different route than > hwmon. I don't actually mind having a thermal management interface that is outside of hwmon, if that's what you want to do. But these "facts" (which are the premises of your rationale) are mostly bogus. <cut> * Thomas, Sujith <[EMAIL PROTECTED]> [2008-02-05 15:44:19 +0530]: > IMO the scope of hwmon is to monitor/report out temperature, voltage , > current etc of the devices/platform . But the scope of these patches is The scope of hwmon is to allow whatever the hardware allows. Period. > purely thermal management for a generic thermal model. As a first step > we have made it work for ACPI thermal model. > The only duplication which I can see of is in the "reporting of > temperature", which is quite reasonable for a thermal management module > to have. Well, HdMH and I apparently disagree about this. All I really care about is that the temp info should be available through /sys/class/hwmon. Many people just want to check their temps, without diving into the fine details of a "thermal management solution". So... what class of hardware would I need to give these patches a try? Probably it would take me less time to write a patch to add hwmon class support to that than it did to write this message... ;) Regards, -- Mark M. Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
