From: Vladimir Oltean <olteanv@gmail.com>
To: "Alvin Šipraga" <alvin@pqrs.dk>
Cc: "Linus Walleij" <linus.walleij@linaro.org>,
"Andrew Lunn" <andrew@lunn.ch>,
"Vivien Didelot" <vivien.didelot@gmail.com>,
"Florian Fainelli" <f.fainelli@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
"Jakub Kicinski" <kuba@kernel.org>,
"Rob Herring" <robh+dt@kernel.org>,
"Heiner Kallweit" <hkallweit1@gmail.com>,
"Russell King" <linux@armlinux.org.uk>,
mir@bang-olufsen.dk, "Alvin Šipraga" <alsi@bang-olufsen.dk>,
netdev@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH net-next 1/5] net: dsa: realtek-smi: fix mdio_free bug on module unload
Date: Mon, 23 Aug 2021 00:54:42 +0300 [thread overview]
Message-ID: <20210822215442.a2xywnodg7qwf2b5@skbuf> (raw)
In-Reply-To: <20210822193145.1312668-2-alvin@pqrs.dk>
On Sun, Aug 22, 2021 at 09:31:39PM +0200, Alvin Šipraga wrote:
> From: Alvin Šipraga <alsi@bang-olufsen.dk>
>
> realtek-smi-core fails to unregister the slave MII bus on module unload,
> raising the following BUG warning:
>
> mdio_bus.c:650: BUG_ON(bus->state != MDIOBUS_UNREGISTERED);
>
> kernel BUG at drivers/net/phy/mdio_bus.c:650!
> Internal error: Oops - BUG: 0 [#1] PREEMPT_RT SMP
> Call trace:
> mdiobus_free+0x4c/0x50
> devm_mdiobus_free+0x18/0x20
> release_nodes.isra.0+0x1c0/0x2b0
> devres_release_all+0x38/0x58
> device_release_driver_internal+0x124/0x1e8
> driver_detach+0x54/0xe0
> bus_remove_driver+0x60/0xd8
> driver_unregister+0x34/0x60
> platform_driver_unregister+0x18/0x20
> realtek_smi_driver_exit+0x14/0x1c [realtek_smi]
>
> Fix this by duly unregistering the slave MII bus with
> mdiobus_unregister. We do this in the DSA teardown path, since
> registration is performed in the DSA setup path.
>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Fixes: d8652956cf37 ("net: dsa: realtek-smi: Add Realtek SMI driver")
> Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk>
> ---
> drivers/net/dsa/realtek-smi-core.c | 6 ++++++
> drivers/net/dsa/realtek-smi-core.h | 1 +
> drivers/net/dsa/rtl8366rb.c | 8 ++++++++
> 3 files changed, 15 insertions(+)
>
> diff --git a/drivers/net/dsa/realtek-smi-core.c b/drivers/net/dsa/realtek-smi-core.c
> index 8e49d4f85d48..6992b6b31db6 100644
> --- a/drivers/net/dsa/realtek-smi-core.c
> +++ b/drivers/net/dsa/realtek-smi-core.c
> @@ -383,6 +383,12 @@ int realtek_smi_setup_mdio(struct realtek_smi *smi)
> return ret;
> }
>
> +void realtek_smi_teardown_mdio(struct realtek_smi *smi)
> +{
> + if (smi->slave_mii_bus)
> + mdiobus_unregister(smi->slave_mii_bus);
> +}
> +
> static int realtek_smi_probe(struct platform_device *pdev)
> {
> const struct realtek_smi_variant *var;
> diff --git a/drivers/net/dsa/realtek-smi-core.h b/drivers/net/dsa/realtek-smi-core.h
> index fcf465f7f922..6cfa5f2df7ea 100644
> --- a/drivers/net/dsa/realtek-smi-core.h
> +++ b/drivers/net/dsa/realtek-smi-core.h
> @@ -119,6 +119,7 @@ struct realtek_smi_variant {
> int realtek_smi_write_reg_noack(struct realtek_smi *smi, u32 addr,
> u32 data);
> int realtek_smi_setup_mdio(struct realtek_smi *smi);
> +void realtek_smi_teardown_mdio(struct realtek_smi *smi);
>
> /* RTL8366 library helpers */
> int rtl8366_mc_is_used(struct realtek_smi *smi, int mc_index, int *used);
> diff --git a/drivers/net/dsa/rtl8366rb.c b/drivers/net/dsa/rtl8366rb.c
> index a89093bc6c6a..6537fac7aba4 100644
> --- a/drivers/net/dsa/rtl8366rb.c
> +++ b/drivers/net/dsa/rtl8366rb.c
> @@ -982,6 +982,13 @@ static int rtl8366rb_setup(struct dsa_switch *ds)
> return 0;
> }
>
> +static void rtl8366rb_teardown(struct dsa_switch *ds)
> +{
> + struct realtek_smi *smi = ds->priv;
> +
> + realtek_smi_teardown_mdio(smi);
> +}
> +
Objection: dsa_switch_teardown has:
if (ds->slave_mii_bus && ds->ops->phy_read)
mdiobus_unregister(ds->slave_mii_bus);
The realtek_smi_setup_mdio function does:
smi->ds->slave_mii_bus = smi->slave_mii_bus;
so I would expect that this would result in a double unregister on some
systems.
I haven't went through your new driver, but I wonder whether you have
the phy_read and phy_write methods implemented? Maybe that is the
difference?
> static enum dsa_tag_protocol rtl8366_get_tag_protocol(struct dsa_switch *ds,
> int port,
> enum dsa_tag_protocol mp)
> @@ -1505,6 +1512,7 @@ static int rtl8366rb_detect(struct realtek_smi *smi)
> static const struct dsa_switch_ops rtl8366rb_switch_ops = {
> .get_tag_protocol = rtl8366_get_tag_protocol,
> .setup = rtl8366rb_setup,
> + .teardown = rtl8366rb_teardown,
> .phylink_mac_link_up = rtl8366rb_mac_link_up,
> .phylink_mac_link_down = rtl8366rb_mac_link_down,
> .get_strings = rtl8366_get_strings,
> --
> 2.32.0
>
next prev parent reply other threads:[~2021-08-22 21:54 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-22 19:31 [RFC PATCH net-next 0/5] net: dsa: add support for RTL8365MB-VC Alvin Šipraga
2021-08-22 19:31 ` [RFC PATCH net-next 1/5] net: dsa: realtek-smi: fix mdio_free bug on module unload Alvin Šipraga
2021-08-22 21:40 ` Andrew Lunn
2021-08-22 22:33 ` Alvin Šipraga
2021-08-22 23:16 ` Andrew Lunn
2021-08-27 22:06 ` Linus Walleij
2021-08-28 10:50 ` Alvin Šipraga
2021-08-22 21:54 ` Vladimir Oltean [this message]
2021-08-22 22:42 ` Alvin Šipraga
2021-08-22 23:10 ` Vladimir Oltean
2021-08-22 19:31 ` [RFC PATCH net-next 2/5] dt-bindings: net: dsa: realtek-smi: document new compatible rtl8365mb Alvin Šipraga
2021-08-22 21:44 ` Andrew Lunn
2021-08-23 10:15 ` Florian Fainelli
2021-08-24 16:51 ` Rob Herring
2021-08-27 22:08 ` Linus Walleij
2021-08-22 19:31 ` [RFC PATCH net-next 3/5] net: dsa: tag_rtl8_4: add realtek 8 byte protocol 4 tag Alvin Šipraga
2021-08-22 22:02 ` Andrew Lunn
2021-08-22 22:50 ` Alvin Šipraga
2021-08-22 23:14 ` Andrew Lunn
2021-08-22 23:27 ` Alvin Šipraga
2021-08-22 22:13 ` Vladimir Oltean
2021-08-22 23:11 ` Alvin Šipraga
2021-08-22 23:25 ` Vladimir Oltean
2021-08-22 23:37 ` Alvin Šipraga
2021-08-22 23:45 ` Vladimir Oltean
2021-08-23 0:28 ` Alvin Šipraga
2021-08-23 0:31 ` Vladimir Oltean
2021-08-22 19:31 ` [RFC PATCH net-next 4/5] net: dsa: realtek-smi: add rtl8365mb subdriver for RTL8365MB-VC Alvin Šipraga
2021-08-22 22:48 ` Vladimir Oltean
2021-08-22 23:56 ` Alvin Šipraga
2021-08-23 0:19 ` Vladimir Oltean
2021-08-23 1:22 ` Alvin Šipraga
2021-08-23 2:12 ` Vladimir Oltean
2021-08-23 10:06 ` Alvin Šipraga
2021-08-23 10:31 ` Vladimir Oltean
2021-08-23 10:54 ` Alvin Šipraga
2021-08-23 13:13 ` Andrew Lunn
2021-08-23 13:20 ` Alvin Šipraga
2021-08-27 22:24 ` Linus Walleij
2021-08-22 23:04 ` Andrew Lunn
2021-08-22 23:25 ` Alvin Šipraga
2021-08-23 1:14 ` Andrew Lunn
2021-08-23 10:08 ` Alvin Šipraga
2021-08-23 4:37 ` DENG Qingfang
2021-08-23 10:11 ` Alvin Šipraga
2021-08-22 19:31 ` [RFC PATCH net-next 5/5] net: phy: realtek: add support for RTL8365MB-VC internal PHYs Alvin Šipraga
2021-08-23 10:13 ` Florian Fainelli
2021-08-27 22:27 ` Linus Walleij
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210822215442.a2xywnodg7qwf2b5@skbuf \
--to=olteanv@gmail.com \
--cc=alsi@bang-olufsen.dk \
--cc=alvin@pqrs.dk \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=f.fainelli@gmail.com \
--cc=hkallweit1@gmail.com \
--cc=kuba@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=mir@bang-olufsen.dk \
--cc=netdev@vger.kernel.org \
--cc=robh+dt@kernel.org \
--cc=vivien.didelot@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).