mbox series

[RFC,v1,0/9] deferred_probe_timeout logic clean up

Message ID 20220526081550.1089805-1-saravanak@google.com
Headers show
Series deferred_probe_timeout logic clean up | expand

Message

Saravana Kannan May 26, 2022, 8:15 a.m. UTC
This series is based on linux-next + these 2 small patches applies on top:
https://lore.kernel.org/lkml/20220526034609.480766-1-saravanak@google.com/

A lot of the deferred_probe_timeout logic is redundant with
fw_devlink=on.  Also, enabling deferred_probe_timeout by default breaks
a few cases.

This series tries to delete the redundant logic, simplify the frameworks
that use driver_deferred_probe_check_state(), enable
deferred_probe_timeout=10 by default, and fixes the nfsroot failure
case.

Patches 1 to 3 are fairly straightforward and can probably be applied
right away.

Patches 4 to 9 are related and are the complicated bits of this series.

Patch 8 is where someone with more knowledge of the IP auto config code
can help rewrite the patch to limit the scope of the workaround by
running the work around only if IP auto config fails the first time
around. But it's also something that can be optimized in the future
because it's already limited to the case where IP auto config is enabled
using the kernel commandline.

Yoshihiro/Geert,

If you can test this patch series and confirm that the NFS root case
works, I'd really appreciate that.

Cc: Mark Brown <broonie@kernel.org>
Cc: Rob Herring <robh@kernel.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Cc: John Stultz <jstultz@google.com>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>

Saravana Kannan (9):
  PM: domains: Delete usage of driver_deferred_probe_check_state()
  pinctrl: devicetree: Delete usage of driver_deferred_probe_check_state()
  net: mdio: Delete usage of driver_deferred_probe_check_state()
  Revert "driver core: Set default deferred_probe_timeout back to 0."
  driver core: Set fw_devlink.strict=1 by default
  iommu/of: Delete usage of driver_deferred_probe_check_state()
  driver core: Add fw_devlink_unblock_may_probe() helper function
  net: ipconfig: Force fw_devlink to unblock any devices that might probe
  driver core: Delete driver_deferred_probe_check_state()

 drivers/base/base.h            |  1 +
 drivers/base/core.c            | 60 +++++++++++++++++++++++++++++++++-
 drivers/base/dd.c              | 37 ++++-----------------
 drivers/base/power/domain.c    |  2 +-
 drivers/iommu/of_iommu.c       |  2 +-
 drivers/net/mdio/fwnode_mdio.c |  4 +--
 drivers/pinctrl/devicetree.c   |  2 +-
 include/linux/device/driver.h  |  1 -
 include/linux/fwnode.h         |  2 ++
 net/ipv4/ipconfig.c            |  2 ++
 10 files changed, 74 insertions(+), 39 deletions(-)

Comments

Sebastian Andrzej Siewior May 30, 2022, 8:49 a.m. UTC | #1
On 2022-05-26 01:15:39 [-0700], Saravana Kannan wrote:
> Yoshihiro/Geert,
Hi Saravana,

> If you can test this patch series and confirm that the NFS root case
> works, I'd really appreciate that.

The two patches you sent earlier, plus this series, plus

diff --git a/drivers/base/core.c b/drivers/base/core.c
index 7ff7fbb006431..829d9b1f7403f 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -1697,8 +1697,6 @@ static int fw_devlink_may_probe(struct device *dev, void *data)
  */
 void __init fw_devlink_unblock_may_probe(void)
 {
-	struct device_link *link, *ln;
-
 	if (!fw_devlink_flags || fw_devlink_is_permissive())
 		return;
 
and it compiles + boots without a delay.

Sebastian
Geert Uytterhoeven May 30, 2022, 9:12 a.m. UTC | #2
Hi Saravana,

On Thu, May 26, 2022 at 10:16 AM Saravana Kannan <saravanak@google.com> wrote:
> This reverts commit 11f7e7ef553b6b93ac1aa74a3c2011b9cc8aeb61.

scripts/chdeckpatch.pl says:

    WARNING: Unknown commit id
'11f7e7ef553b6b93ac1aa74a3c2011b9cc8aeb61', maybe rebased or not
pulled?

I assume this is your local copy of
https://lore.kernel.org/r/20220526034609.480766-3-saravanak@google.com?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
Geert Uytterhoeven May 30, 2022, 9:38 a.m. UTC | #3
Hi Saravana,

On Thu, May 26, 2022 at 10:15 AM Saravana Kannan <saravanak@google.com> wrote:
> This series is based on linux-next + these 2 small patches applies on top:
> https://lore.kernel.org/lkml/20220526034609.480766-1-saravanak@google.com/
>
> A lot of the deferred_probe_timeout logic is redundant with
> fw_devlink=on.  Also, enabling deferred_probe_timeout by default breaks
> a few cases.
>
> This series tries to delete the redundant logic, simplify the frameworks
> that use driver_deferred_probe_check_state(), enable
> deferred_probe_timeout=10 by default, and fixes the nfsroot failure
> case.
>
> Patches 1 to 3 are fairly straightforward and can probably be applied
> right away.
>
> Patches 4 to 9 are related and are the complicated bits of this series.
>
> Patch 8 is where someone with more knowledge of the IP auto config code
> can help rewrite the patch to limit the scope of the workaround by
> running the work around only if IP auto config fails the first time
> around. But it's also something that can be optimized in the future
> because it's already limited to the case where IP auto config is enabled
> using the kernel commandline.

Thanks for your series!

> Yoshihiro/Geert,
>
> If you can test this patch series and confirm that the NFS root case
> works, I'd really appreciate that.

On Salvator-XS, Micrel KSZ9031 Gigabit PHY probe is no longer delayed
by 9s after applying the two earlier patches, and the same is true
after applying this series on top.
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>

I will do testing on more boards, but that may take a while, as we're
in the middle of the merge window.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
Andy Shevchenko May 30, 2022, 9:46 a.m. UTC | #4
On Thu, May 26, 2022 at 1:22 PM Saravana Kannan <saravanak@google.com> wrote:
>
> This function can be used during the kernel boot sequence to forcefully
> override fw_devlink=on and unblock the probing of all devices that have
> a driver.
>
> It's mainly meant to be called from late_initcall() or
> late_initcall_sync() where a device needs to probe before the kernel can
> mount rootfs.

...

> diff --git a/include/linux/fwnode.h b/include/linux/fwnode.h
> index 9a81c4410b9f..0770edda7068 100644
> --- a/include/linux/fwnode.h
> +++ b/include/linux/fwnode.h
> @@ -13,6 +13,7 @@
>  #include <linux/list.h>
>  #include <linux/bits.h>
>  #include <linux/err.h>
> +#include <linux/init.h>
>
>  struct fwnode_operations;
>  struct device;
> @@ -199,5 +200,6 @@ extern bool fw_devlink_is_strict(void);
>  int fwnode_link_add(struct fwnode_handle *con, struct fwnode_handle *sup);
>  void fwnode_links_purge(struct fwnode_handle *fwnode);
>  void fw_devlink_purge_absent_suppliers(struct fwnode_handle *fwnode);
> +void __init fw_devlink_unblock_may_probe(void);

I don't think you need init.h and __init here. Important is that you
have it in the C-file. Am I wrong?
Saravana Kannan June 5, 2022, 3:18 a.m. UTC | #5
On Mon, May 30, 2022 at 2:13 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Saravana,
>
> On Thu, May 26, 2022 at 10:16 AM Saravana Kannan <saravanak@google.com> wrote:
> > This reverts commit 11f7e7ef553b6b93ac1aa74a3c2011b9cc8aeb61.
>
> scripts/chdeckpatch.pl says:
>
>     WARNING: Unknown commit id
> '11f7e7ef553b6b93ac1aa74a3c2011b9cc8aeb61', maybe rebased or not
> pulled?
>
> I assume this is your local copy of
> https://lore.kernel.org/r/20220526034609.480766-3-saravanak@google.com?

I somehow missed all your replies and noticed it just now.

That commit should be based on driver-core-next.

-Saravana

>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds
>
> --
> To unsubscribe from this group and stop receiving emails from it, send an email to kernel-team+unsubscribe@android.com.
>
Saravana Kannan June 5, 2022, 3:45 a.m. UTC | #6
On Mon, May 30, 2022 at 1:49 AM Sebastian Andrzej Siewior
<bigeasy@linutronix.de> wrote:
>
> On 2022-05-26 01:15:39 [-0700], Saravana Kannan wrote:
> > Yoshihiro/Geert,
> Hi Saravana,
>
> > If you can test this patch series and confirm that the NFS root case
> > works, I'd really appreciate that.
>
> The two patches you sent earlier, plus this series, plus
>
> diff --git a/drivers/base/core.c b/drivers/base/core.c
> index 7ff7fbb006431..829d9b1f7403f 100644
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -1697,8 +1697,6 @@ static int fw_devlink_may_probe(struct device *dev, void *data)
>   */
>  void __init fw_devlink_unblock_may_probe(void)
>  {
> -       struct device_link *link, *ln;
> -
>         if (!fw_devlink_flags || fw_devlink_is_permissive())
>                 return;
>
> and it compiles + boots without a delay.

Thanks for testing! I missed your reply until now and I ended up
sending out a v2 a few days back. That's a much better series IMO
because it only temporarily ignores dependencies and only when NFS
root mounting might not work. If you can test that too (and it
shouldn't have the useless variable), I'd appreciate it.

-Saravana
Saravana Kannan June 5, 2022, 3:47 a.m. UTC | #7
On Mon, May 30, 2022 at 2:38 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Saravana,
>
> On Thu, May 26, 2022 at 10:15 AM Saravana Kannan <saravanak@google.com> wrote:
> > This series is based on linux-next + these 2 small patches applies on top:
> > https://lore.kernel.org/lkml/20220526034609.480766-1-saravanak@google.com/
> >
> > A lot of the deferred_probe_timeout logic is redundant with
> > fw_devlink=on.  Also, enabling deferred_probe_timeout by default breaks
> > a few cases.
> >
> > This series tries to delete the redundant logic, simplify the frameworks
> > that use driver_deferred_probe_check_state(), enable
> > deferred_probe_timeout=10 by default, and fixes the nfsroot failure
> > case.
> >
> > Patches 1 to 3 are fairly straightforward and can probably be applied
> > right away.
> >
> > Patches 4 to 9 are related and are the complicated bits of this series.
> >
> > Patch 8 is where someone with more knowledge of the IP auto config code
> > can help rewrite the patch to limit the scope of the workaround by
> > running the work around only if IP auto config fails the first time
> > around. But it's also something that can be optimized in the future
> > because it's already limited to the case where IP auto config is enabled
> > using the kernel commandline.
>
> Thanks for your series!
>
> > Yoshihiro/Geert,
> >
> > If you can test this patch series and confirm that the NFS root case
> > works, I'd really appreciate that.
>
> On Salvator-XS, Micrel KSZ9031 Gigabit PHY probe is no longer delayed
> by 9s after applying the two earlier patches, and the same is true
> after applying this series on top.
> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
>
> I will do testing on more boards, but that may take a while, as we're
> in the middle of the merge window.

Thanks for testing. I missed your email until now. I sent out a v2
series a few days back and that's a much better solution than v1. If
you can test that series instead, that'd be nice.

-Saravana
Saravana Kannan June 5, 2022, 4:12 a.m. UTC | #8
On Sat, Jun 4, 2022 at 8:18 PM Saravana Kannan <saravanak@google.com> wrote:
>
> On Mon, May 30, 2022 at 2:13 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> >
> > Hi Saravana,
> >
> > On Thu, May 26, 2022 at 10:16 AM Saravana Kannan <saravanak@google.com> wrote:
> > > This reverts commit 11f7e7ef553b6b93ac1aa74a3c2011b9cc8aeb61.
> >
> > scripts/chdeckpatch.pl says:
> >
> >     WARNING: Unknown commit id
> > '11f7e7ef553b6b93ac1aa74a3c2011b9cc8aeb61', maybe rebased or not
> > pulled?
> >
> > I assume this is your local copy of
> > https://lore.kernel.org/r/20220526034609.480766-3-saravanak@google.com?
>
> I somehow missed all your replies and noticed it just now.
>
> That commit should be based on driver-core-next.

My bad, it was indeed a local commit, but it's one I had already sent
to LKML. It's one of the 2 patches I asked to pull-in in the cover
letter. I'll fix this once I get some tests/reviews on this series or
if I need to send out a v3 series before that.

-Saravana