linux-kernel - Re: [RFC PATCH] mfd: arizona: Update device tree regulator bindings

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]

Date:	Thu, 26 Sep 2013 18:58:43 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Charles Keepax <ckeepax@...nsource.wolfsonmicro.com>
Cc:	devicetree@...r.kernel.org, patches@...nsource.wolfsonmicro.com,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] mfd: arizona: Update device tree regulator bindings

On Thu, Sep 26, 2013 at 04:29:41PM +0100, Charles Keepax wrote:

Please include some context in replies...

> I had considered adding something like a recursive regulator get
> that works it's way up the tree but this felt rather invasive and
> most places the user code does the regulator get rather than a
> framework so the issue is only really likely to crop up with
> regards to ASoC.

I don't see why this would only be an issue for ASoC - it happens to
have more helpers for this right now than anything else but I'd hope
that at some point in the future we can get some of the common patterns
for holding regulators into the device framework.  You also have the
potential for this to do the wrong thing if it doesn't happen to be
talking to an MFD which is doing this since it just unconditionally
looks at the parent.

I would suggest that rather than unconditionally doing this on lookup
it'd be easier to do it the other way round and explicitly add mappings
from the parent to the child when registering the device.  That doesn't
have the potential to explode and get the wrong thing like this does.

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