On 30/03/2026 09:52, Ivan Vecera wrote:

On 3/26/26 6:48 PM, Ivan Vecera wrote:

quoted

On 3/26/26 12:21 PM, Vadim Fedorenko wrote:

quoted

On 25/03/2026 19:39, Ivan Vecera wrote:

quoted

+static int dpll_msg_add_actual_freq(struct sk_buff *msg, struct 
dpll_pin *pin,
+                    struct dpll_pin_ref *ref,
+                    struct netlink_ext_ack *extack)
+{
+    const struct dpll_device_ops *dev_ops = dpll_device_ops(ref- 

quoted

dpll);

+    const struct dpll_pin_ops *ops = dpll_pin_ops(ref);
+    struct dpll_device *dpll = ref->dpll;
+    enum dpll_feature_state state;
+    u64 actual_freq;
+    int ret;
+
+    if (!ops->actual_freq_get)
+        return 0;
+    if (dev_ops->freq_monitor_get) {
+        ret = dev_ops->freq_monitor_get(dpll, dpll_priv(dpll),
+                        &state, extack);
+        if (ret)
+            return ret;
+        if (state == DPLL_FEATURE_STATE_DISABLE)
+            return 0;

I think we have to signal back to user that frequency monitoring is
disabled via extack.

Hi Vadim,

This would break pin-get operation... Do or dump pin-get operation would
fail with this extack message.

Here we can check if the freq-monitoring is enabled and conditionally
call actual_freq_get() or measured_freq_get()

Let's make it this way, we don't want to waste even small amount of
resources for useless call.

quoted

-or-

Call this callback unconditionally and check for return code and if a
driver returns e.g. -ENODATA then skip nla_put_64bit() but return
success.

WDYT?

Vadim?

Sorry, was AFK this Friday/weekend