From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pidgin.makrotopia.org (pidgin.makrotopia.org [185.142.180.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6FE9A21B185; Tue, 27 Jan 2026 22:11:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.142.180.65 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769551867; cv=none; b=RIeatL0CwH9dr6UjlnRSTlhXZBMMUzC5qwyJPhZWYt2YKpTUi0gFooI9RKmYexhTxjPdyouZwqJhDYZnqkRRdLAIjBwyz2LFzyUBdxTuDXZeOwWhMvUuSi58sc6XfvJn74mbmfVznkCaZMlv01vdin+Ev9dUK7BuSC8mzX/RIaA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769551867; c=relaxed/simple; bh=HXOFUCcMmdKAZGPUTObNKRDSytW18UZt23vKcDslPh4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Xw3SAVfQ2SdIcFHTAeL9yMCDjxiu4jtSKOIO3BlIuGChyQjvZHENjV1u11oHymXwtCmTPTPgZWZixIx5P3E0VFFjt14JaeIzoo88AcqMdSkMZqz16G+5z8xU65V3gwWoriM6G0H+ZNN/IhqZNGu+9KGctFBNGGShfukCwptef0w= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=makrotopia.org; spf=pass smtp.mailfrom=makrotopia.org; arc=none smtp.client-ip=185.142.180.65 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=makrotopia.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=makrotopia.org Received: from local by pidgin.makrotopia.org with esmtpsa (TLS1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.99) (envelope-from ) id 1vkrH3-0000000032J-2LNZ; Tue, 27 Jan 2026 22:11:01 +0000 Date: Tue, 27 Jan 2026 22:10:58 +0000 From: Daniel Golle To: Vladimir Oltean Cc: Hauke Mehrtens , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Rob Herring , Krzysztof Kozlowski , Conor Dooley , netdev@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH net-next 1/3] dt-bindings: net: dsa: lantiq,gswip: reference common PHY properties Message-ID: References: <20260127132919.xsvapgqc65f44iah@skbuf> <20260127150747.lzlfzhusywluuxhs@skbuf> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260127150747.lzlfzhusywluuxhs@skbuf> 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?