All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Hangxiang Ma" <hangxiang.ma@oss.qualcomm.com>
Cc: linux-phy@lists.infradead.org, devicetree@vger.kernel.org,
	robh@kernel.org, conor+dt@kernel.org, media-ci@linuxtv.org,
	vkoul@kernel.org, neil.armstrong@linaro.org, olteanv@gmail.com
Subject: Re: [PATCH v24 11/15] media: qcom: camss: tpg: Add support for v2.4.0 TPG
Date: Mon, 02 Nov 2026 10:52:11 +0000	[thread overview]
Message-ID: <sashiko-outbox-193294@kernel.org> (raw)
In-Reply-To: <20261102-kaanapali-camss-v24-11-d6b8f3f6f66f@oss.qualcomm.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] media: qcom: camss: uninitialized hw_version check in tpg_reset()
--

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

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

This commit adds support for TPG hardware version 2.4.0 on Kaanapali,
controlling test-enable and hardware reset via the TPG_CTRL_CMD register and
routing the TPG output into CSID 1080 RX through 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..cabbb2638cf38 100644
> --- a/drivers/media/platform/qcom/camss/camss-tpg-gen1.c
> +++ b/drivers/media/platform/qcom/camss/camss-tpg-gen1.c

[ ... ]

> @@ -164,18 +167,26 @@ 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);
> +	if (tpg->hw_version < TPG_HW_VER_2_4_0)
> +		writel(0, tpg->base + TPG_CTRL);

[Severity: Medium]
As reported by Sashiko on v17 [1], is tpg->hw_version initialized when
tpg_reset() is called for the first time from tpg_set_power()?

In drivers/media/platform/qcom/camss/camss-tpg.c, tpg_set_power() calls
reset() before hw_version() populates tpg->hw_version from the
TPG_HW_VERSION register:

drivers/media/platform/qcom/camss/camss-tpg.c:tpg_set_power() {
	...
		tpg->res->hw_ops->reset(tpg);

		tpg->res->hw_ops->hw_version(tpg);
	...
}

On the first power-on after probe, tpg->hw_version is still 0, so
tpg->hw_version < TPG_HW_VER_2_4_0 evaluates to true and tpg_reset() writes
0 to TPG_CTRL even on v2.4.0 hardware. Should tpg_set_power() call
hw_version(tpg) before reset(tpg), or should tpg_reset() read the version if
needed?

[1] https://lore.kernel.org/r/20260929061248.E035C1F000FF@smtp.kernel.org

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261102-kaanapali-camss-v24-0-d6b8f3f6f66f@oss.qualcomm.com?part=11

-- 
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, devicetree@vger.kernel.org,
	robh@kernel.org, conor+dt@kernel.org, media-ci@linuxtv.org,
	vkoul@kernel.org, neil.armstrong@linaro.org, olteanv@gmail.com
Subject: Re: [PATCH v24 11/15] media: qcom: camss: tpg: Add support for v2.4.0 TPG
Date: Mon, 02 Nov 2026 10:52:11 +0000	[thread overview]
Message-ID: <sashiko-outbox-193294@kernel.org> (raw)
In-Reply-To: <20261102-kaanapali-camss-v24-11-d6b8f3f6f66f@oss.qualcomm.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] media: qcom: camss: uninitialized hw_version check in tpg_reset()
--

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

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

This commit adds support for TPG hardware version 2.4.0 on Kaanapali,
controlling test-enable and hardware reset via the TPG_CTRL_CMD register and
routing the TPG output into CSID 1080 RX through 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..cabbb2638cf38 100644
> --- a/drivers/media/platform/qcom/camss/camss-tpg-gen1.c
> +++ b/drivers/media/platform/qcom/camss/camss-tpg-gen1.c

[ ... ]

> @@ -164,18 +167,26 @@ 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);
> +	if (tpg->hw_version < TPG_HW_VER_2_4_0)
> +		writel(0, tpg->base + TPG_CTRL);

[Severity: Medium]
As reported by Sashiko on v17 [1], is tpg->hw_version initialized when
tpg_reset() is called for the first time from tpg_set_power()?

In drivers/media/platform/qcom/camss/camss-tpg.c, tpg_set_power() calls
reset() before hw_version() populates tpg->hw_version from the
TPG_HW_VERSION register:

drivers/media/platform/qcom/camss/camss-tpg.c:tpg_set_power() {
	...
		tpg->res->hw_ops->reset(tpg);

		tpg->res->hw_ops->hw_version(tpg);
	...
}

On the first power-on after probe, tpg->hw_version is still 0, so
tpg->hw_version < TPG_HW_VER_2_4_0 evaluates to true and tpg_reset() writes
0 to TPG_CTRL even on v2.4.0 hardware. Should tpg_set_power() call
hw_version(tpg) before reset(tpg), or should tpg_reset() read the version if
needed?

[1] https://lore.kernel.org/r/20260929061248.E035C1F000FF@smtp.kernel.org

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261102-kaanapali-camss-v24-0-d6b8f3f6f66f@oss.qualcomm.com?part=11

  reply	other threads:[~2026-11-02 10:52 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-02 10:42 [PATCH v24 00/15] media: qcom: camss: Add Kaanapali support Hangxiang Ma
2026-11-02 10:42 ` Hangxiang Ma
2026-11-02 10:42 ` [PATCH v24 01/15] dt-bindings: phy: qcom,x1e80100-csi2-phy: Add Kaanapali CSI2 PHY Hangxiang Ma
2026-11-02 10:42   ` Hangxiang Ma
2026-11-02 10:42 ` [PATCH v24 02/15] phy: qcom-mipi-csi2: Parametrise the common status register offset Hangxiang Ma
2026-11-02 10:42   ` Hangxiang Ma
2026-11-02 10:42 ` [PATCH v24 03/15] phy: qcom-mipi-csi2: Add Kaanapali support Hangxiang Ma
2026-11-02 10:42   ` Hangxiang Ma
2026-11-02 10:42 ` [PATCH v24 04/15] media: qcom: camss: Add addr_update hooks and guard CSID reg_update Hangxiang Ma
2026-11-02 10:42   ` Hangxiang Ma
2026-11-02 10:42 ` [PATCH v24 05/15] media: dt-bindings: Add CAMSS device for Kaanapali Hangxiang Ma
2026-11-02 10:42   ` Hangxiang Ma
2026-11-02 10:42 ` [PATCH v24 06/15] media: qcom: camss: Add Kaanapali compatible Hangxiang Ma
2026-11-02 10:42   ` Hangxiang Ma
2026-11-02 10:42 ` [PATCH v24 07/15] media: qcom: camss: Add PM clock definitions for Kaanapali Hangxiang Ma
2026-11-02 10:42   ` Hangxiang Ma
2026-11-02 10:42 ` [PATCH v24 08/15] media: qcom: camss: Allow CSI2 PHY devices without CSIPHY resources Hangxiang Ma
2026-11-02 10:42   ` Hangxiang Ma
2026-11-02 10:42 ` [PATCH v24 09/15] media: qcom: camss: csid: Add support for CSID 1080 Hangxiang Ma
2026-11-02 10:42   ` Hangxiang Ma
2026-11-02 11:02   ` sashiko-bot
2026-11-02 11:02     ` sashiko-bot
2026-11-02 10:42 ` [PATCH v24 10/15] media: qcom: camss: vfe: Add support for VFE 1080 Hangxiang Ma
2026-11-02 10:42   ` Hangxiang Ma
2026-11-02 10:56   ` sashiko-bot
2026-11-02 10:56     ` sashiko-bot
2026-11-02 10:42 ` [PATCH v24 11/15] media: qcom: camss: tpg: Add support for v2.4.0 TPG Hangxiang Ma
2026-11-02 10:42   ` Hangxiang Ma
2026-11-02 10:52   ` sashiko-bot [this message]
2026-11-02 10:52     ` sashiko-bot
2026-11-02 10:42 ` [PATCH v24 12/15] arm64: dts: qcom: kaanapali: Add CAMSS and CSIPHY block definitions Hangxiang Ma
2026-11-02 10:42   ` Hangxiang Ma
2026-11-02 10:57   ` sashiko-bot
2026-11-02 10:57     ` sashiko-bot
2026-11-02 10:42 ` [PATCH v24 13/15] arm64: dts: qcom: kaanapali: Add CCI controller nodes Hangxiang Ma
2026-11-02 10:42   ` Hangxiang Ma
2026-11-02 12:17   ` Loic Poulain
2026-11-02 12:17     ` Loic Poulain
2026-11-02 10:42 ` [PATCH v24 14/15] arm64: dts: qcom: kaanapali: Add camera MCLK pinctrl Hangxiang Ma
2026-11-02 10:42   ` Hangxiang Ma
2026-11-02 10:42 ` [PATCH v24 15/15] arm64: dts: qcom: kaanapali-mtp-camera-s5kjn5: Add DT overlay Hangxiang Ma
2026-11-02 10:42   ` 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=sashiko-outbox-193294@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.