linux-kernel - Re: [lm-sensors] regulator: regulator_get behaviour without CONFIG

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]

Date:	Wed, 07 Apr 2010 12:24:02 +0100
From:	Jonathan Cameron <jic23@....ac.uk>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
CC:	Liam Girdwood <lrg@...mlogic.co.uk>,
	Jean Delvare <khali@...ux-fr.org>,
	lm-sensors <lm-sensors@...sensors.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [lm-sensors] regulator: regulator_get behaviour without CONFIG_REGULATOR
 set

On 04/06/10 19:19, Mark Brown wrote:
> On 6 Apr 2010, at 17:25, Jonathan Cameron <jic23@....ac.uk> wrote:
> 
>> On 04/06/10 16:27, Liam Girdwood wrote:
>>>>
>>>>
>>>>
>>>
>>> I suppose this is something we may look into more when we have more
>>> clients.
>> Makes sense.  There will probably be quite a few IIO drivers over the
>> next
>> few months doing much the same as sht15, where the voltage ref for
>> devices
>> may well be fed by a regulator.  In that case, we may only offer the
>> option
>> of using an external v_ref if the regulator is available.  Many
>> devices have
>> an internal regulator to provide it so typically we'll start them up
>> using that
>> and provide an interface to switch to external regulator if one is
>> available.
>> I haven't thought through exactly how this will work as yet. I'll cc
>> people in
>> when this comes up.
> 
> TBH this seems like a very vanilla use case - there may be some small
> advantage to representing the internal regulator via the regulator API
> but that's about the only thing I can think might be a bit odd.
> 
I wasn't thinking of representing the internal regulator using the regulator
framework (though if it is externally available I guess that would make sense
though probably only if anyone is actually using this to supply something else
- most likely case I can think of is daisy chaining multiple adc's and ensuring
they have the same reference value).

The case I'm interested in is the externally supplied voltage reference. This
typically comes off a fixed regulator or a spare regulator on a pmic.
The use case is getting this voltage (and indeed buffering it using the
same notifier approach as in sht15). This is needed to provide api compliant info
to userspace (which needs sufficient info to work out what the actual value is).

I'd imagine similar cases occur in some hwmon devices.

Basically all these uses look just like that in sht15.

Nothing new here, but there will be a number of consumers that care about changes
in voltage (rather than typically controlling it.)  Hence I'm welcoming the change
just agreed upon.

Thanks,

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/