linux-kernel - Re: [PATCH V7 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: <cbcfeb15-d940-f066-739d-25adfe09f019@linaro.org>
Date:   Fri, 30 Mar 2018 18:24:25 +0300
From:   Georgi Djakov <georgi.djakov@...aro.org>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Viresh Kumar <viresh.kumar@...aro.org>
Cc:     Vincent Guittot <vincent.guittot@...aro.org>,
        Stephen Boyd <sboyd@...nel.org>,
        Rajendra Nayak <rnayak@...eaurora.org>,
        linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        robdclark@...il.com, s.hauer@...gutronix.de,
        l.stach@...gutronix.de, shawnguo@...nel.org, fabio.estevam@....com,
        nm@...com, xuwei5@...ilicon.com, robh+dt@...nel.org, olof@...om.net
Subject: Re: [PATCH V7 00/13] drivers: Boot Constraint core

Hi Greg and Viresh,

On 03/23/2018 05:04 PM, Greg Kroah-Hartman wrote:
> On Thu, Mar 22, 2018 at 09:26:06AM +0800, Viresh Kumar wrote:
>> On 23-02-18, 15:53, Viresh Kumar wrote:
>>> Problem statement:
>>>
>>> Some devices are powered ON by the bootloader before the bootloader
>>> handovers control to Linux. It maybe important for some of those devices
>>> to keep working until the time a Linux device driver probes the device
>>> and reconfigure its resources.
>>>
>>> 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.
>>>
>>> Another case can be a debug serial port enabled from the bootloader.
>>>
>>> Of course we can have more complex cases where the same resource is
>>> getting used by two devices while the kernel boots and the order in
>>> which devices get probed wouldn't matter as the other device will surely
>>> break then.
>>
>> And we have a _real_ use case for this complex scenario as well.
>>
>> Georgi (cc'd) is currently working[1] on implementing generic support for the
>> interconnect bus, which tries to play with the bandwidth of the bus based on how
>> much are the requirements from different parts of the SoC. The 4th version was
>> posted recently by him, and things are looking good/positive.
>>
>> The bootloader configures the interconnect to provide sufficient bandwidth for
>> all the devices which are used during boot, few of them are the CPUs, serial and
>> the LCD controller. As the kernel starts taking control of things, the drivers
>> being probed start putting their requirements on the interconnect bus.  Because
>> the interconnect doesn't have any representation from the devices which are not
>> yet initialized by the kernel, the interconnect core incorrectly reduces the
>> bandwidth of the bus to a level unacceptable to the devices running currently,
>> like the CPUs and this makes kernel boot awfully slow. This is not an ordering
>> problem as no matter which device we probe first, we are going to break
>> something else.

The interconnect core takes requests from consumer drivers for their
bandwidth needs and configures the hardware to keep the lowest possible
power profile. I think that the boot constraint patches would be useful
to make a board run at maximum performance during boot, until all
consumer drivers are probed and all bandwidth requests are taken into
account.

>> Georgi already tried using the boot constraint patches to solve this complex
>> problem, and its a perfect fit.

These patches solve a common problem for different subsystems, so it
makes sense to handle it into the driver core, instead of leaving each
subsystem to do their own hacks.

> I'm delaying this as I still don't see that "perfect fit" yet.  If there
> are add-on patches that take better advantage of this, great, let's see
> those, but right now, it feels like you are the only one wanting this.
> And the increased complexity overall seems not really worth it yet :(

The interconnect code is still under review, but on the next submission
i will include a patch to make use of the boot constraints, so that we
hopefully move this forward.

Thanks,
Georgi