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]

Message-ID: <CAGb2v66xUJn3KoOZW5d7zcU4BY+ZYJqpyJP1bxC_oir-V2+G=w@mail.gmail.com>
Date:   Thu, 11 Jan 2018 10:07:01 +0800
From:   Chen-Yu Tsai <wens@...e.org>
To:     Rob Herring <robh+dt@...nel.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 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.

ChenYu

>> Another case can be a debug serial port enabled from the bootloader.
>
> I looked at your case with HiKey some. As far as the PL011
> driver/console is concerned, it should work as the clock is never
> enabled/disabled and then probe deferred (IMO, doing any h/w init
> before all resources are acquired is a driver error). The problem is
> the AMBA bus enabling apb_pclk (which has a dedicated clk gate) and
> then disabling it on deferred probe. The AMBA bus is fairly odd in
> this regard. We could solve this just with an initcall to find
> stdout-path node and enable all the clocks in the node and then a late
> initcall to disable those clocks. Kind of hacky, but so is this
> series.
>
> Really, I think the clock framework is broken in that we leave clocks
> in a mismatched state (reset state or whatever the bootloader decided)
> until the end of booting. Then we are left with dealing with these
> various platform specific issues. We should either not actually
> disable clocks until the end of boot (just defer until we turn off all
> unused clocks) or start requiring the clock drivers to turn off all
> the clocks except the ones needed to continue booting (or otherwise
> known to be constraints). The former should be easy to implement
> because the code to turn off clocks is already there. We just need a
> boot done flag and check that flag in disable function.