Re: [PATCH v2 0/3] Make fw_devlink=on more forgiving

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