linux-kernel - Re: [PATCH 2/4] regulator: core: Expose init_data to of_parse

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, 5 Mar 2015 00:42:20 +0000
From:	Mark Brown <broonie@...nel.org>
To:	Bjorn Andersson <bjorn.andersson@...ymobile.com>
Cc:	Chanwoo Choi <cw00.choi@...sung.com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Krzysztof Kozlowski <k.kozlowski@...sung.com>,
	Kumar Gala <galak@...eaurora.org>,
	Lee Jones <lee.jones@...aro.org>,
	Liam Girdwood <lgirdwood@...il.com>,
	Mark Rutland <mark.rutland@....com>,
	Pawel Moll <pawel.moll@....com>,
	Rob Herring <robh+dt@...nel.org>,
	Stephen Boyd <sboyd@...eaurora.org>,
	Andy Gross <agross@...eaurora.org>,
	Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>
Subject: Re: [PATCH 2/4] regulator: core: Expose init_data to of_parse_cb

On Tue, Mar 03, 2015 at 08:15:41AM -0800, Bjorn Andersson wrote:
> On Tue 03 Mar 04:50 PST 2015, Mark Brown wrote:

> > Why would the driver need to do that?  I guess I'll see later on in the
> > series but the changelog should make that clear.  Drivers aren't
> > supposed to ever need to look at their init data, modifying the init
> > data from what the machine provied is usually a red flag.

> I think what you're getting at is that the init_data should come from a
> board file or device tree. With the reworkings done in patch 4 this

Yes, that's the entire purpose of the init data.

> As this matches a regulator, there is no way for the driver (or anyone
> else to affect the init_data).

That's a goal not a problem.  There is an interface for the machine
description to configure the system integration which neither the
regulator driver nor the consumer driver should be a part of.

> The problem at hand is that there is nothing in this code path telling
> the core that we can do DRMS - something we can figure out in the driver
> by basically looking at the ops for the registering regulator.

No, that way lies people doing all the crap they usually do with putting
the default constraints for their reference design or the maximum limits
for their PMIC into the constraints and then getting upset when drivers
then go and use this to make their CPU catch fire or whatever.

You need to provide a way for the machine description to say DRMS (or
really setting the load which is what's actually happening here now we
have that op) is safe on a given system.  I think that means adding a
new permission to DT and then using that; it's more sensible to want to
use this feature in the context where we're working with an external
processor which also has a chance to have system tuning than when we're
working with the PMIC directly so a permission that enable load setting
seems good.

We could even kill the existing DRMS permission, there's one user in a
legacy STE platform.

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