Intel-Wired-Lan Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Wojciech Drewek <wojciech.drewek@intel.com>
To: Alexander Lobakin <aleksander.lobakin@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 06/14] iavf: add initial framework for registering PTP clock
Date: Tue, 27 Aug 2024 12:59:50 +0200	[thread overview]
Message-ID: <213347f1-7af5-45a5-a9ce-448d98867d35@intel.com> (raw)
In-Reply-To: <3278c207-b450-4ef0-b240-0fd4cfc0b1df@intel.com>



On 21.08.2024 16:20, Alexander Lobakin wrote:
> From: Wojciech Drewek <wojciech.drewek@intel.com>
> Date: Wed, 21 Aug 2024 14:15:31 +0200
> 
>> From: Jacob Keller <jacob.e.keller@intel.com>
>>
>> Add the iavf_ptp.c file and fill it in with a skeleton framework to
>> allow registering the PTP clock device.
>> Add implementation of helper functions to check if a PTP capability
>> is supported and handle change in PTP capabilities.
>> Enabling virtual clock would be possible, though it would probably
>> perform poorly due to the lack of direct time access.
> 
> [...]
> 
>> +/**
>> + * iavf_ptp_register_clock - Register a new PTP for userspace
>> + * @adapter: private adapter structure
>> + *
>> + * Allocate and register a new PTP clock device if necessary.
>> + *
>> + * Return: 0 if success, error otherwise
> 
> Period ('.') at the end is desired at the end of kdoc.

Sure

> 
>> + */
>> +static int iavf_ptp_register_clock(struct iavf_adapter *adapter)
>> +{
>> +	struct ptp_clock_info *ptp_info = &adapter->ptp.info;
>> +	struct device *dev = &adapter->pdev->dev;
>> +
>> +	memset(ptp_info, 0, sizeof(*ptp_info));
> 
> Is this needed? adapter is allocated using kzalloc() I think?

I think it's not needed, adapter is allocated using alloc_etherdev_mq
since this is netdev's priv in iavf

> 
>> +
>> +	snprintf(ptp_info->name, sizeof(ptp_info->name), "%s-%s-clk",
>> +		 dev_driver_string(dev), dev_name(dev));
> 
> dev_driver_string() can be just KBUILD_MODNAME when it's called inside
> the actual module. It's mostly used when you need to get a module name
> from a different module or core kernel code.

Makes sense

> 
>> +	ptp_info->owner = THIS_MODULE;
>> +
>> +	adapter->ptp.clock = ptp_clock_register(ptp_info, dev);
>> +	if (IS_ERR(adapter->ptp.clock)) {
>> +		adapter->ptp.clock = NULL;
>> +
>> +		return PTR_ERR(adapter->ptp.clock);
> 
> Braino here.
> You first set ptp.clock to %NULL and then return PTR_ERR(ptp.clock).
> IOW, this error path will always return 0.
> 
> I usually use temporary variables to avoid this.
> 
> 	clock = ptp_clock_register(ptp_info, dev);
> 	if (IS_ERR(clock))
> 		return PTR_ERR(clock);
> 
> 	adapter->ptp.clock = clock;

will fix

> 
> 
>> +	}
>> +
>> +	dev_dbg(&adapter->pdev->dev, "PTP clock %s registered\n",
>> +		adapter->ptp.info.name);
>> +
>> +	return 0;
>> +}
>> +
>> +/**
>> + * iavf_ptp_init - Initialize PTP support if capability was negotiated
>> + * @adapter: private adapter structure
>> + *
>> + * Initialize PTP functionality, based on the capabilities that the PF has
>> + * enabled for this VF.
>> + */
>> +void iavf_ptp_init(struct iavf_adapter *adapter)
>> +{
>> +	int err;
>> +
>> +	if (!iavf_ptp_cap_supported(adapter, VIRTCHNL_1588_PTP_CAP_READ_PHC)) {
>> +		pci_warn(adapter->pdev,
>> +			 "Device does not have PTP clock support\n");
> 
> I think it's pci_notice() or even pci_dbg(). A device can miss PTP
> clock, but it's not a failure. _warn() is when something went wrong, but
> not as wrong as _err() :D

sure

> 
>> +		return;
>> +	}
>> +
>> +	err = iavf_ptp_register_clock(adapter);
>> +	if (err) {
>> +		pci_err(adapter->pdev,
>> +			"Failed to register PTP clock device (%p)\n",
>> +			ERR_PTR(err));
>> +		return;
>> +	}
> 
> Why does this function return void if there's an error path? To make
> sure the driver works even if PTP fails to register? But I think it's
> better to bail out if something failed than to work without certain
> functionality?

Most of the drivers don't bail out if ptp init failed, I'll stick to that.

> 
>> +
>> +	adapter->ptp.initialized = true;
>> +}
>> +
>> +/**
>> + * iavf_ptp_release - Disable PTP support
>> + * @adapter: private adapter structure
>> + *
>> + * Release all PTP resources that were previously initialized.
>> + */
>> +void iavf_ptp_release(struct iavf_adapter *adapter)
>> +{
>> +	adapter->ptp.initialized = false;
>> +
>> +	if (!IS_ERR_OR_NULL(adapter->ptp.clock)) {
> 
> Since you always assign clock to %NULL when the initialization failed,
> this could be just

Yep

> 
> 	if (adapter->ptp.clock)
> 
>> +		dev_dbg(&adapter->pdev->dev, "removing PTP clock %s\n",
>> +			adapter->ptp.info.name);
> 
> pci_dbg()
> 
>> +		ptp_clock_unregister(adapter->ptp.clock);
>> +		adapter->ptp.clock = NULL;
>> +	}
> 
> ...but I'd invert the condition to avoid +1 indent level.
> 
> 	if (!adapter->ptp.clock)
> 		return;
> 
> 	pci_dbg() ...

Agree

> 
>> +}
>> +
>> +/**
>> + * iavf_ptp_process_caps - Handle change in PTP capabilities
>> + * @adapter: private adapter structure
>> + *
>> + * Handle any state changes necessary due to change in PTP capabilities, such
>> + * as after a device reset or change in configuration from the PF.
>> + */
>> +void iavf_ptp_process_caps(struct iavf_adapter *adapter)
>> +{
>> +	bool read_phc = iavf_ptp_cap_supported(adapter,
>> +					       VIRTCHNL_1588_PTP_CAP_READ_PHC);
> 
> Maybe split the declaration and initialization to avoid line break? My
> editor says it would fit in 80 if you make the variable name shorter,
> e.g. 'phc'.

Sure, why not

> 
>> +
>> +	/* Check if the device gained or lost necessary access to support the
>> +	 * PTP hardware clock. If so, driver must respond appropriately by
>> +	 * creating or destroying the PTP clock device.
>> +	 */
>> +	if (adapter->ptp.initialized && !read_phc)
>> +		iavf_ptp_release(adapter);
>> +	else if (!adapter->ptp.initialized && read_phc)
>> +		iavf_ptp_init(adapter);
>> +}
> 
> Thanks,
> Olek

  reply	other threads:[~2024-08-27 11:00 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 [this message]
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
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=213347f1-7af5-45a5-a9ce-448d98867d35@intel.com \
    --to=wojciech.drewek@intel.com \
    --cc=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 \
    /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