Hi, Saravana, On 2/2/21 6:33 AM, Saravana Kannan wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > This patch series solves two general issues with fw_devlink=on > > Patch 1/3 and 3/3 addresses the issue of firmware nodes that look like > they'll have struct devices created for them, but will never actually > have struct devices added for them. For example, DT nodes with a > compatible property that don't have devices added for them. > > Patch 2/2 address (for static kernels) the issue of optional suppliers > that'll never have a driver registered for them. So, if the device could > have probed with fw_devlink=permissive with a static kernel, this patch > should allow those devices to probe with a fw_devlink=on. This doesn't > solve it for the case where modules are enabled because there's no way > to tell if a driver will never be registered or it's just about to be > registered. I have some other ideas for that, but it'll have to come > later thinking about it a bit. > > Marek, Geert, > > I don't expect v2 to do any better for your cases. > > This series not making any difference for Marek is still a mystery to > me. I guess one of the consumers doesn't take too well to its probe (and > it's consumers' probe) being delayed till late_initcall(). I'll continue > looking into it. > > Marc, > > This v2 should do better than v1 with gpiolib stub driver reverted. I > forgot to take care of the case where more suppliers could link after I > went and deleted some of the links. v2 handles that now. > > Tudor, > > You should still make the clock driver fix (because it's a bug), but I > think this series will fix your issue too (even without the clock driver > fix). Can you please give this a shot? > Did the following tests (using sama5_defconfig and at91-sama5d2_xplained.dts): 1/ modular kernel with your v2 on top of next-20210202, and without the clock driver fix: the problem persists. 2/ static kernel with your v2 on top of next-20210202, and without the clock driver fix: the problem persists. Comparing to the previous test, I see that the links to pmc are dropped. I can see the following only with early printk enabled: platform fc008000.serial: Dropping the link to f0014000.pmc But later on, the serial still gets deferred waiting for the dma controller this time: platform f8020000.serial: probe deferral - supplier f0010000.dma-controller not ready I'll check what happens in the dma-controller. 3/ modular kernel with your v2 and the clock driver fix on top of next-20210202: I can boot the board and I have access to the console. I still have some probe deferrals that I need to check: root@sama5d2-xplained-sd:~# dmesg | grep -i defer [ 4.335625] platform b0000000.sdio-host: probe deferral - wait for supplier pmic@5b [ 4.474559] platform fc030000.adc: probe deferral - wait for supplier pmic@5b [ 4.884315] calling deferred_probe_initcall+0x0/0xd8 @ 1 [ 4.889206] platform fc030000.adc: probe deferral - wait for supplier pmic@5b [ 5.139447] initcall deferred_probe_initcall+0x0/0xd8 returned 0 after 245132 usecs root@sama5d2-xplained-sd:~# dmesg | grep -i linked [ 4.916342] platform fc030000.adc: Linked as a consumer to 0-005b [ 4.921298] platform b0000000.sdio-host: Linked as a consumer to 0-005b [ 4.926817] i2c 0-005b: Linked as a sync state only consumer to fc038000.pinctrl [ 4.990246] platform act8945a-charger: Linked as a consumer to fc038000.pinctrl [ 5.078488] at24 1-0054: Linked as a consumer to regulator.0 [ 5.111533] at91-sama5d2_adc fc030000.adc: Linked as a consumer to regulator.5 [ 5.118969] sdhci-at91 b0000000.sdio-host: Linked as a consumer to regulator.3 root@sama5d2-xplained-sd:~# dmesg | grep -i drop [ 5.014026] act8945a 0-005b: Dropping the link to fc038000.pinctrl 4/ static kernel with your v2 and the clock driver fix on top of next-20210202: I can boot the board and I have access to the console. The probe deferrals are the same as in test 3/. Cheers, ta
