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: <4FB268A9.5040007@cam.ac.uk>
Date:	Tue, 15 May 2012 15:31:05 +0100
From:	Jonathan Cameron <jic23@....ac.uk>
To:	Lars-Peter Clausen <lars@...afoo.de>
CC:	Guenter Roeck <guenter.roeck@...csson.com>,
	"R, Durgadoss" <durgadoss.r@...el.com>,
	"Tc, Jenny" <jenny.tc@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"lm-sensors@...sensors.org" <lm-sensors@...sensors.org>,
	Jonathan Cameron <jic23@...nel.org>
Subject: Re: [lm-sensors] [PATCH] hwmon: Generic ADC support for hwmon

On 5/15/2012 3:18 PM, Lars-Peter Clausen wrote:
> On 05/15/2012 03:42 PM, Guenter Roeck wrote:
>> On Tue, May 15, 2012 at 08:42:57AM -0400, R, Durgadoss wrote:
>>> Hi Guenter,
>>>
>>> Thanks for a quick reply.
>>>
>>>> On Tue, May 15, 2012 at 10:26:48AM -0400, Jenny TC wrote:
>>>>> Currently drivers are using custom APIs to communicate with ADC driver.
>>>>> So it make sense to have generic APIs to commnicate with ADC drivers.
>>>>> This patch introduces generic APIs to communicate with ADC drivers.
>>>>>
>>>>> Signed-off-by: Jenny TC<jenny.tc@...el.com>
>>>>
>>>> Hi Jenny,
>>>>
>>>> Do you have a practical use case ?
>>>
>>> We have some platform specific component drivers, thermal drivers,
>>> battery drivers using this General purpose ADC in the platform.
>>> That's why we thought of doing something like this.
>>>
>>>>
>>>> Also, shouldn't those generic ADCs rather be supported through the IO
>>>> subsystem ?
>>>> After all, hwmon is all about hardware monitoring, not to provide generic ADC
>>>> access.
>>>
>>> In this case, can we try this in iio or mfd subsystem ?
>>> Kindly advise.
>>>
>> I meant iio (more specifically staging/iio/adc).
>>
>> I suspect it might make more sense to have a hwmon client, in parallel to the other
>> users/clients (battery control, thermal etc), if the values reported by the ADC reflect
>> information relevant for hardware monitoring.
>>
>
> So there is already an experimental IIO to hwmon bridge in
> drivers/staging/iio/, which you can use to expose a IIO ADC driver as an
> hwmon device.
Thanks Lars-Peter.  That bridge is currently limited to voltage reading 
but that's more because my test part didn't do anything else.
Trivial to add other bits and bobs as needed.  In the short term, the
interrupt driven side of things is still under review (so you are 
limited to polling devices - though this is typically fine for hwmon
etc).  I'll be submitting a patch to move the existing hwmon bridge 
driver into drivers/hwmon in the next cycle (after the IIO core is out 
of staging).

Longer term plans involve reducing the connection between the IIO
userspace front end and the backend to give cleaner support when
people don't want generic userspace interfaces.  This means making
absolutely everything under the sun available through generic in kernel
interfaces which will be 'interesting' for some more interesting devices...

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ