On 13/01/2021 11:11, Marc Zyngier wrote:

On 2021-01-07 20:05, Greg Kroah-Hartman wrote:

quoted

On Thu, Dec 17, 2020 at 07:16:58PM -0800, Saravana Kannan wrote:

quoted

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