Using an optional regulator in a driver running on a PC

Using an optional regulator in a driver running on a PC

[Guenter Roeck]

Hi all,

I am currently writing a driver which uses an optional regulator
to determine a reference voltage. The regulator is truly optional;
if it is not there, the chip uses an internal reference voltage.

I am testing the driver on a PC which does not really have any
regulators installed or enabled. Kernel version is 3.13.

I noticed that the call to regulator_get() returns -EPROBE_DEFER.
Looking into the regulator core, this appears intentional; there is
obviously no devicetree entry, and there is no regulator device.
The regulator code always returns -EPROBE_DEFER in this case.
I also tried regulator_get_optional(), with the same results.

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.

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.

Thanks,
Guenter

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1870 bytes --]

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.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]