linux-kernel - Re: [PATCH v1 0/5] Enable fw

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:   Wed, 13 Jan 2021 15:27:03 +0000
From:   Jon Hunter <jonathanh@...dia.com>
To:     Marc Zyngier <maz@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Saravana Kannan <saravanak@...gle.com>
CC:     "Rafael J. Wysocki" <rafael@...nel.org>, <kernel-team@...roid.com>,
        <linux-kernel@...r.kernel.org>,
        Jisheng Zhang <Jisheng.Zhang@...aptics.com>,
        Kevin Hilman <khilman@...libre.com>,
        John Stultz <john.stultz@...aro.org>,
        Nicolas Saenz Julienne <nsaenzjulienne@...e.de>,
        linux-tegra <linux-tegra@...r.kernel.org>
Subject: Re: [PATCH v1 0/5] Enable fw_devlink=on by default


On 13/01/2021 11:11, Marc Zyngier wrote:
> On 2021-01-07 20:05, Greg Kroah-Hartman wrote:
>> On Thu, Dec 17, 2020 at 07:16:58PM -0800, Saravana Kannan wrote:
>>> As discussed in LPC 2020, cyclic dependencies in firmware that couldn't
>>> be broken using logic was one of the last remaining reasons
>>> fw_devlink=on couldn't be set by default.
>>>
>>> This series changes fw_devlink so that when a cyclic dependency is found
>>> in firmware, the links between those devices fallback to permissive mode
>>> behavior. This way, the rest of the system still benefits from
>>> fw_devlink, but the ambiguous cases fallback to permissive mode.
>>>
>>> Setting fw_devlink=on by default brings a bunch of benefits (currently,
>>> only for systems with device tree firmware):
>>> * Significantly cuts down deferred probes.
>>> * Device probe is effectively attempted in graph order.
>>> * Makes it much easier to load drivers as modules without having to
>>>   worry about functional dependencies between modules (depmod is still
>>>   needed for symbol dependencies).
>>>
>>> Greg/Rafael,
>>>
>>> Can we get this pulled into 5.11-rc1 or -rc2 soon please? I expect to
>>> see some issues due to device drivers that aren't following best
>>> practices (they don't expose the device to driver core). Want to
>>> identify those early on and try to have them fixed before 5.11 release.
>>> See [1] for an example of such a case.
>>
>> Now queued up in my tree, will show up in linux-next in a few days,
>> let's see what breaks!  :)
>>
>> And it is scheduled for 5.12-rc1, not 5.11, sorry.
> 
> For the record, this breaks my rk3399 board, (NanoPC-T4) as no mass
> storage can be discovered (it lives on PCIe):
> 
> (initramfs) find /sys -name 'waiting_for_supplier'| xargs grep .| egrep
> -v ':0$'
> /sys/devices/platform/ff3d0000.i2c/i2c-4/4-0022/waiting_for_supplier:1
> /sys/devices/platform/f8000000.pcie/waiting_for_supplier:1
> /sys/devices/platform/fe320000.mmc/waiting_for_supplier:1
> /sys/devices/platform/sdio-pwrseq/waiting_for_supplier:1
> /sys/devices/platform/ff3c0000.i2c/i2c-0/0-001b/waiting_for_supplier:1
> 
> Enabling the debug prints in device_links_check_suppliers(), I end up with
> the dump below (apologies for the size).


I am seeing the same problem on Tegra30 Cardhu A04 where several regulators
are continuously deferred and prevents the board from booting ...

[    2.518334] platform panel: probe deferral - supplier regulator@11 not ready

[    2.525503] platform regulator@1: probe deferral - supplier 4-002d not ready

[    2.533141] platform regulator@3: probe deferral - supplier regulator@101 not ready

[    2.540856] platform regulator@5: probe deferral - supplier regulator@101 not ready

[    2.548589] platform regulator@6: probe deferral - supplier regulator@101 not ready

[    2.556316] platform regulator@7: probe deferral - supplier regulator@101 not ready

[    2.564041] platform regulator@8: probe deferral - supplier regulator@101 not ready

[    2.571743] platform regulator@9: probe deferral - supplier regulator@101 not ready

[    2.579463] platform regulator@10: probe deferral - supplier regulator@101 not ready

[    2.587273] platform regulator@11: probe deferral - supplier regulator@101 not ready

[    2.595088] platform regulator@12: probe deferral - supplier regulator@104 not ready

[    2.603837] platform regulator@102: probe deferral - supplier regulator@104 not ready

[    2.611726] platform regulator@103: probe deferral - supplier regulator@104 not ready

[    2.620137] platform 3000.pcie: probe deferral - supplier regulator@5 not ready


Cheers
Jon

-- 
nvpublic