On 11/9/22 17:59, Vladimir Oltean wrote:

On Thu, Nov 03, 2022 at 05:06:39PM -0400, Sean Anderson wrote:

quoted

For a long time, PCSs have been tightly coupled with their MACs. For
this reason, the MAC creates the "phy" or mdio device, and then passes
it to the PCS to initialize. This has a few disadvantages:

- Each MAC must re-implement the same steps to look up/create a PCS
- The PCS cannot use functions tied to device lifetime, such as devm_*.
- Generally, the PCS does not have easy access to its device tree node

Is there a clear need to solve these disadvantages? There comes extra
runtime complexity with the PCS-as-device scheme.

IMO this is actually simpler for driver implementers and consumers. You
can see this by looking at the diffstats for each of the patches. All of
the consumers are -30 or so. The driver is +30, but that's around the
length of lynx_pcs_create_on_bus (and of course the compatible strings
and driver).

(plus the extra
complexity needed to address the DT backwards compatibility problems
it causes; not addressed here).

New drivers will not need to do this backwards-compatibility dance. They
can be written like almost every other driver in the kernel. There are
parallels here with how phy devices were implemented; first as a library
without drivers (or devices), and gradually converting to devices.

This is also motivated by Xilinx platforms where the PCS can be
implemented on an FPGA. Hard-coding the PCS for the MAC is not
desirable, since the device can change when the bitstream is changed.
Additionally, the devices may need to configure e.g. resets or clocks.

I plan to post a follow-up patch for [1] adding a Xilinx PCS/PMA driver
at some point.

--Sean

[1] https://lore.kernel.org/netdev/20211004191527.1610759-1-sean.anderson@seco.com/ (local)

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