From: Vadim Fedorenko <vadim.fedorenko@linux.dev>
To: Ivan Vecera <ivecera@redhat.com>, netdev@vger.kernel.org
Cc: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>,
Jiri Pirko <jiri@resnulli.us>, Jonathan Corbet <corbet@lwn.net>,
Donald Hunter <donald.hunter@gmail.com>,
Jakub Kicinski <kuba@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Paolo Abeni <pabeni@redhat.com>, Simon Horman <horms@kernel.org>,
Prathosh Satish <Prathosh.Satish@microchip.com>,
Chuck Lever <chuck.lever@oracle.com>,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
Michal Schmidt <mschmidt@redhat.com>,
Petr Oros <poros@redhat.com>
Subject: Re: [PATCH net-next 2/3] dpll: add phase_offset_avg_factor_get/set callback ops
Date: Fri, 26 Sep 2025 16:25:58 +0100 [thread overview]
Message-ID: <3e3742a7-5cfd-4f7c-8ca9-65b1de08ec29@linux.dev> (raw)
In-Reply-To: <20250926142140.691592-3-ivecera@redhat.com>
On 26/09/2025 15:21, Ivan Vecera wrote:
> Add new callback operations for a dpll device:
> - phase_offset_avg_factor_get(...) - to obtain current phase offset
> averaging factor from dpll device,
> - phase_offset_avg_factor_set(...) - to set phase offset averaging factor
>
> Obtain the factor value using the get callback and provide it to the user
> if the device driver implements callbacks. Execute the set callback upon
> user requests.
>
> Signed-off-by: Ivan Vecera <ivecera@redhat.com>
> ---
> drivers/dpll/dpll_netlink.c | 76 +++++++++++++++++++++++++++++++++----
> include/linux/dpll.h | 6 +++
> 2 files changed, 75 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/dpll/dpll_netlink.c b/drivers/dpll/dpll_netlink.c
> index 0a852011653c4..55b3ffe08024b 100644
> --- a/drivers/dpll/dpll_netlink.c
> +++ b/drivers/dpll/dpll_netlink.c
> @@ -164,6 +164,28 @@ dpll_msg_add_phase_offset_monitor(struct sk_buff *msg, struct dpll_device *dpll,
> return 0;
> }
>
> +static int
> +dpll_msg_add_phase_offset_avg_factor(struct sk_buff *msg,
> + struct dpll_device *dpll,
> + struct netlink_ext_ack *extack)
> +{
> + const struct dpll_device_ops *ops = dpll_device_ops(dpll);
> + u32 factor;
> + int ret;
> +
> + if (ops->phase_offset_avg_factor_set &&
> + ops->phase_offset_avg_factor_get) {
> + ret = ops->phase_offset_avg_factor_get(dpll, dpll_priv(dpll),
> + &factor, extack);
Well, correct me if I'm wrong, but the device can have offset average
factor as a constant, and it can technically report it. I would make
set/get callback optional and don't require both of them to be
implemented.
> + if (ret)
> + return ret;
> + if (nla_put_u32(msg, DPLL_A_PHASE_OFFSET_AVG_FACTOR, factor))
> + return -EMSGSIZE;
> + }
> +
> + return 0;
> +}
> +
> static int
> dpll_msg_add_lock_status(struct sk_buff *msg, struct dpll_device *dpll,
> struct netlink_ext_ack *extack)
> @@ -675,6 +697,9 @@ dpll_device_get_one(struct dpll_device *dpll, struct sk_buff *msg,
> if (nla_put_u32(msg, DPLL_A_TYPE, dpll->type))
> return -EMSGSIZE;
> ret = dpll_msg_add_phase_offset_monitor(msg, dpll, extack);
> + if (ret)
> + return ret;
> + ret = dpll_msg_add_phase_offset_avg_factor(msg, dpll, extack);
> if (ret)
> return ret;
>
> @@ -839,6 +864,32 @@ dpll_phase_offset_monitor_set(struct dpll_device *dpll, struct nlattr *a,
> extack);
> }
>
> +static int
> +dpll_phase_offset_avg_factor_set(struct dpll_device *dpll, struct nlattr *a,
> + struct netlink_ext_ack *extack)
> +{
> + const struct dpll_device_ops *ops = dpll_device_ops(dpll);
> + u32 factor = nla_get_u32(a), old_factor;
> + int ret;
> +
> + if (!(ops->phase_offset_avg_factor_set &&
> + ops->phase_offset_avg_factor_get)) {
> + NL_SET_ERR_MSG_ATTR(extack, a, "dpll device not capable of phase offset averaging");
> + return -EOPNOTSUPP;
> + }
> + ret = ops->phase_offset_avg_factor_get(dpll, dpll_priv(dpll),
> + &old_factor, extack);
> + if (ret) {
> + NL_SET_ERR_MSG(extack, "unable to get current phase offset averaging factor");
> + return ret;
> + }
> + if (factor == old_factor)
> + return 0;
I don't think the core should do any checks here. If the user for some
reason wants to re-install the same value - give them a chance. Some
drivers may implement check logic if it's relevant to the hardware, but
not in general.
> +
> + return ops->phase_offset_avg_factor_set(dpll, dpll_priv(dpll), factor,
> + extack);
> +}
> +
[...]
next prev parent reply other threads:[~2025-09-26 15:26 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-26 14:21 [PATCH net-next 0/3] dpll: add phase offset averaging factor Ivan Vecera
2025-09-26 14:21 ` [PATCH net-next 1/3] dpll: add phase-offset-avg-factor device attribute to netlink spec Ivan Vecera
2025-09-26 14:21 ` [PATCH net-next 2/3] dpll: add phase_offset_avg_factor_get/set callback ops Ivan Vecera
2025-09-26 15:25 ` Vadim Fedorenko [this message]
2025-09-26 14:21 ` [PATCH net-next 3/3] dpll: zl3073x: allow to configure phase offset averaging factor Ivan Vecera
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3e3742a7-5cfd-4f7c-8ca9-65b1de08ec29@linux.dev \
--to=vadim.fedorenko@linux.dev \
--cc=Prathosh.Satish@microchip.com \
--cc=arkadiusz.kubalewski@intel.com \
--cc=chuck.lever@oracle.com \
--cc=corbet@lwn.net \
--cc=davem@davemloft.net \
--cc=donald.hunter@gmail.com \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=ivecera@redhat.com \
--cc=jiri@resnulli.us \
--cc=kuba@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mschmidt@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=poros@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.