On 10/4/2024 12:12 AM, Andrew Lunn wrote: >> Agree that switchdev is the right model for this device. We were >> planning to enable base Ethernet functionality using regular >> (non-switchdev) netdevice representation for the ports initially, >> without offload support. As the next step, L2/VLAN offload support using >> switchdev will be enabled on top. Hope this phased approach is fine. > > Since it is not a DSA switch, yes, a phased approach should be O.K. > Ok. >>>> 3) PCS driver patch series: >>>> Driver for the PCS block in IPQ9574. New IPQ PCS driver will >>>> be enabled in drivers/net/pcs/ >>>> Dependent on NSS CC patch series (2). >>> >>> I assume this dependency is pure at runtime? So the code will build >>> without the NSS CC patch series? >> >> The MII Rx/Tx clocks are supplied from the NSS clock controller to the >> PCS's MII channels. To represent this in the DTS, the PCS node in the >> DTS is configured with the MII Rx/Tx clock that it consumes, using >> macros for clocks which are exported from the NSS CC driver in a header >> file. So, there will be a compile-time dependency for the dtbindings/DTS >> on the NSS CC patch series. We will clearly call out this dependency in >> the cover letter of the PCS driver. Hope that this approach is ok. > > Since there is a compile time dependency, you might want to ask for > the clock patches to be put into a stable branch which can be merged > into netdev. > Sure. We will request for such a stable branch merge once the NSS CC patches are accepted by the reviewers. Could the 'net' tree be one such stable branch option to merge the NSS CC driver? > Or you need to wait a kernel cycle.> Understand. > Andrew
