Hi all,
We have a review for a thermal driver for the Intel MID platform pending
against the hwmon subsystem. See
http://lists.lm-sensors.org/pipermail/lm-sensors/2010-November/030471.html for details.
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. Potential problem with drivers/thermal is that
there are no thermal drivers in there (yet), and there does not seem to
be a maintainer. Another alternative would be to put it into platform
code, similar to the existing thermal drivers.
Thought, anyone ? Is there a preferred location for thermal drivers ?
Thanks,
Guenter
On Fri, Nov 12, 2010 at 12:33 PM, Guenter Roeck
<[email protected]> 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. Potential problem with drivers/thermal is that
> there are no thermal drivers in there (yet), and there does not seem to
> be a maintainer.
What is the difference between a "thermal" sensor and a "temperature"
sensor? Aren't they the same thing?
Why does drivers/thermal exist if there are no drivers in it and no maintainer?
Phil P.
On Fri, 2010-11-12 at 16:53 -0500, Phil Pokorny wrote:
> On Fri, Nov 12, 2010 at 12:33 PM, Guenter Roeck
> <[email protected]> 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. Potential problem with drivers/thermal is that
> > there are no thermal drivers in there (yet), and there does not seem to
> > be a maintainer.
>
> 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.
> Why does drivers/thermal exist if there are no drivers in it and no maintainer?
>
The framework resides there. Drivers supporting it are in various
platform directories.
As for why there are no drivers - only the framework - in
drivers/thermal, and why there is no maintainer - no idea.
Guenter
> > Why does drivers/thermal exist if there are no drivers in it and no maintainer?
It has a maintainer - they are just not listed in MAINTAINERS only in the
file itself.
> >
> The framework resides there. Drivers supporting it are in various
> platform directories.
>
> As for why there are no drivers - only the framework - in
> drivers/thermal, and why there is no maintainer - no idea.
Well I could put it in arch/x86/platform/mrst now we have that structure
from 2.6.37-rc1 onwards
On Fri, 2010-11-12 at 17:39 -0500, Alan Cox wrote:
> > > Why does drivers/thermal exist if there are no drivers in it and no maintainer?
>
> It has a maintainer - they are just not listed in MAINTAINERS only in the
> file itself.
>
> > >
> > The framework resides there. Drivers supporting it are in various
> > platform directories.
> >
> > As for why there are no drivers - only the framework - in
> > drivers/thermal, and why there is no maintainer - no idea.
>
> Well I could put it in arch/x86/platform/mrst now we have that structure
> from 2.6.37-rc1 onwards
I thought the driver is for Medfield ? Is that the same ? Or do you mean
you would add platform/medfield ? That might be another option.
Then there is drivers/platform/x86/intel_menlow.c, which has the thermal
driver code for Menlow.
Guenter
On Fri, Nov 12, 2010 at 2:06 PM, Guenter Roeck
<[email protected]> wrote:
> On Fri, 2010-11-12 at 16:53 -0500, Phil Pokorny wrote:
>> On Fri, Nov 12, 2010 at 12:33 PM, Guenter Roeck
>> <[email protected]> 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.
I vote for hwmon rather than drivers/thermal...
Phil P.
On Sat, Nov 13, 2010 at 02:21:58AM -0500, Phil Pokorny wrote:
> On Fri, Nov 12, 2010 at 2:06 PM, Guenter Roeck
> <[email protected]> wrote:
> > On Fri, 2010-11-12 at 16:53 -0500, Phil Pokorny wrote:
> >> On Fri, Nov 12, 2010 at 12:33 PM, Guenter Roeck
> >> <[email protected]> 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
On Sat, 13 Nov 2010 06:40:21 -0800, Guenter Roeck wrote:
> On Sat, Nov 13, 2010 at 02:21:58AM -0500, Phil Pokorny wrote:
> > 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.
+1
--
Jean Delvare