linux-kernel - Re: Using an optional regulator in a driver running on a PC

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:	Sun, 26 Jan 2014 12:39:21 +0000
From:	Mark Brown <broonie@...nel.org>
To:	Guenter Roeck <groeck7@...il.com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Liam Girdwood <lgirdwood@...il.com>
Subject: Re: Using an optional regulator in a driver running on a PC

On Sun, Jan 26, 2014 at 02:53:07AM -0800, Guenter Roeck wrote:

> This leads to an interesting question: How are drivers which require
> regulators (optional or not) supposed to run on a system
> which does not support devicetree, and does not have any
> regulators installed (such as a PC) ? REGULATOR_DUMMY
> isn't there anymore, and the dummy code it replaces only
> executes on devicetree based systems.

A feature like regulator_get_optional() can only work if we know about
all the regulator mappings that exist which with the current way of
registering mappings via platform data we can only do once regulators
have been registered.  This is a bit unfortunate and is why we never
used to have get_optional().

> Also, how are non-dt systems supposed to determine if an optional
> regulator exists or not ? AFAICS the regulator code always returns
> -EPROBE_DEFER, which isn't very helpful. If I just assume that
> -EPROBE_DEFER means that the regulator is not there, I end up with
> a conflict with a system which _does_ support devicetree, where
> -EPROBE_DEFER really means that the probe needs to be deferred.

It's nothing to do with devicetree, other systems can do it if they
specify full constraints.  All the core is doing is saying that it might
get told about more registrations later and not knowing if the regulator
might appear or not it's going with a conservative report.  Other
platforms need to either call regulator_have_full_constraints() when
they've registered all the mappings or do something else (OF is doing
the something else because it embeds the lookup code into the regulator
framework rather than translating and registering the mappings at boot
time).

I think platforms like PCs need to add a new way of registering mappings
outside of regulator registrations and then use those especially for
things like regulators on PCI cards.

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)