On 11/9/22 17:59, Vladimir Oltean wrote: > On Thu, Nov 03, 2022 at 05:06:39PM -0400, Sean Anderson wrote: >> 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@xxxxxxxx/
