Re: [PATCH v19 09/12] media: qcom: camss: tpg: Add support for v2.4.0 TPG - sashiko-bot

From: sashiko-bot@kernel.org
To: "Hangxiang Ma" <hangxiang.ma@oss.qualcomm.com>
Cc: media-ci@linuxtv.org, vkoul@kernel.org,
	linux-phy@lists.infradead.org, neil.armstrong@linaro.org,
	robh@kernel.org, devicetree@vger.kernel.org, olteanv@gmail.com,
	conor+dt@kernel.org
Subject: Re: [PATCH v19 09/12] media: qcom: camss: tpg: Add support for v2.4.0 TPG
Date: Thu, 08 Oct 2026 07:27:27 +0000	[thread overview]
Message-ID: <sashiko-outbox-163752@kernel.org> (raw)
In-Reply-To: <20261008-kaanapali-camss-v19-9-b2c583ef50e0@oss.qualcomm.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] media: qcom: camss: data race in __csid_configure_rx reading TPG state
--

commit 0224a6f288ad77d57684837805849143fea2532e
Author: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>

media: qcom: camss: tpg: Add support for v2.4.0 TPG

This commit adds support for the Test Pattern Generator (TPG) on Kaanapali
using hardware version 2.4.0. It updates control logic for test-enable and
reset, and routes the TPG output into the CSID 1080 RX.

> diff --git a/drivers/media/platform/qcom/camss/camss-csid-1080.c b/drivers/media/platform/qcom/camss/camss-csid-1080.c
> --- a/drivers/media/platform/qcom/camss/camss-csid-1080.c
> +++ b/drivers/media/platform/qcom/camss/camss-csid-1080.c

[ ... ]

> @@ -148,8 +151,16 @@ static void __csid_configure_rx(struct csid_device *csid,
>  
>  	val = (lane_cnt - 1) << CSI2_RX_CFG0_NUM_ACTIVE_LANES;
>  	val |= phy->lane_assign << CSI2_RX_CFG0_DL0_INPUT_SEL;
> -	val |= (phy->csiphy_id + CSI2_RX_CFG0_PHY_SEL_BASE_IDX)
> -	       << CSI2_RX_CFG0_PHY_NUM_SEL;
> +
> +	if (camss->tpg && csid->tpg_linked &&
> +	    camss->tpg[phy->csiphy_id].testgen.mode != TPG_PAYLOAD_MODE_DISABLED) {

[Severity: Low]
Does reading camss->tpg[phy->csiphy_id].testgen.mode here introduce a data
race with concurrent V4L2 control updates?

The V4L2 control framework modifies testgen.mode in tpg_s_ctrl() while
holding the TPG control handler lock:

tpg_s_ctrl() -> tpg_configure_testgen_pattern()

Since __csid_configure_rx() reads this foreign subdevice state locklessly,
it bypasses the control framework's locking. Can this trigger a race condition
leading to a transient stream misconfiguration during concurrent VIDIOC_S_CTRL
calls?

> +		val |= FIELD_PREP(CSI2_RX_CFG0_TPG_MUX_SEL, phy->csiphy_id + 1);
> +		val |= CSI2_RX_CFG0_TPG_MUX_EN;
> +	} else {
> +		val |= (phy->csiphy_id + CSI2_RX_CFG0_PHY_SEL_BASE_IDX)
> +			<< CSI2_RX_CFG0_PHY_NUM_SEL;
> +	}
> +
>  	writel(val, csid->base + CSID_CSI2_RX_CFG0);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261008-kaanapali-camss-v19-0-b2c583ef50e0@oss.qualcomm.com?part=9

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy