linux-kernel - Re: [lm-sensors] regulator: regulator_get behaviour without CONFIG

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:	Mon, 5 Apr 2010 14:23:47 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Jean Delvare <khali@...ux-fr.org>
Cc:	Jerome Oufella <jerome.oufella@...oirfairelinux.com>,
	lm-sensors <lm-sensors@...sensors.org>,
	linux-kernel@...r.kernel.org, Liam Girdwood <lrg@...mlogic.co.uk>
Subject: Re: [lm-sensors] regulator: regulator_get behaviour without
 CONFIG_REGULATOR set

On Sat, Apr 03, 2010 at 05:37:45PM +0200, Jean Delvare wrote:
> On Fri, 2 Apr 2010 21:45:03 +0100, Mark Brown wrote:

> > In this case you don't need the if (voltage) check - the code that uses
> > supply_uV is going to have to cope with it being set to 0 if the driver
> > doesn't just give up, and the enable wants to happen anyway (perhaps
> > we've got a switchable supply we can't read the voltage of).  It should
> > never make any odds if the notifier never gets called since the supply
> > could be invariant.

> We still need to check if (voltage) to not overwrite the previous value
> of data->supply_uV with 0. We will probably do that as an immediate fix
> to the sht15 driver. But yes, the rest doesn't need a condition.

I was assuming that there wasn't a previous value since this was in
probe(), sorry.

> Still, I'd prefer if drivers were just able to check for data->reg ==
> NULL and skip the whole thing. Would you apply the following patch?

> From: Jean Delvare <khali@...ux-fr.org>
> Subject: regulator: Let drivers know when they use the stub API

> Have the stub variant of regulator_get() return NULL, so that drivers
> can (but still don't have to) handle this case specifically.

I guess I'll ack it but I'd be suspicous of driver code which actually
makes use of this - there is actual hardware which has the same features
as the regulator that gets stubbed in and ought to be handled.  On the
other hand, perhaps someone will come up with a good use for it.

It also seems a bit odd to return a traditional error value in a success
case but it doesn't actually make much difference.
--
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/