From: sashiko-bot@kernel.org
To: "Hangxiang Ma" <hangxiang.ma@oss.qualcomm.com>
Cc: linux-phy@lists.infradead.org, robh@kernel.org,
olteanv@gmail.com, conor+dt@kernel.org,
neil.armstrong@linaro.org, devicetree@vger.kernel.org,
media-ci@linuxtv.org, vkoul@kernel.org
Subject: Re: [PATCH v18 06/11] media: qcom: camss: csid: Add support for CSID 1080
Date: Sat, 03 Oct 2026 09:18:32 +0000 [thread overview]
Message-ID: <20261003091832.92E9B1F0089B@smtp.kernel.org> (raw)
In-Reply-To: <20261003-kaanapali-camss-v18-6-87ba4ebe0db1@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Data Race / Unprotected State Modification
--
commit e1475151b2b7806091d8fbadf7603ba11320d02e
Author: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
media: qcom: camss: csid: Add support for CSID 1080
Add support for the CSID 1080 hardware found on Kaanapali SoC.
Introduce CSID 1080 hardware resource descriptions and implement the
hardware-specific register programming, reset sequence, and BUF_DONE
interrupt handling. CSID 1080 splits RUP and AUP updates into separate
registers and uses a SET register to commit the updates.
> diff --git a/drivers/media/platform/qcom/camss/camss-csid-1080.c b/drivers/media/platform/qcom/camss/camss-csid-1080.c
> new file mode 100644
> index 0000000000000..46e443e05195a
> --- /dev/null
> +++ b/drivers/media/platform/qcom/camss/camss-csid-1080.c
[ ... ]
> +static void __csid_aup_rup_clear(struct csid_device *csid, int port_id)
> +{
> + /* Hardware clears the registers upon consuming the settings */
> + csid->aup_update &= ~CSID_RUP_AUP_RDI(port_id);
> + csid->rup_update &= ~CSID_RUP_AUP_RDI(port_id);
> +}
> +
> +static void __csid_aup_update(struct csid_device *csid, int port_id)
> +{
> + csid->aup_update |= CSID_RUP_AUP_RDI(port_id);
> + writel(csid->aup_update, csid->base + CSID_AUP_CMD);
> +
> + __csid_aup_rup_trigger(csid);
> +}
> +
> +static void __csid_reg_update(struct csid_device *csid, int port_id)
> +{
> + csid->rup_update |= CSID_RUP_AUP_RDI(port_id);
> + writel(csid->rup_update, csid->base + CSID_RUP_CMD);
> +
> + __csid_aup_rup_trigger(csid);
> +}
[Severity: Low]
Can these un-synchronized read-modify-write operations race between hardirq
and process contexts?
When starting multiple streams in csid_configure_stream(), RDI 0 could
complete a frame and trigger the BUF_DONE interrupt while RDI 1 is still being
configured. This would cause csid_isr() to call __csid_aup_rup_clear()
concurrently with __csid_aup_update() or __csid_reg_update() executing in
process context.
Since these updates to csid->aup_update and csid->rup_update are unprotected,
a concurrent modification might cause bit updates to be lost. While this might
only lead to a harmless redundant trigger or prevent a redundant write, it is
undefined behavior in C and can trigger KCSAN warnings.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261003-kaanapali-camss-v18-0-87ba4ebe0db1@oss.qualcomm.com?part=6
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
WARNING: multiple messages have this Message-ID (diff)
From: sashiko-bot@kernel.org
To: "Hangxiang Ma" <hangxiang.ma@oss.qualcomm.com>
Cc: linux-phy@lists.infradead.org, robh@kernel.org,
olteanv@gmail.com, conor+dt@kernel.org,
neil.armstrong@linaro.org, devicetree@vger.kernel.org,
media-ci@linuxtv.org, vkoul@kernel.org
Subject: Re: [PATCH v18 06/11] media: qcom: camss: csid: Add support for CSID 1080
Date: Sat, 03 Oct 2026 09:18:32 +0000 [thread overview]
Message-ID: <20261003091832.92E9B1F0089B@smtp.kernel.org> (raw)
In-Reply-To: <20261003-kaanapali-camss-v18-6-87ba4ebe0db1@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Data Race / Unprotected State Modification
--
commit e1475151b2b7806091d8fbadf7603ba11320d02e
Author: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
media: qcom: camss: csid: Add support for CSID 1080
Add support for the CSID 1080 hardware found on Kaanapali SoC.
Introduce CSID 1080 hardware resource descriptions and implement the
hardware-specific register programming, reset sequence, and BUF_DONE
interrupt handling. CSID 1080 splits RUP and AUP updates into separate
registers and uses a SET register to commit the updates.
> diff --git a/drivers/media/platform/qcom/camss/camss-csid-1080.c b/drivers/media/platform/qcom/camss/camss-csid-1080.c
> new file mode 100644
> index 0000000000000..46e443e05195a
> --- /dev/null
> +++ b/drivers/media/platform/qcom/camss/camss-csid-1080.c
[ ... ]
> +static void __csid_aup_rup_clear(struct csid_device *csid, int port_id)
> +{
> + /* Hardware clears the registers upon consuming the settings */
> + csid->aup_update &= ~CSID_RUP_AUP_RDI(port_id);
> + csid->rup_update &= ~CSID_RUP_AUP_RDI(port_id);
> +}
> +
> +static void __csid_aup_update(struct csid_device *csid, int port_id)
> +{
> + csid->aup_update |= CSID_RUP_AUP_RDI(port_id);
> + writel(csid->aup_update, csid->base + CSID_AUP_CMD);
> +
> + __csid_aup_rup_trigger(csid);
> +}
> +
> +static void __csid_reg_update(struct csid_device *csid, int port_id)
> +{
> + csid->rup_update |= CSID_RUP_AUP_RDI(port_id);
> + writel(csid->rup_update, csid->base + CSID_RUP_CMD);
> +
> + __csid_aup_rup_trigger(csid);
> +}
[Severity: Low]
Can these un-synchronized read-modify-write operations race between hardirq
and process contexts?
When starting multiple streams in csid_configure_stream(), RDI 0 could
complete a frame and trigger the BUF_DONE interrupt while RDI 1 is still being
configured. This would cause csid_isr() to call __csid_aup_rup_clear()
concurrently with __csid_aup_update() or __csid_reg_update() executing in
process context.
Since these updates to csid->aup_update and csid->rup_update are unprotected,
a concurrent modification might cause bit updates to be lost. While this might
only lead to a harmless redundant trigger or prevent a redundant write, it is
undefined behavior in C and can trigger KCSAN warnings.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261003-kaanapali-camss-v18-0-87ba4ebe0db1@oss.qualcomm.com?part=6
next prev parent reply other threads:[~2026-10-03 9:18 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-03 9:02 [PATCH v18 00/11] media: qcom: camss: Add Kaanapali support Hangxiang Ma
2026-10-03 9:02 ` Hangxiang Ma
2026-10-03 9:02 ` [PATCH v18 01/11] dt-bindings: phy: qcom,x1e80100-csi2-phy: Add Kaanapali CSI2 PHY Hangxiang Ma
2026-10-03 9:02 ` Hangxiang Ma
2026-10-03 9:02 ` [PATCH v18 02/11] media: dt-bindings: Add CAMSS device for Kaanapali Hangxiang Ma
2026-10-03 9:02 ` Hangxiang Ma
2026-10-03 9:04 ` Bryan O'Donoghue
2026-10-03 9:04 ` Bryan O'Donoghue
2026-10-06 2:56 ` Rob Herring (Arm)
2026-10-06 2:56 ` Rob Herring (Arm)
2026-10-03 9:02 ` [PATCH v18 03/11] media: qcom: camss: Add Kaanapali compatible Hangxiang Ma
2026-10-03 9:02 ` Hangxiang Ma
2026-10-03 9:02 ` [PATCH v18 04/11] phy: qcom-mipi-csi2: Parametrise the common status register offset Hangxiang Ma
2026-10-03 9:02 ` Hangxiang Ma
2026-10-03 9:08 ` Bryan O'Donoghue
2026-10-03 9:08 ` Bryan O'Donoghue
2026-10-03 11:10 ` Hangxiang Ma
2026-10-03 11:10 ` Hangxiang Ma
2026-10-03 21:13 ` Bryan O'Donoghue
2026-10-03 21:13 ` Bryan O'Donoghue
2026-10-03 9:02 ` [PATCH v18 05/11] media: qcom: camss: csiphy: Add support for v2.4.0 two-phase CSIPHY Hangxiang Ma
2026-10-03 9:02 ` Hangxiang Ma
2026-10-03 9:09 ` Bryan O'Donoghue
2026-10-03 9:09 ` Bryan O'Donoghue
2026-10-03 11:11 ` Hangxiang Ma
2026-10-03 11:11 ` Hangxiang Ma
2026-10-03 9:02 ` [PATCH v18 06/11] media: qcom: camss: csid: Add support for CSID 1080 Hangxiang Ma
2026-10-03 9:02 ` Hangxiang Ma
2026-10-03 9:18 ` sashiko-bot [this message]
2026-10-03 9:18 ` sashiko-bot
2026-10-03 9:02 ` [PATCH v18 07/11] media: qcom: camss: vfe: Add support for VFE 1080 Hangxiang Ma
2026-10-03 9:02 ` Hangxiang Ma
2026-10-03 9:21 ` sashiko-bot
2026-10-03 9:21 ` sashiko-bot
2026-10-03 9:02 ` [PATCH v18 08/11] media: qcom: camss: tpg: Add support for v2.4.0 TPG Hangxiang Ma
2026-10-03 9:02 ` Hangxiang Ma
2026-10-03 9:16 ` sashiko-bot
2026-10-03 9:16 ` sashiko-bot
2026-10-03 9:02 ` [PATCH v18 09/11] arm64: dts: qcom: kaanapali: Add CAMSS and CSIPHY block definitions Hangxiang Ma
2026-10-03 9:02 ` Hangxiang Ma
2026-10-03 9:19 ` sashiko-bot
2026-10-03 9:19 ` sashiko-bot
2026-10-03 9:02 ` [PATCH v18 10/11] arm64: dts: qcom: kaanapali: Add CCI controller nodes Hangxiang Ma
2026-10-03 9:02 ` Hangxiang Ma
2026-10-03 9:02 ` [PATCH v18 11/11] arm64: dts: qcom: kaanapali: Add camera MCLK pinctrl Hangxiang Ma
2026-10-03 9:02 ` Hangxiang Ma
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=20261003091832.92E9B1F0089B@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=hangxiang.ma@oss.qualcomm.com \
--cc=linux-phy@lists.infradead.org \
--cc=media-ci@linuxtv.org \
--cc=neil.armstrong@linaro.org \
--cc=olteanv@gmail.com \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=vkoul@kernel.org \
/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.