linux-kernel - Re: [PATCH V6 Resend 00/13] drivers: Boot Constraint core

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]

Date:   Thu, 11 Jan 2018 07:45:08 -0600
From:   Rob Herring <robh+dt@...nel.org>
To:     Chen-Yu Tsai <wens@...e.org>
Cc:     Viresh Kumar <viresh.kumar@...aro.org>, Nishanth Menon <nm@...com>,
        Rajendra Nayak <rnayak@...eaurora.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Stephen Boyd <sboyd@...eaurora.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Wei Xu <xuwei5@...ilicon.com>, Rob Clark <robdclark@...il.com>,
        Fabio Estevam <fabio.estevam@....com>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Shawn Guo <shawnguo@...nel.org>,
        "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" 
        <linux-arm-kernel@...ts.infradead.org>,
        Lucas Stach <l.stach@...gutronix.de>
Subject: Re: [PATCH V6 Resend 00/13] drivers: Boot Constraint core

On Wed, Jan 10, 2018 at 8:07 PM, Chen-Yu Tsai <wens@...e.org> wrote:
> On Thu, Jan 11, 2018 at 7:13 AM, Rob Herring <robh+dt@...nel.org> wrote:
>> On Tue, Jan 9, 2018 at 9:47 PM, Viresh Kumar <viresh.kumar@...aro.org> wrote:
>>> Hi Greg,
>>>
>>> I am re-sending V6 as you suggested. There is no change from the patches
>>> sent on 14/15th of December, apart from rebasing on driver-core-next.
>>>
>>> I have tested the Hisilicon patches (again) on hikey 9660 board, IMX
>>> stuff was earlier tested by Sascha (Pengutronix) on i.MX6 and Qualcomm
>>> stuff was earlier tested by Rajendra (Qualcomm) on Dragonboard 410C
>>> (This required some more patches related to display driver which
>>> Rajendra should be sending separately later on).
>>>
>>>
>>> Problem statement:
>>>
>>> Some devices are powered ON by the bootloader before the bootloader
>>> handovers control to Linux. It maybe important for those devices to keep
>>> working until the time a Linux device driver probes the device and
>>> reconfigure its resources.
>>
>> Some devices are powered on by a bootloader, but only a small few have
>> to be maintained thru booting. Most you can just re-initialized.
>>
>>> 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
>>> Linux.  The LCD controller can be using some resources, like clk,
>>> regulators, 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 disabling or reconfiguring these
>>> resources to ranges satisfying the current users (only device X) and
>>> that can make the LCD screen unstable.
>>
>> We already have simple fb and a binding for it. It only handles clocks
>> I think, but could be extended to other things. I rather not extend
>> it, but it is there already and we don't need different solutions for
>> this.
>
> simplefb also handles regulators. This was added quite a while ago to
> keep LCD displays powered on Allwinner tablets. However in general it
> only grabs references to these resources and enables them so the kernel
> frameworks don't think they are unused and turn them off. It doesn't
> do clock rate or voltage constraints which Viresh wants. It should be
> easy to do for regulators, and AFAIK there is a clock rate protection
> mechanism for the clk framework in the works.

Why do we need constraints beyond taking a reference? The constraint
is don't change things. If it is more complex than that, then you need
something to parse the "real" DT nodes for the h/w blocks.

Rob