From: Vadim Fedorenko <vadim.fedorenko@linux.dev>
To: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>,
netdev@vger.kernel.org
Cc: jiri@resnulli.us, corbet@lwn.net, davem@davemloft.net,
kuba@kernel.org, pabeni@redhat.com, jesse.brandeburg@intel.com,
anthony.l.nguyen@intel.com, linux-doc@vger.kernel.org,
intel-wired-lan@lists.osuosl.org
Subject: Re: [PATCH net-next 3/4] dpll: netlink/core: add support for pin-dpll signal phase offset/adjust
Date: Wed, 27 Sep 2023 19:09:07 +0100 [thread overview]
Message-ID: <4018c0b0-b288-ff60-09be-7ded382f4a82@linux.dev> (raw)
In-Reply-To: <20230927092435.1565336-4-arkadiusz.kubalewski@intel.com>
On 27/09/2023 10:24, Arkadiusz Kubalewski wrote:
> Add callback op (get) for pin-dpll phase-offset measurment.
> Add callback ops (get/set) for pin signal phase adjustment.
> Add min and max phase adjustment values to pin proprties.
> Invoke get callbacks when filling up the pin details to provide user
> with phase related attribute values.
> Invoke phase-adjust set callback when phase-adjust value is provided for
> pin-set request.
>
> Signed-off-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>
[...]
> +static int
> +dpll_pin_phase_adj_set(struct dpll_pin *pin, struct nlattr *phase_adj_attr,
> + struct netlink_ext_ack *extack)
> +{
> + struct dpll_pin_ref *ref;
> + unsigned long i;
> + s32 phase_adj;
> + int ret;
> +
> + phase_adj = nla_get_s32(phase_adj_attr);
> + if (phase_adj > pin->prop->phase_range.max ||
> + phase_adj < pin->prop->phase_range.min) {
> + NL_SET_ERR_MSG(extack, "phase adjust value not supported");
> + return -EINVAL;
> + }
> + xa_for_each(&pin->dpll_refs, i, ref) {
> + const struct dpll_pin_ops *ops = dpll_pin_ops(ref);
> + struct dpll_device *dpll = ref->dpll;
> +
> + if (!ops->phase_adjust_set)
> + return -EOPNOTSUPP;
I'm thinking about this part. We can potentially have dpll devices with
different expectations on phase adjustments, right? And if one of them
won't be able to adjust phase (or will fail in the next line), then
netlink will return EOPNOTSUPP while _some_ of the devices will be
adjusted. Doesn't look great. Can we think about different way to apply
the change?
> + ret = ops->phase_adjust_set(pin,
> + dpll_pin_on_dpll_priv(dpll, pin),
> + dpll, dpll_priv(dpll), phase_adj,
> + extack);
> + if (ret)
> + return ret;
> + }
> + __dpll_pin_change_ntf(pin);
> +
> + return 0;
> +}
> +
next prev parent reply other threads:[~2023-09-27 18:16 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-27 9:24 [PATCH net-next 0/4] dpll: add phase-offset and phase-adjust Arkadiusz Kubalewski
2023-09-27 9:24 ` [PATCH net-next 1/4] dpll: docs: add support for pin signal phase offset/adjust Arkadiusz Kubalewski
2023-10-02 15:00 ` Jiri Pirko
2023-10-09 22:53 ` Kubalewski, Arkadiusz
2023-09-27 9:24 ` [PATCH net-next 2/4] dpll: spec: add support for pin-dpll " Arkadiusz Kubalewski
2023-10-02 14:53 ` Jiri Pirko
2023-10-06 10:29 ` Kubalewski, Arkadiusz
2023-09-27 9:24 ` [PATCH net-next 3/4] dpll: netlink/core: " Arkadiusz Kubalewski
2023-09-27 18:09 ` Vadim Fedorenko [this message]
2023-10-02 14:32 ` Kubalewski, Arkadiusz
2023-10-02 15:04 ` Jiri Pirko
2023-10-02 15:09 ` Vadim Fedorenko
2023-10-02 23:10 ` [Intel-wired-lan] " Kubalewski, Arkadiusz
2023-10-03 6:27 ` Jiri Pirko
2023-10-03 14:29 ` Kubalewski, Arkadiusz
2023-10-03 17:18 ` Jiri Pirko
2023-10-04 9:13 ` Kubalewski, Arkadiusz
2023-10-02 23:03 ` Kubalewski, Arkadiusz
2023-10-03 6:32 ` Jiri Pirko
2023-10-03 14:29 ` Kubalewski, Arkadiusz
2023-10-03 17:19 ` Jiri Pirko
2023-10-04 9:11 ` Kubalewski, Arkadiusz
2023-09-27 9:24 ` [PATCH net-next 4/4] ice: dpll: implement phase related callbacks Arkadiusz Kubalewski
2023-09-27 13:17 ` kernel test robot
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=4018c0b0-b288-ff60-09be-7ded382f4a82@linux.dev \
--to=vadim.fedorenko@linux.dev \
--cc=anthony.l.nguyen@intel.com \
--cc=arkadiusz.kubalewski@intel.com \
--cc=corbet@lwn.net \
--cc=davem@davemloft.net \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=jesse.brandeburg@intel.com \
--cc=jiri@resnulli.us \
--cc=kuba@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).