linux-kernel - Re: [PATCH v2 1/3] 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]

Date:	Thu, 8 Aug 2013 13:00:26 -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 Thu, Aug 08, 2013 at 06:15:54PM +0100, Mark Brown wrote:
> On Thu, Aug 08, 2013 at 08:21:48AM -0700, Guenter Roeck wrote:
> > On 08/08/2013 06:08 AM, Mark Brown wrote:
> 
> > >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.
> 
> Sure, it'll work in systems that have always on regulators.
> 
> > 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.
> 
> Sure, that's the transition issues I mentioned - the regulator API does
> have stubbing facilities which should cover things and it's very easy to
> define stub regulators if you need to.  Like I say I expect this to be a
> lot easier after the next merge window as another way of doing stubs is
> being added which should make this even easier by avoiding disrupting
> drivers that do genuinely want to check for absent supplies and handle
> that better.
> 
We will need to make sure that all dts files using any of the compatible chips
are updated accordingly. There are several entries in various dts files for
adm1032, adt7461, lm90, and nct1008.

> > 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 ?
> 
> That's not what the name means - they are nothing to do with the board.

Ok, makes sense.

> The names requested by a driver are defined with regard to the device
> and should be the names used by the chip itself as defined in the

9 votes for vdd, 11 votes for vcc, one undecided (no datasheet available).
Guess one is as good as the other ;-).

Guenter

> datasheet.  A board that uses regulators then maps these onto specific
> regulators in the system, the driver doesn't need to know anything about
> this process.
--
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/