Mon, Jul 07, 2025 at 11:46:54AM +0200, ivecera@xxxxxxxxxx wrote: > > >On 07. 07. 25 10:32 dop., Jiri Pirko wrote: >> Fri, Jul 04, 2025 at 08:22:02PM +0200, ivecera@xxxxxxxxxx wrote: >> >> [...] >> >> > +static int >> > +zl3073x_dpll_input_pin_frequency_set(const struct dpll_pin *dpll_pin, >> > + void *pin_priv, >> > + const struct dpll_device *dpll, >> > + void *dpll_priv, u64 frequency, >> > + struct netlink_ext_ack *extack) >> >> Unrelated to this patch, but ny idea why we don't implement >> "FREQUENCY_CAN_CHANGE" capability. I think we are missing it. >> >Interesting question... from the driver API it is not necessary >as the DPLL core can deduce FREQUENCY_CAN_CHANGE from existence >of pin_frequency_set() callback and also if the pin reports >empty or single item supported-frequencies list. Yep, the same applies to the rest of the set function. You may always check the setter it present. I don't recollect why we have capabilities like we have them. > >Ivan >
