Re: [PATCH v14 00/15] phy: Add support for Lynx 10G SerDes

From: Vladimir Oltean <vladimir.oltean@nxp.com>
To: Sean Anderson <sean.anderson@seco.com>
Cc: "Ioana Ciornei" <ioana.ciornei@nxp.com>,
	"Vinod Koul" <vkoul@kernel.org>,
	"Kishon Vijay Abraham I" <kishon@kernel.org>,
	linux-phy@lists.infradead.org,
	"Madalin Bucur" <madalin.bucur@nxp.com>,
	linux-arm-kernel@lists.infradead.org,
	"Camelia Alexandra Groza" <camelia.groza@nxp.com>,
	devicetree@vger.kernel.org, "Rob Herring" <robh+dt@kernel.org>,
	linuxppc-dev@lists.ozlabs.org,
	"Bagas Sanjaya" <bagasdotme@gmail.com>,
	"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
	"Bartosz Golaszewski" <brgl@bgdev.pl>,
	"Fern├índez Rojas" <noltari@gmail.com>,
	"Jonas Gorski" <jonas.gorski@gmail.com>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Li Yang" <leoyang.li@nxp.com>,
	"Linus Walleij" <linus.walleij@linaro.org>,
	"Michael Turquette" <mturquette@baylibre.com>,
	"Shawn Guo" <shawnguo@kernel.org>,
	"Stephen Boyd" <sboyd@kernel.org>,
	linux-clk@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-gpio@vger.kernel.org
Subject: Re: [PATCH v14 00/15] phy: Add support for Lynx 10G SerDes
Date: Mon, 21 Aug 2023 22:58:23 +0300	[thread overview]
Message-ID: <20230821195823.ns55h3livxgol7fp@skbuf> (raw)
In-Reply-To: <73d59dd2-88f0-3c1a-0de2-de2e050cba5a@seco.com>

On Mon, Aug 21, 2023 at 02:46:53PM -0400, Sean Anderson wrote:
> After further review, it seems the reason 28g can get away without this
> is because there's a one-to-one mapping between protocol controllers and
> lanes. Unfortunately, that regularity is not present for 10g.
> 
> --Sean

There are some things I saw in your phy-fsl-lynx-10g.c driver and device
tree bindings that I don't understand (the concept of lane groups), and
I'm not sure if they're related with what you're saying here, so if you
could elaborate a bit more (ideally with an example) on the one-to-one
mapping and the specific problems it causes, it would be great.

I may be off with my understanding of the regularity you are talking about,
but the LX2160 (and Lynx 28G block) also has multi-lane protocols like 40G,
100G, assuming that's what you are talking about. I haven't started yet
working on those for the mtip_backplane driver, but I'm not currently
seeing a problem with the architecture where a phy_device represents a
single lane that's part of a multi-lane port, and not an entire group.

In my imagination, there are 2 cases:
- all 4 lanes are managed by the single dpaa2-mac consumer (which has 4
  phandles, and iterates over them with a "for" loop)
- each of the 4 lanes is managed by the respective backplane AN/LT core,
  and thus, there's one phandle to each lane

I sketched some dt-bindings for the second case here, so I guess it must
be the first scenario that's somehow problematic?
https://patchwork.kernel.org/project/netdevbpf/patch/20230817150644.3605105-9-vladimir.oltean@nxp.com/

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel