| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <de5fbe8d-3f9e-4be8-a9e3-991b959305e4@linaro.org>
Date: Sat, 17 Jan 2026 21:38:17 +0000
From: Bryan O'Donoghue <bryan.odonoghue@...aro.org>
To: david@...t.cz, Robert Foss <rfoss@...nel.org>,
Todor Tomov <todor.too@...il.com>,
Vladimir Zapolskiy <vladimir.zapolskiy@...aro.org>,
Mauro Carvalho Chehab <mchehab@...nel.org>,
Luca Weiss <luca.weiss@...rphone.com>, Petr Hodina <phodina@...tonmail.com>,
Casey Connolly <casey.connolly@...aro.org>, "Dr. Git" <drgitx@...il.com>
Cc: Konrad Dybcio <konrad.dybcio@....qualcomm.com>,
Joel Selvaraj <foss@...lselvaraj.com>, Kieran Bingham <kbingham@...nel.org>,
Sakari Ailus <sakari.ailus@...ux.intel.com>, linux-media@...r.kernel.org,
linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
phone-devel@...r.kernel.org
Subject: Re: [PATCH v3 2/8] media: qcom: camss: csiphy-3ph: Use odd bits for
configuring C-PHY lanes
On 17/01/2026 15:36, David Heidelberg via B4 Relay wrote:
> From: David Heidelberg <david@...t.cz>
>
> So far, only D-PHY mode was supported, which uses even bits when enabling
> or masking lanes. For C-PHY configuration, the hardware instead requires
> using the odd bits.
>
> Since there can be unrecognized configuration allow returning failure.
>
> Signed-off-by: David Heidelberg <david@...t.cz>
> ---
> .../platform/qcom/camss/camss-csiphy-2ph-1-0.c | 8 ++--
> .../platform/qcom/camss/camss-csiphy-3ph-1-0.c | 49 +++++++++++++++++-----
> drivers/media/platform/qcom/camss/camss-csiphy.c | 4 +-
> drivers/media/platform/qcom/camss/camss-csiphy.h | 6 +--
> 4 files changed, 47 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/media/platform/qcom/camss/camss-csiphy-2ph-1-0.c b/drivers/media/platform/qcom/camss/camss-csiphy-2ph-1-0.c
> index 9d67e7fa6366a..bb4b91f69616b 100644
> --- a/drivers/media/platform/qcom/camss/camss-csiphy-2ph-1-0.c
> +++ b/drivers/media/platform/qcom/camss/camss-csiphy-2ph-1-0.c
> @@ -94,9 +94,9 @@ static u8 csiphy_settle_cnt_calc(s64 link_freq, u32 timer_clk_rate)
> return settle_cnt;
> }
>
> -static void csiphy_lanes_enable(struct csiphy_device *csiphy,
> - struct csiphy_config *cfg,
> - s64 link_freq, u8 lane_mask)
> +static int csiphy_lanes_enable(struct csiphy_device *csiphy,
> + struct csiphy_config *cfg,
> + s64 link_freq, u8 lane_mask)
> {
> struct csiphy_lanes_cfg *c = &cfg->csi2->lane_cfg;
> u8 settle_cnt;
> @@ -132,6 +132,8 @@ static void csiphy_lanes_enable(struct csiphy_device *csiphy,
> writel_relaxed(0x3f, csiphy->base +
> CAMSS_CSI_PHY_INTERRUPT_CLEARn(l));
> }
> +
> + return 0;
> }
>
> static void csiphy_lanes_disable(struct csiphy_device *csiphy,
> diff --git a/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c b/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
> index 4154832745525..f3a8625511e1e 100644
> --- a/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
> +++ b/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
> @@ -14,6 +14,7 @@
> #include <linux/delay.h>
> #include <linux/interrupt.h>
> #include <linux/io.h>
> +#include <linux/media-bus-format.h>
>
> #define CSIPHY_3PH_LNn_CFG1(n) (0x000 + 0x100 * (n))
> #define CSIPHY_3PH_LNn_CFG1_SWI_REC_DLY_PRG (BIT(7) | BIT(6))
> @@ -993,13 +994,22 @@ static void csiphy_gen2_config_lanes(struct csiphy_device *csiphy,
>
> static u8 csiphy_get_lane_mask(struct csiphy_lanes_cfg *lane_cfg)
> {
> - u8 lane_mask;
> - int i;
> + u8 lane_mask = 0;
>
> - lane_mask = CSIPHY_3PH_CMN_CSI_COMMON_CTRL5_CLK_ENABLE;
> + switch (lane_cfg->phy_cfg) {
> + case V4L2_MBUS_CSI2_CPHY:
> + for (int i = 0; i < lane_cfg->num_data; i++)
> + lane_mask |= (1 << lane_cfg->data[i].pos) + 1;
1 << anything == BIT(anything)
I've always disliked the look of this code and now it occurs to me why.
This code is analogous to:
lane_mask |= BIT(lane_cfg->data[i].pos) + 1);
but BIT() is less janky and more upstreamy.
janky/upstreamy - this is the on-point technical argument y'all came
here for :)
> + break;
> + case V4L2_MBUS_CSI2_DPHY:
> + lane_mask = CSIPHY_3PH_CMN_CSI_COMMON_CTRL5_CLK_ENABLE;
>
> - for (i = 0; i < lane_cfg->num_data; i++)
> - lane_mask |= 1 << lane_cfg->data[i].pos;
> + for (int i = 0; i < lane_cfg->num_data; i++)
> + lane_mask |= 1 << lane_cfg->data[i].pos;
> + break;
> + default:
> + break;
> + }
>
> return lane_mask;
> }
> @@ -1027,10 +1037,11 @@ static bool csiphy_is_gen2(u32 version)
> return ret;
> }
>
> -static void csiphy_lanes_enable(struct csiphy_device *csiphy,
> - struct csiphy_config *cfg,
> - s64 link_freq, u8 lane_mask)
> +static int csiphy_lanes_enable(struct csiphy_device *csiphy,
> + struct csiphy_config *cfg,
> + s64 link_freq, u8 lane_mask)
> {
> + struct device *dev = csiphy->camss->dev;
> struct csiphy_lanes_cfg *c = &cfg->csi2->lane_cfg;
> struct csiphy_device_regs *regs = csiphy->regs;
> u8 settle_cnt;
> @@ -1039,9 +1050,23 @@ static void csiphy_lanes_enable(struct csiphy_device *csiphy,
>
> settle_cnt = csiphy_settle_cnt_calc(link_freq, csiphy->timer_clk_rate);
>
> - val = CSIPHY_3PH_CMN_CSI_COMMON_CTRL5_CLK_ENABLE;
> - for (i = 0; i < c->num_data; i++)
> - val |= BIT(c->data[i].pos * 2);
> + val = 0;
> +
> + switch (c->phy_cfg) {
> + case V4L2_MBUS_CSI2_CPHY:
> + for (i = 0; i < c->num_data; i++)
> + val |= BIT((c->data[i].pos * 2) + 1);
> + break;
> + case V4L2_MBUS_CSI2_DPHY:
> + val = CSIPHY_3PH_CMN_CSI_COMMON_CTRL5_CLK_ENABLE;
> +
> + for (i = 0; i < c->num_data; i++)
> + val |= BIT(c->data[i].pos * 2);
> + break;
> + default:
> + dev_err(dev, "Unsupported bus type %d\n", c->phy_cfg);
> + return -EINVAL;
> + }
>
> writel_relaxed(val, csiphy->base +
> CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->offset, 5));
> @@ -1068,6 +1093,8 @@ static void csiphy_lanes_enable(struct csiphy_device *csiphy,
> writel_relaxed(0, csiphy->base +
> CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->offset, i));
> }
> +
> + return 0;
> }
>
> static void csiphy_lanes_disable(struct csiphy_device *csiphy,
> diff --git a/drivers/media/platform/qcom/camss/camss-csiphy.c b/drivers/media/platform/qcom/camss/camss-csiphy.c
> index 62623393f4144..08dd238e52799 100644
> --- a/drivers/media/platform/qcom/camss/camss-csiphy.c
> +++ b/drivers/media/platform/qcom/camss/camss-csiphy.c
> @@ -295,9 +295,7 @@ static int csiphy_stream_on(struct csiphy_device *csiphy)
> wmb();
> }
>
> - csiphy->res->hw_ops->lanes_enable(csiphy, cfg, link_freq, lane_mask);
> -
> - return 0;
> + return csiphy->res->hw_ops->lanes_enable(csiphy, cfg, link_freq, lane_mask);
ick.
More high brow stuff from bod here but, more seriously this is three
levels of indirection deep and the statement keeps getting longer.
Could you get a pointer to hw_ops() to reduce this down a bit.
> }
>
> /*
> diff --git a/drivers/media/platform/qcom/camss/camss-csiphy.h b/drivers/media/platform/qcom/camss/camss-csiphy.h
> index d198171700e73..21cf2ce931c1d 100644
> --- a/drivers/media/platform/qcom/camss/camss-csiphy.h
> +++ b/drivers/media/platform/qcom/camss/camss-csiphy.h
> @@ -73,9 +73,9 @@ struct csiphy_hw_ops {
> void (*hw_version_read)(struct csiphy_device *csiphy,
> struct device *dev);
> void (*reset)(struct csiphy_device *csiphy);
> - void (*lanes_enable)(struct csiphy_device *csiphy,
> - struct csiphy_config *cfg,
> - s64 link_freq, u8 lane_mask);
> + int (*lanes_enable)(struct csiphy_device *csiphy,
> + struct csiphy_config *cfg,
> + s64 link_freq, u8 lane_mask);
> void (*lanes_disable)(struct csiphy_device *csiphy,
> struct csiphy_config *cfg);
> irqreturn_t (*isr)(int irq, void *dev);
>
With those tweaks.
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@...aro.org>
---
bod
Powered by blists - more mailing lists