Re: [PATCH v5 1/2] phy: qcom-qmp-ufs: Add UFS PHY support on Hawi

[email protected] Mon, 03 Aug 2026 13:41:03 +0000
Newsgroups org.kernel.vger.linux-scsi,org.infradead.lists.linux-phy,org.kernel.vger.linux-devicetree
Message-ID <[email protected]>
Thank you for your contribution! Sashiko AI review found 1 potential issue(=
s) to consider:
- [High] Missing UFS_HS_G4 PHY configuration fallback overlay for the Hawi =
SoC, leading to uninitialized critical registers.
--

--- Patch [1]: [PATCH v5 1/2] phy: qcom-qmp-ufs: Add UFS PHY support on Haw=
i ---
commit 4d0cc515a612b40d0f5a7fc9e44b9fbc6b1527fb
Author: Palash Kambar <[email protected]>
Subject: phy: qcom-qmp-ufs: Add UFS PHY support on Hawi

Add the init sequence tables and config for the UFS QMP phy found in
the Hawi SoC.

> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c b/drivers/phy/qualco=
mm/phy-qcom-qmp-ufs.c
> index 0f4ad24aa4058..d4aca22c181e4 100644
> --- a/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c

[ ... ]

> @@ -1845,6 +1868,119 @@ static const struct qmp_phy_cfg sm8750_ufsphy_cfg=
 =3D {
> =20
>  };
> =20
> +static const struct qmp_phy_init_tbl hawi_ufsphy_serdes[] =3D {

[ ... ]

> +static const struct qmp_phy_cfg hawi_ufsphy_cfg =3D {
> +	.lanes			=3D 2,
> +
> +	.offsets		=3D &qmp_ufs_offsets_v7,
> +	.max_supported_gear	=3D UFS_HS_G5,
> +
> +	.tbls =3D {
> +		.serdes		=3D hawi_ufsphy_serdes,
> +		.serdes_num	=3D ARRAY_SIZE(hawi_ufsphy_serdes),
> +		.tx		=3D hawi_ufsphy_tx,
> +		.tx_num		=3D ARRAY_SIZE(hawi_ufsphy_tx),
> +		.rx		=3D hawi_ufsphy_rx,
> +		.rx_num		=3D ARRAY_SIZE(hawi_ufsphy_rx),
> +		.pcs		=3D hawi_ufsphy_pcs,
> +		.pcs_num	=3D ARRAY_SIZE(hawi_ufsphy_pcs),
> +	},
> +
> +	.tbls_hs_overlay[0] =3D {
> +		.pcs		=3D hawi_ufsphy_g5_pcs,
> +		.pcs_num	=3D ARRAY_SIZE(hawi_ufsphy_g5_pcs),
> +		.max_gear	=3D UFS_HS_G5,
> +	},

[Severity: High]
Does this missing G4 overlay cause initialization to fail when a device
requests HS-G4?

If a UFS 3.1 device is attached (max gear G4) or link training drops to G4,
the host driver will call phy_set_mode() with UFS_HS_G4. Since the
tbls_hs_overlay array only defines an entry for UFS_HS_G5,
qmp_ufs_get_gear_overlay() will return -EINVAL.

This leaves critical PCS registers like QPHY_V7_PCS_UFS_PLL_CNTL,
TX_HSGEAR_CAPABILITY, and RX_HSGEAR_CAPABILITY at their hardware defaults,
which could lead to link failures. Should there be a fallback G4 overlay
defined here?

> +
> +	.vreg_list		=3D hawi_ufsphy_vreg_l,
> +	.num_vregs		=3D ARRAY_SIZE(hawi_ufsphy_vreg_l),
> +	.regs			=3D ufsphy_v7_regs_layout,
> +};

--=20
Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260803130852.1432=
[email protected]?part=3D1