lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20101113144021.GA29753@ericsson.com>
Date:	Sat, 13 Nov 2010 06:40:21 -0800
From:	Guenter Roeck <guenter.roeck@...csson.com>
To:	Phil Pokorny <ppokorny@...guincomputing.com>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	"lm-sensors@...sensors.org" <lm-sensors@...sensors.org>
Subject: Re: [lm-sensors] Location for thermal drivers

On Sat, Nov 13, 2010 at 02:21:58AM -0500, Phil Pokorny wrote:
> On Fri, Nov 12, 2010 at 2:06 PM, Guenter Roeck
> <guenter.roeck@...csson.com> wrote:
> > On Fri, 2010-11-12 at 16:53 -0500, Phil Pokorny wrote:
> >> On Fri, Nov 12, 2010 at 12:33 PM, Guenter Roeck
> >> <guenter.roeck@...csson.com> wrote:
> >> > I think a better location for the driver would be drivers/thermal.
> >> > drivers/hwmon is not really a good fit, since hwmon support for thermal
> >> > drivers is optional.
> >>
> >> What is the difference between a "thermal" sensor and a "temperature"
> >> sensor?  Aren't they the same thing?
> >>
> > The thermal framework is much more extensive than the hwmon framework.
> > See Documentation/thermal/sysfs-api.txt for details.
> 
> Ahh...  Sorry for wasting your time without reading the necessary
> background first.  I have rectified this oversight.
> 
> Reading the thermal sysfs-api and code, it's seems clear that it is a
> very ACPI centric kind of thing.  It's involved in the coordination of
> temperatures and the ways (fans, throttle algorithms, etc.) to keep
> them in check.  It makes regular calls into the ACPI parser to
> evaluate values.
> 
> But this driver that Alan has written seems to be a hwmon driver.
> It's poking at registers, setting up A2D channels and dealing with
> thermistors and perhaps voltages?  Those are very hwmon like things
> for a driver to do.
> 
> It appears to be very similar to the coretemp and k10temp drivers that
> read temperatures from the internals of the CPU.
> 
If the driver would use the hwmon framework, yes. However, it uses the thermal
framework, in which hwmon support is optional.

The thermal framework itself is acpi independent. There is no single
acpi call in the thermal framework code. acpi use may be true for the 
drivers currently registering with the thermal framework, but that
doesn't mean that the thermal framework itself in any way depends on 
or is only supposed to be used with ACPI devices. ACPI is only referenced
in the documentation as example.

If the thermal framework were to be used for acpi devices only, it would
presumably reside in drivers/acpi and not be independent.

So your reasoning isn't really correct. Putting thermal drivers into 
the hwmon directory doesn't really make sense. hwmon functionality
is an optional subset of thermal drivers, but that does not mean
that thermal drivers _are_ hwmon drivers.

Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ