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>] [day] [month] [year] [list]
Message-id: <29524060.615241389971045531.JavaMail.weblogic@epml20>
Date:	Fri, 17 Jan 2014 15:04:08 +0000 (GMT)
From:	Saurabh Singh <saurabh1.s@...sung.com>
To:	Mark Brown <broonie@...nel.org>, rob.herring@...nel.org
Cc:	Mark Rutland <mark.rutland@....com>,
	"lgirdwood@...il.com" <lgirdwood@...il.com>,
	"grant.likely@...aro.org" <grant.likely@...aro.org>,
	"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: [PATCH] Parse missing regulator constraints from device tree blob

Hi Mark,

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

Ok, I have created the patch with guidelines, which I will be sending in a separate mail 
Also, this time I have tested my patch it by "git am".

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

Provide the information in documentation, and provide better abstraction so as to hide
linux internals in device tree.

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

Valid point! , removed from the code.

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

Added documentation with example

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

We often use suspend to memory  in our mobile domain and is much useful.
Suspend to disk could be useful for special cases of hibernate like debugging.
Couldn't find the use of standby constraint, but I added in code so as to provide completeness to the framework. 

Please let me know your feedback.

Regards,
Saurabh Singh Sengar
Lead Engineer
Samsung R&D Institute
India

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ