linux-kernel - Re: [RFC] shared regulator initialization and protection

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-next>] [day] [month] [year] [list]

Message-ID: <20160412034804.GT3351@sirena.org.uk>
Date:	Tue, 12 Apr 2016 04:48:04 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Pingbo Wen <pingbo.wen@...aro.org>
Cc:	linux-kernel@...r.kernel.org, lgirdwood@...il.com,
	Serge Broslavsky <serge.broslavsky@...aro.org>,
	Vincent Guittot <vincent.guittot@...aro.org>
Subject: Re: [RFC] shared regulator initialization and protection

On Tue, Apr 12, 2016 at 10:44:11AM +0800, Pingbo Wen wrote:

Please fix your mail client to word wrap within paragraphs at something
substantially less than 80 columns.  Doing this makes your messages much
easier to read and reply to.

> Those day, I get some fuzz idea in a proxy-consumer regulator driver
> [1] from Qcom kernel tree. The driver is simple, that let some
> critical regulator, which specified in DT tree, initializing in a
> pre-defined state, and hold a regulator consumer during system boot,
> to provide some protection between multi-consumers.

> And I think this driver is a hint that our upstream code lack of some
> regulator intialization and protection. We already have some regulator

Given how poorly most of the Qualcom code uses the regulator API I'd
take anything they've got out of tree with a pinch of salt.  At best
this looks like a hack for some system specific issues but since it's
just some undocumented code it's hard to tell.

> If a regulator only used by one consumer, current code will work fine.
> But for the regulator which shared between multi-consumers, we can not
> make sure that the regulator will work in a defined-state, during
> system boot, since the device driver can probe in any order, and set
> some conflict attributes.

What is the actual problem here?  Every driver is responsible for
ensuring that regulators are in a good state before it starts using the
hardware, if some other device did something before why do we care?

> Currently, I didn’t have much solution for this problem, but I’m work
> on that. The simplest solution is to create an agent regulator driver
> to do the first ‘regulator_get’, just like Qcom proxy consumer driver.
> Or we define a master device of a regulator, only the master device
> can set the regulator attributes, other device can only do the enable
> operation.

If there are constraints they need to be set in the constraints.  If
drivers need to cooperate then they need to arrange to cooperate
including handling the case where some of them aren't loaded.

Anything based on doing things at initcall levels is fundamentally
broken, as soon as things are built modular like most things in a distro
kernel then it'll stop working.  If the system integrator needs some
devices to start early to provide continuity (the main case here is
display) they need to deal with that at the system integration level.

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