mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: "Vaittinen, Matti" <Matti.Vaittinen@fi.rohmeurope.com>
Cc: "angus@akkea.ca" <angus@akkea.ca>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Laine, Markus" <Markus.Laine@fi.rohmeurope.com>
Subject: Re: regulator: BD71837: possible regression
Date: Tue, 14 May 2019 10:11:05 +0100	[thread overview]
Message-ID: <20190514091105.GA8665@sirena.org.uk> (raw)
In-Reply-To: <4efe8d75766719eee3987fd80b2c11a0e66c75fa.camel@fi.rohmeurope.com>

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

On Tue, May 14, 2019 at 06:14:41AM +0000, Vaittinen, Matti wrote:

> I am not sure but perhaps the regulator core is changed so that this
> parent/child relation must be modelled using <foo>-supply properties in
> device-tree. Are you able to bisect the change which breaks this? There
> may be other regulator drivers doing the same as bd718x7 is (which
> means trusiting to setting the supply_name in desc to be enough - and
> without deeper understanding I'd say it should be enough).

The framework will look for the parent regulator and warn if it can't
find it but it should still instantiate it if the mapping is a hard
failure (as opposed to a probe deferral).

> If this change is intentional and buck6-supply and buck7-supply are bow
> required also in DT, then we should reflect this fact also in bindings
> doc for BD71837 and BD71847.

It is always and has always been best practice to wire up the regulators
as completely as possible; this is less error prone and gives you more
ability to take advantage of framework improvements.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

      reply	other threads:[~2019-05-14  9:11 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <34f520784f0b489861d62bc30749bf2a@www.akkea.ca>
2019-05-14  6:14 ` Vaittinen, Matti
2019-05-14  9:11   ` 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=20190514091105.GA8665@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=Markus.Laine@fi.rohmeurope.com \
    --cc=Matti.Vaittinen@fi.rohmeurope.com \
    --cc=angus@akkea.ca \
    --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®