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:	Tue, 5 Jun 2012 17:22:14 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	David Collins <collinsd@...eaurora.org>
Cc:	Rajendra Nayak <rnayak@...com>, Liam Girdwood <lrg@...com>,
	linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: Supporting non-device tree consumers with device tree regulator
 drivers

On Tue, Jun 05, 2012 at 09:16:22AM -0700, David Collins wrote:

>  Therefore, we are left with a situation currently where some regulator
> consumer drivers are being probed via device tree and some are being
> probed via board file devices within a single platform.  If the regulator
> driver supporting the consumer drivers is converted to use device tree and
> probed via device tree, then the non-device tree consumer drivers will not
> be able to make use of the regulator devices.

This isn't something anyone else seems to be running into - most of the
world is converting entire boards to device tree in one fell swoop and
sticking with normal style until that works.

> Would it be possible to add a new binding that is handled inside of
> of_get_regulator_init_data() or of_get_regulation_constraints() that
> provides a means to directly specify regulator_init_data.consumer_supplies
> entries?  Is there some other mechanism that could be used instead to
> handle the mapping?

> One potentially binding could be:
> regulator-consumer-supplies = "supply_name1", "device_name1",
> "supply_name2", "device_name2", ...

Well, we certainly shouldn't be putting this in the device tree as that
rather defeats the point...  Some sort of auxdata style thing would be
possible I guess but I'm not sure it's worth bothering.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ