Re: [PATCH v6 2/8] media: qcom: camss: csiphy-3ph: Use odd bits for configuring C-PHY lanes

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The patch claims to allow returning a failure for unrecognized bus configurations, but silently ignores the error and proceeds with hardware configuration.
--

commit 0f031c8a889a78fead270238000243029f1f3462
Author: David Heidelberg <david@ixit.cz>

media: qcom: camss: csiphy-3ph: Use odd bits for configuring C-PHY lanes

This commit adds C-PHY support by using odd bits for configuration instead
of even bits. It also mentions allowing failures for unrecognized
configurations.

> Since there can be unrecognized configuration allow returning failure.

[Severity: Medium]
The commit message mentions allowing returning failure for unrecognized
configurations, but does the implementation actually propagate any errors
back to the caller?

> 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 dac8d2ecf7995..15876eb973718 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

[ ... ]

> @@ -1113,13 +1114,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 |= BIT(lane_cfg->data[i].pos + 1);
> +		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 |= BIT(lane_cfg->data[i].pos);
> +		break;
> +	default:
> +		break;
> +	}
>  
>  	return lane_mask;
>  }

[Severity: Medium]
If the configuration is unrecognized, csiphy_get_lane_mask() returns 0.
Since the caller treats 0 as a valid u8 mask, how does it detect the
unrecognized configuration failure mentioned in the commit message?

[ ... ]

> @@ -1160,9 +1170,22 @@ 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:
> +		WARN_ONCE(1, "Unsupported bus type %d!\n", c->phy_cfg);
> +	}
>  
>  	writel_relaxed(val, csiphy->base +
>  		       CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->offset, 5));

[Severity: Medium]
Here csiphy_lanes_enable() prints a warning but proceeds to configure the
hardware registers with val = 0.

Since the return type of csiphy_lanes_enable() is void, the caller
csiphy_stream_on() can't check for failure, and ultimately returns 0
(success) to V4L2:

drivers/media/platform/qcom/camss/camss-csiphy.c:csiphy_stream_on() {
    ...
    csiphy->res->hw_ops->lanes_enable(csiphy, cfg, link_freq, lane_mask);

    return 0;
}

Should csiphy_lanes_enable() be updated to return an int so we can abort
and return an error like -EINVAL?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260603-qcom-cphy-v6-0-e50de0b557a8@ixit.cz?part=2