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

[Sean Anderson]

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