lkml.org 
[lkml]   [2021]   [Feb]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v1 0/2] Make fw_devlink=on more forgiving
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...

\
 
 \ /
  Last update: 2021-02-01 15:47    [W:0.204 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site