linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Jiri Pirko <jiri@resnulli.us>
To: Vadim Fedorenko <vadfed@meta.com>
Cc: Jakub Kicinski <kuba@kernel.org>,
	Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>,
	Jonathan Lemon <jonathan.lemon@gmail.com>,
	Paolo Abeni <pabeni@redhat.com>,
	Vadim Fedorenko <vadim.fedorenko@linux.dev>,
	poros@redhat.com, mschmidt@redhat.com, netdev@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, linux-clk@vger.kernel.org,
	Milena Olech <milena.olech@intel.com>,
	Michal Michalik <michal.michalik@intel.com>
Subject: Re: [PATCH RFC v6 2/6] dpll: Add DPLL framework base functions
Date: Fri, 24 Mar 2023 10:29:01 +0100	[thread overview]
Message-ID: <ZB1tXZZp+g5o7wRM@nanopsycho> (raw)
In-Reply-To: <20230312022807.278528-3-vadfed@meta.com>

Sun, Mar 12, 2023 at 03:28:03AM CET, vadfed@meta.com wrote:

[...]


>+static int
>+dpll_msg_add_pin_direction(struct sk_buff *msg, const struct dpll_pin *pin,
>+			   struct netlink_ext_ack *extack)
>+{
>+	enum dpll_pin_direction direction;
>+	struct dpll_pin_ref *ref;
>+	unsigned long i;
>+
>+	xa_for_each((struct xarray *)&pin->dpll_refs, i, ref) {
>+		if (ref && ref->ops && ref->dpll)
>+			break;
>+	}
>+	if (!ref || !ref->ops || !ref->dpll)
>+		return -ENODEV;
>+	if (!ref->ops->direction_get)
>+		return -EOPNOTSUPP;
>+	if (ref->ops->direction_get(pin, ref->dpll, &direction, extack))
>+		return -EFAULT;
>+	if (nla_put_u8(msg, DPLL_A_PIN_DIRECTION, direction))
>+		return -EMSGSIZE;
>+
>+	return 0;
>+}
>+
>+static int
>+dpll_msg_add_pin_freq(struct sk_buff *msg, const struct dpll_pin *pin,
>+		      struct netlink_ext_ack *extack, bool dump_any_freq)
>+{
>+	enum dpll_pin_freq_supp fs;
>+	struct dpll_pin_ref *ref;
>+	unsigned long i;
>+	u32 freq;
>+
>+	xa_for_each((struct xarray *)&pin->dpll_refs, i, ref) {
>+		if (ref && ref->ops && ref->dpll)

Checking for "ref" is nonsense here, as xa_for_each fills it up
for every iteration.

ref->dpll is always filled. Also pointless check.

Does it make sense to register with ops==NULL? I think we should
forbid it and make this just xa_find(0) to get the first item in the
xarray.

I'm doing this in my patch, as it is dependency on some other patch I do
in this area.


>+			break;
>+	}
>+	if (!ref || !ref->ops || !ref->dpll)
>+		return -ENODEV;
>+	if (!ref->ops->frequency_get)
>+		return -EOPNOTSUPP;
>+	if (ref->ops->frequency_get(pin, ref->dpll, &freq, extack))
>+		return -EFAULT;
>+	if (nla_put_u32(msg, DPLL_A_PIN_FREQUENCY, freq))
>+		return -EMSGSIZE;
>+	if (!dump_any_freq)
>+		return 0;
>+	for (fs = DPLL_PIN_FREQ_SUPP_UNSPEC + 1;
>+	     fs <= DPLL_PIN_FREQ_SUPP_MAX; fs++) {
>+		if (test_bit(fs, &pin->prop.freq_supported)) {
>+			if (nla_put_u32(msg, DPLL_A_PIN_FREQUENCY_SUPPORTED,
>+			    dpll_pin_freq_value[fs]))
>+				return -EMSGSIZE;
>+		}
>+	}
>+	if (pin->prop.any_freq_min && pin->prop.any_freq_max) {
>+		if (nla_put_u32(msg, DPLL_A_PIN_ANY_FREQUENCY_MIN,
>+				pin->prop.any_freq_min))
>+			return -EMSGSIZE;
>+		if (nla_put_u32(msg, DPLL_A_PIN_ANY_FREQUENCY_MAX,
>+				pin->prop.any_freq_max))
>+			return -EMSGSIZE;
>+	}
>+
>+	return 0;
>+}
>+

[...]


>+static int
>+dpll_cmd_pin_on_dpll_get(struct sk_buff *msg, struct dpll_pin *pin,
>+			 struct dpll_device *dpll,
>+			 struct netlink_ext_ack *extack)
>+{
>+	struct dpll_pin_ref *ref;
>+	int ret;
>+
>+	if (nla_put_u32(msg, DPLL_A_PIN_IDX, pin->dev_driver_id))
>+		return -EMSGSIZE;
>+	if (nla_put_string(msg, DPLL_A_PIN_DESCRIPTION, pin->prop.description))
>+		return -EMSGSIZE;
>+	if (nla_put_u8(msg, DPLL_A_PIN_TYPE, pin->prop.type))
>+		return -EMSGSIZE;
>+	if (nla_put_u32(msg, DPLL_A_PIN_DPLL_CAPS, pin->prop.capabilities))
>+		return -EMSGSIZE;
>+	ret = dpll_msg_add_pin_direction(msg, pin, extack);
>+	if (ret)

Why -EOPNOTSUPP here is not ok, as for the others below?


>+		return ret;
>+	ret = dpll_msg_add_pin_freq(msg, pin, extack, true);
>+	if (ret && ret != -EOPNOTSUPP)
>+		return ret;
>+	ref = dpll_xa_ref_dpll_find(&pin->dpll_refs, dpll);
>+	if (!ref)

How this can happen? I don't think it could.


>+		return -EFAULT;
>+	ret = dpll_msg_add_pin_prio(msg, pin, ref, extack);
>+	if (ret && ret != -EOPNOTSUPP)
>+		return ret;
>+	ret = dpll_msg_add_pin_on_dpll_state(msg, pin, ref, extack);
>+	if (ret && ret != -EOPNOTSUPP)
>+		return ret;
>+	ret = dpll_msg_add_pin_parents(msg, pin, extack);
>+	if (ret)
>+		return ret;
>+	if (pin->rclk_dev_name)
>+		if (nla_put_string(msg, DPLL_A_PIN_RCLK_DEVICE,
>+				   pin->rclk_dev_name))
>+			return -EMSGSIZE;
>+
>+	return 0;
>+}
>+
>+static int
>+__dpll_cmd_pin_dump_one(struct sk_buff *msg, struct dpll_pin *pin,
>+			struct netlink_ext_ack *extack, bool dump_dpll)
>+{
>+	int ret;
>+
>+	if (nla_put_u32(msg, DPLL_A_PIN_IDX, pin->dev_driver_id))
>+		return -EMSGSIZE;
>+	if (nla_put_string(msg, DPLL_A_PIN_DESCRIPTION, pin->prop.description))
>+		return -EMSGSIZE;
>+	if (nla_put_u8(msg, DPLL_A_PIN_TYPE, pin->prop.type))
>+		return -EMSGSIZE;
>+	ret = dpll_msg_add_pin_direction(msg, pin, extack);
>+	if (ret)
>+		return ret;
>+	ret = dpll_msg_add_pin_freq(msg, pin, extack, true);
>+	if (ret && ret != -EOPNOTSUPP)
>+		return ret;
>+	ret = dpll_msg_add_pins_on_pin(msg, pin, extack);
>+	if (ret)
>+		return ret;
>+	if (!xa_empty(&pin->dpll_refs) && dump_dpll) {

How dpll refs could be empty? I don't think it is possible.

Overall, whole the code has very odd habit of checking for conditions
that are obviously impossible to happen. Only confuses reader as he
naturally expects that the check is there for a reason.



>+		ret = dpll_msg_add_pin_dplls(msg, pin, extack);
>+		if (ret)
>+			return ret;
>+	}
>+	if (pin->rclk_dev_name)
>+		if (nla_put_string(msg, DPLL_A_PIN_RCLK_DEVICE,
>+				   pin->rclk_dev_name))
>+			return -EMSGSIZE;
>+
>+	return 0;
>+}
>+

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2023-03-24  9:30 UTC|newest]

Thread overview: 94+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-12  2:28 [PATCH RFC v6 0/6] Create common DPLL/clock configuration API Vadim Fedorenko
2023-03-12  2:28 ` [PATCH RFC v6 1/6] dpll: spec: Add Netlink spec in YAML Vadim Fedorenko
2023-03-14 14:44   ` Jiri Pirko
2023-03-16 13:15     ` Kubalewski, Arkadiusz
2023-03-16 13:45       ` Jiri Pirko
2023-03-16 15:19         ` Jiri Pirko
2023-03-17  0:53           ` Kubalewski, Arkadiusz
2023-03-17 10:07             ` Jiri Pirko
2023-03-17  0:52         ` Kubalewski, Arkadiusz
2023-03-17 10:05           ` Jiri Pirko
2023-03-17 14:29             ` Jiri Pirko
2023-03-17 15:14             ` Kubalewski, Arkadiusz
2023-03-17 16:20               ` Jiri Pirko
2023-03-17 18:22                 ` Kubalewski, Arkadiusz
2023-03-20  8:10                   ` Jiri Pirko
2023-03-21  4:05       ` Jakub Kicinski
2023-03-21  4:13         ` Jakub Kicinski
2023-03-21  4:20           ` Jakub Kicinski
2023-03-17 16:23   ` Jiri Pirko
2023-03-21  4:00     ` Jakub Kicinski
2023-03-17 16:53   ` Jiri Pirko
2023-03-17 18:50     ` Kubalewski, Arkadiusz
2023-03-12  2:28 ` [PATCH RFC v6 2/6] dpll: Add DPLL framework base functions Vadim Fedorenko
2023-03-13 16:21   ` Jiri Pirko
2023-03-13 22:59     ` Vadim Fedorenko
2023-03-14 16:43       ` Kubalewski, Arkadiusz
2023-03-15 12:14         ` Jiri Pirko
     [not found]       ` <ZBA8ofFfKigqZ6M7@nanopsycho>
2023-03-14 17:50         ` Kubalewski, Arkadiusz
2023-03-15  9:22           ` Jiri Pirko
2023-03-16 12:31             ` Jiri Pirko
2023-03-28 15:22             ` Vadim Fedorenko
2023-04-01 12:49               ` Jiri Pirko
2023-04-03 18:18             ` Jakub Kicinski
2023-04-09  7:51               ` Jiri Pirko
     [not found]                 ` <20230410153149.602c6bad@kernel.org>
2023-04-16 16:23                   ` Jiri Pirko
2023-04-17 15:53                     ` Vadim Fedorenko
     [not found]                     ` <20230417124942.4305abfa@kernel.org>
2023-04-27  8:05                       ` Paolo Abeni
2023-04-27 10:20                         ` Vadim Fedorenko
     [not found]                       ` <ZFDPaXlJainSOqmV@nanopsycho>
     [not found]                         ` <20230502083244.19543d26@kernel.org>
2023-05-03  7:56                           ` Jiri Pirko
2023-05-04  2:16                             ` Jakub Kicinski
2023-05-04 11:00                               ` Jiri Pirko
2023-05-04 11:14                                 ` Jiri Pirko
2023-05-04 16:04                                 ` Jakub Kicinski
2023-05-04 17:51                                   ` Jiri Pirko
2023-05-04 18:44                                     ` Jakub Kicinski
2023-05-05 10:41                                       ` Jiri Pirko
2023-05-05 15:35                                         ` Jakub Kicinski
2023-05-07  7:58                                           ` Jiri Pirko
2023-03-14 15:45   ` Jiri Pirko
2023-03-14 18:35     ` Kubalewski, Arkadiusz
2023-03-15 14:43       ` Jiri Pirko
2023-03-15 15:29   ` Jiri Pirko
2023-03-16 12:20   ` Jiri Pirko
2023-03-16 12:37   ` Jiri Pirko
2023-03-16 13:53   ` Jiri Pirko
2023-03-16 16:16   ` Jiri Pirko
2023-03-17 16:21   ` Jiri Pirko
2023-03-20 10:24   ` Jiri Pirko
2023-03-21 13:34   ` Jiri Pirko
2023-03-23 11:18   ` Jiri Pirko
2023-03-24  9:29   ` Jiri Pirko [this message]
2023-03-12  2:28 ` [PATCH RFC v6 3/6] dpll: documentation on DPLL subsystem interface Vadim Fedorenko
2023-03-14 16:14   ` Jiri Pirko
2023-04-03 10:21     ` Kubalewski, Arkadiusz
2023-03-16 13:46   ` Jiri Pirko
2023-04-03 10:23     ` Kubalewski, Arkadiusz
2023-03-12  2:28 ` [PATCH RFC v6 4/6] ice: add admin commands to access cgu configuration Vadim Fedorenko
2023-03-12  2:28 ` [PATCH RFC v6 5/6] ice: implement dpll interface to control cgu Vadim Fedorenko
2023-03-12  2:28 ` [PATCH RFC v6 6/6] ptp_ocp: implement DPLL ops Vadim Fedorenko
     [not found]   ` <ZBBG2xRhLOIPMD0+@nanopsycho>
2023-03-15  0:10     ` Vadim Fedorenko
2023-03-15 12:24       ` Jiri Pirko
2023-03-31 23:28         ` Vadim Fedorenko
2023-04-01 12:53           ` Jiri Pirko
2023-03-15 15:34   ` Jiri Pirko
2023-03-15 15:52     ` Vadim Fedorenko
2023-03-16 12:12   ` Jiri Pirko
2023-03-13 12:20 ` [PATCH RFC v6 0/6] Create common DPLL/clock configuration API Jiri Pirko
2023-03-13 15:33   ` Vadim Fedorenko
2023-03-13 16:22     ` Jiri Pirko
2023-03-13 16:31       ` Vadim Fedorenko
2023-03-17 16:10     ` Jiri Pirko
2023-03-18  5:01       ` Jakub Kicinski
2023-03-23 11:21 ` Jiri Pirko
2023-03-23 18:00   ` Vadim Fedorenko
2023-03-26 17:00 ` [patch dpll-rfc 0/7] dpll: initial patchset extension by mlx5 implementation Jiri Pirko
2023-03-26 17:00   ` [patch dpll-rfc 1/7] dpll: make ops function args const Jiri Pirko
2023-03-26 17:00   ` [patch dpll-rfc 2/7] dpll: allow to call device register multiple times Jiri Pirko
2023-03-26 17:00   ` [patch dpll-rfc 3/7] dpll: introduce a helper to get first dpll ref and use it Jiri Pirko
2023-03-26 17:00   ` [patch dpll-rfc 4/7] dpll: allow to call pin register multiple times Jiri Pirko
2023-03-26 17:00   ` [patch dpll-rfc 5/7] dpll: export dpll_pin_notify() Jiri Pirko
2023-03-26 17:00   ` [patch dpll-rfc 6/7] netdev: expose DPLL pin handle for netdevice Jiri Pirko
2023-03-26 17:00   ` [patch dpll-rfc 7/7] mlx5: Implement SyncE support using DPLL infrastructure Jiri Pirko
2023-03-28 16:36   ` [patch dpll-rfc 0/7] dpll: initial patchset extension by mlx5 implementation Vadim Fedorenko
2023-04-01 12:54     ` Jiri Pirko

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=ZB1tXZZp+g5o7wRM@nanopsycho \
    --to=jiri@resnulli.us \
    --cc=arkadiusz.kubalewski@intel.com \
    --cc=jonathan.lemon@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=michal.michalik@intel.com \
    --cc=milena.olech@intel.com \
    --cc=mschmidt@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=poros@redhat.com \
    --cc=vadfed@meta.com \
    --cc=vadim.fedorenko@linux.dev \
    /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).