linux-kernel - Re: Regulator supplies when using Device Tree

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4F7A581D.2020303@codeaurora.org>
Date:	Mon, 02 Apr 2012 18:53:33 -0700
From:	Michael Bohan <mbohan@...eaurora.org>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
CC:	rnayak@...com, lrg@...com, LKML <linux-kernel@...r.kernel.org>,
	linux-arm-msm@...r.kernel.org
Subject: Re: Regulator supplies when using Device Tree

On 4/2/2012 2:22 PM, Mark Brown wrote:
> On Mon, Apr 02, 2012 at 10:35:22AM -0700, Michael Bohan wrote:
>> Some of our regulators take inputs from other regulators. Some
>> regulators take their input from the battery. We support both types
>
> Oh, if that's all it is that's totally normal and unsurprising.  Just
> tell the regulator API about the battery supply, typically people use
> a fixed regulator for this.  You don't have to specify a voltage when
> you use them.

One problem here is the added run-time overhead. This includes the 
callbacks for the battery device which serve no functional purpose. And 
then there's the contention for a single mutex on the battery regulator, 
which all regulators using it as a supply would have to contend for. 
That is actually a sizable number of devices in our configuration; And 
these operations are frequent and time sensitive.

Plus, then there's other complexities that arise here by introducing yet 
another regulator driver into the configuration. The 'fixed' regulator 
driver initializes at subsys_initcall, but our other regulator drivers 
are registered at arch_initcall. This is because with Device Tree 
configurations we are forced to explicitly register drivers in a precise 
sequence in order to satisfy device dependencies and early probe times. 
But using 'fixed' would complicate this process, since we don't have 
control over it.

And generally speaking, why incur a larger memory footprint by linking 
another driver when there's no technical need to?

Thus it seems like there are use cases to have a single driver that can 
support regulators with or without supplies specified. I see adding a 
few lines of ugly code in the driver more ideal than accepting the 
problems above. But it would be nice if the regulator Device Tree 
support could handle it natively.

Thanks,
Mike

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/