[PATCH 1/3] phy: rockchip: phy-rockchip-inno-csidphy: fix rk1808 hsfreq table

[sashiko-bot at kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Valid low-frequency ranges mapping to configuration bit 0x00 are incorrectly rejected as errors.
--

commit 73e8683965255c344bec41b44d480c1cece33b57
Author: Gerald Loacker <gerald.loacker at wolfvision.net>

phy: rockchip: phy-rockchip-inno-csidphy: fix rk1808 hsfreq table

This commit extends the final entry in the rk1808 hsfreq table to exactly
2500 Mbps. This allows the RK3588, which reuses this array, to fully
support rates up to 2500 Mbps.

> diff --git a/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c b/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c
> index c79fb53d8ee5c..5281f8dea0ad3 100644
> --- a/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c
> +++ b/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c
> @@ -170,7 +170,7 @@ static const struct hsfreq_range rk1808_mipidphy_hsfreq_ranges[] = {
>  	{ 299, 0x06}, { 399, 0x08}, { 499, 0x0b}, { 599, 0x0e},
>  	{ 699, 0x10}, { 799, 0x12}, { 999, 0x16}, {1199, 0x1e},
>  	{1399, 0x23}, {1599, 0x2d}, {1799, 0x32}, {1999, 0x37},
> -	{2199, 0x3c}, {2399, 0x41}, {2499, 0x46}
> +	{2199, 0x3c}, {2399, 0x41}, {2500, 0x46}
>  };
>  
>  static const struct hsfreq_range rk3326_mipidphy_hsfreq_ranges[] = {

[Severity: High]
This is a pre-existing issue, but while looking at these frequency range
tables it appears that valid low-frequency configurations are incorrectly
rejected as errors.

In rockchip_inno_csidphy_configure(), the code iterates through the
hsfreq_ranges to find the cfg_bit:

drivers/phy/rockchip/phy-rockchip-inno-csidphy.c:rockchip_inno_csidphy_configure() {
    ...
    if (!hsfreq)
        return -EINVAL;
    ...
}

The rk3326_mipidphy_hsfreq_ranges table defines an entry for frequencies up
to 109 Mbps with a valid cfg_bit of 0x00:

    { 109, 0x00}, { 149, 0x01}, { 199, 0x02}, { 249, 0x03},

If the data rate falls into this lowest range, hsfreq is correctly set
to 0x00, but the subsequent if (!hsfreq) check evaluates to true and
incorrectly returns -EINVAL instead of applying the configuration.

A similar issue appears in rk_dphy_configure() inside 
drivers/phy/rockchip/phy-rockchip-dphy-rx0.c with tables like
rk3399_mipidphy_hsfreq_ranges which has { 89, 0x00 }.

Could this validation be modified to verify if a valid match was found 
during iteration rather than checking if the resulting configuration bit 
is non-zero?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260617-feature-mipi-csi-dphy-4k60-v1-0-4611ff00b0ff@wolfvision.net?part=1