[PATCH v1 0/3] Clean up and fix error handling in mdio_mux_init()

[PATCH v1 0/3] Clean up and fix error handling in mdio_mux_init()

[Saravana Kannan]

This patch series was started due to -EPROBE_DEFER not being handled
correctly in mdio_mux_init() and causing issues [1]. While at it, I also
did some more error handling fixes and clean ups. The -EPROBE_DEFER fix is
the last patch.

Ideally, in the last patch we'd treat any error similar to -EPROBE_DEFER
but I'm not sure if it'll break any board/platforms where some child
mdiobus never successfully registers. If we treated all errors similar to
-EPROBE_DEFER, then none of the child mdiobus will work and that might be a
regression. If people are sure this is not a real case, then I can fix up
the last patch to always fail the entire mdio-mux init if any of the child
mdiobus registration fails.

Cc: Marc Zyngier <maz@kernel.org>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Kevin Hilman <khilman@baylibre.com>
[1] - https://lore.kernel.org/lkml/CAGETcx95kHrv8wA-O+-JtfH7H9biJEGJtijuPVN0V5dUKUAB3A@mail.gmail.com/#t

Saravana Kannan (3):
  net: mdio-mux: Delete unnecessary devm_kfree
  net: mdio-mux: Don't ignore memory allocation errors
  net: mdio-mux: Handle -EPROBE_DEFER correctly

 drivers/net/mdio/mdio-mux.c | 37 ++++++++++++++++++++++++-------------
 1 file changed, 24 insertions(+), 13 deletions(-)

-- 
2.32.0.554.ge1b32706d8-goog

[PATCH v1 1/3] net: mdio-mux: Delete unnecessary devm_kfree

[Saravana Kannan]

The whole point of devm_* APIs is that you don't have to undo them if you
are returning an error that's going to get propagated out of a probe()
function. So delete unnecessary devm_kfree() call in the error return path.

Signed-off-by: Saravana Kannan <saravanak@google.com>
---
 drivers/net/mdio/mdio-mux.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/mdio/mdio-mux.c b/drivers/net/mdio/mdio-mux.c
index 110e4ee85785..5b37284f54d6 100644
--- a/drivers/net/mdio/mdio-mux.c
+++ b/drivers/net/mdio/mdio-mux.c
@@ -181,7 +181,6 @@ int mdio_mux_init(struct device *dev,
 	}
 
 	dev_err(dev, "Error: No acceptable child buses found\n");
-	devm_kfree(dev, pb);
 err_pb_kz:
 	put_device(&parent_bus->dev);
 err_parent_bus:
-- 
2.32.0.554.ge1b32706d8-goog

[PATCH v1 2/3] net: mdio-mux: Don't ignore memory allocation errors

[Saravana Kannan]

If we are seeing memory allocation errors, don't try to continue
registering child mdiobus devices. It's unlikely they'll succeed.

Signed-off-by: Saravana Kannan <saravanak@google.com>
---
 drivers/net/mdio/mdio-mux.c | 28 ++++++++++++++++++----------
 1 file changed, 18 insertions(+), 10 deletions(-)

diff --git a/drivers/net/mdio/mdio-mux.c b/drivers/net/mdio/mdio-mux.c
index 5b37284f54d6..13035e2685c4 100644
--- a/drivers/net/mdio/mdio-mux.c
+++ b/drivers/net/mdio/mdio-mux.c
@@ -82,6 +82,17 @@ static int mdio_mux_write(struct mii_bus *bus, int phy_id,
 
 static int parent_count;
 
+static void mdio_mux_uninit_children(struct mdio_mux_parent_bus *pb)
+{
+	struct mdio_mux_child_bus *cb = pb->children;
+
+	while (cb) {
+		mdiobus_unregister(cb->mii_bus);
+		mdiobus_free(cb->mii_bus);
+		cb = cb->next;
+	}
+}
+
 int mdio_mux_init(struct device *dev,
 		  struct device_node *mux_node,
 		  int (*switch_fn)(int cur, int desired, void *data),
@@ -144,7 +155,7 @@ int mdio_mux_init(struct device *dev,
 		cb = devm_kzalloc(dev, sizeof(*cb), GFP_KERNEL);
 		if (!cb) {
 			ret_val = -ENOMEM;
-			continue;
+			goto err_loop;
 		}
 		cb->bus_number = v;
 		cb->parent = pb;
@@ -152,8 +163,7 @@ int mdio_mux_init(struct device *dev,
 		cb->mii_bus = mdiobus_alloc();
 		if (!cb->mii_bus) {
 			ret_val = -ENOMEM;
-			devm_kfree(dev, cb);
-			continue;
+			goto err_loop;
 		}
 		cb->mii_bus->priv = cb;
 
@@ -181,6 +191,10 @@ int mdio_mux_init(struct device *dev,
 	}
 
 	dev_err(dev, "Error: No acceptable child buses found\n");
+
+err_loop:
+	mdio_mux_uninit_children(pb);
+	of_node_put(child_bus_node);
 err_pb_kz:
 	put_device(&parent_bus->dev);
 err_parent_bus:
@@ -192,14 +206,8 @@ EXPORT_SYMBOL_GPL(mdio_mux_init);
 void mdio_mux_uninit(void *mux_handle)
 {
 	struct mdio_mux_parent_bus *pb = mux_handle;
-	struct mdio_mux_child_bus *cb = pb->children;
-
-	while (cb) {
-		mdiobus_unregister(cb->mii_bus);
-		mdiobus_free(cb->mii_bus);
-		cb = cb->next;
-	}
 
+	mdio_mux_uninit_children(pb);
 	put_device(&pb->mii_bus->dev);
 }
 EXPORT_SYMBOL_GPL(mdio_mux_uninit);
-- 
2.32.0.554.ge1b32706d8-goog

[PATCH v1 3/3] net: mdio-mux: Handle -EPROBE_DEFER correctly

[Saravana Kannan]

When registering mdiobus children, if we get an -EPROBE_DEFER, we shouldn't
ignore it and continue registering the rest of the mdiobus children. This
would permanently prevent the deferring child mdiobus from working instead
of reattempting it in the future. So, if a child mdiobus needs to be
reattempted in the future, defer the entire mdio-mux initialization.

This fixes the issue where PHYs sitting under the mdio-mux aren't
initialized correctly if the PHY's interrupt controller is not yet ready
when the mdio-mux is being probed. Additional context in the link below.

Link: https://lore.kernel.org/lkml/CAGETcx95kHrv8wA-O+-JtfH7H9biJEGJtijuPVN0V5dUKUAB3A@mail.gmail.com/#t
Signed-off-by: Saravana Kannan <saravanak@google.com>
---
 drivers/net/mdio/mdio-mux.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/net/mdio/mdio-mux.c b/drivers/net/mdio/mdio-mux.c
index 13035e2685c4..ebd001f0eece 100644
--- a/drivers/net/mdio/mdio-mux.c
+++ b/drivers/net/mdio/mdio-mux.c
@@ -175,11 +175,15 @@ int mdio_mux_init(struct device *dev,
 		cb->mii_bus->write = mdio_mux_write;
 		r = of_mdiobus_register(cb->mii_bus, child_bus_node);
 		if (r) {
+			mdiobus_free(cb->mii_bus);
+			if (r == -EPROBE_DEFER) {
+				ret_val = r;
+				goto err_loop;
+			}
+			devm_kfree(dev, cb);
 			dev_err(dev,
 				"Error: Failed to register MDIO bus for child %pOF\n",
 				child_bus_node);
-			mdiobus_free(cb->mii_bus);
-			devm_kfree(dev, cb);
 		} else {
 			cb->next = pb->children;
 			pb->children = cb;
-- 
2.32.0.554.ge1b32706d8-goog

Re: [PATCH v1 0/3] Clean up and fix error handling in mdio_mux_init()

[Marc Zyngier]

Hi Saravana,

On Wed, 04 Aug 2021 22:43:29 +0100,
Saravana Kannan <saravanak@google.com> wrote:
> 
> This patch series was started due to -EPROBE_DEFER not being handled
> correctly in mdio_mux_init() and causing issues [1]. While at it, I also
> did some more error handling fixes and clean ups. The -EPROBE_DEFER fix is
> the last patch.
> 
> Ideally, in the last patch we'd treat any error similar to -EPROBE_DEFER
> but I'm not sure if it'll break any board/platforms where some child
> mdiobus never successfully registers. If we treated all errors similar to
> -EPROBE_DEFER, then none of the child mdiobus will work and that might be a
> regression. If people are sure this is not a real case, then I can fix up
> the last patch to always fail the entire mdio-mux init if any of the child
> mdiobus registration fails.
> 
> Cc: Marc Zyngier <maz@kernel.org>
> Cc: Neil Armstrong <narmstrong@baylibre.com>
> Cc: Kevin Hilman <khilman@baylibre.com>
> [1] - https://lore.kernel.org/lkml/CAGETcx95kHrv8wA-O+-JtfH7H9biJEGJtijuPVN0V5dUKUAB3A@mail.gmail.com/#t
> 
> Saravana Kannan (3):
>   net: mdio-mux: Delete unnecessary devm_kfree
>   net: mdio-mux: Don't ignore memory allocation errors
>   net: mdio-mux: Handle -EPROBE_DEFER correctly
> 
>  drivers/net/mdio/mdio-mux.c | 37 ++++++++++++++++++++++++-------------
>  1 file changed, 24 insertions(+), 13 deletions(-)

Thanks for this. I've just gave it a go on my test platform, and this
indeed addresses the issues I was seeing [1].

Acked-by: Marc Zyngier <maz@kernel.org>
Tested-by: Marc Zyngier <maz@kernel.org>

	M.

[1] https://lore.kernel.org/r/87im0m277h.wl-maz@kernel.org

-- 
Without deviation from the norm, progress is not possible.

Re: [PATCH v1 0/3] Clean up and fix error handling in mdio_mux_init()

[David Miller]

Please resubmit the cleanups targetting net-next and the bug fix targetting net.

Thank you.

Re: [PATCH v1 0/3] Clean up and fix error handling in mdio_mux_init()

[Kevin Hilman]

Marc Zyngier <maz@kernel.org> writes:

> Hi Saravana,
>
> On Wed, 04 Aug 2021 22:43:29 +0100,
> Saravana Kannan <saravanak@google.com> wrote:
>> 
>> This patch series was started due to -EPROBE_DEFER not being handled
>> correctly in mdio_mux_init() and causing issues [1]. While at it, I also
>> did some more error handling fixes and clean ups. The -EPROBE_DEFER fix is
>> the last patch.
>> 
>> Ideally, in the last patch we'd treat any error similar to -EPROBE_DEFER
>> but I'm not sure if it'll break any board/platforms where some child
>> mdiobus never successfully registers. If we treated all errors similar to
>> -EPROBE_DEFER, then none of the child mdiobus will work and that might be a
>> regression. If people are sure this is not a real case, then I can fix up
>> the last patch to always fail the entire mdio-mux init if any of the child
>> mdiobus registration fails.
>> 
>> Cc: Marc Zyngier <maz@kernel.org>
>> Cc: Neil Armstrong <narmstrong@baylibre.com>
>> Cc: Kevin Hilman <khilman@baylibre.com>
>> [1] - https://lore.kernel.org/lkml/CAGETcx95kHrv8wA-O+-JtfH7H9biJEGJtijuPVN0V5dUKUAB3A@mail.gmail.com/#t
>> 
>> Saravana Kannan (3):
>>   net: mdio-mux: Delete unnecessary devm_kfree
>>   net: mdio-mux: Don't ignore memory allocation errors
>>   net: mdio-mux: Handle -EPROBE_DEFER correctly
>> 
>>  drivers/net/mdio/mdio-mux.c | 37 ++++++++++++++++++++++++-------------
>>  1 file changed, 24 insertions(+), 13 deletions(-)
>
> Thanks for this. I've just gave it a go on my test platform, and this
> indeed addresses the issues I was seeing [1].
>
> Acked-by: Marc Zyngier <maz@kernel.org>
> Tested-by: Marc Zyngier <maz@kernel.org>

I wasn't seeing the same issues as Marc, but am heavily using everything
as modules on a few platforms using this code, and I'm not seeing any
regressions.

Thanks Saravana for finding the root cause here.

Acked-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>

Kevin

Re: [PATCH v1 0/3] Clean up and fix error handling in mdio_mux_init()

[Kevin Hilman]

On Thu, Aug 5, 2021 at 11:36 AM Kevin Hilman <khilman@baylibre.com> wrote:
>
> Marc Zyngier <maz@kernel.org> writes:
>
> > Hi Saravana,
> >
> > On Wed, 04 Aug 2021 22:43:29 +0100,
> > Saravana Kannan <saravanak@google.com> wrote:
> >>
> >> This patch series was started due to -EPROBE_DEFER not being handled
> >> correctly in mdio_mux_init() and causing issues [1]. While at it, I also
> >> did some more error handling fixes and clean ups. The -EPROBE_DEFER fix is
> >> the last patch.
> >>
> >> Ideally, in the last patch we'd treat any error similar to -EPROBE_DEFER
> >> but I'm not sure if it'll break any board/platforms where some child
> >> mdiobus never successfully registers. If we treated all errors similar to
> >> -EPROBE_DEFER, then none of the child mdiobus will work and that might be a
> >> regression. If people are sure this is not a real case, then I can fix up
> >> the last patch to always fail the entire mdio-mux init if any of the child
> >> mdiobus registration fails.
> >>
> >> Cc: Marc Zyngier <maz@kernel.org>
> >> Cc: Neil Armstrong <narmstrong@baylibre.com>
> >> Cc: Kevin Hilman <khilman@baylibre.com>
> >> [1] - https://lore.kernel.org/lkml/CAGETcx95kHrv8wA-O+-JtfH7H9biJEGJtijuPVN0V5dUKUAB3A@mail.gmail.com/#t
> >>
> >> Saravana Kannan (3):
> >>   net: mdio-mux: Delete unnecessary devm_kfree
> >>   net: mdio-mux: Don't ignore memory allocation errors
> >>   net: mdio-mux: Handle -EPROBE_DEFER correctly
> >>
> >>  drivers/net/mdio/mdio-mux.c | 37 ++++++++++++++++++++++++-------------
> >>  1 file changed, 24 insertions(+), 13 deletions(-)
> >
> > Thanks for this. I've just gave it a go on my test platform, and this
> > indeed addresses the issues I was seeing [1].
> >
> > Acked-by: Marc Zyngier <maz@kernel.org>
> > Tested-by: Marc Zyngier <maz@kernel.org>
>
> I wasn't seeing the same issues as Marc, but am heavily using everything
> as modules on a few platforms using this code, and I'm not seeing any
> regressions.
>
> Thanks Saravana for finding the root cause here.
>
> Acked-by: Kevin Hilman <khilman@baylibre.com>
> Signed-off-by: Kevin Hilman <khilman@baylibre.com>

Oops, that should not be a SoB, but rather:

Tested-by: Kevin Hilman <khilman@baylibre.com>

Re: [PATCH v1 0/3] Clean up and fix error handling in mdio_mux_init()

[Saravana Kannan]

On Thu, Aug 5, 2021 at 11:38 AM Kevin Hilman <khilman@baylibre.com> wrote:
>
> On Thu, Aug 5, 2021 at 11:36 AM Kevin Hilman <khilman@baylibre.com> wrote:
> >
> > Marc Zyngier <maz@kernel.org> writes:
> >
> > > Hi Saravana,
> > >
> > > On Wed, 04 Aug 2021 22:43:29 +0100,
> > > Saravana Kannan <saravanak@google.com> wrote:
> > >>
> > >> This patch series was started due to -EPROBE_DEFER not being handled
> > >> correctly in mdio_mux_init() and causing issues [1]. While at it, I also
> > >> did some more error handling fixes and clean ups. The -EPROBE_DEFER fix is
> > >> the last patch.
> > >>
> > >> Ideally, in the last patch we'd treat any error similar to -EPROBE_DEFER
> > >> but I'm not sure if it'll break any board/platforms where some child
> > >> mdiobus never successfully registers. If we treated all errors similar to
> > >> -EPROBE_DEFER, then none of the child mdiobus will work and that might be a
> > >> regression. If people are sure this is not a real case, then I can fix up
> > >> the last patch to always fail the entire mdio-mux init if any of the child
> > >> mdiobus registration fails.
> > >>
> > >> Cc: Marc Zyngier <maz@kernel.org>
> > >> Cc: Neil Armstrong <narmstrong@baylibre.com>
> > >> Cc: Kevin Hilman <khilman@baylibre.com>
> > >> [1] - https://lore.kernel.org/lkml/CAGETcx95kHrv8wA-O+-JtfH7H9biJEGJtijuPVN0V5dUKUAB3A@mail.gmail.com/#t
> > >>
> > >> Saravana Kannan (3):
> > >>   net: mdio-mux: Delete unnecessary devm_kfree
> > >>   net: mdio-mux: Don't ignore memory allocation errors
> > >>   net: mdio-mux: Handle -EPROBE_DEFER correctly
> > >>
> > >>  drivers/net/mdio/mdio-mux.c | 37 ++++++++++++++++++++++++-------------
> > >>  1 file changed, 24 insertions(+), 13 deletions(-)
> > >
> > > Thanks for this. I've just gave it a go on my test platform, and this
> > > indeed addresses the issues I was seeing [1].
> > >
> > > Acked-by: Marc Zyngier <maz@kernel.org>
> > > Tested-by: Marc Zyngier <maz@kernel.org>
> >
> > I wasn't seeing the same issues as Marc, but am heavily using everything
> > as modules on a few platforms using this code, and I'm not seeing any
> > regressions.

The only guess I have for this difference in results is I'm guessing
in your case the IRQ module is somehow getting loaded before the
mux/PHY driver?

> >
> > Thanks Saravana for finding the root cause here.
> >
> > Acked-by: Kevin Hilman <khilman@baylibre.com>
> > Signed-off-by: Kevin Hilman <khilman@baylibre.com>
>
> Oops, that should not be a SoB, but rather:
>
> Tested-by: Kevin Hilman <khilman@baylibre.com>

Thanks for the Acks/tests.

-Saravana

Re: [PATCH v1 1/3] net: mdio-mux: Delete unnecessary devm_kfree

[Andrew Lunn]

On Wed, Aug 04, 2021 at 02:43:30PM -0700, Saravana Kannan wrote:
> The whole point of devm_* APIs is that you don't have to undo them if you
> are returning an error that's going to get propagated out of a probe()
> function. So delete unnecessary devm_kfree() call in the error return path.
> 
> Signed-off-by: Saravana Kannan <saravanak@google.com>

Reviewed-by: Andrew Lunn <andrew@lunn.ch>

    Andrew

Re: [PATCH v1 2/3] net: mdio-mux: Don't ignore memory allocation errors

[Andrew Lunn]

On Wed, Aug 04, 2021 at 02:43:31PM -0700, Saravana Kannan wrote:
> If we are seeing memory allocation errors, don't try to continue
> registering child mdiobus devices. It's unlikely they'll succeed.
> 
> Signed-off-by: Saravana Kannan <saravanak@google.com>

Reviewed-by: Andrew Lunn <andrew@lunn.ch>

    Andrew

Re: [PATCH v1 3/3] net: mdio-mux: Handle -EPROBE_DEFER correctly

[Andrew Lunn]

On Wed, Aug 04, 2021 at 02:43:32PM -0700, Saravana Kannan wrote:
> When registering mdiobus children, if we get an -EPROBE_DEFER, we shouldn't
> ignore it and continue registering the rest of the mdiobus children. This
> would permanently prevent the deferring child mdiobus from working instead
> of reattempting it in the future. So, if a child mdiobus needs to be
> reattempted in the future, defer the entire mdio-mux initialization.
> 
> This fixes the issue where PHYs sitting under the mdio-mux aren't
> initialized correctly if the PHY's interrupt controller is not yet ready
> when the mdio-mux is being probed. Additional context in the link below.
> 
> Link: https://lore.kernel.org/lkml/CAGETcx95kHrv8wA-O+-JtfH7H9biJEGJtijuPVN0V5dUKUAB3A@mail.gmail.com/#t
> Signed-off-by: Saravana Kannan <saravanak@google.com>

Reviewed-by: Andrew Lunn <andrew@lunn.ch>

    Andrew