netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexander Lobakin <aleksander.lobakin@intel.com>
To: Wojciech Drewek <wojciech.drewek@intel.com>
Cc: <netdev@vger.kernel.org>, <intel-wired-lan@lists.osuosl.org>,
	<horms@kernel.org>, <anthony.l.nguyen@intel.com>,
	<kuba@kernel.org>, <alexandr.lobakin@intel.com>
Subject: Re: [PATCH iwl-next v10 07/14] iavf: add support for indirect access to PHC time
Date: Wed, 28 Aug 2024 14:05:03 +0200	[thread overview]
Message-ID: <1a4232c2-34c9-4b14-a581-4bc2cdc11afd@intel.com> (raw)
In-Reply-To: <79623019-60be-4db7-a35e-f2e4c41b6f63@intel.com>

From: Wojciech Drewek <wojciech.drewek@intel.com>
Date: Wed, 28 Aug 2024 13:15:09 +0200

> 
> 
> On 21.08.2024 16:31, Alexander Lobakin wrote:
>> 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().
> 
> I think that Jake's intention here was to execute the work that is already queued,
> not to queue new work

mod_delayed_work(0) works exactly as queue_work(), which is:

* if the work is already queued and the timeout is non-zero, modify the
timeout
* if the work is already queued and the timeout is zero, do nothing
* if the work is not queued, queue it

So my comment it still valid. You don't need delayed_work, but work_struct.

> 
>>
>>> +}
>>> +
>>> +/**
>>> + * 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?
> 
> I'll use ENODEV in both cases

But why -ENODEV? Can you show me some other drivers and/or core PTP code
which use it?

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

Thanks,
Olek

  reply	other threads:[~2024-08-28 12:05 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-21 12:15 [PATCH iwl-next v10 00/14] Add support for Rx timestamping for both ice and iavf drivers Wojciech Drewek
2024-08-21 12:15 ` [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 ` [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 ` [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 ` [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 ` [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 ` [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 ` [PATCH iwl-next v10 07/14] iavf: add support for indirect access to PHC time Wojciech Drewek
2024-08-21 14:31   ` Alexander Lobakin
2024-08-28 11:15     ` Wojciech Drewek
2024-08-28 12:05       ` Alexander Lobakin [this message]
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 ` [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 ` [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 ` [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 ` [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 ` [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 ` [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 ` [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=1a4232c2-34c9-4b14-a581-4bc2cdc11afd@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;
as well as URLs for NNTP newsgroup(s).