mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Guenter Roeck <groeck7@gmail.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Liam Girdwood <lgirdwood@gmail.com>
Subject: Re: Using an optional regulator in a driver running on a PC
Date: Sun, 26 Jan 2014 12:39:21 +0000	[thread overview]
Message-ID: <20140126123921.GE11727@sirena.org.uk> (raw)
In-Reply-To: <52E4E913.6030300@roeck-us.net>

[-- 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 --]

      reply	other threads:[~2014-01-26 12:39 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-26 10:53 Guenter Roeck
2014-01-26 12:39 ` Mark Brown [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140126123921.GE11727@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=groeck7@gmail.com \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®