From: Marc Zyngier <maz@kernel.org>
To: Saravana Kannan <saravanak@google.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Tudor Ambarus <Tudor.Ambarus@microchip.com>,
Linus Walleij <linus.walleij@linaro.org>,
Bartosz Golaszewski <bgolaszewski@baylibre.com>,
linux-kernel@vger.kernel.org, kernel-team@android.com
Subject: Re: [PATCH v1 0/2] Make fw_devlink=on more forgiving
Date: Mon, 01 Feb 2021 14:42:57 +0000 [thread overview]
Message-ID: <5419284dc9008907ccc36f1df5110356@kernel.org> (raw)
In-Reply-To: <20210130040344.2807439-1-saravanak@google.com>
Hi Saravana,
Thanks for this.
On 2021-01-30 04:03, Saravana Kannan wrote:
> This patch series solves two general issues with fw_devlink=on
>
> Patch 1/2 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.
>
> These two patches might remove the need for several other patches that
> went in as fixes for commit e590474768f1 ("driver core: Set
> fw_devlink=on by default"), but I think all those fixes are good
> changes. So I think we should leave those in.
>
> Marek, Geert,
>
> Can you try this series on a static kernel with your OF_POPULATED
> changes reverted? I just want to make sure these patches can identify
> and fix those cases.
>
> 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?
>
> Marc,
>
> Can you try this series with the gpiolib fix reverted please? I'm
> pretty
> sure this will fix that case.
Almost. The board boots and behaves as expected, except that a few
devices
such as the SD card are unusable (probably because the corresponding
suppliers are still not identified as being available:
# find /sys -name waiting_for_supplier| xargs grep .| grep -v :0
/sys/devices/platform/vcc3v0-sd/waiting_for_supplier:1
/sys/devices/platform/vbus-typec/waiting_for_supplier:1
/sys/devices/platform/sdio-pwrseq/waiting_for_supplier:1
/sys/devices/platform/ir-receiver/waiting_for_supplier:1
With the GPIO patch that I reverted, no device is waiting for
a supplier.
Let me know if I can further help.
M.
--
Jazz is not dead. It just smells funny...
prev parent reply other threads:[~2021-02-01 14:46 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-30 4:03 Saravana Kannan
2021-01-30 4:03 ` [PATCH v1 1/2] driver core: fw_devlink: Detect supplier devices that will never be added Saravana Kannan
2021-02-01 14:29 ` Rafael J. Wysocki
2021-01-30 4:03 ` [PATCH v1 2/2] driver core: fw_devlink: Handle missing drivers for optional suppliers Saravana Kannan
2021-02-01 10:31 ` Geert Uytterhoeven
2021-02-01 20:48 ` Saravana Kannan
2021-02-02 8:49 ` Geert Uytterhoeven
2021-02-02 19:33 ` Saravana Kannan
2021-03-10 2:08 ` [gpiolib] 4731210c09: BUG:kernel_NULL_pointer_dereference,address kernel test robot
2021-01-30 4:08 ` [PATCH v1 0/2] Make fw_devlink=on more forgiving Saravana Kannan
2021-02-01 8:05 ` Marek Szyprowski
2021-02-01 9:02 ` Saravana Kannan
2021-02-02 8:12 ` Marek Szyprowski
2021-02-02 8:33 ` Saravana Kannan
2021-02-01 10:39 ` Geert Uytterhoeven
2021-02-02 3:00 ` Saravana Kannan
2021-02-02 7:55 ` Geert Uytterhoeven
2021-02-02 8:20 ` Saravana Kannan
2021-01-31 21:37 ` Saravana Kannan
2021-02-01 14:42 ` Marc Zyngier [this message]
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=5419284dc9008907ccc36f1df5110356@kernel.org \
--to=maz@kernel.org \
--cc=Tudor.Ambarus@microchip.com \
--cc=bgolaszewski@baylibre.com \
--cc=geert@linux-m68k.org \
--cc=gregkh@linuxfoundation.org \
--cc=kernel-team@android.com \
--cc=linus.walleij@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=rafael@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
all inboxes | Powered by JetHome®