From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-182.mta1.migadu.com (out-182.mta1.migadu.com [95.215.58.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CC7FC41B362 for ; Wed, 1 Apr 2026 16:37:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.182 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775061462; cv=none; b=bfAdFW1Li0i2p1hgGfQwrV0JJ4ehHqhag+dDcNEtiebcvXlgRkj2F4Rzb3H9rieA5DWa15SLBC/hzdmGlMbke/f/xfl5VQp5cIFlSublTw6BrDjm9VMXWVbqv/N7bQseikhIsZGxSJ+NMWkeC9XMS5FDe+38Bnx1uf9HxhDehps= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775061462; c=relaxed/simple; bh=nuoQhq0m6dI/iXvqGriSqSvBUUReXI7pTT5nO34AccU=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=tQb9XQ+VONsjeZR87rIwBg9E+fdG02QJAgnOqmzZb1UGYrDXuGzPQ6zFFDJXGMkJNtHpYwweI2AJjuLZ5kIfQ8XMNiccpIhZaCH2bF+isvY6JHx+ZLk+0sTuKzzvbtoWACtxvgMYnWaVciDwzi+NcQZL5MDrPdipi4e3daZMh58= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=TANrpt4y; arc=none smtp.client-ip=95.215.58.182 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="TANrpt4y" Message-ID: <360f36e2-4ff9-4707-b661-be242970811d@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1775061452; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ok/UIDzQfKSCTfq4WRzgEXWxUjOMvqRKwtV5Slboj8g=; b=TANrpt4yphvmQ4ahVR/spQ0/y1JrAGnaBmDSYOzpAfxCl9HyAQRXQFCN4JUISRc+fEfxAj VMRGzA+y+uNsD4WfICae9yi5mePINQqVTVCa5Y19KKFqK1Z9ND8twQJUhsXTFALUCsxHYb BmYCgzYaVoCSyGscnzP/3zr4MLVMUbY= Date: Wed, 1 Apr 2026 17:37:21 +0100 Precedence: bulk X-Mailing-List: linux-doc@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH net-next v3 2/3] dpll: add frequency monitoring callback ops To: Ivan Vecera , netdev@vger.kernel.org Cc: Arkadiusz Kubalewski , "David S. Miller" , Donald Hunter , Eric Dumazet , Jakub Kicinski , Jiri Pirko , Jonathan Corbet , Michal Schmidt , Paolo Abeni , Petr Oros , Prathosh Satish , Shuah Khan , Simon Horman , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org References: <20260401091237.1071995-1-ivecera@redhat.com> <20260401091237.1071995-3-ivecera@redhat.com> Content-Language: en-US X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Vadim Fedorenko In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT On 01/04/2026 17:29, Ivan Vecera wrote: > Hi Vadim, > > 1. dubna 2026 16:47:21 SELČ, Vadim Fedorenko napsal: >> On 01/04/2026 10:12, Ivan Vecera wrote: >>> Add new callback operations for a dpll device: >>> - freq_monitor_get(..) - to obtain current state of frequency monitor >>> feature from dpll device, >>> - freq_monitor_set(..) - to allow feature configuration. >>> >>> Add new callback operation for a dpll pin: >>> - measured_freq_get(..) - to obtain the measured frequency in mHz. >>> >>> Obtain the feature state value using the get callback and provide it to >>> the user if the device driver implements callbacks. The measured_freq_get >>> pin callback is only invoked when the frequency monitor is enabled. >>> The freq_monitor_get device callback is required when measured_freq_get >>> is provided by the driver. >>> >>> Execute the set callback upon user requests. >>> >>> Reviewed-by: Vadim Fedorenko >>> Signed-off-by: Ivan Vecera >>> --- >>> Changes v2 -> v3: >>> - Made freq_monitor_get required when measured_freq_get is present (Jakub) >>> >>> Changes v1 -> v2: >>> - Renamed actual-frequency to measured-frequency (Vadim) >>> --- >>> drivers/dpll/dpll_netlink.c | 92 +++++++++++++++++++++++++++++++++++++ >>> include/linux/dpll.h | 10 ++++ >>> 2 files changed, 102 insertions(+) >>> >>> diff --git a/drivers/dpll/dpll_netlink.c b/drivers/dpll/dpll_netlink.c >>> index 83cbd64abf5a4..576d0cd074bd4 100644 >>> --- a/drivers/dpll/dpll_netlink.c >>> +++ b/drivers/dpll/dpll_netlink.c >>> @@ -175,6 +175,26 @@ dpll_msg_add_phase_offset_monitor(struct sk_buff *msg, struct dpll_device *dpll, >>> return 0; >>> } >>> +static int >>> +dpll_msg_add_freq_monitor(struct sk_buff *msg, struct dpll_device *dpll, >>> + struct netlink_ext_ack *extack) >>> +{ >>> + const struct dpll_device_ops *ops = dpll_device_ops(dpll); >>> + enum dpll_feature_state state; >>> + int ret; >>> + >>> + if (ops->freq_monitor_set && ops->freq_monitor_get) { >>> + ret = ops->freq_monitor_get(dpll, dpll_priv(dpll), >>> + &state, extack); >>> + if (ret) >>> + return ret; >>> + if (nla_put_u32(msg, DPLL_A_FREQUENCY_MONITOR, state)) >>> + return -EMSGSIZE; >>> + } >>> + >>> + return 0; >>> +} >>> + >>> static int >>> dpll_msg_add_phase_offset_avg_factor(struct sk_buff *msg, >>> struct dpll_device *dpll, >>> @@ -400,6 +420,40 @@ static int dpll_msg_add_ffo(struct sk_buff *msg, struct dpll_pin *pin, >>> ffo); >>> } >>> +static int dpll_msg_add_measured_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->dpll); >>> + const struct dpll_pin_ops *ops = dpll_pin_ops(ref); >>> + struct dpll_device *dpll = ref->dpll; >>> + enum dpll_feature_state state; >>> + u64 measured_freq; >>> + int ret; >>> + >>> + if (!ops->measured_freq_get) >>> + return 0; >>> + if (WARN_ON(!dev_ops->freq_monitor_get)) >>> + return -EINVAL; >> >> I think pin registration function has to be adjusted to not allow >> measured_freq_get() callback if device doesn't have freq_monitor_get() >> callback (or both freq_monitor_{s,g}et). Then this defensive part can >> be completely removed. > > Ok, make sense... Will move such check to pin registration function... > > Q: with WARN_ON or without? Well, we have to provide reason for blocking device registration somehow, and the only way to this is via "WARN_ON"... > > Thanks > Ivan >