linux-kernel - Re: regulator: BD71837: possible regression

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:   Tue, 14 May 2019 10:11:05 +0100
From:   Mark Brown <broonie@...nel.org>
To:     "Vaittinen, Matti" <Matti.Vaittinen@...rohmeurope.com>
Cc:     "angus@...ea.ca" <angus@...ea.ca>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Laine, Markus" <Markus.Laine@...rohmeurope.com>
Subject: Re: regulator: BD71837: possible regression

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.

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