linux-kernel - Re: [PATCH 3/5] regulator: axp20x: Update the bindings to use a local parent regulator

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140605154931.GY2520@sirena.org.uk>
Date:	Thu, 5 Jun 2014 16:49:31 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Maxime Ripard <maxime.ripard@...e-electrons.com>
Cc:	carlo@...one.org, Boris Brezillon <boris@...e-electrons.com>,
	lgirdwood@...il.com, lee.jones@...aro.org,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	kevin.z.m.zh@...il.com, sunny@...winnertech.com,
	shuge@...winnertech.com, zhuzhenhua@...winnertech.com
Subject: Re: [PATCH 3/5] regulator: axp20x: Update the bindings to use a
 local parent regulator

On Thu, Jun 05, 2014 at 04:27:29PM +0200, Maxime Ripard wrote:

> You already list the regulators available and their supply in the
> regulator driver, why do you need to set the regulator parents in the
> mfd driver as well?

Unless they're being used by the MFD directly there should be no need
for the MFD to know anything about the supplies.

> My guess is that it's to work around the fact that
> regulator_dev_lookup only looks for the regulator's device of_node (so
> not the PMIC one, but one of its child), which doesn't have the supply
> properties, and then just falls back on the regulator alias
> list. Would it make some sense to add a lookup in the parent device
> of_node (which would be the "main" PMIC node in our case)?

This sounds like you are passing the MFD child device into the regulator
API when you should be passing the parent device in.

> Also, there's also the fact that all the supply properties seems to
> also be mandatory in the DT, even though the regulator itself might
> not be used at all on the board, and the input voltage not wired to
> anything.

For electrical engineering reasons it's unlikely that the supplies are
actually floating but yes, they are mandatory.  This is an issue with
registering one device for the entire regulator subsystem on the PMIC,
it interacts somewhat poorly with deferred probe.  However for systems
with full constraints like DT and ACPI ones it should be mostly
sidestepped since the if there is no supply mapped a dummy supply will
be substituted.

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