linux-kernel - Re: [PATCH V4 08/12] boot_constraint: Manage deferrable constraints

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

Message-ID: <CAKohponB0V-jNozTSo4mb0kw3BV_fBDBWLQEq5fF7WrvCvXRHg@mail.gmail.com>
Date:   Wed, 1 Nov 2017 02:29:24 +0000
From:   Viresh Kumar <viresh.kumar@...aro.org>
To:     Rob Herring <robh+dt@...nel.org>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Stephen Boyd <sboyd@...eaurora.org>,
        Rajendra Nayak <rnayak@...eaurora.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        Rob Clark <robdclark@...il.com>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Lucas Stach <l.stach@...gutronix.de>,
        Shawn Guo <shawnguo@...nel.org>,
        Fabio Estevam <fabio.estevam@....com>,
        Nishanth Menon <nm@...com>, Wei Xu <xuwei5@...ilicon.com>
Subject: Re: [PATCH V4 08/12] boot_constraint: Manage deferrable constraints

On 31 October 2017 at 16:20, Rob Herring <robh+dt@...nel.org> wrote:
> What is the effect on boot time? It's highly platform dependent, but
> the worst case could be pretty bad I think.

Yeah, it can increase considerably here and I have plans for that, just
that i didn't wanted to get them in the first iteration to keep things simple.

What we can (should?) do is, that the boot constraint framework can hook
into other frameworks like regulators/clk/PM, etc, so that whenever a new
clk/regulator is added to those frameworks, they check for pending
requests from boot constraint framework. If found, they can call a callback
of the boot constraint framework which will set the constraints to the resource
before anyone else gets a chance. At that point we can remove the early
defer probing support that this patch is adding. And things would be quite fast
then.

> I don't see how this handles the case you mentioned where the amba
> pclk gets disabled. It only works if the constraint device is added
> before any others, but that is done with initcall level games.

Yeah, so as I said earlier, the basic idea is that these constraints must get
set before any user driver (for constrained devices) comes up. And the
only way to do that is by making sure the constraints get added at early
initcall levels. The same is done for all the three example drivers I have
added.

The amba-pclk thing isn't a issue then, as that stuff happens only at probe
and not when the amba device is created.

--
viresh