Intel-Wired-Lan Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Lobakin <aleksander.lobakin@intel.com>
To: Wojciech Drewek <wojciech.drewek@intel.com>
Cc: netdev@vger.kernel.org, alexandr.lobakin@intel.com,
	horms@kernel.org, kuba@kernel.org, anthony.l.nguyen@intel.com,
	intel-wired-lan@lists.osuosl.org
Subject: Re: [Intel-wired-lan] [PATCH iwl-next v10 07/14] iavf: add support for indirect access to PHC time
Date: Wed, 21 Aug 2024 16:31:45 +0200	[thread overview]
Message-ID: <9e708174-d6c0-4b8b-9a0d-5807463d6c43@intel.com> (raw)
In-Reply-To: <20240821121539.374343-8-wojciech.drewek@intel.com>

From: Wojciech Drewek <wojciech.drewek@intel.com>
Date: Wed, 21 Aug 2024 14:15:32 +0200

> From: Jacob Keller <jacob.e.keller@intel.com>
> 
> Implement support for reading the PHC time indirectly via the
> VIRTCHNL_OP_1588_PTP_GET_TIME operation.

[...]

> +/**
> + * iavf_queue_ptp_cmd - Queue PTP command for sending over virtchnl
> + * @adapter: private adapter structure
> + * @cmd: the command structure to send
> + *
> + * Queue the given command structure into the PTP virtchnl command queue tos
> + * end to the PF.
> + */
> +static void iavf_queue_ptp_cmd(struct iavf_adapter *adapter,
> +			       struct iavf_ptp_aq_cmd *cmd)
> +{
> +	mutex_lock(&adapter->ptp.aq_cmd_lock);
> +	list_add_tail(&cmd->list, &adapter->ptp.aq_cmds);
> +	mutex_unlock(&adapter->ptp.aq_cmd_lock);
> +
> +	adapter->aq_required |= IAVF_FLAG_AQ_SEND_PTP_CMD;
> +	mod_delayed_work(adapter->wq, &adapter->watchdog_task, 0);

Are you sure you need delayed_work here? delayed_work is used only when
you need to run it after a delay. If the delay is always 0, then you
only need work_struct and queue_work().

> +}
> +
> +/**
> + * iavf_send_phc_read - Send request to read PHC time

[...]

> +static int iavf_ptp_gettimex64(struct ptp_clock_info *info,
> +			       struct timespec64 *ts,
> +			       struct ptp_system_timestamp *sts)
> +{
> +	struct iavf_adapter *adapter = iavf_clock_to_adapter(info);
> +
> +	if (!adapter->ptp.initialized)
> +		return -ENODEV;

Why is it -ENODEV here, but -EOPNOTSUPP several functions above, are you
sure these codes are the ones expected by the upper layers?

> +
> +	return iavf_read_phc_indirect(adapter, ts, sts);
> +}

[...]

> diff --git a/drivers/net/ethernet/intel/iavf/iavf_ptp.h b/drivers/net/ethernet/intel/iavf/iavf_ptp.h
> index c2ed24cef926..0bb4bddc1495 100644
> --- a/drivers/net/ethernet/intel/iavf/iavf_ptp.h
> +++ b/drivers/net/ethernet/intel/iavf/iavf_ptp.h
> @@ -6,9 +6,13 @@
>  
>  #include "iavf_types.h"
>  
> +#define iavf_clock_to_adapter(info)				\
> +	container_of_const(info, struct iavf_adapter, ptp.info)

It's only used in one file, are you sure you need it here in the header?
Or it will be used in later patches?

[...]

> +void iavf_virtchnl_send_ptp_cmd(struct iavf_adapter *adapter)
> +{
> +	struct device *dev = &adapter->pdev->dev;
> +	struct iavf_ptp_aq_cmd *cmd;
> +	int err;
> +
> +	if (!adapter->ptp.initialized) {

BTW does it make sense to introduce ptp.initialized since you can always
check ptp.clock for being %NULL and it will be the same?

> +		/* This shouldn't be possible to hit, since no messages should
> +		 * be queued if PTP is not initialized.
> +		 */
> +		pci_err(adapter->pdev, "PTP is not initialized\n");
> +		adapter->aq_required &= ~IAVF_FLAG_AQ_SEND_PTP_CMD;
> +		return;
> +	}
> +
> +	mutex_lock(&adapter->ptp.aq_cmd_lock);
> +	cmd = list_first_entry_or_null(&adapter->ptp.aq_cmds,
> +				       struct iavf_ptp_aq_cmd, list);
> +	if (!cmd) {
> +		/* no further PTP messages to send */
> +		adapter->aq_required &= ~IAVF_FLAG_AQ_SEND_PTP_CMD;
> +		goto out_unlock;
> +	}
> +
> +	if (adapter->current_op != VIRTCHNL_OP_UNKNOWN) {
> +		/* bail because we already have a command pending */
> +		dev_err(dev, "Cannot send PTP command %d, command %d pending\n",

pci_err()

> +			cmd->v_opcode, adapter->current_op);
> +		goto out_unlock;
> +	}
> +
> +	err = iavf_send_pf_msg(adapter, cmd->v_opcode, cmd->msg, cmd->msglen);
> +	if (!err) {
> +		/* Command was sent without errors, so we can remove it from
> +		 * the list and discard it.
> +		 */
> +		list_del(&cmd->list);
> +		kfree(cmd);
> +	} else {
> +		/* We failed to send the command, try again next cycle */
> +		dev_warn(dev, "Failed to send PTP command %d\n", cmd->v_opcode);

pci_err() I'd say.

> +	}
> +
> +	if (list_empty(&adapter->ptp.aq_cmds))
> +		/* no further PTP messages to send */
> +		adapter->aq_required &= ~IAVF_FLAG_AQ_SEND_PTP_CMD;
> +
> +out_unlock:
> +	mutex_unlock(&adapter->ptp.aq_cmd_lock);
> +}
> +
>  /**
>   * iavf_print_link_message - print link up or down
>   * @adapter: adapter structure
> @@ -2093,6 +2151,39 @@ static void iavf_activate_fdir_filters(struct iavf_adapter *adapter)
>  		adapter->aq_required |= IAVF_FLAG_AQ_ADD_FDIR_FILTER;
>  }
>  
> +/**
> + * iavf_virtchnl_ptp_get_time - Respond to VIRTCHNL_OP_1588_PTP_GET_TIME
> + * @adapter: private adapter structure
> + * @data: the message from the PF
> + * @len: length of the message from the PF
> + *
> + * Handle the VIRTCHNL_OP_1588_PTP_GET_TIME message from the PF. This message
> + * is sent by the PF in response to the same op as a request from the VF.
> + * Extract the 64bit nanoseconds time from the message and store it in
> + * cached_phc_time. Then, notify any thread that is waiting for the update via
> + * the wait queue.
> + */
> +static void iavf_virtchnl_ptp_get_time(struct iavf_adapter *adapter,
> +				       void *data, u16 len)
> +{
> +	struct virtchnl_phc_time *msg;
> +
> +	if (len == sizeof(*msg)) {
> +		msg = (struct virtchnl_phc_time *)data;

Redundant cast.

> +	} else {
> +		dev_err_once(&adapter->pdev->dev,
> +			     "Invalid VIRTCHNL_OP_1588_PTP_GET_TIME from PF. Got size %u, expected %zu\n",
> +			     len, sizeof(*msg));
> +		return;
> +	}

	struct virtchnl_phc_time *msg = data;

	if (len != sizeof(*msg))
		// error path

	adapter->ptp.cached ...

IOW there's no point in this complex if-else.

> +
> +	adapter->ptp.cached_phc_time = msg->time;
> +	adapter->ptp.cached_phc_updated = jiffies;
> +	adapter->ptp.phc_time_ready = true;
> +
> +	wake_up(&adapter->ptp.phc_time_waitqueue);
> +}

Thanks,
Olek

  reply	other threads:[~2024-08-21 14:32 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-21 12:15 [Intel-wired-lan] [PATCH iwl-next v10 00/14] Add support for Rx timestamping for both ice and iavf drivers Wojciech Drewek
2024-08-21 12:15 ` [Intel-wired-lan] [PATCH iwl-next v10 01/14] virtchnl: add support for enabling PTP on iAVF Wojciech Drewek
2024-08-21 13:32   ` Alexander Lobakin
2024-08-21 12:15 ` [Intel-wired-lan] [PATCH iwl-next v10 02/14] ice: support Rx timestamp on flex descriptor Wojciech Drewek
2024-08-21 13:29   ` Alexander Lobakin
2024-08-23  9:52     ` Wojciech Drewek
2024-08-21 12:15 ` [Intel-wired-lan] [PATCH iwl-next v10 03/14] virtchnl: add enumeration for the rxdid format Wojciech Drewek
2024-08-21 13:30   ` Alexander Lobakin
2024-08-21 12:15 ` [Intel-wired-lan] [PATCH iwl-next v10 04/14] iavf: add support for negotiating flexible RXDID format Wojciech Drewek
2024-08-21 13:52   ` Alexander Lobakin
2024-08-26  9:45     ` Wojciech Drewek
2024-08-21 12:15 ` [Intel-wired-lan] [PATCH iwl-next v10 05/14] iavf: negotiate PTP capabilities Wojciech Drewek
2024-08-21 14:06   ` Alexander Lobakin
2024-08-26 12:43     ` Wojciech Drewek
2024-08-21 12:15 ` [Intel-wired-lan] [PATCH iwl-next v10 06/14] iavf: add initial framework for registering PTP clock Wojciech Drewek
2024-08-21 14:20   ` Alexander Lobakin
2024-08-27 10:59     ` Wojciech Drewek
2024-08-21 12:15 ` [Intel-wired-lan] [PATCH iwl-next v10 07/14] iavf: add support for indirect access to PHC time Wojciech Drewek
2024-08-21 14:31   ` Alexander Lobakin [this message]
2024-08-28 11:15     ` Wojciech Drewek
2024-08-28 12:05       ` Alexander Lobakin
2024-08-28 14:50         ` Wojciech Drewek
2024-10-01  7:20     ` Mateusz Polchlopek
2024-10-01 13:49       ` Alexander Lobakin
2024-08-21 12:15 ` [Intel-wired-lan] [PATCH iwl-next v10 08/14] iavf: periodically cache " Wojciech Drewek
2024-08-21 14:43   ` Alexander Lobakin
2024-08-28 11:31     ` Wojciech Drewek
2024-08-21 12:15 ` [Intel-wired-lan] [PATCH iwl-next v10 09/14] libeth: move idpf_rx_csum_decoded and idpf_rx_extracted Wojciech Drewek
2024-08-21 15:03   ` Alexander Lobakin
2024-08-21 12:15 ` [Intel-wired-lan] [PATCH iwl-next v10 10/14] iavf: define Rx descriptors as qwords Wojciech Drewek
2024-08-22 16:16   ` Alexander Lobakin
2024-08-21 12:15 ` [Intel-wired-lan] [PATCH iwl-next v10 11/14] iavf: refactor iavf_clean_rx_irq to support legacy and flex descriptors Wojciech Drewek
2024-08-22 16:40   ` Alexander Lobakin
2024-08-21 12:15 ` [Intel-wired-lan] [PATCH iwl-next v10 12/14] iavf: Implement checking DD desc field Wojciech Drewek
2024-08-22 16:46   ` Alexander Lobakin
2024-08-21 12:15 ` [Intel-wired-lan] [PATCH iwl-next v10 13/14] iavf: handle set and get timestamps ops Wojciech Drewek
2024-08-22 16:48   ` Alexander Lobakin
2024-08-21 12:15 ` [Intel-wired-lan] [PATCH iwl-next v10 14/14] iavf: add support for Rx timestamps to hotpath Wojciech Drewek
2024-08-22 16:54   ` Alexander Lobakin

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=9e708174-d6c0-4b8b-9a0d-5807463d6c43@intel.com \
    --to=aleksander.lobakin@intel.com \
    --cc=alexandr.lobakin@intel.com \
    --cc=anthony.l.nguyen@intel.com \
    --cc=horms@kernel.org \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=wojciech.drewek@intel.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