linux-kernel - Re: [PATCH v3 4/5] regulators: tps65912: Add regulator driver for the TPS65912 PMIC

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, 1 Oct 2015 11:53:08 +0100
From:	Mark Brown <broonie@...nel.org>
To:	"Andrew F. Davis" <afd@...com>
Cc:	Rob Herring <robh+dt@...nel.org>, Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	Lee Jones <lee.jones@...aro.org>,
	Linus Walleij <linus.walleij@...aro.org>,
	Alexandre Courbot <gnurou@...il.com>,
	Samuel Ortiz <sameo@...ux.intel.com>,
	Liam Girdwood <lgirdwood@...il.com>,
	linux-gpio@...r.kernel.org, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 4/5] regulators: tps65912: Add regulator driver for
 the TPS65912 PMIC

On Wed, Sep 30, 2015 at 06:32:14PM -0500, Andrew F. Davis wrote:
> On 09/30/2015 05:20 PM, Mark Brown wrote:

> >>This is already the case then, missing regulator nodes in old drivers will not
> >>get instantiated ether. And old drivers don't always store any more info about
> >>available regulators than mine does.

> >No, well implemented older drivers will still unconditionally register
> >everything.

> Is this desired? If they are not in the DT could this be used to signal
> we don't want to register this regulator?

Yes, this is desired.  The point is that there is no situation in which
we do not want to register all the regulators physically present on the
device.

> >You're talking about a trivial loop that takes perhaps a couple of lines
> >to open and close the for loop and another line to declare an iterator
> >variable.

> Adding any extra code and complexity to use a helper that does something
> that already works with less doesn't make much sense to me, but if that's
> the API you want I'll use it.

It would take a lot less effort to implement the requested changes
rather than go on and on about this.  There is no meaningful complexity
here, we're talking about removing code and moving some data tables from
DT (where they are an ABI) to code (where they are not an ABI).

> >Look, please stop arguing about this.  There appears to be nothing
> >special about this device that makes it different to other devices.

> I'm sorry if I sounded overly argumentative about this, I'm just trying to make
> points in favor of me not having to re-write my driver.

It's hardly a rewrite.

> The new framework helpers do not help my driver as it does things differently.
> You signed off on this different way of doing things just last year with the
> TPS65218.

> If you no longer want it done this way then I'll go and change my driver.

It should already be apparent that this is not a desired configuration,
old drivers are never a good reason not to do the right thing on new
code.

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