linux-kernel - Re: [RFC PATCH 0/2] HWMON: add in-kernel interfaces to read sensor values.

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] [day] [month] [year] [list]

Date:	Thu, 17 Nov 2011 20:40:45 +0000
From:	Jonathan Cameron <jic23@....ac.uk>
To:	MyungJoo Ham <myungjoo.ham@...il.com>
CC:	Ben Hutchings <bhutchings@...arflare.com>,
	lm-sensors@...sensors.org, linux-kernel@...r.kernel.org,
	Jean Delvare <khali@...ux-fr.org>,
	Guenter Roeck <guenter.roeck@...csson.com>,
	dg77.kim@...sung.com, kyungmin.park@...sung.com
Subject: Re: [RFC PATCH 0/2] HWMON: add in-kernel interfaces to read sensor
 values.

On 11/17/2011 08:22 AM, MyungJoo Ham wrote:
> On Tue, Nov 15, 2011 at 1:39 AM, Jonathan Cameron <jic23@....ac.uk> wrote:
>> On 11/14/2011 01:31 AM, MyungJoo Ham wrote:
>>> On Sat, Nov 12, 2011 at 5:46 AM, Ben Hutchings
>>> <bhutchings@...arflare.com> wrote:
>>>> On Fri, 2011-11-04 at 15:50 +0900, MyungJoo Ham wrote:
>>>>> We have been reading hwmon values (TMU, the SoC-core temperature sensor,
>>>>> and NTC, the ambient or battery surface temperature sensor) for
>>>>> Charger-Manager. However, because hwmon does not have in-kernel interface,
>>>>> we have been using undesired method, including "../../../fs/*.h".
>>>>>
>>>>> This patch is to provide in-kernel interface for hwmon:
>>>>> hwmon_get_value and hwmon_set_value. In order to use these two functions,
>>>>> the hwmon driver should provide its sysfs attributes to hwmon framework
>>>>> as well. If the hwmon driver does not provide (by providing NULL), the users
>>>>> of the hwmon won't be able to use hwmon_get/set_value();
>>>>> The sysfs attribute (struct attribuyte_group *) is provided with
>>>>> hwmon_device_register; adding the second parameter to hwmon_device_register().
>>>>> The 2/2 patch shows the changes in device drivers due to this.
>>>> [...]
>>>>
>>>> This is an improvement, but I don't think it is quite enough.  As I
>>>> understand the hwmon sysfs interface, all sensor values should be
>>>> integers.  So the in-kernel interface should also work with integers,
>>>> not strings.
>>>>
>>>> As a first implementation you could perhaps parse the strings back to
>>>> integers.  However in the longer term the driver API should be changed
>>>> so that hwmon drivers fully describe their sensors to the core and the
>>>> core takes care of exposing them through sysfs and the in-kernel API.
>>>
>>> I agree.
>>>
>>> I'll let it the in-kernel interfaces provide integer value although it will
>>> simply parse strings as you've addressed until we have some other
>>> interfaces for sysfs entries in hwmon device drivers.
>>>
>>>
>> To throw another option into the mix, you could make it an IIO driver
>> and sit hwmon on top of that (there is already a simple driver for
>> doing this) - IIO has in kernel interfaces of the type
>> you want.  Not everything is there yet though.
>>
>> Jonathan
> 
> Yes, we may alter the HWMON drivers to be IIO drivers as well.
> 
> However, to me, at least for the HWMON devices I've been looking, IIO
> seems to be an overkill and more complex than needed for the target
> devices.
It should (at least in theory) be very simple for anything like a simple
hwmon device on which one wants to do polled reads.

All you do is allocate an iio_dev, set up the channel descriptions,
register it with the core.  Then a map is used to match supplied
channels to their consumers in kernel.

There is a simple hwmon driver that then takes one of these maps if
you want conventional hwmon interfaces.  Other interested drivers can
have their own maps.

Anyhow, IIO is complex for some devices, but pretty simple for simple
things (at least it should be!)

Jonathan
--
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/