Linux kernel and device drivers for NXP i.MX platforms
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: wei.fang@oss.nxp.com
Cc: Frank.Li@kernel.org, imx@lists.linux.dev
Subject: Re: [PATCH v2 net] ptp: netc: fix potential interrupt storm caused by incorrect unbind order
Date: Tue, 28 Jul 2026 06:00:51 +0000	[thread overview]
Message-ID: <20260728060051.B45491F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260727060348.1887464-1-wei.fang@oss.nxp.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] The driver fails to clear the hardware interrupt status register (NETC_TMR_TEVENT) during initialization and only clears unmasked events in the ISR, permanently leaving masked events pending.
--

--- Patch [1]: [PATCH v2 net] ptp: netc: fix potential interrupt storm caused by incorrect unbind order ---
commit 31de617b2b5f4f30ac1afdcfbd8ebfecdf0a6a03
Author: Wei Fang <wei.fang@nxp.com>

ptp: netc: fix potential interrupt storm caused by incorrect unbind order

This commit attempts to fix an interrupt storm during driver unbind by
requesting the IRQ with IRQF_NO_AUTOEN and ensuring hardware interrupts
are disabled before unregistering the PTP clock. It also adds logic to
return IRQ_NONE when no unmasked events are pending.

Closes: https://sashiko.dev/#/patchset/20260720012508.23227-1-wei.fang%40oss.nxp.com

> diff --git a/drivers/ptp/ptp_netc.c b/drivers/ptp/ptp_netc.c
> --- a/drivers/ptp/ptp_netc.c
> +++ b/drivers/ptp/ptp_netc.c
> @@ -769,6 +769,7 @@ static void netc_timer_init(struct netc_timer *priv)
>  		   TMR_CTRL_TE | TMR_CTRL_FS;
>  	netc_timer_wr(priv, NETC_TMR_CTRL, tmr_ctrl);
>  	netc_timer_wr(priv, NETC_TMR_PRSC, priv->oclk_prsc);
> +	netc_timer_wr(priv, NETC_TMR_TEMASK, 0);

[Severity: High]
This is a pre-existing issue, but does this initialization also need to clear
the event register (NETC_TMR_TEVENT)?

If the hardware holds pending events from a previous unbind or an unclean
shutdown, clearing the mask here won't clear the pending bits themselves,
leaving stale interrupt status in the hardware.

[ ... ]

> @@ -901,6 +902,11 @@ static irqreturn_t netc_timer_isr(int irq, void *data)
>  	/* Clear interrupts status */
>  	netc_timer_wr(priv, NETC_TMR_TEVENT, tmr_event);
>  
> +	if (!tmr_event) {
> +		spin_unlock(&priv->lock);
> +		return IRQ_NONE;
> +	}
> +

[Severity: High]
This is a pre-existing issue, but does writing back the masked tmr_event
fail to clear pending but masked hardware events?

Looking earlier in netc_timer_isr(), tmr_event is masked before being written
back to the register:

    tmr_event = netc_timer_rd(priv, NETC_TMR_TEVENT);
    tmr_event &= priv->tmr_emask;
    /* Clear interrupts status */
    netc_timer_wr(priv, NETC_TMR_TEVENT, tmr_event);

If NETC_TMR_TEVENT is a Write-1-to-Clear register, writing back 0 for
any masked events means they are never cleared. 

If priv->tmr_emask is 0, the ISR will write 0 to NETC_TMR_TEVENT and then
return IRQ_NONE without clearing the actual hardware state. Could this
cause the unacknowledged hardware interrupt to re-trigger indefinitely,
forcing the kernel's spurious interrupt detector to permanently disable the
IRQ line?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260727060348.1887464-1-wei.fang@oss.nxp.com?part=1

      reply	other threads:[~2026-07-28  6:00 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-27  6:03 [PATCH v2 net] ptp: netc: fix potential interrupt storm caused by incorrect unbind order wei.fang
2026-07-28  6:00 ` sashiko-bot [this message]

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=20260728060051.B45491F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=Frank.Li@kernel.org \
    --cc=imx@lists.linux.dev \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=wei.fang@oss.nxp.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