public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: ivecera@redhat.com
Cc: Jakub Kicinski <kuba@kernel.org>,
	conor+dt@kernel.org, poros@redhat.com,
	anthony.l.nguyen@intel.com, linux-rdma@vger.kernel.org,
	tariqt@nvidia.com, robh@kernel.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, aleksander.lobakin@intel.com,
	mbloch@nvidia.com, jiri@resnulli.us,
	Prathosh.Satish@microchip.com, krzk+dt@kernel.org,
	saeedm@nvidia.com, devicetree@vger.kernel.org,
	davem@davemloft.net, pabeni@redhat.com,
	przemyslaw.kitszel@intel.com, arkadiusz.kubalewski@intel.com,
	jonathan.lemon@gmail.com, saravanak@kernel.org,
	aleksandr.loktionov@intel.com, mschmidt@redhat.com,
	edumazet@google.com, leon@kernel.org, vadim.fedorenko@linux.dev,
	grzegorz.nitka@intel.com, intel-wired-lan@lists.osuosl.org,
	richardcochran@gmail.com, andrew+netdev@lunn.ch
Subject: Re: [net-next,v2,12/12] ice: dpll: Support E825-C SyncE and dynamic pin discovery
Date: Tue, 20 Jan 2026 16:18:54 -0800	[thread overview]
Message-ID: <20260121001854.1905391-1-kuba@kernel.org> (raw)
In-Reply-To: <20260116184610.147591-13-ivecera@redhat.com>

This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.

For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
---
ice: dpll: Support E825-C SyncE and dynamic pin discovery

This patch adds DPLL support for the Intel E825-C Ethernet controller.
It implements dynamic pin discovery via firmware nodes, asynchronous
registration using a DPLL notifier chain, and hardware configuration
for CGU registers.

> diff --git a/drivers/net/ethernet/intel/ice/ice_dpll.c b/drivers/net/ethernet/intel/ice/ice_dpll.c
> index 4eca62688d83..9d82748810a3 100644

[ ... ]

> +static void ice_dpll_pin_notify_work(struct work_struct *work)
> +{
> +	struct ice_dpll_pin_work *w = container_of(work,
> +						   struct ice_dpll_pin_work,
> +						   work);
> +	struct ice_dpll_pin *pin, *parent = w->pin;
> +	struct ice_pf *pf = parent->pf;
> +	int ret;
> +
> +	switch (w->action) {
> +	case DPLL_PIN_CREATED:
> +		if (!IS_ERR_OR_NULL(parent->pin)) {
> +			/* We have already our pin registered */
> +			goto out;
> +		}
> +
> +		/* Grab reference on fwnode pin */
> +		parent->pin = fwnode_dpll_pin_find(parent->fwnode,
> +						   &parent->tracker);
> +		if (IS_ERR_OR_NULL(parent->pin)) {
> +			dev_err(ice_pf_to_dev(pf),
> +				"Cannot get fwnode pin reference\n");
> +			goto out;
> +		}
> +
> +		/* Register rclk pin */
> +		pin = &pf->dplls.rclk;
> +		ret = dpll_pin_on_pin_register(parent->pin, pin->pin,
> +					       &ice_dpll_rclk_ops, pin);

Can pin->pin (pf->dplls.rclk.pin) be NULL here? Looking at the init
order in ice_dpll_init_pins_e825():

    ret = ice_dpll_init_fwnode_pins(pf, pf->dplls.inputs, 0);
    ...
    ret = ice_dpll_init_rclk_pin(pf, DPLL_PIN_IDX_UNSPEC, ...);

The fwnode pins are initialized first, which registers notifiers. If a
DPLL_PIN_CREATED notification fires before ice_dpll_init_rclk_pin()
completes, this work handler will run while pf->dplls.rclk.pin is still
NULL (the structure is zeroed by kcalloc). Passing NULL to
dpll_pin_on_pin_register() causes a NULL dereference in
dpll_xa_ref_pin_add() when it accesses pin->parent_refs.

> +		if (ret) {
> +			dev_err(ice_pf_to_dev(pf),
> +				"Failed to register pin: %pe\n", ERR_PTR(ret));
> +			dpll_pin_put(parent->pin, &parent->tracker);
> +			parent->pin = NULL;
> +			goto out;
> +		}
> +		break;

[ ... ]

> diff --git a/drivers/net/ethernet/intel/ice/ice_ptp.c b/drivers/net/ethernet/intel/ice/ice_ptp.c
> index 4c8d20f2d2c0..0eb8a9e29a52 100644
> --- a/drivers/net/ethernet/intel/ice/ice_ptp.c
> +++ b/drivers/net/ethernet/intel/ice/ice_ptp.c
> @@ -1341,6 +1341,35 @@ void ice_ptp_link_change(struct ice_pf *pf, bool linkup)
>  	if (pf->hw.reset_ongoing)
>  		return;
>
> +	if (hw->mac_type == ICE_MAC_GENERIC_3K_E825) {
> +		int pin, err;
> +
> +		mutex_lock(&pf->dplls.lock);

Should this check ICE_FLAG_DPLL before using pf->dplls.lock? Looking at
ice_dpll_init_e825(), if initialization fails the mutex is destroyed:

    err = ice_dpll_init_info_e825c(pf);
    if (err)
        goto err_exit;
    ...
    err_exit:
        mutex_destroy(&d->lock);

But ICE_FLAG_DPLL is only set on success. If DPLL init fails and a link
change event occurs, this code will use a destroyed mutex.

> +		for (pin = 0; pin < ICE_SYNCE_CLK_NUM; pin++) {
> +			enum ice_synce_clk clk_pin;
> +			bool active;
> +			u8 port_num;
> +
> +			port_num = ptp_port->port_num;
> +			clk_pin = (enum ice_synce_clk)pin;
> +			err = ice_tspll_bypass_mux_active_e825c(hw,
> +								port_num,
> +								&active,
> +								clk_pin);
> +			if (WARN_ON_ONCE(err)) {
> +				mutex_unlock(&pf->dplls.lock);
> +				return;
> +			}
> +
> +			err = ice_tspll_cfg_synce_ethdiv_e825c(hw, clk_pin);
> +			if (active && WARN_ON_ONCE(err)) {
> +				mutex_unlock(&pf->dplls.lock);
> +				return;
> +			}
> +		}
> +		mutex_unlock(&pf->dplls.lock);
> +	}

  reply	other threads:[~2026-01-21  0:18 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-16 18:45 [PATCH net-next v2 00/12] dpll: Core improvements and ice E825-C SyncE support Ivan Vecera
2026-01-16 18:45 ` [PATCH net-next v2 01/12] dt-bindings: dpll: support acting as pin provider Ivan Vecera
2026-01-16 18:46 ` [PATCH net-next v2 02/12] dpll: Allow associating dpll pin with a firmware node Ivan Vecera
2026-01-16 18:46 ` [PATCH net-next v2 03/12] dpll: Add helpers to find DPLL pin fwnode Ivan Vecera
2026-02-08  1:46   ` Saravana Kannan
2026-02-10  7:19   ` [Intel-wired-lan] " Loktionov, Aleksandr
2026-01-16 18:46 ` [PATCH net-next v2 04/12] dpll: zl3073x: Associate pin with fwnode handle Ivan Vecera
2026-01-19  7:49   ` [Intel-wired-lan] " Loktionov, Aleksandr
2026-01-16 18:46 ` [PATCH net-next v2 05/12] dpll: Add notifier chain for dpll events Ivan Vecera
2026-01-16 18:46 ` [PATCH net-next v2 06/12] dpll: Support dynamic pin index allocation Ivan Vecera
2026-01-16 18:46 ` [PATCH net-next v2 07/12] dpll: zl3073x: Add support for mux pin type Ivan Vecera
2026-01-19  7:50   ` [Intel-wired-lan] " Loktionov, Aleksandr
2026-01-16 18:46 ` [PATCH net-next v2 08/12] dpll: Enhance and consolidate reference counting logic Ivan Vecera
2026-01-21  0:16   ` [net-next,v2,08/12] " Jakub Kicinski
2026-01-21  8:18     ` Ivan Vecera
2026-01-23 14:58       ` Simon Horman
2026-01-23 15:27         ` Ivan Vecera
2026-01-23 18:04           ` Simon Horman
2026-01-16 18:46 ` [PATCH net-next v2 09/12] dpll: Prevent duplicate registrations Ivan Vecera
2026-01-19  7:50   ` [Intel-wired-lan] " Loktionov, Aleksandr
2026-01-16 18:46 ` [PATCH net-next v2 10/12] dpll: Add reference count tracking support Ivan Vecera
2026-01-16 18:46 ` [PATCH net-next v2 11/12] drivers: Add support for DPLL reference count tracking Ivan Vecera
2026-01-16 18:46 ` [PATCH net-next v2 12/12] ice: dpll: Support E825-C SyncE and dynamic pin discovery Ivan Vecera
2026-01-21  0:18   ` Jakub Kicinski [this message]
2026-01-21 14:20     ` [net-next,v2,12/12] " Nitka, Grzegorz

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=20260121001854.1905391-1-kuba@kernel.org \
    --to=kuba@kernel.org \
    --cc=Prathosh.Satish@microchip.com \
    --cc=aleksander.lobakin@intel.com \
    --cc=aleksandr.loktionov@intel.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=anthony.l.nguyen@intel.com \
    --cc=arkadiusz.kubalewski@intel.com \
    --cc=conor+dt@kernel.org \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=edumazet@google.com \
    --cc=grzegorz.nitka@intel.com \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=ivecera@redhat.com \
    --cc=jiri@resnulli.us \
    --cc=jonathan.lemon@gmail.com \
    --cc=krzk+dt@kernel.org \
    --cc=leon@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=mbloch@nvidia.com \
    --cc=mschmidt@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=poros@redhat.com \
    --cc=przemyslaw.kitszel@intel.com \
    --cc=richardcochran@gmail.com \
    --cc=robh@kernel.org \
    --cc=saeedm@nvidia.com \
    --cc=saravanak@kernel.org \
    --cc=tariqt@nvidia.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