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 06/14] iavf: add initial framework for registering PTP clock
Date: Wed, 21 Aug 2024 16:20:46 +0200 [thread overview]
Message-ID: <3278c207-b450-4ef0-b240-0fd4cfc0b1df@intel.com> (raw)
In-Reply-To: <20240821121539.374343-7-wojciech.drewek@intel.com>
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.
> + */
> +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?
> +
> + 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.
> + 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;
> + }
> +
> + 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
> + 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?
> +
> + 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
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() ...
> +}
> +
> +/**
> + * 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'.
> +
> + /* 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
next prev parent reply other threads:[~2024-08-21 14:21 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 [this message]
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
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=3278c207-b450-4ef0-b240-0fd4cfc0b1df@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