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.