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

Message-ID: <CAL_Jsq+oAB3gejRMXuY0q9+Et4GrtvF3RwGzPNJ08TPooVyXJg@mail.gmail.com>
Date:   Wed, 12 Jul 2017 16:28:16 -0500
From:   Rob Herring <robh+dt@...nel.org>
To:     Viresh Kumar <viresh.kumar@...aro.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 Wed, Jul 12, 2017 at 1:34 AM, Viresh Kumar <viresh.kumar@...aro.org> wrote:
> This adds device tree bindings for boot constraints. Only power supply
> constraint types are supported currently.
>
> Signed-off-by: Viresh Kumar <viresh.kumar@...aro.org>
> ---
>  .../devicetree/bindings/boot-constraints.txt       | 68 ++++++++++++++++++++++
>  1 file changed, 68 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/boot-constraints.txt
>
> diff --git a/Documentation/devicetree/bindings/boot-constraints.txt b/Documentation/devicetree/bindings/boot-constraints.txt
> new file mode 100644
> index 000000000000..9a01ea1e6e72
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/boot-constraints.txt
> @@ -0,0 +1,68 @@
> +BOOT CONSTRAINTS
> +================
> +
> +Some devices are powered ON by the bootloader before the bootloader handovers
> +control to the Operating System (OS). It maybe important for those devices to
> +keep working until the time the OS takes over and starts configuring the devices
> +again.
> +
> +A typical example of that can be the LCD controller, which is used by the
> +bootloaders to show image(s) while the platform is booting into the Operating
> +System. The LCD controller can be using some resources, like clk, supplies, etc,
> +that are shared between several devices. These shared resources should be
> +configured to satisfy need of all the users. If another device's (X) driver gets
> +probed before the LCD controller driver in this case, then it may end up
> +reconfiguring these resources to ranges satisfying the current users (only
> +device X) and that can make the LCD screen unstable.

Display is a pretty well known use case here. Do you have other
examples in mind? 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.

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.

Rob