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 22:18:25 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Guenter Roeck <linux@...ck-us.net>
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 01:00:26PM -0700, Guenter Roeck wrote:
> On Thu, Aug 08, 2013 at 06:15:54PM +0100, Mark Brown wrote:

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

Yes, and probably also board files as well.  Or either just accept
bisection trouble for now or wait till the better stubbing is in there -
that will mean that for DT systems the core will just assume the supply
is really there and not fail requests if it's not in the DT.

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

What I've suggested before is to use the name from the part for which
the driver is named.  Assuming the vendor doesn't randomly change their
datasheet (but that causes problems for hardware engineers so tends to
be avoided).

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)