From: <Tudor.Ambarus@microchip.com>
To: <saravanak@google.com>, <gregkh@linuxfoundation.org>,
<rafael@kernel.org>, <m.szyprowski@samsung.com>,
<geert@linux-m68k.org>, <maz@kernel.org>,
<linus.walleij@linaro.org>, <bgolaszewski@baylibre.com>,
<martin@kaiser.cx>, <robh+dt@kernel.org>,
<frowand.list@gmail.com>, <lenb@kernel.org>
Cc: <linux-kernel@vger.kernel.org>, <devicetree@vger.kernel.org>,
<linux-acpi@vger.kernel.org>, <kernel-team@android.com>
Subject: Re: [PATCH v2 0/3] Make fw_devlink=on more forgiving
Date: Tue, 2 Feb 2021 16:52:53 +0000 [thread overview]
Message-ID: <cb6edbd0-346b-0674-5b5c-7ce3a437736d@microchip.com> (raw)
In-Reply-To: <20210202043345.3778765-1-saravanak@google.com>
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
next prev parent reply other threads:[~2021-02-02 16:56 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-02 4:33 [PATCH v2 0/3] Make fw_devlink=on more forgiving Saravana Kannan
2021-02-02 4:33 ` [PATCH v2 1/3] driver core: fw_devlink: Detect supplier devices that will never be added Saravana Kannan
2021-02-02 14:12 ` Rafael J. Wysocki
2021-02-02 19:35 ` Saravana Kannan
2021-02-02 4:33 ` [PATCH v2 2/3] driver core: fw_devlink: Handle missing drivers for optional suppliers Saravana Kannan
2021-02-02 14:34 ` Rafael J. Wysocki
2021-02-02 19:46 ` Saravana Kannan
2021-02-04 18:41 ` Rafael J. Wysocki
2021-02-04 19:03 ` Saravana Kannan
2021-02-02 4:33 ` [PATCH v2 3/3] of: property: Don't add links to absent suppliers Saravana Kannan
2021-02-04 19:17 ` Saravana Kannan
2021-02-02 16:52 ` Tudor.Ambarus [this message]
2021-02-02 17:41 ` [PATCH v2 0/3] Make fw_devlink=on more forgiving Rob Herring
2021-02-02 18:28 ` Saravana Kannan
2021-02-02 21:22 ` Martin Kaiser
2021-02-02 22:43 ` Saravana Kannan
2021-02-03 7:54 ` Geert Uytterhoeven
2021-02-03 8:11 ` Saravana Kannan
2021-02-03 8:15 ` Geert Uytterhoeven
2021-02-03 22:02 ` Martin Kaiser
2021-02-03 21:57 ` Martin Kaiser
2021-02-03 22:03 ` Saravana Kannan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cb6edbd0-346b-0674-5b5c-7ce3a437736d@microchip.com \
--to=tudor.ambarus@microchip.com \
--cc=bgolaszewski@baylibre.com \
--cc=devicetree@vger.kernel.org \
--cc=frowand.list@gmail.com \
--cc=geert@linux-m68k.org \
--cc=gregkh@linuxfoundation.org \
--cc=kernel-team@android.com \
--cc=lenb@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=martin@kaiser.cx \
--cc=maz@kernel.org \
--cc=rafael@kernel.org \
--cc=robh+dt@kernel.org \
--cc=saravanak@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox