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: <0da0328b-c0a2-215e-64be-5c27aa58572f@kernel.org>
Date:	Sun, 10 Jul 2016 15:39:15 +0100
From:	Jonathan Cameron <jic23@...nel.org>
To:	Pratik Prajapati <pratik.prajapati12@...il.com>,
	linux-iio@...r.kernel.org, linux-hwmon@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: How to set Current register in IIO driver from sysfs

On 10/07/16 14:11, Pratik Prajapati wrote:
> Including more members.
> 
> On Sat, Jul 9, 2016 at 5:22 PM, Pratik Prajapati
> <pratik.prajapati12@...il.com> wrote:
>> Hi,
hi Pratik,
>>
>> I am trying to add support of adjusting IR led current in vcnl4000
>> driver (has IR led current register for doing the same).
This is always a bit of a 'rough' corner when it comes to what interface
to do it with.  Strictly speaking this is typically just a regulator that
happens to be used for this special purpose.  Sometimes they are tightly
tied together with the input and sometime (on devices with more than one)
there is no explicit linkage at all.

In this particular case we seem to actually have a high frequency modulated
LED driver so it's pretty tightly tied to this use.
>>
>> Below is what I have done till now:
>>
>> 1) Added Current channel in the vcnl4000_channels structure with
>> separate mask IIO_CHAN_INFO_RAW
>> 2) Reading the LED current register inside IIO_CURRENT case in vcnl4010_read_raw
>> 3) Writing to LED current register inside IIO_CURRENT case in vcnl4010_write_raw
>>
>> Is this the correct way of setting Current register in IIO subsystem?
That's about the best option we currently have. This is exactly how it's done
in the max44000 driver for example.
 
It's not an interface anyone is terribly happy with so you are welcome to
suggestion alternatives (easy to add them as an additional interface to
existing cases - which is why we haven't been that worried about ending up
with the current less than ideal interface)
The tight coupling in this particular case might justify something more
explicitly linked to the proximity channel but as noted above it's not
always that obvious (see the health/afe parts for example which are way
too flexible in my view!)

Jonathan


>>
>> Best Regards,
>> Pratik Prajapati
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ