From: Vladimir Oltean <olteanv@gmail.com>
To: Daniel Golle <daniel@makrotopia.org>
Cc: Hauke Mehrtens <hauke@hauke-m.de>, Andrew Lunn <andrew@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Russell King <linux@armlinux.org.uk>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Rasmus Villemoes <ravi@prevas.dk>,
"Benny (Ying-Tsan) Weng" <yweng@maxlinear.com>,
John Crispin <john@phrozen.org>
Subject: Re: [PATCH net v4 4/4] net: dsa: mxl-gsw1xx: manually clear RANEG bit
Date: Wed, 10 Dec 2025 17:52:49 +0200 [thread overview]
Message-ID: <20251210155249.bpjm2hkvujstxt4i@skbuf> (raw)
In-Reply-To: <76745fceb5a3f53088110fb7a96acf88434088ca.1765241054.git.daniel@makrotopia.org> <76745fceb5a3f53088110fb7a96acf88434088ca.1765241054.git.daniel@makrotopia.org>
On Tue, Dec 09, 2025 at 01:29:34AM +0000, Daniel Golle wrote:
> Despite being documented as self-clearing, the RANEG bit sometimes
> remains set, preventing auto-negotiation from happening.
>
> Manually clear the RANEG bit after 10ms as advised by MaxLinear.
> In order to not hold RTNL during the 10ms of waiting schedule
> delayed work to take care of clearing the bit asynchronously, which
> is similar to the self-clearing behavior.
>
> Fixes: 22335939ec90 ("net: dsa: add driver for MaxLinear GSW1xx switch family")
> Reported-by: Rasmus Villemoes <ravi@prevas.dk>
> Signed-off-by: Daniel Golle <daniel@makrotopia.org>
> ---
> v4:
> * fix order of operations in remove and shutdown functions
>
> v3:
> * fix wrong parameter name in call of cancel_delayed_work_sync
>
> v2:
> * cancel pending work before setting RANEG bit
> * cancel pending work on remove and shutdown
> * document that GSW1XX_RST_REQ_SGMII_SHELL also clears RANEG bit
> * improve commit message
>
> drivers/net/dsa/lantiq/mxl-gsw1xx.c | 34 ++++++++++++++++++++++++++++-
> 1 file changed, 33 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/dsa/lantiq/mxl-gsw1xx.c b/drivers/net/dsa/lantiq/mxl-gsw1xx.c
> index 4dc287ad141e1..f8ff8a604bf53 100644
> --- a/drivers/net/dsa/lantiq/mxl-gsw1xx.c
> +++ b/drivers/net/dsa/lantiq/mxl-gsw1xx.c
> @@ -11,10 +11,12 @@
>
> #include <linux/bits.h>
> #include <linux/delay.h>
> +#include <linux/jiffies.h>
> #include <linux/module.h>
> #include <linux/of_device.h>
> #include <linux/of_mdio.h>
> #include <linux/regmap.h>
> +#include <linux/workqueue.h>
> #include <net/dsa.h>
>
> #include "lantiq_gswip.h"
> @@ -29,6 +31,7 @@ struct gsw1xx_priv {
> struct regmap *clk;
> struct regmap *shell;
> struct phylink_pcs pcs;
> + struct delayed_work clear_raneg;
> phy_interface_t tbi_interface;
> struct gswip_priv gswip;
> };
> @@ -145,7 +148,9 @@ static void gsw1xx_pcs_disable(struct phylink_pcs *pcs)
> {
> struct gsw1xx_priv *priv = pcs_to_gsw1xx(pcs);
>
> - /* Assert SGMII shell reset */
> + cancel_delayed_work_sync(&priv->clear_raneg);
> +
> + /* Assert SGMII shell reset (will also clear RANEG bit) */
> regmap_set_bits(priv->shell, GSW1XX_SHELL_RST_REQ,
> GSW1XX_RST_REQ_SGMII_SHELL);
>
> @@ -428,12 +433,29 @@ static int gsw1xx_pcs_config(struct phylink_pcs *pcs, unsigned int neg_mode,
> return 0;
> }
>
> +static void gsw1xx_pcs_clear_raneg(struct work_struct *work)
> +{
> + struct gsw1xx_priv *priv =
> + container_of(work, struct gsw1xx_priv, clear_raneg.work);
> +
> + regmap_clear_bits(priv->sgmii, GSW1XX_SGMII_TBI_ANEGCTL,
> + GSW1XX_SGMII_TBI_ANEGCTL_RANEG);
> +}
> +
> static void gsw1xx_pcs_an_restart(struct phylink_pcs *pcs)
> {
> struct gsw1xx_priv *priv = pcs_to_gsw1xx(pcs);
>
> + cancel_delayed_work_sync(&priv->clear_raneg);
> +
> regmap_set_bits(priv->sgmii, GSW1XX_SGMII_TBI_ANEGCTL,
> GSW1XX_SGMII_TBI_ANEGCTL_RANEG);
> +
> + /* despite being documented as self-clearing, the RANEG bit
> + * sometimes remains set, preventing auto-negotiation from happening.
> + * MaxLinear advises to manually clear the bit after 10ms.
> + */
> + schedule_delayed_work(&priv->clear_raneg, msecs_to_jiffies(10));
> }
>
> static void gsw1xx_pcs_link_up(struct phylink_pcs *pcs,
> @@ -636,6 +658,8 @@ static int gsw1xx_probe(struct mdio_device *mdiodev)
> if (ret)
> return ret;
>
> + INIT_DELAYED_WORK(&priv->clear_raneg, gsw1xx_pcs_clear_raneg);
> +
> ret = gswip_probe_common(&priv->gswip, version);
> if (ret)
> return ret;
> @@ -648,16 +672,21 @@ static int gsw1xx_probe(struct mdio_device *mdiodev)
> static void gsw1xx_remove(struct mdio_device *mdiodev)
> {
> struct gswip_priv *priv = dev_get_drvdata(&mdiodev->dev);
> + struct gsw1xx_priv *gsw1xx_priv;
>
> if (!priv)
> return;
>
> dsa_unregister_switch(priv->ds);
> +
> + gsw1xx_priv = container_of(priv, struct gsw1xx_priv, gswip);
> + cancel_delayed_work_sync(&gsw1xx_priv->clear_raneg);
> }
>
> static void gsw1xx_shutdown(struct mdio_device *mdiodev)
> {
> struct gswip_priv *priv = dev_get_drvdata(&mdiodev->dev);
> + struct gsw1xx_priv *gsw1xx_priv;
>
> if (!priv)
> return;
> @@ -665,6 +694,9 @@ static void gsw1xx_shutdown(struct mdio_device *mdiodev)
> dsa_switch_shutdown(priv->ds);
>
> dev_set_drvdata(&mdiodev->dev, NULL);
> +
> + gsw1xx_priv = container_of(priv, struct gsw1xx_priv, gswip);
> + cancel_delayed_work_sync(&gsw1xx_priv->clear_raneg);
Nitpick: why did you place this after dev_set_drvdata(dev, NULL) and not before?
The work item doesn't call dev_get_drvdata(), true, but it's one more refactoring
step that needs to be taken care of if it should.
> }
>
> static const struct gswip_hw_info gsw12x_data = {
> --
> 2.52.0
next prev parent reply other threads:[~2025-12-10 15:52 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-09 1:27 [PATCH net v4 0/4] net: dsa: lantiq: a bunch of fixes Daniel Golle
2025-12-09 1:28 ` [PATCH net v4 1/4] net: dsa: lantiq_gswip: fix order in .remove operation Daniel Golle
2025-12-09 1:28 ` [PATCH net v4 2/4] net: dsa: mxl-gsw1xx: " Daniel Golle
2025-12-09 1:29 ` [PATCH net v4 3/4] net: dsa: mxl-gsw1xx: fix .shutdown driver operation Daniel Golle
2025-12-09 1:29 ` [PATCH net v4 4/4] net: dsa: mxl-gsw1xx: manually clear RANEG bit Daniel Golle
2025-12-10 15:52 ` Vladimir Oltean [this message]
2025-12-10 16:03 ` Daniel Golle
2025-12-10 16:16 ` [PATCH net v4 0/4] net: dsa: lantiq: a bunch of fixes Vladimir Oltean
2025-12-16 18:08 ` Daniel Golle
2025-12-16 18:13 ` Vladimir Oltean
2025-12-18 12:00 ` patchwork-bot+netdevbpf
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=20251210155249.bpjm2hkvujstxt4i@skbuf \
--to=olteanv@gmail.com \
--cc=andrew@lunn.ch \
--cc=daniel@makrotopia.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hauke@hauke-m.de \
--cc=john@phrozen.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=ravi@prevas.dk \
--cc=yweng@maxlinear.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