On Tue, Oct 31, 2023 at 08:28:47AM +0100, Oleksij Rempel wrote: > Transferring these issues to KSZ8863, we might face difficulties configuring > STMMAC if KSZ8863, acting as the clock provider, isn't enabled early before MAC > driver probing, a tricky scenario in the DSA framework. So for each driver, there are 2 components to using CCF for MAC/PHY interface clocks, one is providing what you have, and the other is requesting what you need. To avoid circular dependencies, we should make the clock provider per DSA port be independent of the DSA driver itself. That is because, as you point out in your example, the conduit interface (stmmac) may depend on a clock provided by the switch, but the switch also depends on the conduit being fully probed. Stronger separation / more granular dependencies was one reason why I wanted for more DSA drivers to follow Colin Foster's suit, but I stopped working on that too: https://lore.kernel.org/lkml/20221222134844.lbzyx5hz7z5n763n@skbuf/ but in the case of interface clocks, the separation is not so clear. I would expect that for most if not all switches, the interface clock is implicitly provided by enabling and configuring the respective MAC, the same MAC that is intrinsically controlled through phylink by the main DSA (switching IP) driver. So we have 2 APIs for controlling the same piece of hardware, I'm not sure how conflicting requests are supposed to be resolved. This piece of the puzzle is quite complicated to fit into the larger architecture in a coherent way, although I'm not arguing that there will also be benefits.
