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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 08 Aug 2013 08:21:48 -0700
From:	Guenter Roeck <linux@...ck-us.net>
To:	Mark Brown <broonie@...nel.org>
CC:	Wei Ni <wni@...dia.com>, swarren@...dotorg.org,
	linux-kernel@...r.kernel.org, lm-sensors@...sensors.org,
	linux-tegra@...r.kernel.org, MLongnecker@...dia.com,
	khali@...ux-fr.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v2 1/3] hwmon: (lm90) Add power control

On 08/08/2013 06:08 AM, Mark Brown wrote:
> On Thu, Aug 08, 2013 at 04:25:41AM -0700, Guenter Roeck wrote:
>> On 08/08/2013 04:01 AM, Mark Brown wrote:
>
>>> That said if you *are* going to do this you should request the
>>> regulator using devm_regulator_get_optional(), this is intended to
>>> support things that don't need regulators (though that's not the case
>>> here).
>
>> The lm90 driver works perfectly fine without regulator.
>
> I'd be most surprised if the device worked without power, if the driver
> fails to get and enable a regulator for it then that's not great
> (especially if it does so silently).
>
Correct, but it appears that the driver magically worked for a long time
without it.

Is it guaranteed that the driver keeps working for all cases where
regulator support is enabled in the kernel, and where it used to work
so far without mandating the existence of this specific regulator ?
My main concern is having to deal with complaints that the driver stopped
working for no good reason.

In this context, is it common practice to name such regulators "vdd"
or similar ? What if there are multiple LM90 or compatible chips
in a system, connected to different power rails ? Who determines
if the regulator is supposed to be named "vdd" or "vcc" or anything
else, and to which power rails it is actually connected ? How can
and does one guarantee that "vdd" is the correct regulator to use
for all systems ? What if some other driver requests "vdd", but the chip
it supports happens to be connected to a different power rail ?

Sorry for my ignorance in that matter. I did browse through Documentation/power,
but did not find a clear answer.

> Note that the regulator API is written to stub itself out if not
> enabled, the code should be able to assume that it's there.
>
I am aware of that; this is why the driver should not dump an error message
if the function returns NULL and bail out, as it did originally.

Guenter

--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ