From: sashiko-bot@kernel.org
To: "Bryan O'Donoghue" <bryan.odonoghue@linaro.org>
Cc: media-ci@linuxtv.org, linux-phy@lists.infradead.org,
devicetree@vger.kernel.org, olteanv@gmail.com,
conor+dt@kernel.org, neil.armstrong@linaro.org, vkoul@kernel.org,
linux-clk@vger.kernel.org, robh@kernel.org
Subject: Re: [PATCH v16 5/5] media: qcom: camss: Use data-lanes starting at 1 for new CSIPHY mode
Date: Sun, 06 Sep 2026 12:00:01 +0000 [thread overview]
Message-ID: <20260906120002.4A1D71F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260906-b4-linux-next-25-03-13-dtsi-x1e80100-camss-v16-5-f7bd68b5369f@linaro.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The patch introduces a build failure due to an undeclared identifier `CSI2_MAX_DATA_LANES` used in the bounds check. The correct identifier is likely `V4L2_MBUS_CSI2_MAX_DATA_LANES`.
--
commit 6412cb87019badaa2684393747963c54499766bc
Author: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
media: qcom: camss: Use data-lanes starting at 1 for new CSIPHY mode
This patch updates the CSIPHY logic to accommodate a change where data-lane
indexing starts at 1 instead of 0 for new CSIPHY modes. It introduces a
lane_base offset to dynamically normalize the lane indices depending on
whether the PHY is legacy or new.
> diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c
> index 84097d82d99c9..8a4d8a206cf0d 100644
> --- a/drivers/media/platform/qcom/camss/camss.c
> +++ b/drivers/media/platform/qcom/camss/camss.c
[ ... ]
> @@ -4777,7 +4778,14 @@ static int camss_parse_endpoint_node(struct device *dev,
> return -ENOMEM;
>
> for (i = 0; i < lncfg->num_data; i++) {
> - lncfg->data[i].pos = mipi_csi2->data_lanes[i];
> + u8 lane = mipi_csi2->data_lanes[i];
> +
> + if (lane < lane_base || lane - lane_base >= CSI2_MAX_DATA_LANES) {
[Severity: Low]
Is there a missing declaration for CSI2_MAX_DATA_LANES here? This looks like it
might cause a build failure. Should this be V4L2_MBUS_CSI2_MAX_DATA_LANES
instead?
> + dev_err(dev, "invalid data-lane %u\n", lane);
> + return -EINVAL;
> + }
> +
> + lncfg->data[i].pos = mipi_csi2->data_lanes[i] - lane_base;
> lncfg->data[i].pol = mipi_csi2->lane_polarities[i + 1];
> }
>
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260906-b4-linux-next-25-03-13-dtsi-x1e80100-camss-v16-0-f7bd68b5369f@linaro.org?part=5
WARNING: multiple messages have this Message-ID (diff)
From: sashiko-bot@kernel.org
To: "Bryan O'Donoghue" <bryan.odonoghue@linaro.org>
Cc: media-ci@linuxtv.org, linux-phy@lists.infradead.org,
devicetree@vger.kernel.org, olteanv@gmail.com,
conor+dt@kernel.org, neil.armstrong@linaro.org, vkoul@kernel.org,
linux-clk@vger.kernel.org, robh@kernel.org
Subject: Re: [PATCH v16 5/5] media: qcom: camss: Use data-lanes starting at 1 for new CSIPHY mode
Date: Sun, 06 Sep 2026 12:00:01 +0000 [thread overview]
Message-ID: <20260906120002.4A1D71F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260906-b4-linux-next-25-03-13-dtsi-x1e80100-camss-v16-5-f7bd68b5369f@linaro.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The patch introduces a build failure due to an undeclared identifier `CSI2_MAX_DATA_LANES` used in the bounds check. The correct identifier is likely `V4L2_MBUS_CSI2_MAX_DATA_LANES`.
--
commit 6412cb87019badaa2684393747963c54499766bc
Author: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
media: qcom: camss: Use data-lanes starting at 1 for new CSIPHY mode
This patch updates the CSIPHY logic to accommodate a change where data-lane
indexing starts at 1 instead of 0 for new CSIPHY modes. It introduces a
lane_base offset to dynamically normalize the lane indices depending on
whether the PHY is legacy or new.
> diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c
> index 84097d82d99c9..8a4d8a206cf0d 100644
> --- a/drivers/media/platform/qcom/camss/camss.c
> +++ b/drivers/media/platform/qcom/camss/camss.c
[ ... ]
> @@ -4777,7 +4778,14 @@ static int camss_parse_endpoint_node(struct device *dev,
> return -ENOMEM;
>
> for (i = 0; i < lncfg->num_data; i++) {
> - lncfg->data[i].pos = mipi_csi2->data_lanes[i];
> + u8 lane = mipi_csi2->data_lanes[i];
> +
> + if (lane < lane_base || lane - lane_base >= CSI2_MAX_DATA_LANES) {
[Severity: Low]
Is there a missing declaration for CSI2_MAX_DATA_LANES here? This looks like it
might cause a build failure. Should this be V4L2_MBUS_CSI2_MAX_DATA_LANES
instead?
> + dev_err(dev, "invalid data-lane %u\n", lane);
> + return -EINVAL;
> + }
> +
> + lncfg->data[i].pos = mipi_csi2->data_lanes[i] - lane_base;
> lncfg->data[i].pol = mipi_csi2->lane_polarities[i + 1];
> }
>
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260906-b4-linux-next-25-03-13-dtsi-x1e80100-camss-v16-0-f7bd68b5369f@linaro.org?part=5
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
next prev parent reply other threads:[~2026-09-06 12:00 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-06 11:52 [PATCH v16 0/5] Add phy_get_by_of_node and devm helper Bryan O'Donoghue
2026-09-06 11:52 ` Bryan O'Donoghue
2026-09-06 11:52 ` [PATCH v16 1/5] phy: core: Fix use-after-free in phy_get paths Bryan O'Donoghue
2026-09-06 11:52 ` Bryan O'Donoghue
2026-09-11 20:56 ` Frank Li
2026-09-11 20:56 ` Frank Li
2026-09-14 11:37 ` Bryan O'Donoghue
2026-09-14 11:37 ` Bryan O'Donoghue
2026-09-14 13:55 ` Frank Li
2026-09-14 13:55 ` Frank Li
2026-09-14 15:49 ` Krzysztof Kozlowski
2026-09-14 15:49 ` Krzysztof Kozlowski
2026-09-06 11:52 ` [PATCH v16 2/5] phy: core: Add phy_get_by_of_node() Bryan O'Donoghue
2026-09-06 11:52 ` Bryan O'Donoghue
2026-09-06 11:52 ` [PATCH v16 3/5] phy: core: Add devm_phy_get_by_of_node() Bryan O'Donoghue
2026-09-06 11:52 ` Bryan O'Donoghue
2026-09-11 21:09 ` Frank Li
2026-09-11 21:09 ` Frank Li
2026-09-14 11:03 ` Bryan O'Donoghue
2026-09-14 11:03 ` Bryan O'Donoghue
2026-09-06 11:52 ` [PATCH v16 4/5] media: qcom: camss: Add support for PHY API devices Bryan O'Donoghue
2026-09-06 11:52 ` Bryan O'Donoghue
2026-09-06 12:07 ` sashiko-bot
2026-09-06 12:07 ` sashiko-bot
2026-09-06 11:52 ` [PATCH v16 5/5] media: qcom: camss: Use data-lanes starting at 1 for new CSIPHY mode Bryan O'Donoghue
2026-09-06 11:52 ` Bryan O'Donoghue
2026-09-06 12:00 ` sashiko-bot [this message]
2026-09-06 12:00 ` sashiko-bot
2026-09-06 13:03 ` Nihal Kumar Gupta
2026-09-06 13:03 ` Nihal Kumar Gupta
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=20260906120002.4A1D71F00A3A@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bryan.odonoghue@linaro.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=linux-clk@vger.kernel.org \
--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.