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, 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)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ