linux-kernel - Re: [PATCH v3 1/2] hwmon: (lm90) Add power control

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: <20130910181837.GD29403@sirena.org.uk>
Date:	Tue, 10 Sep 2013 19:18:37 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Stephen Warren <swarren@...dotorg.org>
Cc:	Guenter Roeck <linux@...ck-us.net>, Wei Ni <wni@...dia.com>,
	"khali@...ux-fr.org" <khali@...ux-fr.org>,
	"lm-sensors@...sensors.org" <lm-sensors@...sensors.org>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 1/2] hwmon: (lm90) Add power control

On Tue, Sep 10, 2013 at 11:44:05AM -0600, Stephen Warren wrote:

> OK, so I believe you're saying that the case of a chip with just a
> single power source, which absolutely must be present in HW for the chip
> to be powered, isn't appropriate for regulator_get_optional(). Something
> must always define a regulator for that power source, even if there is
> no external SW control over that power source.

Well, it really should be mandatory - personally I don't think it's
sensible to add off-SoC chips without defining their regulators, it's
more trouble than it's worth to have to add them later for all the time
it takes to define the bindings.  In IETF terms it's a should.

> We either allow the regulator to be optional (since SW control over the
> regulator is optional), or go back to every board file and DT and add a
> dummy regulator in (which then breaks DT ABI, and even ignoring that is
> a pain).

The whole point of the way I'm changing the dummy support is to allow
us to gracefully cope with errors here so there's no mandatory update
even though strictly there should be one.

> And note that when I say "optional" at the start of the previous
> paragraph, I'm talking about probe-time regulator_get() operations and
> DT content. Clearly as far as the rest of the driver is concerned,
> something can always provide a dummy regulator so that e.g.
> regulator_enable/disable() elsewhere  always have something to operate
> on. However, probe() either needs to call an API that automatically
> provides such a dummy regulator, or open-code that itself. I'm still not
> clear which option you think should be used.

Clearly open coding this in every single driver is just not sane, you're
immediately in the situation where every single driver has to implement
the same thing at which point no driver ought to be doing it.

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