[PATCH v4 3/4] phy: qcom-qusb2: Add support for Shikra

[sashiko-bot at kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Mismatch between commit message and code regarding the Shikra initialization sequence, indicating a potentially missing SoC-specific init table.
--

commit 32d713dabf7fa1b123bcb3d8f9e6ad4438cd95c4
Author: Krishna Kurapati <krishna.kurapati at oss.qualcomm.com>

phy: qcom-qusb2: Add support for Shikra

This commit introduces the PHY configuration and match table entries
necessary to support the Shikra platform in the qcom-qusb2 driver.

> diff --git a/drivers/phy/qualcomm/phy-qcom-qusb2.c b/drivers/phy/qualcomm/phy-qcom-qusb2.c
> --- a/drivers/phy/qualcomm/phy-qcom-qusb2.c
> +++ b/drivers/phy/qualcomm/phy-qcom-qusb2.c
[ ... ]
> @@ -381,6 +381,19 @@ static const struct qusb2_phy_cfg sdm660_phy_cfg = {
>  	.autoresume_en	 = BIT(3),
>  };
>  
> +static const struct qusb2_phy_cfg shikra_phy_cfg = {
> +	.tbl            = qcs615_init_tbl,

[Severity: Medium]
The commit message states "Add init sequence and phy configuration for
Shikra", but this configuration reuses qcs615_init_tbl.

Since shikra_phy_cfg differs from qcs615 in key hardware parameters like
has_pll_test, se_clk_scheme_default, and autoresume_en, does the Shikra
PHY actually require its own specific tuning table that might have been
accidentally omitted?

If reusing the QCS615 table is intentional, could the commit message be
updated to clarify this reuse instead of stating an init sequence was added?

> +	.tbl_num        = ARRAY_SIZE(qcs615_init_tbl),
> +	.regs           = ipq6018_regs_layout,
> +
> +	.has_pll_test	= true,
> +	.se_clk_scheme_default = true,
> +	.disable_ctrl   = CLAMP_N_EN | FREEZIO_N | POWER_DOWN,
> +	.mask_core_ready = PLL_LOCKED,
> +	.autoresume_en   = BIT(3),
> +	.update_tune1_with_efuse = false,
> +};

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260701165051.4122259-1-krishna.kurapati@oss.qualcomm.com?part=3