All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Ivan Vecera" <ivecera@redhat.com>
Cc: intel-wired-lan@lists.osuosl.org
Subject: Re: [PATCH net-next 02/10] ice: dpll: serialize changes of the SyncE CGU registers
Date: Sat, 07 Nov 2026 12:11:34 +0000	[thread overview]
Message-ID: <sashiko-outbox-202874@kernel.org> (raw)
In-Reply-To: <20261106121005.1327603-3-ivecera@redhat.com>

Thank you for your contribution! Sashiko AI review found 2 potential
issues to consider:
- [Medium] ice: ptp: unconditional R10 write and lock scope in
  ice_ptp_link_change()
- [Low] ice: dpll: missing Fixes trailer for commit ad1df4f2d591
--

commit 6fdc60cccd47bebe7d61ff60807ee77303bf58bd
Author: Ivan Vecera <ivecera@redhat.com>

> ice: dpll: serialize changes of the SyncE CGU registers
>
> On dual complex E825 only complex 0 has a functional CGU and the second
> complex reaches it through cgu_peer, so PFs of both complexes share the
> CGU registers R10 and R11. They read, modify and write them when the
> state of an RCLK pin changes, and ice_ptp_link_change() rewrites R10 when
> a link changes, under the pf->dplls.lock of their own PF only.
>
> ice_ptp_link_change() does not hold dpll_lock, so it can already overwrite
> an update of another PF. RCLK callbacks are serialized by dpll_lock, but
> the DPLL core is going to serialize callbacks per (module, clock_id), and
> each complex has its own DSN and so its own clock_id. With that change, a
> test toggling RCLK pins of both complexes lost an update.
>
> Add a mutex to struct ice_adapter, which all E825C PFs share, and hold it
> around these sequences.
>
> Signed-off-by: Ivan Vecera <ivecera@redhat.com>

[Severity: Low]
Since this fixes concurrent CGU register updates in E825-C SyncE support,
should it include:

  Fixes: ad1df4f2d591 ("ice: dpll: Support E825-C SyncE and dynamic pin discovery")

[ ... ]

> diff --git a/drivers/net/ethernet/intel/ice/ice_ptp.c b/drivers/net/ethernet/intel/ice/ice_ptp.c
> index 3df08714510da..4d4b6aaaf30c2 100644
> --- a/drivers/net/ethernet/intel/ice/ice_ptp.c
> +++ b/drivers/net/ethernet/intel/ice/ice_ptp.c
> @@ -1395,7 +1395,9 @@ void ice_ptp_link_change(struct ice_pf *pf, bool linkup)
>  				break;
>  			}
>  
> +			mutex_lock(&pf->adapter->cgu_synce_lock);
>  			err = ice_tspll_cfg_synce_ethdiv_e825c(hw, clk_pin);
> +			mutex_unlock(&pf->adapter->cgu_synce_lock);
>  			if (active && err) {
>  				dev_err_once(ice_pf_to_dev(pf),
>  					     "Failed to configure SyncE ETH divider for pin %d, err %d\n",

[Severity: Medium]
Should cgu_synce_lock also cover ice_tspll_bypass_mux_active_e825c(), and
should ice_tspll_cfg_synce_ethdiv_e825c() be skipped when active is false?

ice_ptp_link_change() checks active via ice_tspll_bypass_mux_active_e825c(),
but then calls ice_tspll_cfg_synce_ethdiv_e825c() unconditionally:

drivers/net/ethernet/intel/ice/ice_ptp.c:ice_ptp_link_change() {
    ...
			err = ice_tspll_bypass_mux_active_e825c(hw,
								port_num,
								&active,
								clk_pin);
			if (err) {
    ...
				break;
			}

			mutex_lock(&pf->adapter->cgu_synce_lock);
			err = ice_tspll_cfg_synce_ethdiv_e825c(hw, clk_pin);
			mutex_unlock(&pf->adapter->cgu_synce_lock);
			if (active && err) {
    ...
}

Because ICE_CGU_R10 has a single divider per SyncE output pin shared across
all ports, a link-up on any inactive port with a non-zero link_speed
overwrites the divider of whichever port is actively driving clk_pin.

Even if gated on active, reading the mux state outside cgu_synce_lock leaves
a window where another PF running ice_dpll_synce_update_e825c() can switch
the mux to a new port and program its divider before ice_ptp_link_change()
takes cgu_synce_lock and overwrites ICE_CGU_R10 with the old port's divider.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261106121005.1327603-1-ivecera@redhat.com?part=2

  reply	other threads:[~2026-11-07 12:11 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-06 12:09 [PATCH net-next 00/10] dpll: do not serialize driver callbacks under global dpll_lock Ivan Vecera
2026-11-06 12:09 ` [PATCH net-next 01/10] ice: dpll: notify TSPLL lock status from the periodic work only Ivan Vecera
2026-11-10 12:20   ` Petr Oros
2026-11-10 17:53   ` netdev-bot+sashiko
2026-11-11 10:55     ` Ivan Vecera
2026-11-06 12:09 ` [PATCH net-next 02/10] ice: dpll: serialize changes of the SyncE CGU registers Ivan Vecera
2026-11-07 12:11   ` sashiko-bot [this message]
2026-11-10  9:45     ` Ivan Vecera
2026-11-10 17:53   ` netdev-bot+sashiko
2026-11-11 10:56     ` Ivan Vecera
2026-11-06 12:09 ` [PATCH net-next 03/10] dpll: add domain object Ivan Vecera
2026-11-10 12:23   ` Petr Oros
2026-11-10 17:53   ` netdev-bot+sashiko
2026-11-11 10:58     ` Ivan Vecera
2026-11-06 12:09 ` [PATCH net-next 04/10] dpll: take domain locks around driver callbacks Ivan Vecera
2026-11-07 12:11   ` sashiko-bot
2026-11-09 14:27     ` Ivan Vecera
2026-11-10 12:23   ` Petr Oros
2026-11-06 12:10 ` [PATCH net-next 05/10] dpll: convert dpll_lock to rwsem Ivan Vecera
2026-11-10 12:24   ` Petr Oros
2026-11-10 17:53   ` netdev-bot+sashiko
2026-11-11 11:01     ` Ivan Vecera
2026-11-06 12:10 ` [PATCH net-next 06/10] dpll: add KUnit tests for core locking Ivan Vecera
2026-11-07 12:11   ` sashiko-bot
2026-11-10  9:45     ` Ivan Vecera
2026-11-10 12:24   ` Petr Oros
2026-11-10 17:53   ` netdev-bot+sashiko
2026-11-11 10:53     ` Ivan Vecera
2026-11-06 12:10 ` [PATCH net-next 07/10] dpll: reject measured_freq_get for foreign and on-pin registrations Ivan Vecera
2026-11-10 12:24   ` Petr Oros
2026-11-06 12:10 ` [PATCH net-next 08/10] dpll: zl3073x: update locking comments Ivan Vecera
2026-11-10 12:24   ` Petr Oros
2026-11-06 12:10 ` [PATCH net-next 09/10] ice: dpll: " Ivan Vecera
2026-11-10 15:31   ` Petr Oros
2026-11-10 17:53   ` netdev-bot+sashiko
2026-11-11 11:03     ` Ivan Vecera
2026-11-06 12:10 ` [PATCH net-next 10/10] dpll: document locking rules Ivan Vecera
2026-11-10 12:25   ` Petr Oros
2026-11-10 17:53   ` netdev-bot+sashiko
2026-11-11 11:07     ` Ivan Vecera

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=sashiko-outbox-202874@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=ivecera@redhat.com \
    --cc=sashiko-reviews@lists.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.