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: <522F5A65.8040907@wwwdotorg.org>
Date:	Tue, 10 Sep 2013 11:44:05 -0600
From:	Stephen Warren <swarren@...dotorg.org>
To:	Mark Brown <broonie@...nel.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 09/10/2013 11:04 AM, Mark Brown wrote:
> On Tue, Sep 10, 2013 at 09:07:43AM -0600, Stephen Warren wrote:
>> On 09/10/2013 04:09 AM, Mark Brown wrote:
> 
>>> No.  There are a couple of issues here.  One is that we don't want
>>> to litter all drivers with conditional code to check if they
>>> actually got the regulator and so on, that's just pointless make
>>> work on the part of consumers.
> 
>> So that's exactly the difference between (a) and (b) above.
> 
> Right, but the idea is that we just only ignore a failure to get a
> supply if we can usefully run without that supply being present and
> there's more code there than simply ignoring the error - if the driver
> can genuinely just ignore all errors and otherwise not do anything
> different then requesting the regulator in the first place is clearly a
> waste of time and enabling it would be a waste of power.
> 
> A driver should only be carrying code for a missing regulator if it can
> usefully work without it, like the cases where devices can use an
> internal reference if one is not available.

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.

If so, how does a driver (or binding) that's been written without any
support for a regulator (since so far all boards have had no SW control
over that power source; it's always on) get enhanced to support boards
where there is SW control over the power source?

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

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/