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, olteanv@gmail.com,
robh@kernel.org, neil.armstrong@linaro.org, conor+dt@kernel.org,
devicetree@vger.kernel.org
Subject: Re: [PATCH v18 08/11] media: qcom: camss: tpg: Add support for v2.4.0 TPG
Date: Sat, 03 Oct 2026 09:16:10 +0000 [thread overview]
Message-ID: <20261003091610.BC9351F0089B@smtp.kernel.org> (raw)
In-Reply-To: <20261003-kaanapali-camss-v18-8-87ba4ebe0db1@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] media: camss: uninitialized hw_version used in tpg_reset()
--
commit df88e7d7afd82d4d282e25499832401b80cc7ee6
Author: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
media: qcom: camss: tpg: Add support for v2.4.0 TPG
Add support for the TPG found on Kaanapali. This TPG uses hardware
version 2.4.0, which drives test-enable and reset through a separate
TPG_CTRL_CMD register instead of TPG_CTRL, and routes its output into
the CSID 1080 RX via the CSI2 TPG mux.
> diff --git a/drivers/media/platform/qcom/camss/camss-tpg-gen1.c b/drivers/media/platform/qcom/camss/camss-tpg-gen1.c
> index d29de5f93c18e..770a9e5d5ba5f 100644
> --- a/drivers/media/platform/qcom/camss/camss-tpg-gen1.c
> +++ b/drivers/media/platform/qcom/camss/camss-tpg-gen1.c
[ ... ]
> @@ -164,18 +167,30 @@ static int tpg_stream_on(struct tpg_device *tpg)
[ ... ]
> static int tpg_reset(struct tpg_device *tpg)
> {
> - writel(0, tpg->base + TPG_CTRL);
> - writel(1, tpg->base + TPG_CLEAR);
> + /*
> + * On TPG older than v2.4.0 test-enable lives in TPG_CTRL, so clear it
> + * first; v2.4.0+ drives both test-enable and reset through TPG_CTRL_CMD.
> + */
> + if (tpg->hw_version < TPG_HW_VER_2_4_0)
[Severity: Medium]
Does this newly added check incorrectly evaluate to true on the first power
cycle due to tpg->hw_version being uninitialized?
Looking at tpg_set_power() in camss-tpg.c, the reset callback is invoked
before hw_version is populated:
tpg_set_power() {
...
tpg->res->hw_ops->reset(tpg);
tpg->res->hw_ops->hw_version(tpg);
...
}
Since tpg->hw_version is 0 during the first power cycle, this condition
will evaluate to true even for v2.4.0+ hardware. This executes the legacy
fallback reset writel(0, tpg->base + TPG_CTRL), which this patch explicitly
intended to avoid for newer hardware.
Can this unintended write prior to TPG_CTRL_CMD_HW_RESET cause issues on
v2.4.0 hardware?
> + writel(0, tpg->base + TPG_CTRL);
> +
> + writel(TPG_CTRL_CMD_HW_RESET, tpg->base + TPG_CTRL_CMD);
>
> return 0;
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261003-kaanapali-camss-v18-0-87ba4ebe0db1@oss.qualcomm.com?part=8
--
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: media-ci@linuxtv.org, vkoul@kernel.org,
linux-phy@lists.infradead.org, olteanv@gmail.com,
robh@kernel.org, neil.armstrong@linaro.org, conor+dt@kernel.org,
devicetree@vger.kernel.org
Subject: Re: [PATCH v18 08/11] media: qcom: camss: tpg: Add support for v2.4.0 TPG
Date: Sat, 03 Oct 2026 09:16:10 +0000 [thread overview]
Message-ID: <20261003091610.BC9351F0089B@smtp.kernel.org> (raw)
In-Reply-To: <20261003-kaanapali-camss-v18-8-87ba4ebe0db1@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] media: camss: uninitialized hw_version used in tpg_reset()
--
commit df88e7d7afd82d4d282e25499832401b80cc7ee6
Author: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
media: qcom: camss: tpg: Add support for v2.4.0 TPG
Add support for the TPG found on Kaanapali. This TPG uses hardware
version 2.4.0, which drives test-enable and reset through a separate
TPG_CTRL_CMD register instead of TPG_CTRL, and routes its output into
the CSID 1080 RX via the CSI2 TPG mux.
> diff --git a/drivers/media/platform/qcom/camss/camss-tpg-gen1.c b/drivers/media/platform/qcom/camss/camss-tpg-gen1.c
> index d29de5f93c18e..770a9e5d5ba5f 100644
> --- a/drivers/media/platform/qcom/camss/camss-tpg-gen1.c
> +++ b/drivers/media/platform/qcom/camss/camss-tpg-gen1.c
[ ... ]
> @@ -164,18 +167,30 @@ static int tpg_stream_on(struct tpg_device *tpg)
[ ... ]
> static int tpg_reset(struct tpg_device *tpg)
> {
> - writel(0, tpg->base + TPG_CTRL);
> - writel(1, tpg->base + TPG_CLEAR);
> + /*
> + * On TPG older than v2.4.0 test-enable lives in TPG_CTRL, so clear it
> + * first; v2.4.0+ drives both test-enable and reset through TPG_CTRL_CMD.
> + */
> + if (tpg->hw_version < TPG_HW_VER_2_4_0)
[Severity: Medium]
Does this newly added check incorrectly evaluate to true on the first power
cycle due to tpg->hw_version being uninitialized?
Looking at tpg_set_power() in camss-tpg.c, the reset callback is invoked
before hw_version is populated:
tpg_set_power() {
...
tpg->res->hw_ops->reset(tpg);
tpg->res->hw_ops->hw_version(tpg);
...
}
Since tpg->hw_version is 0 during the first power cycle, this condition
will evaluate to true even for v2.4.0+ hardware. This executes the legacy
fallback reset writel(0, tpg->base + TPG_CTRL), which this patch explicitly
intended to avoid for newer hardware.
Can this unintended write prior to TPG_CTRL_CMD_HW_RESET cause issues on
v2.4.0 hardware?
> + writel(0, tpg->base + TPG_CTRL);
> +
> + writel(TPG_CTRL_CMD_HW_RESET, tpg->base + TPG_CTRL_CMD);
>
> return 0;
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261003-kaanapali-camss-v18-0-87ba4ebe0db1@oss.qualcomm.com?part=8
next prev parent reply other threads:[~2026-10-03 9:16 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
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 [this message]
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=20261003091610.BC9351F0089B@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.