linux-kernel - Re: [RFC 0/5] drivers: Add boot constraints 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: <1522ae7b-fd5b-5403-62bf-b0140e116d65@gr13.net>
Date:   Thu, 29 Jun 2017 15:06:01 +0000
From:   "Enrico Weigelt, metux IT consult" <enrico.weigelt@...3.net>
To:     Viresh Kumar <viresh.kumar@...aro.org>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        Rafael Wysocki <rjw@...ysocki.net>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Stephen Boyd <sboyd@...eaurora.org>,
        Mark Brown <broonie@...nel.org>,
        Shiraz Hashim <shashim@...eaurora.org>,
        Rob Herring <robh@...nel.org>, rnayak@...eaurora.org
Subject: Re: [RFC 0/5] drivers: Add boot constraints core

On 29.06.2017 14:47, Viresh Kumar wrote:

> No. Drivers are registered to the kernel (randomly, though we can know
> their order) and devices are registered separately (platform/amba
> devices get registered automatically with DT, hint:
> drivers/of/platform.c). The device core checks while registering
> devices/drivers if their drivers/devices are available or not. If
> yes, then the devices are probed using the drivers. Now the drivers
> must make sure all the dependencies are met at this point, else they
> can return -EPROBE_DEFER and the kernel will try probing them again.

Could we somehow introduce an strict ordering ?
Maybe by letting the device core know of the dependencies, before
individual probe()'s explicitly ask for them ?

>> Let's imagine a LCD panel driven by a regulator behind SPI. The panel
>> driver would ask the regulator framework to switch on, which would
>> call the regulator driver. This one now would talk to SPI framework,
>> which finally calls the SPI driver. If SPI isn't up yet, it would all
>> be deferred, leaving the panel driver uninitialized (tried again later).
>
> This should happen in probe, otherwise we are screwed.

Yes, but the probe result may be deferred, so it's tried again in the
next round. Correct ?

>> If the bootloader already switched on the panel (therefore already
>> enabled SPI), why does it matter that the panel driver isn't up yet ?
>
> But the kernel doesn't know how it is configured, there can be so many
> configurable parameters. The kernel needs to do it again by itself.

Could it read back the config ?

By the way: I've got a similar problem w/ gpmc right now: uboot already
sets it up, but the kernel only knows about one CS (for the nand) and
screwes up the others (eg. fpga), so it cant access the fpga . Until
I've sorted out all the parameters for DT (unfortunately, only have the
raw register values), I'll have to rely on an userland test program
to set it all up ...

> Let me try with an example. A regulator is shared between LCD and DMA
> controller.
>
> Operable ranges of the regulator: 1.8 - 3.0 V
> Range required by LCD: 2.0 - 3.0 V
> Range required by DMA: 1.8 - 2.5 V

Would a config readback help here ?

The regulator core then should know that we're already in proper
range for DMA and no need to touch the regulator.


--mtx