linux-kernel - Re: sdmmc controllers without vmmc 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] [day] [month] [year] [list]

Date:	Sat, 25 Feb 2012 11:57:59 +0000
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Stephen Warren <swarren@...dia.com>
Cc:	"Liam Girdwood (lrg@...com)" <lrg@...com>,
	Chris Ball <cjb@...top.org>,
	Marek Szyprowski <m.szyprowski@...sung.com>,
	"linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: sdmmc controllers without vmmc regulator

On Fri, Feb 24, 2012 at 01:35:08PM -0800, Stephen Warren wrote:

> Can we eliminate this warning in of_get_regulator(), and let clients
> Control whether they warn when a regulator isn't found, if they think
> one is mandatory? I think I'd prefer this option; it's consistent with
> the non-DT path in regulator_dev_lookup().

This would be sensible but...

> Or, should I set up dummy regulators in device tree to cover this case,
> such that an SD controller's vmmc-supply always points at a valid phandle.
> In which case, I'd have to add DT support to the dummy regulator.

...you really ought to be doing this anyway (except with the fixed
voltage regulator, the dummy regulator is for stubbing out regulator
support entirely on systems with just one or two software controlled
regulators or where you don't have any information on the board design).
The MMC regulator usage is a bit of a mess for historical reasons, it
shouldn't really be conditional.

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