Devicetree
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Selvamani Rajagopal" <Selvamani.Rajagopal@onsemi.com>
Cc: devicetree@vger.kernel.org, robh@kernel.org, conor+dt@kernel.org
Subject: Re: [PATCH net-next v10 05/11] net: ethernet: oa_tc6: Support for hardware timestamp
Date: Sat, 07 Nov 2026 23:19:09 +0000	[thread overview]
Message-ID: <sashiko-outbox-203381@kernel.org> (raw)
In-Reply-To: <20261106-s2500-mac-phy-support-v10-5-31b5a69b85b7@onsemi.com>

Thank you for your contribution! Sashiko AI review found 2 potential
issues to consider:
- [Medium] net: oa_tc6: NULL deref in oa_tc6_phy_exit() on oa_tc6_init()
  error path
- [Medium] net: oa_tc6: race and partial update in
  oa_tc6_set_hwtstamp_settings()
--

commit 7845a5d180b9f247dce7a81aeca4e94a68402ceb
Author: Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>

net: ethernet: oa_tc6: Support for hardware timestamp

This commit adds hardware timestamping and PTP clock registration support
to the OPEN Alliance TC6 10BASE-T1x MAC-PHY framework.

> diff --git a/drivers/net/ethernet/oa_tc6/oa_tc6_main.c b/drivers/net/ethernet/oa_tc6/oa_tc6_main.c
> index 45eb896cd986c..e793d7fb0635f 100644
> --- a/drivers/net/ethernet/oa_tc6/oa_tc6_main.c
> +++ b/drivers/net/ethernet/oa_tc6/oa_tc6_main.c

[ ... ]

> @@ -1435,6 +1725,12 @@ struct oa_tc6 *oa_tc6_init(struct spi_device *spi, struct net_device *netdev,
>  		return ERR_PTR(ret);
>  	}
>  
> +	ret = oa_tc6_update_standard_capability(tc6);
> +	if (ret) {
> +		dev_err(&tc6->spi->dev, "Failed to read capability\n");
> +		goto phy_exit;
> +	}
> +
>  	ret = oa_tc6_unmask_macphy_error_interrupts(tc6);
>  	if (ret) {
>  		dev_err(&tc6->spi->dev,

[Severity: Medium]
Does jumping to phy_exit here cause a NULL pointer dereference in
oa_tc6_phy_exit()?  oa_tc6_phy_init() has not run yet at this point, so
tc6->phydev and tc6->mdiobus are still NULL when oa_tc6_phy_exit() calls
phy_disconnect(tc6->phydev) and oa_tc6_mdiobus_unregister(tc6).  This error
path should return ERR_PTR(ret) directly, like the surrounding pre-PHY
checks.

> diff --git a/drivers/net/ethernet/oa_tc6/oa_tc6_tstamp.c b/drivers/net/ethernet/oa_tc6/oa_tc6_tstamp.c
> new file mode 100644
> index 0000000000000..539cbd36a1d04
> --- /dev/null
> +++ b/drivers/net/ethernet/oa_tc6/oa_tc6_tstamp.c
> @@ -0,0 +1,224 @@

[ ... ]

> +static int oa_tc6_set_hwtstamp_settings(struct oa_tc6 *tc6,
> +					const struct hwtstamp_config *ts_cfg)
> +{
> +	u32 regs[CFG0_TO_IMASK0_REG_COUNT];
> +	u32 cfg0, irqm, status0;
> +	bool disabled;
> +	int ret;

[ ... ]

> +	/* STATUS0 is write-one-to-clear, so this acknowledges a capture
> +	 * without delivering its timestamp. Skip it while TX timestamping
> +	 * stays enabled, where a capture may still be outstanding.
> +	 */
> +	status0 &= OA_TC6_STATUS0_TTSCA_MASK;
> +	if (status0 && (tc6->ts_config.tx_type != HWTSTAMP_TX_ON ||
> +			ts_cfg->tx_type != HWTSTAMP_TX_ON)) {
> +		ret = oa_tc6_write_register(tc6, OA_TC6_REG_STATUS0,
> +					    status0);
> +		if (ret) {
> +			dev_err(&tc6->spi->dev,
> +				"failed to write STATUS0 register\n");
> +			goto out;
> +		}
> +	}
> +
> +	ret = oa_tc6_write_register(tc6, OA_TC6_REG_INT_MASK0, irqm);
> +	if (ret) {
> +		dev_err(&tc6->spi->dev, "failed to write IRQM register\n");
> +		goto out;
> +	}
> +
> +	ret = oa_tc6_write_register(tc6, OA_TC6_REG_CONFIG0, cfg0);
> +	if (ret) {
> +		dev_err(&tc6->spi->dev, "failed to write CFG0 register\n");
> +		goto out;
> +	}
> +	spin_lock_bh(&tc6->tx_skb_lock);
> +	tc6->ts_config = *ts_cfg;
> +	if (cfg0 & OA_TC6_CONFIG0_FTSE_ENABLE)
> +		tc6->hw_tstamp_enabled = true;
> +	else
> +		tc6->hw_tstamp_enabled = false;
> +	spin_unlock_bh(&tc6->tx_skb_lock);
> +
> +	/* The TX timestamp completion interrupt is masked now. Time
> +	 * to release the queued skbs.
> +	 */
> +	if (ts_cfg->tx_type != HWTSTAMP_TX_ON)
> +		oa_tc6_cleanup_tx_tstamp_skbs(tc6);
> +out:
> +	return ret;
> +}

[Severity: Medium]
When disabling TX hardware timestamping while packets are in flight, can
clearing OA_TC6_REG_STATUS0 before updating tc6->ts_config and before
purging tc6->tx_ts_skb_q leave stale capture bits latched in STATUS0?

CPU0                                    CPU1 (irq thread)
oa_tc6_set_hwtstamp_settings()
  oa_tc6_read_registers(CONFIG0..IMASK0)
  oa_tc6_write_register(STATUS0, ...)
                                        oa_tc6_prepare_spi_tx_buf_for_tx_skbs()
                                          oa_tc6_req_tx_hwtstamp()
                                            /* assigns tsc slot */
                                        /* frame transmitted, hardware
                                         * latches TTSCA bit in STATUS0 */
  oa_tc6_write_register(INT_MASK0, ...)
  oa_tc6_write_register(CONFIG0, ...)
  spin_lock_bh(&tc6->tx_skb_lock)
  tc6->ts_config = *ts_cfg
  spin_unlock_bh(&tc6->tx_skb_lock)
  oa_tc6_cleanup_tx_tstamp_skbs()
    /* purges tx_ts_skb_q */
                                        oa_tc6_process_extended_status()
                                          oa_tc6_events_handle()
                                            /* no matching skb for TTSCA bit:
                                             * "Unexpected event",
                                             * tx_hwtstamp_err++ */

Because tc6->ts_config and tc6->hw_tstamp_enabled are only updated after
the blocking SPI register writes, oa_tc6_req_tx_hwtstamp() can continue
allocating timestamp slots (and frames already in flight can finish
transmission) after STATUS0 has been read and cleared.  Once
oa_tc6_cleanup_tx_tstamp_skbs() frees the queued skbs, the newly latched
STATUS0 bit has no matching skb in tc6->tx_ts_skb_q, causing
oa_tc6_events_handle() to report an unexpected event and increment
tc6->tx_hwtstamp_err.

In addition, if writing OA_TC6_REG_INT_MASK0 or OA_TC6_REG_CONFIG0 fails
after OA_TC6_REG_STATUS0 was already cleared, the function returns early
without calling oa_tc6_cleanup_tx_tstamp_skbs(), leaving the corresponding
skbs stuck on tc6->tx_ts_skb_q with their tc6->ts_ttsc_pending bits
permanently set.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261106-s2500-mac-phy-support-v10-0-31b5a69b85b7@onsemi.com?part=5

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

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-06 23:18 [PATCH net-next v10 00/11] Support for onsemi's S2500 10Base-T1S MAC-PHY Selvamani Rajagopal via B4 Relay
2026-11-06 23:18 ` [PATCH net-next v10 01/11] dt-bindings: net: add onsemi's S2500 Selvamani Rajagopal via B4 Relay
2026-11-06 23:18 ` [PATCH net-next v10 02/11] Documentation: networking: Add timestamp related APIs to OA TC6 framework Selvamani Rajagopal via B4 Relay
2026-11-08  0:15   ` netdev-bot+sashiko
2026-11-06 23:18 ` [PATCH net-next v10 03/11] net: ethernet: oa_tc6: Move oa_tc6.c to its own directory Selvamani Rajagopal via B4 Relay
2026-11-06 23:18 ` [PATCH net-next v10 04/11] net: ethernet: oa_tc6: Move constant definitions to header file Selvamani Rajagopal via B4 Relay
2026-11-08  0:15   ` netdev-bot+sashiko
2026-11-06 23:18 ` [PATCH net-next v10 05/11] net: ethernet: oa_tc6: Support for hardware timestamp Selvamani Rajagopal via B4 Relay
2026-11-07 23:19   ` sashiko-bot [this message]
2026-11-08  0:15   ` netdev-bot+sashiko
2026-11-09  3:11     ` Selvamani Rajagopal
2026-11-06 23:18 ` [PATCH net-next v10 06/11] net: ethernet: oa_tc6: Support for vendor specific MMS Selvamani Rajagopal via B4 Relay
2026-11-07 23:19   ` sashiko-bot
2026-11-08  0:15   ` netdev-bot+sashiko
2026-11-08 19:42     ` Selvamani Rajagopal
2026-11-06 23:18 ` [PATCH net-next v10 07/11] net: phy: ncn26000: Enable enhanced noise immunity Selvamani Rajagopal via B4 Relay
2026-11-06 23:18 ` [PATCH net-next v10 08/11] onsemi: s2500: Add driver support for S2500 MAC-PHY Selvamani Rajagopal via B4 Relay
2026-11-07 23:19   ` sashiko-bot
2026-11-08  0:15   ` netdev-bot+sashiko
2026-11-09  7:21     ` Selvamani Rajagopal
2026-11-06 23:18 ` [PATCH net-next v10 09/11] onsemi: s2500: Added selftest support to onsemi's S2500 driver Selvamani Rajagopal via B4 Relay
2026-11-06 23:18 ` [PATCH net-next v10 10/11] net: phy: ncn26000: Support for onsemi's S2500 internal phy Selvamani Rajagopal via B4 Relay
2026-11-08  0:15   ` netdev-bot+sashiko
2026-11-06 23:18 ` [PATCH net-next v10 11/11] net: phy: ncn26000: Support for loopback Selvamani Rajagopal via B4 Relay
2026-11-07 23:19   ` sashiko-bot
2026-11-08  0:15   ` netdev-bot+sashiko
2026-11-09  1:48     ` Selvamani Rajagopal

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-203381@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=Selvamani.Rajagopal@onsemi.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=robh@kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox