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

Date:	Mon, 18 Apr 2016 15:26:03 +0800
From:	Pingbo Wen <pingbo.wen@...aro.org>
To:	Mark Brown <broonie@...nel.org>
Cc:	pingbo.wen@...aro.org, 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

Hi, Mark

On Tuesday, April 12, 2016 11:48 AM, Mark Brown wrote:
> 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.

Ok, I have re-send another pre-formated email, but you replied to the bad
one. Anyway, sorry for this.

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

It's hard to tell how many Qualcom code uses the regulator API, I didn't
do such investigation. Maybe the 'proxy' consumer driver is just a
work-around code, but I don't think it's a reason to prevent us to get
some hints from it.

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

Yes, I agree the driver should set the regulator before do the real work,
when the device life time is started from driver probing. But if the device
life time is started before Linux kernel loading, the regulator core should
do the regulator initialization and protection to power the device properly,
during kernel booting, until the consumer driver probed.

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

Adding a initcall to do the consumer removing is not a decent method.
We can do some hack in regulator_get(), removing agent consumer until
specified device call regulator_get(), or the first regulator_get().

Pingbo