On Sun, Jul 16, 2023 at 6:07 PM Andrew Lunn <andrew@xxxxxxx> wrote: > > > So, there's the adin.c PHY driver which has a similar functionality > > with the adin_config_clk_out(). > > Something in the micrel.c PHY driver (with > > micrel,rmii-reference-clock-select-25-mhz); hopefully I did not > > misread the code about that one. > > And the at803x.c PHY driver has a 'qca,clk-out-frequency' property too. > > > > Now with the mscc.c driver, there is a common-ality that could use a framework. > > > > @Rob are you suggesting something like registering a clock provider > > (somewhere in the PHY framework) and let the PHY drivers use it? > > Usually, these clock signals (once enabled on startup), don't get > > turned off; but I've worked mostly on reference designs; somewhere > > down the line some people get different requirements. > > These clocks get connected back to the MAC (usually), and are usually > > like a "fixed-clock" driver. > > They are not necessarily fixed clocks. The clock you are adding here > has three frequencies. Two frequencies is common for PHY devices. So > you need to use something more than clk-fixed-rate.c. Also, mostly > PHYs allows the clock to be gated. > > > In our case, turning off the clock would be needed if the PHY > > negotiates a non-gigabit link; i.e 100 or 10 Mbps; in that case, the > > CLKOUT signal is not needed and it can be turned off. > > Who does not need it? The PHY, or the MAC? If it is the MAC, it should > really be the MAC driver which uses the common clock API to turn it > off. Just watch out for deadlocks with phydev->lock. The MAC needs the clock in GMII mode, when going in gigabit mode. > > > Maybe start out with a hook in 'struct phy_driver'? > > Like "int (*config_clk_out)(struct phy_device *dev);" or something? > > And underneath, this delegates to the CLK framework? > > Yes, have phy_device.c implement that registration/unregister of the > clock, deal with locking, and call into the PHY driver to actually > manipulate the clock. You missed the requested frequency in the > function prototype. I would also call it refclk. Three is sometimes > confusion about the different clocks. Ack. Then something like: int (*config_refclk)(struct phy_device *dev, uint32_t frequency); > > Traditionally, clk_enable() can be called in atomic context, but that > is not allowed with phylib, it always assume thread context. I don't > know if the clock framework has some helpers for that, but i also > don't see there being a real need for MAC to enable the clock in > atomic context. > > Andrew
