lkml.org 
[lkml]   [2021]   [Feb]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH v1 0/2] Make fw_devlink=on more forgiving
    On Mon, Feb 1, 2021 at 2:40 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
    >
    > Hi Saravana,
    >
    > On Sat, Jan 30, 2021 at 5:09 AM Saravana Kannan <saravanak@google.com> wrote:
    > > On Fri, Jan 29, 2021 at 8:03 PM Saravana Kannan <saravanak@google.com> 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?
    > >
    > > Marek, Geert, Tudor,
    > >
    > > Forgot to say that this will probably fix your issues only in a static
    > > kernel. So please try this with a static kernel. If you can also try
    > > and confirm that this does not fix the issue for a modular kernel,
    > > that'd be good too.
    >
    > Thanks for your series!
    >
    > For the modular case, this series has no impact, as expected (i.e. fails
    > to boot, no I/O devices probed).
    > With modules disabled, both r8a7791/koelsch and r8a77951/salvator-xs
    > seem to boot fine, except for one issue on koelsch:

    Thanks a lot for testing the series!

    Regarding the koelsch issue, do you not see it with your OF_POPULATED
    fix for rcar-sysc driver? But only see if you revert it and use this
    series?

    >
    > dmesg:
    >
    > +i2c-demux-pinctrl i2c-12: failed to setup demux-adapter 0 (-19)
    > +i2c-demux-pinctrl i2c-13: failed to setup demux-adapter 0 (-19)
    > +i2c-demux-pinctrl i2c-14: failed to setup demux-adapter 0 (-19)
    >
    > - #0: rsnd-dai.0-ak4642-hifi
    > + No soundcards found.
    >
    > regulator_summary:
    >
    > -13-0050-vcc 0 0mA 0mV 0mV
    > -13-0039-dvdd-3v 1 0mA 0mV 0mV
    > -13-0039-bgvdd 1 0mA 0mV 0mV
    > -13-0039-pvdd 1 0mA 0mV 0mV
    > -13-0039-dvdd 1 0mA 0mV 0mV
    > -13-0039-avdd 1 0mA 0mV 0mV
    >
    > pm_genpd_summary:
    >
    > -/devices/platform/soc/e6518000.i2c suspended 0
    > -/devices/platform/soc/e6530000.i2c suspended 0
    > -/devices/platform/soc/e6520000.i2c suspended 0
    >
    > These are all symptoms of the same issue: i2c buses and devices are not
    > probed, due to the use of the i2c demuxer.
    > I guess the fw_devlink tracker doesn't consider "i2c-parent" links?

    No, it doesn't parse "i2c-parent". Ugh... looked at it. It's going to
    be a problem to parse because it requires the parents to be disbled in
    DT and then fixes them up during run time. fw_devlink can handle DT
    overlay changing a specific node, but the problem is that the consumer
    DT node doesn't get changed. So the i2c-parent will first be parsed,
    fw_devlink will notice they are disabled, so it'll ignore them. Then
    those nodes are enabled, but the i2c-parent isn't reparsed because the
    consumer isn't updated.

    > Note that I only tested this on R-Car Gen2 and Gen3.
    > I did not test this on Renesas SH/R-Mobile or RZ/A SoCs.

    Thanks for any testing you can do :)

    So overall, this series seems to be helping, but doesn't cover 100% of
    the cases. So I suppose this is still a useful series. I'll be happy
    to take any Tested-by or Reviewed-by.

    -Saravana

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