From: sashiko-bot@kernel.org
To: "Andrew Gigena" <mail@andrewgigena.dev>
Cc: devicetree@vger.kernel.org, linux-phy@lists.infradead.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 v3 4/7] media: qcom: camss: Match VFE lite clocks by name prefix
Date: Fri, 06 Nov 2026 18:49:52 +0000 [thread overview]
Message-ID: <sashiko-outbox-202104@kernel.org> (raw)
In-Reply-To: <20261106-sm8150-v7.4-rc1-camss-v3-4-0103e8a0bbcd@andrewgigena.dev>
Thank you for your contribution! Sashiko AI review found 3 potential
issues to consider:
- [High] media: qcom: camss: undeclared CAMSS_8150 in camss-vfe.c breaks
build
- [Low] media: qcom: camss: missing Fixes trailer for
vfe_match_clock_names() bug
- [Low] media: camss: unguarded lite clock checks in
vfe_match_clock_names()
--
commit 304a59495a7a3eb87dc5d254ba4381a9abf0957b
Author: Andrew Gigena <mail@andrewgigena.dev>
> media: qcom: camss: Match VFE lite clocks by name prefix
>
> vfe_match_clock_names() builds the expected lite clock name from
> vfe->id, but vfe->id is the index of the VFE in the resources array.
> On SoCs where the lite VFEs come after the full VFEs, the generated
> name is vfe_lite2, vfe_lite3, ... and never matches the actual
> vfe_lite0/vfe_lite1 clocks, so their rates are never programmed.
>
> Restrict the new prefix match to numbered "vfe_liteN" clocks (digit
> check) to avoid matching aux clocks, leaving the pre-existing
> vfe_lite_name and bare "vfe_lite" matches unchanged.
>
> This affects SM8150, SC7280 and SC8280XP. On a Pixel 4 (SM8150),
> streaming through VFE-lite0 left cam_cc_ife_lite_0_clk at 19.2 MHz and
> failed with "VFE reset timeout".
>
> Signed-off-by: Andrew Gigena <mail@andrewgigena.dev>
[Severity: Low]
This fixes VFE lite clock matching on existing platforms such as SC7280 and
SC8280XP. Should this include:
Fixes: bcd2adfef23a ("media: qcom: camss: Allow clocks vfeN vfe_liteN or vfe_lite")
> diff --git a/drivers/media/platform/qcom/camss/camss-vfe.c b/drivers/media/platform/qcom/camss/camss-vfe.c
> index 2680a9914765f..29e04d0971163 100644
> --- a/drivers/media/platform/qcom/camss/camss-vfe.c
> +++ b/drivers/media/platform/qcom/camss/camss-vfe.c
[ ... ]
> @@ -346,6 +347,7 @@ static u32 vfe_src_pad_code(struct vfe_line *line, u32 sink_code,
> case CAMSS_6350:
> case CAMSS_7280:
> case CAMSS_8x96:
> + case CAMSS_8150:
> case CAMSS_8250:
> case CAMSS_8280XP:
> case CAMSS_8300:
[Severity: High]
Does adding case CAMSS_8150 here and in vfe_bpl_align_rdi() break the build at
this commit? CAMSS_8150 is not declared in enum camss_version in
drivers/media/platform/qcom/camss/camss.h until the following commit "media:
qcom: camss: Add support for SM8150", where these two hunks belong.
> @@ -914,6 +916,9 @@ static int vfe_match_clock_names(struct vfe_device *vfe,
> return (!strcmp(clock->name, vfe_name) ||
> !strcmp(clock->name, vfe_lite_name) ||
> !strcmp(clock->name, "vfe_lite") ||
> + (vfe->res->is_lite &&
> + !strncmp(clock->name, "vfe_lite", 8) &&
> + isdigit((unsigned char)clock->name[8])) ||
> !strcmp(clock->name, "camnoc_axi") ||
> !strcmp(clock->name, "camnoc_rt_axi"));
> }
[Severity: Low]
As reported by Bryan O'Donoghue on v2 [1], should all lite clock checks in
vfe_match_clock_names() be gated on vfe->res->is_lite? Only lite VFE resource
entries use vfe_lite or vfe_liteN clocks, and once gated on vfe->res->is_lite,
the vfe_lite_name buffer and its snprintf() call are already covered by the
numbered "vfe_lite" prefix check and can be dropped.
[1] https://lore.kernel.org/r/ac2e970b-1f3a-4aef-9a84-034d7e460c0f@linaro.org
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261106-sm8150-v7.4-rc1-camss-v3-0-0103e8a0bbcd@andrewgigena.dev?part=4
WARNING: multiple messages have this Message-ID (diff)
From: sashiko-bot@kernel.org
To: "Andrew Gigena" <mail@andrewgigena.dev>
Cc: devicetree@vger.kernel.org, linux-phy@lists.infradead.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 v3 4/7] media: qcom: camss: Match VFE lite clocks by name prefix
Date: Fri, 06 Nov 2026 18:49:52 +0000 [thread overview]
Message-ID: <sashiko-outbox-202104@kernel.org> (raw)
In-Reply-To: <20261106-sm8150-v7.4-rc1-camss-v3-4-0103e8a0bbcd@andrewgigena.dev>
Thank you for your contribution! Sashiko AI review found 3 potential
issues to consider:
- [High] media: qcom: camss: undeclared CAMSS_8150 in camss-vfe.c breaks
build
- [Low] media: qcom: camss: missing Fixes trailer for
vfe_match_clock_names() bug
- [Low] media: camss: unguarded lite clock checks in
vfe_match_clock_names()
--
commit 304a59495a7a3eb87dc5d254ba4381a9abf0957b
Author: Andrew Gigena <mail@andrewgigena.dev>
> media: qcom: camss: Match VFE lite clocks by name prefix
>
> vfe_match_clock_names() builds the expected lite clock name from
> vfe->id, but vfe->id is the index of the VFE in the resources array.
> On SoCs where the lite VFEs come after the full VFEs, the generated
> name is vfe_lite2, vfe_lite3, ... and never matches the actual
> vfe_lite0/vfe_lite1 clocks, so their rates are never programmed.
>
> Restrict the new prefix match to numbered "vfe_liteN" clocks (digit
> check) to avoid matching aux clocks, leaving the pre-existing
> vfe_lite_name and bare "vfe_lite" matches unchanged.
>
> This affects SM8150, SC7280 and SC8280XP. On a Pixel 4 (SM8150),
> streaming through VFE-lite0 left cam_cc_ife_lite_0_clk at 19.2 MHz and
> failed with "VFE reset timeout".
>
> Signed-off-by: Andrew Gigena <mail@andrewgigena.dev>
[Severity: Low]
This fixes VFE lite clock matching on existing platforms such as SC7280 and
SC8280XP. Should this include:
Fixes: bcd2adfef23a ("media: qcom: camss: Allow clocks vfeN vfe_liteN or vfe_lite")
> diff --git a/drivers/media/platform/qcom/camss/camss-vfe.c b/drivers/media/platform/qcom/camss/camss-vfe.c
> index 2680a9914765f..29e04d0971163 100644
> --- a/drivers/media/platform/qcom/camss/camss-vfe.c
> +++ b/drivers/media/platform/qcom/camss/camss-vfe.c
[ ... ]
> @@ -346,6 +347,7 @@ static u32 vfe_src_pad_code(struct vfe_line *line, u32 sink_code,
> case CAMSS_6350:
> case CAMSS_7280:
> case CAMSS_8x96:
> + case CAMSS_8150:
> case CAMSS_8250:
> case CAMSS_8280XP:
> case CAMSS_8300:
[Severity: High]
Does adding case CAMSS_8150 here and in vfe_bpl_align_rdi() break the build at
this commit? CAMSS_8150 is not declared in enum camss_version in
drivers/media/platform/qcom/camss/camss.h until the following commit "media:
qcom: camss: Add support for SM8150", where these two hunks belong.
> @@ -914,6 +916,9 @@ static int vfe_match_clock_names(struct vfe_device *vfe,
> return (!strcmp(clock->name, vfe_name) ||
> !strcmp(clock->name, vfe_lite_name) ||
> !strcmp(clock->name, "vfe_lite") ||
> + (vfe->res->is_lite &&
> + !strncmp(clock->name, "vfe_lite", 8) &&
> + isdigit((unsigned char)clock->name[8])) ||
> !strcmp(clock->name, "camnoc_axi") ||
> !strcmp(clock->name, "camnoc_rt_axi"));
> }
[Severity: Low]
As reported by Bryan O'Donoghue on v2 [1], should all lite clock checks in
vfe_match_clock_names() be gated on vfe->res->is_lite? Only lite VFE resource
entries use vfe_lite or vfe_liteN clocks, and once gated on vfe->res->is_lite,
the vfe_lite_name buffer and its snprintf() call are already covered by the
numbered "vfe_lite" prefix check and can be dropped.
[1] https://lore.kernel.org/r/ac2e970b-1f3a-4aef-9a84-034d7e460c0f@linaro.org
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261106-sm8150-v7.4-rc1-camss-v3-0-0103e8a0bbcd@andrewgigena.dev?part=4
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
next prev parent reply other threads:[~2026-11-06 18:49 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-06 18:35 [PATCH v3 0/7] media: qcom: camss: Add SM8150 CAMSS support Andrew Gigena via B4 Relay
2026-11-06 18:35 ` Andrew Gigena
2026-11-06 18:35 ` Andrew Gigena via B4 Relay
2026-11-06 18:35 ` [PATCH v3 1/7] dt-bindings: i2c: qcom-cci: Document SM8150 compatible Andrew Gigena via B4 Relay
2026-11-06 18:35 ` Andrew Gigena
2026-11-06 18:35 ` Andrew Gigena via B4 Relay
2026-11-06 21:26 ` Vladimir Zapolskiy
2026-11-06 21:26 ` Vladimir Zapolskiy
2026-11-07 14:14 ` Wolfram Sang
2026-11-07 14:14 ` Wolfram Sang
2026-11-06 18:35 ` [PATCH v3 2/7] dt-bindings: media: qcom,sm8150-camss: Add SM8150 CAMSS Andrew Gigena via B4 Relay
2026-11-06 18:35 ` Andrew Gigena
2026-11-06 18:35 ` Andrew Gigena via B4 Relay
2026-11-06 21:38 ` Vladimir Zapolskiy
2026-11-06 21:38 ` Vladimir Zapolskiy
2026-11-10 23:46 ` Andrew Gigena
2026-11-10 23:46 ` Andrew Gigena
2026-11-09 10:44 ` Krzysztof Kozlowski
2026-11-09 10:44 ` Krzysztof Kozlowski
2026-11-10 15:43 ` Andrew Gigena
2026-11-10 15:43 ` Andrew Gigena
2026-11-06 18:35 ` [PATCH v3 3/7] dt-bindings: phy: qcom,sm8150-csi2-phy: Add SM8150 CSI2 PHY Andrew Gigena via B4 Relay
2026-11-06 18:35 ` Andrew Gigena
2026-11-06 18:35 ` Andrew Gigena via B4 Relay
2026-11-06 21:24 ` Vladimir Zapolskiy
2026-11-06 21:24 ` Vladimir Zapolskiy
2026-11-10 23:52 ` Andrew Gigena
2026-11-10 23:52 ` Andrew Gigena
2026-11-06 22:32 ` Bryan O'Donoghue
2026-11-06 22:32 ` Bryan O'Donoghue
2026-11-06 18:35 ` [PATCH v3 4/7] media: qcom: camss: Match VFE lite clocks by name prefix Andrew Gigena via B4 Relay
2026-11-06 18:35 ` Andrew Gigena
2026-11-06 18:35 ` Andrew Gigena via B4 Relay
2026-11-06 18:49 ` sashiko-bot [this message]
2026-11-06 18:49 ` sashiko-bot
2026-11-06 22:34 ` Bryan O'Donoghue
2026-11-06 22:34 ` Bryan O'Donoghue
2026-11-06 18:35 ` [PATCH v3 5/7] media: qcom: camss: Add support for SM8150 Andrew Gigena via B4 Relay
2026-11-06 18:35 ` Andrew Gigena
2026-11-06 18:35 ` Andrew Gigena via B4 Relay
2026-11-06 18:53 ` sashiko-bot
2026-11-06 18:53 ` sashiko-bot
2026-11-06 21:50 ` Vladimir Zapolskiy
2026-11-06 21:50 ` Vladimir Zapolskiy
2026-11-11 1:27 ` Andrew Gigena
2026-11-11 1:27 ` Andrew Gigena
2026-11-06 22:35 ` Bryan O'Donoghue
2026-11-06 22:35 ` Bryan O'Donoghue
2026-11-06 18:35 ` [PATCH v3 6/7] phy: qcom-mipi-csi2: Add SM8150 CSI2 DPHY support Andrew Gigena via B4 Relay
2026-11-06 18:35 ` Andrew Gigena
2026-11-06 18:35 ` Andrew Gigena via B4 Relay
2026-11-06 18:50 ` sashiko-bot
2026-11-06 18:50 ` sashiko-bot
2026-11-06 22:29 ` Bryan O'Donoghue
2026-11-06 22:29 ` Bryan O'Donoghue
2026-11-07 14:03 ` Bryan O'Donoghue
2026-11-07 14:03 ` Bryan O'Donoghue
2026-11-10 23:56 ` Andrew Gigena
2026-11-10 23:56 ` Andrew Gigena
2026-11-06 18:35 ` [PATCH v3 7/7] arm64: dts: qcom: sm8150: Add CAMSS and CCI nodes Andrew Gigena via B4 Relay
2026-11-06 18:35 ` Andrew Gigena
2026-11-06 18:35 ` Andrew Gigena via B4 Relay
2026-11-06 18:59 ` sashiko-bot
2026-11-06 18:59 ` sashiko-bot
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-202104@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=linux-phy@lists.infradead.org \
--cc=mail@andrewgigena.dev \
--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.