Hi Sean,

On Fri, Aug 11, 2023 at 07:36:37PM +0300, Vladimir Oltean wrote:

Let me explain that approach, because your mention of "swapping out the
bootloaders" makes it appear as if you are not visualising what I am
proposing.

The Lynx SerDes family has 2 PLLs, and more lanes (4 or 8). Each lane
uses one PLL or the other, to derive its protocol frequency. Through the
RCW, you provision the 2 PLL frequencies that may be used by the lanes
at runtime.

The Lynx 28G SerDes driver reads the PLL frequencies in
lynx_28g_pll_read_configuration(), and determines the interface modes
supportable by each PLL (this is used by phylink). But it never changes
those PLL frequencies, since that operation is practically impossible in
the general sense (PLLs are shared by multiple lanes, so changing a PLL
frequency disrupts all lanes that use it).

Is my high-level feedback clear and actionable to you? I am suggesting
to keep the look and feel the same between the lynx-10g and lynx-28g
drivers, and to not use "fsl,type" protocols listed in the device tree
as the immutable source of information for populating mode->protos, but
instead the current PLL frequency configuration. So this implies that I
am requesting that the dt-bindings should not contain a listing of the
supported protocols.

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