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
