netdev - Re: [PATCH net-next 1/3] dt-bindings: net: dsa: lantiq,gswip: reference common PHY properties

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aXk38o39i62SIq_K@makrotopia.org>
Date: Tue, 27 Jan 2026 22:10:58 +0000
From: Daniel Golle <daniel@...rotopia.org>
To: Vladimir Oltean <olteanv@...il.com>
Cc: Hauke Mehrtens <hauke@...ke-m.de>, Andrew Lunn <andrew@...n.ch>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>, netdev@...r.kernel.org,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next 1/3] dt-bindings: net: dsa: lantiq,gswip:
 reference common PHY properties

On Tue, Jan 27, 2026 at 05:07:47PM +0200, Vladimir Oltean wrote:
> On Tue, Jan 27, 2026 at 02:07:03PM +0000, Daniel Golle wrote:
> > Yeah, I thought about that, but it would be a lot of work to
> > let the driver expose and simple-bus as MFD with devices (clk controller,
> > reset controller, pcs, ...) sitting on register ranges. Imho not worth
> > the effort in this case, we discussed it.
> 
> Possibly so; I don't have access from this computer to my previous notes
> on this topic.
> 
> > However, even in that case imho it's fine to let it share the OF node
> > with the ethernet-port. Why not?
> 
> I don't have a good feeling of how reusable this PCS IP truly is.
> For example the XPCS gained DT bindings before I needed to customize the
> lane polarity for its SJA1105 instantiation, so now I have to work with
> and somehow adapt those.
> 
> If the PCS has a fixed mapping to that port then I suppose it can use
> its OF node space without any extra overengineering. There should exist
> ways to keep compatibility with this scheme even if there will be
> efforts to have a reusable driver later.

Taking a step back I noticed that we need to decide this also for
mt7530.

commit bde1ae2d52ab ("net: pcs: pcs-mtk-lynxi: pass SGMIISYS OF node to PCS")
currently doesn't pass any fwnode when creating the LynxI PCS.
> +               pcs = mtk_pcs_lynxi_create(priv->dev, NULL, regmap,
> +                                          MT7531_PHYA_CTRL_SIGNAL3);

However, each PCS does belong to a specific switch port, and it would be
advantegous and imho consistent to also assign the ports OF node to the
PCS, this would allow to configure the polarities also on the MT7530
SerDes ports.

Ie.

diff --git a/drivers/net/dsa/mt7530-mdio.c b/drivers/net/dsa/mt7530-mdio.c
index 11ea924a9f35..3da9f42cefcb 100644
--- a/drivers/net/dsa/mt7530-mdio.c
+++ b/drivers/net/dsa/mt7530-mdio.c
@@ -86,9 +86,16 @@ mt7531_create_sgmii(struct mt7530_priv *priv)
 	struct regmap_config *mt7531_pcs_config[2] = {};
 	struct phylink_pcs *pcs;
 	struct regmap *regmap;
+	struct dsa_port *dp;
 	int i, ret = 0;
 
 	for (i = priv->p5_sgmii ? 0 : 1; i < 2; i++) {
+		dp = dsa_to_port(priv->ds, i + 5);
+		if (!dp) {
+			ret = -EINVAL;
+			break;
+		}
+
 		mt7531_pcs_config[i] = devm_kzalloc(priv->dev,
 						    sizeof(struct regmap_config),
 						    GFP_KERNEL);
@@ -113,8 +120,8 @@ mt7531_create_sgmii(struct mt7530_priv *priv)
 			ret = PTR_ERR(regmap);
 			break;
 		}
-		pcs = mtk_pcs_lynxi_create(priv->dev, NULL, regmap,
-					   MT7531_PHYA_CTRL_SIGNAL3);
+		pcs = mtk_pcs_lynxi_create(priv->dev, of_fwnode_handle(dp->dn),
+					   regmap, MT7531_PHYA_CTRL_SIGNAL3);
 		if (!pcs) {
 			ret = -ENXIO;
 			break;


What do you think?