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 <[email protected]>
Cc: Neil Armstrong <[email protected]>
Cc: Kevin Hilman <[email protected]>
[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
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 <[email protected]>
---
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
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 <[email protected]>
---
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
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 <[email protected]>
---
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
Hi Saravana,
On Wed, 04 Aug 2021 22:43:29 +0100,
Saravana Kannan <[email protected]> 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 <[email protected]>
> Cc: Neil Armstrong <[email protected]>
> Cc: Kevin Hilman <[email protected]>
> [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 <[email protected]>
Tested-by: Marc Zyngier <[email protected]>
M.
[1] https://lore.kernel.org/r/[email protected]
--
Without deviation from the norm, progress is not possible.
Please resubmit the cleanups targetting net-next and the bug fix targetting net.
Thank you.
Marc Zyngier <[email protected]> writes:
> Hi Saravana,
>
> On Wed, 04 Aug 2021 22:43:29 +0100,
> Saravana Kannan <[email protected]> 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 <[email protected]>
>> Cc: Neil Armstrong <[email protected]>
>> Cc: Kevin Hilman <[email protected]>
>> [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 <[email protected]>
> Tested-by: Marc Zyngier <[email protected]>
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 <[email protected]>
Signed-off-by: Kevin Hilman <[email protected]>
Kevin
On Thu, Aug 5, 2021 at 11:36 AM Kevin Hilman <[email protected]> wrote:
>
> Marc Zyngier <[email protected]> writes:
>
> > Hi Saravana,
> >
> > On Wed, 04 Aug 2021 22:43:29 +0100,
> > Saravana Kannan <[email protected]> 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 <[email protected]>
> >> Cc: Neil Armstrong <[email protected]>
> >> Cc: Kevin Hilman <[email protected]>
> >> [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 <[email protected]>
> > Tested-by: Marc Zyngier <[email protected]>
>
> 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 <[email protected]>
> Signed-off-by: Kevin Hilman <[email protected]>
Oops, that should not be a SoB, but rather:
Tested-by: Kevin Hilman <[email protected]>
On Thu, Aug 5, 2021 at 11:38 AM Kevin Hilman <[email protected]> wrote:
>
> On Thu, Aug 5, 2021 at 11:36 AM Kevin Hilman <[email protected]> wrote:
> >
> > Marc Zyngier <[email protected]> writes:
> >
> > > Hi Saravana,
> > >
> > > On Wed, 04 Aug 2021 22:43:29 +0100,
> > > Saravana Kannan <[email protected]> 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 <[email protected]>
> > >> Cc: Neil Armstrong <[email protected]>
> > >> Cc: Kevin Hilman <[email protected]>
> > >> [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 <[email protected]>
> > > Tested-by: Marc Zyngier <[email protected]>
> >
> > 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 <[email protected]>
> > Signed-off-by: Kevin Hilman <[email protected]>
>
> Oops, that should not be a SoB, but rather:
>
> Tested-by: Kevin Hilman <[email protected]>
Thanks for the Acks/tests.
-Saravana
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 <[email protected]>
Reviewed-by: Andrew Lunn <[email protected]>
Andrew
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 <[email protected]>
Reviewed-by: Andrew Lunn <[email protected]>
Andrew
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 <[email protected]>
Reviewed-by: Andrew Lunn <[email protected]>
Andrew