linux-kernel - Re: [PATCH v2 3/5] regulator: helper routine to extract regulator_init

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: <20111013183821.GN18574@ponder.secretlab.ca>
Date:	Thu, 13 Oct 2011 12:38:21 -0600
From:	Grant Likely <grant.likely@...retlab.ca>
To:	Rajendra Nayak <rnayak@...com>
Cc:	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	devicetree-discuss@...ts.ozlabs.org, linux-omap@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, tony@...mide.com, lrg@...com,
	b-cousson@...com, patches@...aro.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 3/5] regulator: helper routine to extract
 regulator_init_data

On Tue, Oct 11, 2011 at 11:29:29AM +0530, Rajendra Nayak wrote:
> On Monday 10 October 2011 10:52 PM, Mark Brown wrote:
> >On Mon, Oct 10, 2011 at 09:49:36PM +0530, Rajendra Nayak wrote:
> >
> >>+- regulator-change-voltage: boolean, Output voltage can be changed by software
> >>+- regulator-change-current: boolean, Output current can be chnaged by software
> >>+- regulator-change-mode: boolean, Operating mode can be changed by software
> >>+- regulator-change-status: boolean, Enable/Disable control for regulator exists
> >>+- regulator-change-drms: boolean, Dynamic regulator mode switching is enabled
> >>+- regulator-mode-fast: boolean, allow/set fast mode for the regulator
> >>+- regulator-mode-normal: boolean, allow/set normal mode for the regulator
> >>+- regulator-mode-idle: boolean, allow/set idle mode for the regulator
> >>+- regulator-mode-standby: boolean, allow/set standby mode for the regulator
> >>+- regulator-input-uV: Input voltage for regulator when supplied by another regulator
> >>+- regulator-always-on: boolean, regulator should never be disabled
> >
> >Thinking about this I'm not sure that these should go in the device
> >tree, they're as much talking about what Linux is able to cope with as
> >they are talking about what the hardware is able to do.  Sometimes
> >they'll be fixed by the design but they are sometimes also restricted by
> >what the software is currently capable of.  DRMS is a prime example
> >here, it depends on how good we are at telling the API about how much
> >current we're using.
> 
> So is there another way of passing these, if not through device tree?
> There are other linux specific things that need to be passed to the
> framework as well, like the state of the regulator in the various
> linux specific suspend states, like standby/mem/disk.
> So if these can't be passed through device tree, should they still
> be passed in some way through platform_data? Or is it best to identify
> the bindings as being linux specific and not generic by appending a
> "linux," to the bindings.
> 
> Grant, need some help and advice.
> 

I can't really help much here.  If it is a property of the hardware,
then it absolutely needs to be in the device tree.  If it is a
limitation of Linux, or the Linux driver, then I would say that it
should be encoded in the driver.  I don't understand enough of the
problem space of regulators to give a good answer about what you
should do.

These *sound* like flags that the driver would set based on its own
capabilities; in which case it is something that would be encoded
directly into the driver.

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