Message ID | ZDSlm-0gyyDZXy_k@makrotopia.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp2253332vqo; Mon, 10 Apr 2023 18:03:54 -0700 (PDT) X-Google-Smtp-Source: AKy350Y3iVwOEc+p+lRBEZQ+2N3I88GFk+X7k8DRdPLEy1RtfNczCN+9SZWx2MyZiB1v01V8TI9x X-Received: by 2002:aa7:cb97:0:b0:504:81d4:118d with SMTP id r23-20020aa7cb97000000b0050481d4118dmr7919640edt.3.1681175034318; Mon, 10 Apr 2023 18:03:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1681175034; cv=none; d=google.com; s=arc-20160816; b=UY1quoKOxrka5w2lKykoKrsxy/qM7e2QEkdx650kJd8ihaKxxdwFPg0Qcz2ebSpQsM 0OUKjGN/m77cWXnE4uRhx7eZUirKAXcGzBU7PG2JNF5rFCIX+piy/gPwYY5+1PW8fiRZ Xm0AUMYCh3PZ7iU4d94hbG+eDpzbe5OQUd5inKKORAOvXZ3BdOkHmEJSRkqcydJOgMqI ezznPldyh/TJp9fmwTrLn9AakE7e10ab9ate9PvKEjhJBoB3HtL69Ot5/z02teq9ad5E +p0EbzmmtAdF5ndgW+HMzSvI1x4qMVc1Ww5IoJTkGdGmQUKwiFnlyeZ9bvgXVL1eQmJk uiTA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-disposition:mime-version:message-id :subject:to:from:date; bh=PwDNwnu45uNJkcjW3fc8b1bSVRqg7U+HFWkF444tmmY=; b=IPwIL6Dr+7+c6xg8lUbw2CQY0mjSxJWRFSEvzEAN/CV/1j+Yhf2GohZkxzGgNjV2lq RaMMdmG0JHQ1rqMOt7Pro3ZsvJbok1Oni+eD7naMvhHyfgIF2G1uozFs5UsoYj2VXCHB eVw493pUqxo8YGnIJJqbg+j2nTLkRkdyrNu3O+hqspQWzLXBvmRilkH7kuSqllhefyO5 Ev/MeVL9Cst8tcOEMuQYeATgkQdbdJ10Mrx1WSJR7Y0fMo3qMh6g7WxBGTyGj0hF04u2 BF4/04l+aWbJsk5cuz+VPmE936aIgx//m8UUSYoBYlFwtXyDDwsyaOHoy4flKaZbvdCB RkOA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id c25-20020aa7d619000000b00504b2a6ace0si1810455edr.335.2023.04.10.18.03.27; Mon, 10 Apr 2023 18:03:54 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229886AbjDKAL0 (ORCPT <rfc822;yuanzuo1009@gmail.com> + 99 others); Mon, 10 Apr 2023 20:11:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60956 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229591AbjDKALY (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 10 Apr 2023 20:11:24 -0400 Received: from fudo.makrotopia.org (fudo.makrotopia.org [IPv6:2a07:2ec0:3002::71]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8224226AB; Mon, 10 Apr 2023 17:11:22 -0700 (PDT) Received: from local by fudo.makrotopia.org with esmtpsa (TLS1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.96) (envelope-from <daniel@makrotopia.org>) id 1pm1bP-0007rm-1O; Tue, 11 Apr 2023 02:11:15 +0200 Date: Tue, 11 Apr 2023 01:11:07 +0100 From: Daniel Golle <daniel@makrotopia.org> To: netdev@vger.kernel.org, linux-mediatek@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Sean Wang <sean.wang@mediatek.com>, Landen Chao <Landen.Chao@mediatek.com>, DENG Qingfang <dqfext@gmail.com>, =?utf-8?b?QXLEsW7DpyDDnE5BTA==?= <arinc.unal@arinc9.com>, Russell King <linux@armlinux.org.uk>, AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>, Matthias Brugger <matthias.bgg@gmail.com>, Paolo Abeni <pabeni@redhat.com>, Jakub Kicinski <kuba@kernel.org>, Eric Dumazet <edumazet@google.com>, "David S. Miller" <davem@davemloft.net>, Vladimir Oltean <olteanv@gmail.com>, Florian Fainelli <f.fainelli@gmail.com>, Andrew Lunn <andrew@lunn.ch> Subject: [PATCH net-next] net: dsa: mt7530: fix support for MT7531BE Message-ID: <ZDSlm-0gyyDZXy_k@makrotopia.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=0.0 required=5.0 tests=SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1762839792534200616?= X-GMAIL-MSGID: =?utf-8?q?1762839792534200616?= |
Series |
[net-next] net: dsa: mt7530: fix support for MT7531BE
|
|
Commit Message
Daniel Golle
April 11, 2023, 12:11 a.m. UTC
There are two variants of the MT7531 switch IC which got different
features (and pins) regarding port 5:
* MT7531AE: SGMII/1000Base-X/2500Base-X SerDes
* MT7531BE: RGMII
Moving the creation of the SerDes PCS from mt753x_setup to mt7530_probe
with commit 6de285229773 ("net: dsa: mt7530: move SGMII PCS creation to
mt7530_probe function") works fine for MT7531AE which got two instances
of mtk-pcs-lynxi, however, MT7531BE requires mt7531_pll_setup to setup
clocks before the single PCS on port 6 (usually used as CPU port)
starts to work and hence the PCS creation failed on MT7531BE.
Fix this by introducing a pointer to mt7531_create_sgmii function in
struct mt7530_priv and call it again at the end of mt753x_setup like it
was before commit 6de285229773 ("net: dsa: mt7530: move SGMII PCS
creation to mt7530_probe function").
Fixes: 6de285229773 ("net: dsa: mt7530: move SGMII PCS creation to mt7530_probe function")
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
---
drivers/net/dsa/mt7530-mdio.c | 14 +++++++-------
drivers/net/dsa/mt7530.c | 6 ++++++
drivers/net/dsa/mt7530.h | 4 ++++
3 files changed, 17 insertions(+), 7 deletions(-)
Comments
On 4/10/2023 5:11 PM, Daniel Golle wrote: > There are two variants of the MT7531 switch IC which got different > features (and pins) regarding port 5: > * MT7531AE: SGMII/1000Base-X/2500Base-X SerDes > * MT7531BE: RGMII > > Moving the creation of the SerDes PCS from mt753x_setup to mt7530_probe > with commit 6de285229773 ("net: dsa: mt7530: move SGMII PCS creation to > mt7530_probe function") works fine for MT7531AE which got two instances > of mtk-pcs-lynxi, however, MT7531BE requires mt7531_pll_setup to setup > clocks before the single PCS on port 6 (usually used as CPU port) > starts to work and hence the PCS creation failed on MT7531BE. > > Fix this by introducing a pointer to mt7531_create_sgmii function in > struct mt7530_priv and call it again at the end of mt753x_setup like it > was before commit 6de285229773 ("net: dsa: mt7530: move SGMII PCS > creation to mt7530_probe function"). > > Fixes: 6de285229773 ("net: dsa: mt7530: move SGMII PCS creation to mt7530_probe function") > Signed-off-by: Daniel Golle <daniel@makrotopia.org> > --- > drivers/net/dsa/mt7530-mdio.c | 14 +++++++------- > drivers/net/dsa/mt7530.c | 6 ++++++ > drivers/net/dsa/mt7530.h | 4 ++++ > 3 files changed, 17 insertions(+), 7 deletions(-) > > diff --git a/drivers/net/dsa/mt7530-mdio.c b/drivers/net/dsa/mt7530-mdio.c > index 34a547b88e497..f17eab67d15fa 100644 > --- a/drivers/net/dsa/mt7530-mdio.c > +++ b/drivers/net/dsa/mt7530-mdio.c > @@ -81,14 +81,17 @@ static const struct regmap_bus mt7530_regmap_bus = { > }; > > static int > -mt7531_create_sgmii(struct mt7530_priv *priv) > +mt7531_create_sgmii(struct mt7530_priv *priv, bool dual_sgmii) > { > struct regmap_config *mt7531_pcs_config[2]; [1] use = {}; > struct phylink_pcs *pcs; > struct regmap *regmap; > int i, ret = 0; > > - for (i = 0; i < 2; i++) { > + /* MT7531AE has two SGMII units for port 5 and port 6 > + * MT7531BE has only one SGMII unit for port 6 > + */ > + for (i = dual_sgmii ? 0 : 1; i < 2; i++) { > mt7531_pcs_config[i] = devm_kzalloc(priv->dev, hm, I don't like this, you're no longer initializing array[0] if dual_sgmii is set. This seems like a recipe for disaster. you could initialize the array to NULL above when allocating this on the stack? [1] > sizeof(struct regmap_config), > GFP_KERNEL); > @@ -208,11 +211,8 @@ mt7530_probe(struct mdio_device *mdiodev) > if (IS_ERR(priv->regmap)) > return PTR_ERR(priv->regmap); > > - if (priv->id == ID_MT7531) { > - ret = mt7531_create_sgmii(priv); > - if (ret) > - return ret; > - } > + if (priv->id == ID_MT7531) > + priv->create_sgmii = mt7531_create_sgmii; > > return dsa_register_switch(priv->ds); > } > diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c > index e4bb5037d3525..c680873819b01 100644 > --- a/drivers/net/dsa/mt7530.c > +++ b/drivers/net/dsa/mt7530.c > @@ -3018,6 +3018,12 @@ mt753x_setup(struct dsa_switch *ds) > if (ret && priv->irq) > mt7530_free_irq_common(priv); > > + if (priv->create_sgmii) { > + ret = priv->create_sgmii(priv, mt7531_dual_sgmii_supported(priv)); > + if (ret && priv->irq) > + mt7530_free_irq(priv); > + } > + > return ret; > } > > diff --git a/drivers/net/dsa/mt7530.h b/drivers/net/dsa/mt7530.h > index 01db5c9724fa8..6e89578b4de02 100644 > --- a/drivers/net/dsa/mt7530.h > +++ b/drivers/net/dsa/mt7530.h > @@ -752,6 +752,8 @@ struct mt753x_info { > * @irq: IRQ number of the switch > * @irq_domain: IRQ domain of the switch irq_chip > * @irq_enable: IRQ enable bits, synced to SYS_INT_EN > + * no extra blank line needed here. > + * @create_sgmii: Pointer to function creating SGMII PCS instance(s) > */ > struct mt7530_priv { > struct device *dev; > @@ -778,6 +780,8 @@ struct mt7530_priv { > int irq; > struct irq_domain *irq_domain; > u32 irq_enable; > + > + int (*create_sgmii)(struct mt7530_priv *priv, bool dual_sgmii); > }; > > struct mt7530_hw_vlan_entry {
On 11.04.2023 03:11, Daniel Golle wrote: > There are two variants of the MT7531 switch IC which got different > features (and pins) regarding port 5: > * MT7531AE: SGMII/1000Base-X/2500Base-X SerDes > * MT7531BE: RGMII > > Moving the creation of the SerDes PCS from mt753x_setup to mt7530_probe > with commit 6de285229773 ("net: dsa: mt7530: move SGMII PCS creation to > mt7530_probe function") works fine for MT7531AE which got two instances > of mtk-pcs-lynxi, however, MT7531BE requires mt7531_pll_setup to setup > clocks before the single PCS on port 6 (usually used as CPU port) > starts to work and hence the PCS creation failed on MT7531BE. > > Fix this by introducing a pointer to mt7531_create_sgmii function in > struct mt7530_priv and call it again at the end of mt753x_setup like it > was before commit 6de285229773 ("net: dsa: mt7530: move SGMII PCS > creation to mt7530_probe function"). If I understand correctly, this patch does two things. Run mt7531_create_sgmii() from mt753x_setup(), after mt7531_setup() and mt7531_setup_common() is run so that PCS on MT7531BE works. Run the PCS creation code inside the loop only once if mt7531_dual_sgmii_supported() is false so it doesn't set the nonexistent port 5 SGMII on MT7531BE. Regarding the first part: I was actually in the middle of moving the code until after mt7530_pll_setup() and mt7531_pll_setup() on mt7530_setup() and mt7531_setup() to mt7530_probe(). To me it makes more sense to run them on mt7530_probe() as there's a good amount of duplicate code on mt7530_setup() and mt7531_setup(). This will resolve the problem here, and make my future work regarding the PHY muxing feature on the MT7530 switch possible to do. Regarding the second part: I'll take your changes to my current RFC patch series while addressing Jesse's suggestion if this is fine by you. Arınç
On Tue, Apr 11, 2023 at 10:30:06PM +0300, Arınç ÜNAL wrote: > On 11.04.2023 03:11, Daniel Golle wrote: > > There are two variants of the MT7531 switch IC which got different > > features (and pins) regarding port 5: > > * MT7531AE: SGMII/1000Base-X/2500Base-X SerDes > > * MT7531BE: RGMII > > > > Moving the creation of the SerDes PCS from mt753x_setup to mt7530_probe > > with commit 6de285229773 ("net: dsa: mt7530: move SGMII PCS creation to > > mt7530_probe function") works fine for MT7531AE which got two instances > > of mtk-pcs-lynxi, however, MT7531BE requires mt7531_pll_setup to setup > > clocks before the single PCS on port 6 (usually used as CPU port) > > starts to work and hence the PCS creation failed on MT7531BE. > > > > Fix this by introducing a pointer to mt7531_create_sgmii function in > > struct mt7530_priv and call it again at the end of mt753x_setup like it > > was before commit 6de285229773 ("net: dsa: mt7530: move SGMII PCS > > creation to mt7530_probe function"). > > If I understand correctly, this patch does two things. > > Run mt7531_create_sgmii() from mt753x_setup(), after mt7531_setup() and > mt7531_setup_common() is run so that PCS on MT7531BE works. > > Run the PCS creation code inside the loop only once if > mt7531_dual_sgmii_supported() is false so it doesn't set the nonexistent > port 5 SGMII on MT7531BE. Yes, both is correct. > > Regarding the first part: > I was actually in the middle of moving the code until after > mt7530_pll_setup() and mt7531_pll_setup() on mt7530_setup() and > mt7531_setup() to mt7530_probe(). To me it makes more sense to run them on > mt7530_probe() as there's a good amount of duplicate code on mt7530_setup() > and mt7531_setup(). I thought about doing that as well, however, note that you will have to move all the reset and regulator setup procedure to mt7530_probe() as well then, as PLL setup currently happens after that, and that's probably for a reason. As the reset and regulator setup works differently on MT7530 and MT7531, and depending on whether it's a standalone IC package or MCM, I believe changes unifying this will have to be tested on a lot of boards... > > This will resolve the problem here, and make my future work regarding the > PHY muxing feature on the MT7530 switch possible to do. > > Regarding the second part: > I'll take your changes to my current RFC patch series while addressing > Jesse's suggestion if this is fine by you. Yes, I'd appreciate that and I'm ready to test and review once you post your updated series.
On 11.04.2023 22:43, Daniel Golle wrote: > On Tue, Apr 11, 2023 at 10:30:06PM +0300, Arınç ÜNAL wrote: >> On 11.04.2023 03:11, Daniel Golle wrote: >>> There are two variants of the MT7531 switch IC which got different >>> features (and pins) regarding port 5: >>> * MT7531AE: SGMII/1000Base-X/2500Base-X SerDes >>> * MT7531BE: RGMII >>> >>> Moving the creation of the SerDes PCS from mt753x_setup to mt7530_probe >>> with commit 6de285229773 ("net: dsa: mt7530: move SGMII PCS creation to >>> mt7530_probe function") works fine for MT7531AE which got two instances >>> of mtk-pcs-lynxi, however, MT7531BE requires mt7531_pll_setup to setup >>> clocks before the single PCS on port 6 (usually used as CPU port) >>> starts to work and hence the PCS creation failed on MT7531BE. >>> >>> Fix this by introducing a pointer to mt7531_create_sgmii function in >>> struct mt7530_priv and call it again at the end of mt753x_setup like it >>> was before commit 6de285229773 ("net: dsa: mt7530: move SGMII PCS >>> creation to mt7530_probe function"). >> >> If I understand correctly, this patch does two things. >> >> Run mt7531_create_sgmii() from mt753x_setup(), after mt7531_setup() and >> mt7531_setup_common() is run so that PCS on MT7531BE works. > >> >> Run the PCS creation code inside the loop only once if >> mt7531_dual_sgmii_supported() is false so it doesn't set the nonexistent >> port 5 SGMII on MT7531BE. > > Yes, both is correct. > >> >> Regarding the first part: >> I was actually in the middle of moving the code until after >> mt7530_pll_setup() and mt7531_pll_setup() on mt7530_setup() and >> mt7531_setup() to mt7530_probe(). To me it makes more sense to run them on >> mt7530_probe() as there's a good amount of duplicate code on mt7530_setup() >> and mt7531_setup(). > > I thought about doing that as well, however, note that you will have to > move all the reset and regulator setup procedure to mt7530_probe() as > well then, as PLL setup currently happens after that, and that's > probably for a reason. > > As the reset and regulator setup works differently on MT7530 and > MT7531, and depending on whether it's a standalone IC package or MCM, I > believe changes unifying this will have to be tested on a lot of > boards... Not if we don't change the behaviour at all for both switches, which is what I intend to do. > >> >> This will resolve the problem here, and make my future work regarding the >> PHY muxing feature on the MT7530 switch possible to do. >> >> Regarding the second part: >> I'll take your changes to my current RFC patch series while addressing >> Jesse's suggestion if this is fine by you. > > Yes, I'd appreciate that and I'm ready to test and review once you post > your updated series. Sounds good, cheers. Arınç
diff --git a/drivers/net/dsa/mt7530-mdio.c b/drivers/net/dsa/mt7530-mdio.c index 34a547b88e497..f17eab67d15fa 100644 --- a/drivers/net/dsa/mt7530-mdio.c +++ b/drivers/net/dsa/mt7530-mdio.c @@ -81,14 +81,17 @@ static const struct regmap_bus mt7530_regmap_bus = { }; static int -mt7531_create_sgmii(struct mt7530_priv *priv) +mt7531_create_sgmii(struct mt7530_priv *priv, bool dual_sgmii) { struct regmap_config *mt7531_pcs_config[2]; struct phylink_pcs *pcs; struct regmap *regmap; int i, ret = 0; - for (i = 0; i < 2; i++) { + /* MT7531AE has two SGMII units for port 5 and port 6 + * MT7531BE has only one SGMII unit for port 6 + */ + for (i = dual_sgmii ? 0 : 1; i < 2; i++) { mt7531_pcs_config[i] = devm_kzalloc(priv->dev, sizeof(struct regmap_config), GFP_KERNEL); @@ -208,11 +211,8 @@ mt7530_probe(struct mdio_device *mdiodev) if (IS_ERR(priv->regmap)) return PTR_ERR(priv->regmap); - if (priv->id == ID_MT7531) { - ret = mt7531_create_sgmii(priv); - if (ret) - return ret; - } + if (priv->id == ID_MT7531) + priv->create_sgmii = mt7531_create_sgmii; return dsa_register_switch(priv->ds); } diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c index e4bb5037d3525..c680873819b01 100644 --- a/drivers/net/dsa/mt7530.c +++ b/drivers/net/dsa/mt7530.c @@ -3018,6 +3018,12 @@ mt753x_setup(struct dsa_switch *ds) if (ret && priv->irq) mt7530_free_irq_common(priv); + if (priv->create_sgmii) { + ret = priv->create_sgmii(priv, mt7531_dual_sgmii_supported(priv)); + if (ret && priv->irq) + mt7530_free_irq(priv); + } + return ret; } diff --git a/drivers/net/dsa/mt7530.h b/drivers/net/dsa/mt7530.h index 01db5c9724fa8..6e89578b4de02 100644 --- a/drivers/net/dsa/mt7530.h +++ b/drivers/net/dsa/mt7530.h @@ -752,6 +752,8 @@ struct mt753x_info { * @irq: IRQ number of the switch * @irq_domain: IRQ domain of the switch irq_chip * @irq_enable: IRQ enable bits, synced to SYS_INT_EN + * + * @create_sgmii: Pointer to function creating SGMII PCS instance(s) */ struct mt7530_priv { struct device *dev; @@ -778,6 +780,8 @@ struct mt7530_priv { int irq; struct irq_domain *irq_domain; u32 irq_enable; + + int (*create_sgmii)(struct mt7530_priv *priv, bool dual_sgmii); }; struct mt7530_hw_vlan_entry {