Re: [PATCH v1 0/5] Enable fw_devlink=on by default

[Jon Hunter <jonathanh@nvidia.com>]

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