On 8/21/23 14:13, Ioana Ciornei wrote: > On Mon, Aug 21, 2023 at 01:45:44PM -0400, Sean Anderson wrote: >> Well, we have two pieces of information we need >> >> - What values do we need to program in the PCCRs to select a particular >> mode? This includes whether to e.g. set the KX bits. >> - Implied by the above, what protocols are supported on which lanes? >> This is not strictly necessary, but will certainly solve a lot of >> headscratching. >> >> This information varies between different socs, and different serdes on >> the same socs. We can't really look at the RCW or the clocks and figure >> out what we need to program. So what are our options? >> >> - We can have a separate compatible for each serdes on each SoC (e.g. >> "fsl,lynx-10g-a"). This was rejected by the devicetree maintainers. >> - We can have one compatible for each SoC, and determine the serdes >> based on the address. I would like to avoid this... > > To me this really seems like a straightforward approach. Indeed it would be straightforward, but what's the point of having a devicetree in the first place then? We could just go back to being a (non-dt) platform device. >> - We can stick all the details which vary between serdes/socs into the >> device tree. This is very flexible, since supporting new SoCs is >> mostly a matter of adding a new compatible and writing a new >> devicetree. On the other hand, if you have a bug in your devicetree, >> it's not easy to fix it in the kernel. >> - Just don't support protocol switching. The 28G driver does this, which >> is why it only has one compatible. However, supporting protocol >> switching is a core goal of this driver, so dropping support is not an >> option. >> > > The Lynx 28G SerDes driver does support protocol switching. > How did you arrive at the opposite conclusion? Sorry, it's been a while and I just did a quick look-over, and noticed there was no configuration for different SoCs. 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 > The initial commit on the driver is even part of a patch set named > "dpaa2-mac: add support for changing the protocol at runtime". In > upstream it only supports the 1G <-> 10G transition but I have some > patches on the way to also support 25G. > > Ioana
