linux-kernel - Re: [RFC v2 5/6] drivers: boot_constraint: Add initial DT bindings

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:   Tue, 18 Jul 2017 11:28:04 +0530
From:   Viresh Kumar <viresh.kumar@...aro.org>
To:     Rob Herring <robh@...nel.org>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Mark Rutland <mark.rutland@....com>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Mark Brown <broonie@...nel.org>,
        Stephen Boyd <sboyd@...eaurora.org>,
        Rajendra Nayak <rnayak@...eaurora.org>,
        Shiraz Hashim <shashim@...eaurora.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: [RFC v2 5/6] drivers: boot_constraint: Add initial DT bindings

On 17-07-17, 12:34, Rob Herring wrote:
> On Thu, Jul 13, 2017 at 03:06:08PM +0530, Viresh Kumar wrote:
> > On 12-07-17, 16:28, Rob Herring wrote:
> > > Display is a pretty well known use case here. Do you have other
> > > examples in mind?
> > 
> > No, I don't.
> > 
> > @Stephen: Do you have more cases like this for your Qcom products ?
> > 
> > > Other cases I've seen are automotive with keeping
> > > the backup camera going and CAN bus handling. Though my new car has a
> > > flicker shortly after coming on, so I guess the handoff doesn't have
> > > to be completely seemless. :)
> > 
> > :)
> > 
> > > [...]
> > > 
> > > > +       mmc: mmc@0x0 {
> > > > +               ...
> > > > +               ...
> > > > +               vmmc-supply = <&twl_reg1>;
> > > > +               vmmcaux-supply = <&twl_reg2>;
> > > > +               boot-constraint-supplies = "vmmc", "vmmcaux";
> > > > +               boot-constraint-uV = <1800000 2000000>, /* vmmc */
> > > > +                                    <2000000 2000000>; /* vmmcaux */
> > > 
> > > No. I don't like how this is going to extend to all the other bindings
> > > people are going to want constraints for. We don't need a parallel set
> > > of properties for each type of binding.
> > 
> > Fair enough.
> > 
> > > I'm not convinced that we need a general solution for what's probably
> > > a handful of things that need a handoff versus just re-initialize.
> > 
> > What about keeping the first four patches (mostly) as it is and adding
> > these constraints from a platform specific constraints driver ?
> > 
> > Will that be acceptable ?
> 
> Meaning no DT binding? Then I don't care (from a DT perspective).

Yeah, kind of the way we decided to do the first step in the
power domain performance state series [1].

And then later on we can see how to get such information from DT, as
the kernel needs this information irrespective of the way we solve
this problem in the kernel.

-- 
viresh

[1] https://marc.info/?l=linux-kernel&m=149802907711074&w=2