All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Bryan O'Donoghue" <bryan.odonoghue@linaro.org>
Cc: conor+dt@kernel.org, linux-phy@lists.infradead.org,
	neil.armstrong@linaro.org, media-ci@linuxtv.org, robh@kernel.org,
	vkoul@kernel.org, devicetree@vger.kernel.org, olteanv@gmail.com
Subject: Re: [PATCH v16 2/2] phy: qcom-mipi-csi2: Add a CSI2 MIPI DPHY driver
Date: Tue, 01 Sep 2026 20:24:57 +0000	[thread overview]
Message-ID: <20260901202457.60AD01F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260901-x1e-csi2-phy-v16-2-dd863b929080@linaro.org>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The MIPI CSI-2 PHY driver validates the dynamically requested lane count in `phy_configure` but then drops it, always powering up all statically connected lanes.
--

commit 195a47fa2ff62bda0e1e24d4911794d18fcb86c8
Author: Bryan O'Donoghue <bryan.odonoghue@linaro.org>

phy: qcom-mipi-csi2: Add a CSI2 MIPI DPHY driver

Add a new MIPI CSI2 driver in DPHY mode initially. The entire set of
existing CAMSS CSI PHY init sequences are imported in order to save time
and effort in later patches.

> diff --git a/drivers/phy/qualcomm/phy-qcom-mipi-csi2-core.c b/drivers/phy/qualcomm/phy-qcom-mipi-csi2-core.c
> new file mode 100644
> index 0000000000000..24ccd3264686f
> --- /dev/null
> +++ b/drivers/phy/qualcomm/phy-qcom-mipi-csi2-core.c
[ ... ]
> +static int phy_qcom_mipi_csi2_configure(struct phy *phy,
> +					union phy_configure_opts *opts)
> +{
> +	struct mipi_csi2phy_device *csi2phy = phy_get_drvdata(phy);
> +	struct phy_configure_opts_mipi_dphy *dphy_cfg = &opts->mipi_dphy;
> +	struct mipi_csi2phy_stream_cfg *stream_cfg = &csi2phy->stream_cfg;
> +	int ret;
> +
> +	ret = phy_mipi_dphy_config_validate(dphy_cfg);
> +	if (ret)
> +		return ret;
> +
> +	if (dphy_cfg->lanes < 1 || dphy_cfg->lanes > CSI2_MAX_DATA_LANES)
> +		return -EINVAL;
> +
> +	stream_cfg->link_freq = dphy_cfg->hs_clk_rate;
> +
> +	return 0;
> +}

[Severity: Medium]
Does this code inadvertently drop the requested lane count from
opts->mipi_dphy.lanes?

In phy_qcom_mipi_csi2_configure(), dphy_cfg->lanes is bounds-checked but
never assigned to stream_cfg->num_data_lanes. This causes the dynamic lane
count to be dropped.

Because it is dropped, the driver later relies on the statically probed count
when enabling the lanes:

drivers/phy/qualcomm/phy-qcom-mipi-csi2-3ph-dphy.c:phy_qcom_mipi_csi2_lanes_enable() {
    ...
    val = BIT(lane_cfg->clk.pos);
    for (i = 0; i < cfg->num_data_lanes; i++)
        val |= BIT(lane_cfg->data[i].pos * 2);
    ...
}

Should stream_cfg->num_data_lanes be updated here so that the PHY only
powers up the requested subset of physically connected lanes?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260901-x1e-csi2-phy-v16-0-dd863b929080@linaro.org?part=2

WARNING: multiple messages have this Message-ID (diff)
From: sashiko-bot@kernel.org
To: "Bryan O'Donoghue" <bryan.odonoghue@linaro.org>
Cc: conor+dt@kernel.org, linux-phy@lists.infradead.org,
	neil.armstrong@linaro.org, media-ci@linuxtv.org, robh@kernel.org,
	vkoul@kernel.org, devicetree@vger.kernel.org, olteanv@gmail.com
Subject: Re: [PATCH v16 2/2] phy: qcom-mipi-csi2: Add a CSI2 MIPI DPHY driver
Date: Tue, 01 Sep 2026 20:24:57 +0000	[thread overview]
Message-ID: <20260901202457.60AD01F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260901-x1e-csi2-phy-v16-2-dd863b929080@linaro.org>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The MIPI CSI-2 PHY driver validates the dynamically requested lane count in `phy_configure` but then drops it, always powering up all statically connected lanes.
--

commit 195a47fa2ff62bda0e1e24d4911794d18fcb86c8
Author: Bryan O'Donoghue <bryan.odonoghue@linaro.org>

phy: qcom-mipi-csi2: Add a CSI2 MIPI DPHY driver

Add a new MIPI CSI2 driver in DPHY mode initially. The entire set of
existing CAMSS CSI PHY init sequences are imported in order to save time
and effort in later patches.

> diff --git a/drivers/phy/qualcomm/phy-qcom-mipi-csi2-core.c b/drivers/phy/qualcomm/phy-qcom-mipi-csi2-core.c
> new file mode 100644
> index 0000000000000..24ccd3264686f
> --- /dev/null
> +++ b/drivers/phy/qualcomm/phy-qcom-mipi-csi2-core.c
[ ... ]
> +static int phy_qcom_mipi_csi2_configure(struct phy *phy,
> +					union phy_configure_opts *opts)
> +{
> +	struct mipi_csi2phy_device *csi2phy = phy_get_drvdata(phy);
> +	struct phy_configure_opts_mipi_dphy *dphy_cfg = &opts->mipi_dphy;
> +	struct mipi_csi2phy_stream_cfg *stream_cfg = &csi2phy->stream_cfg;
> +	int ret;
> +
> +	ret = phy_mipi_dphy_config_validate(dphy_cfg);
> +	if (ret)
> +		return ret;
> +
> +	if (dphy_cfg->lanes < 1 || dphy_cfg->lanes > CSI2_MAX_DATA_LANES)
> +		return -EINVAL;
> +
> +	stream_cfg->link_freq = dphy_cfg->hs_clk_rate;
> +
> +	return 0;
> +}

[Severity: Medium]
Does this code inadvertently drop the requested lane count from
opts->mipi_dphy.lanes?

In phy_qcom_mipi_csi2_configure(), dphy_cfg->lanes is bounds-checked but
never assigned to stream_cfg->num_data_lanes. This causes the dynamic lane
count to be dropped.

Because it is dropped, the driver later relies on the statically probed count
when enabling the lanes:

drivers/phy/qualcomm/phy-qcom-mipi-csi2-3ph-dphy.c:phy_qcom_mipi_csi2_lanes_enable() {
    ...
    val = BIT(lane_cfg->clk.pos);
    for (i = 0; i < cfg->num_data_lanes; i++)
        val |= BIT(lane_cfg->data[i].pos * 2);
    ...
}

Should stream_cfg->num_data_lanes be updated here so that the PHY only
powers up the requested subset of physically connected lanes?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260901-x1e-csi2-phy-v16-0-dd863b929080@linaro.org?part=2

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

  reply	other threads:[~2026-09-01 20:24 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-01 20:15 [PATCH v16 0/2] phy: qcom-mipi-csi2: Add a CSI2 MIPI DPHY driver Bryan O'Donoghue
2026-09-01 20:15 ` Bryan O'Donoghue
2026-09-01 20:15 ` [PATCH v16 1/2] dt-bindings: phy: qcom: Add CSI2 C-PHY/DPHY schema Bryan O'Donoghue
2026-09-01 20:15   ` Bryan O'Donoghue
2026-09-01 20:26   ` sashiko-bot
2026-09-01 20:26     ` sashiko-bot
2026-09-03 11:53   ` Vladimir Zapolskiy
2026-09-03 11:53     ` Vladimir Zapolskiy
2026-09-03 12:32     ` Bryan O'Donoghue
2026-09-03 12:32       ` Bryan O'Donoghue
2026-09-03 16:16       ` Vladimir Zapolskiy
2026-09-03 16:16         ` Vladimir Zapolskiy
2026-09-01 20:15 ` [PATCH v16 2/2] phy: qcom-mipi-csi2: Add a CSI2 MIPI DPHY driver Bryan O'Donoghue
2026-09-01 20:15   ` Bryan O'Donoghue
2026-09-01 20:24   ` sashiko-bot [this message]
2026-09-01 20:24     ` sashiko-bot
2026-09-02  7:07   ` Neil Armstrong
2026-09-02  7:07     ` Neil Armstrong
2026-09-03 13:15   ` Vladimir Zapolskiy
2026-09-03 13:15     ` Vladimir Zapolskiy

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=20260901202457.60AD01F00A3A@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-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.