linux-kernel - Re: [PATCH] regulator: Support different config and dev of_nodes in 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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Thu, 12 Feb 2015 10:32:52 +0800
From:	Mark Brown <broonie@...nel.org>
To:	Tim Bird <tim.bird@...ymobile.com>
Cc:	"Andersson, Björn" 
	<Bjorn.Andersson@...ymobile.com>,
	"lgirdwood@...il.com" <lgirdwood@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] regulator: Support different config and dev of_nodes in
 regulator_register

On Wed, Feb 11, 2015 at 09:21:32AM -0800, Tim Bird wrote:

> Also, when registering a regulator, you can pass a different
> of_node in config (struct regulator_config) than the one in dev
> (struct device)

> However, this has problems in the current code, as the test in
> regulator_dev_lookup requires that the device_node found by of_get_regulator()
> match the dev.of_node in the regulator in the regulator list.

...

> It took me a while to figure this out, because a regulator defined
> with dev.of_node != config.of_node worked fine, when accessed
> directly by name (not using a supply-name).  I only had problems
> when I accessed the regulator using the "-supply" indirection technique
> in DT.

I'm not quite sure exactly what you've done here but I'm pretty sure
there's some confusion somewhere since the -supply based lookups are of
course what everything in mainline is doing except for CPU supplies.
The fact that you are using of_get_regulator_init_data() is a bit of a
red flag here, you shouldn't have to use that unless your bindings are
in some way unusual.

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