linux-kernel - Re: Re: [PATCH] Parse missing regulator constraints from device tree blob

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

Date:	Thu, 16 Jan 2014 17:56:53 +0000
From:	Mark Brown <broonie@...nel.org>
To:	Saurabh Singh <saurabh1.s@...sung.com>
Cc:	Mark Rutland <mark.rutland@....com>,
	"lgirdwood@...il.com" <lgirdwood@...il.com>,
	"grant.likely@...aro.org" <grant.likely@...aro.org>,
	"rob.herring@...xeda.com" <rob.herring@...xeda.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"celinux-dev@...e.celinuxforum.org" 
	<celinux-dev@...e.celinuxforum.org>,
	SREEVATSA D B <srevatsa@...sung.com>,
	Praveen BP <bp.praveen@...sung.com>
Subject: Re: Re: [PATCH] Parse missing regulator constraints from device tree
 blob

On Thu, Jan 16, 2014 at 03:18:03PM +0000, Saurabh Singh wrote:
> Hi Mark,
> 
> > Please send patches using the process in SubmittingPatches, the formatting
> > of the submission is very important for tools like git am which people use to
> > work with patches.
> 
> As per your request sending the patch and description in git format.
> Please find below the patch.
> 
> Regards,

No, please do as I asked and follow the process in SubmittingPatches -
as I said the format things are sent in is very important for the
tooling.  Pasting the patch into a mail after some other text definitely
doesn't give a mail in the format covered in SubmittingPatches.  If in
doubt send the mail to yourself and then compare it with other patches
sent to the list and test by applying with git am and make sure the
patch and changelog come out OK.

> +- regulator-valid-modes-mask: valid operations for regulator on particular machine

This is not adequately documented, what are "valid operations" and how
would they be encoded?

> +- regulator-input-uv: regulator input voltage, only if supply is another regulator

Why provide a property for this, surely if there is another regulator we
can just find out from that regulator what voltage it is outputting?

> +- regulator-initial-mode: default mode to set on startup

It is not documented what a mode is here or how one would specify it in
the property.

> +- regulator-initial-state: suspend state to set at init

Again, no semantics are provided for this.

> +- regulator-state-mem, regulator-state-disk, regulator-state-standby:
> +	defines regulator suspend to memory, suspend to disk (hibernate) and standby respectively.
> +	have following sub-constarints:
> +	- regulator-state-uv: suspend voltage
> +	- regulator-state-mode: suspend regulator operating mode
> +	- regulator-state-enabled: is regulator enabled in this suspend state
> +	- regulator-state-disabled: is the regulator disbled in this suspend state

I am very nervous about the idea of putting this stuff into DT.  This
matches less and less well with modern system designs which are becoming
more and more dynamic, and of course the concepts of suspending to
memory, disk and standby are unclear and fluid - what is the difference
between memory and standby for example?

I'd be interested to know if there are real systems that need this and
can't figure out what to do dynamically.

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