From: sashiko-bot@kernel.org
To: palash.kambar@oss.qualcomm.com
Cc: vkoul@kernel.org, linux-scsi@vger.kernel.org,
neil.armstrong@linaro.org, robh@kernel.org,
devicetree@vger.kernel.org, conor+dt@kernel.org,
olteanv@gmail.com, linux-phy@lists.infradead.org
Subject: Re: [PATCH v6 2/2] phy: qcom-qmp-ufs: Add UFS PHY support on Hawi
Date: Thu, 06 Aug 2026 16:56:37 +0000 [thread overview]
Message-ID: <20260806165637.8E41A1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260806161301.1010876-3-palash.kambar@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Missing configuration overlay for UFS Gear 4 in Hawi UFS PHY
--
--- Patch [2]: [PATCH v6 2/2] phy: qcom-qmp-ufs: Add UFS PHY support on Hawi ---
commit 69d2ab29b4fbd3a27d861c7619c3a546898758d6
Author: Palash Kambar <palash.kambar@oss.qualcomm.com>
phy: qcom-qmp-ufs: Add UFS PHY support on Hawi
This patch adds the init sequence tables and configuration for the UFS QMP
PHY found in the Hawi SoC.
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c b/drivers/phy/qualcomm/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 = {
>
> };
>
> +static const struct qmp_phy_init_tbl hawi_ufsphy_serdes[] = {
[ ... ]
> +static const struct qmp_phy_init_tbl hawi_ufsphy_g5_pcs[] = {
> + QMP_PHY_INIT_CFG(QPHY_V7_PCS_UFS_PLL_CNTL, 0x3b),
> + QMP_PHY_INIT_CFG(QPHY_V7_PCS_UFS_TX_HSGEAR_CAPABILITY, 0x05),
> + QMP_PHY_INIT_CFG(QPHY_V7_PCS_UFS_RX_HSGEAR_CAPABILITY, 0x05),
> +};
> +
> +static const struct qmp_phy_cfg hawi_ufsphy_cfg = {
> + .lanes = 2,
> +
> + .offsets = &qmp_ufs_offsets_v7,
> + .max_supported_gear = UFS_HS_G5,
> +
> + .tbls = {
> + .serdes = hawi_ufsphy_serdes,
> + .serdes_num = ARRAY_SIZE(hawi_ufsphy_serdes),
> + .tx = hawi_ufsphy_tx,
> + .tx_num = ARRAY_SIZE(hawi_ufsphy_tx),
> + .rx = hawi_ufsphy_rx,
> + .rx_num = ARRAY_SIZE(hawi_ufsphy_rx),
> + .pcs = hawi_ufsphy_pcs,
> + .pcs_num = ARRAY_SIZE(hawi_ufsphy_pcs),
> + },
> +
> + .tbls_hs_overlay[0] = {
> + .pcs = hawi_ufsphy_g5_pcs,
> + .pcs_num = ARRAY_SIZE(hawi_ufsphy_g5_pcs),
> + .max_gear = UFS_HS_G5,
> + },
[Severity: High]
Does this configuration need a fallback overlay for Gear 4?
Looking at qmp_ufs_get_gear_overlay(), if the UFS controller negotiates Gear 4
(or lower) with the connected UFS device, it will return -EINVAL because the
only overlay provided here has max_gear = UFS_HS_G5:
for (idx = NUM_OVERLAY - 1; idx >= 0; idx--) {
max_gear = cfg->tbls_hs_overlay[idx].max_gear;
/* Skip if the table is not available */
if (max_gear == 0)
continue;
/* Direct matching, bail */
if (qmp->submode == max_gear)
return idx;
/* If no direct matching, the lowest gear is the best matching */
if (max_gear < floor_max_gear) {
ret = idx;
floor_max_gear = max_gear;
}
}
return ret;
Without an overlay where max_gear < 5, it fails to find a fallback. If the
overlay fails to apply, critical hardware configurations like
QPHY_V7_PCS_UFS_PLL_CNTL and the HSGEAR capabilities are omitted since they
are only present in the G5 overlay and not in the base hawi_ufsphy_pcs table.
Will this cause UFS link failure and render the storage unusable for any gear
below G5?
> +
> + .vreg_list = hawi_ufsphy_vreg_l,
> + .num_vregs = ARRAY_SIZE(hawi_ufsphy_vreg_l),
> + .regs = ufsphy_v7_regs_layout,
> +};
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260806161301.1010876-1-palash.kambar@oss.qualcomm.com?part=2
WARNING: multiple messages have this Message-ID (diff)
From: sashiko-bot@kernel.org
To: palash.kambar@oss.qualcomm.com
Cc: vkoul@kernel.org, linux-scsi@vger.kernel.org,
neil.armstrong@linaro.org, robh@kernel.org,
devicetree@vger.kernel.org, conor+dt@kernel.org,
olteanv@gmail.com, linux-phy@lists.infradead.org
Subject: Re: [PATCH v6 2/2] phy: qcom-qmp-ufs: Add UFS PHY support on Hawi
Date: Thu, 06 Aug 2026 16:56:37 +0000 [thread overview]
Message-ID: <20260806165637.8E41A1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260806161301.1010876-3-palash.kambar@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Missing configuration overlay for UFS Gear 4 in Hawi UFS PHY
--
--- Patch [2]: [PATCH v6 2/2] phy: qcom-qmp-ufs: Add UFS PHY support on Hawi ---
commit 69d2ab29b4fbd3a27d861c7619c3a546898758d6
Author: Palash Kambar <palash.kambar@oss.qualcomm.com>
phy: qcom-qmp-ufs: Add UFS PHY support on Hawi
This patch adds the init sequence tables and configuration for the UFS QMP
PHY found in the Hawi SoC.
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c b/drivers/phy/qualcomm/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 = {
>
> };
>
> +static const struct qmp_phy_init_tbl hawi_ufsphy_serdes[] = {
[ ... ]
> +static const struct qmp_phy_init_tbl hawi_ufsphy_g5_pcs[] = {
> + QMP_PHY_INIT_CFG(QPHY_V7_PCS_UFS_PLL_CNTL, 0x3b),
> + QMP_PHY_INIT_CFG(QPHY_V7_PCS_UFS_TX_HSGEAR_CAPABILITY, 0x05),
> + QMP_PHY_INIT_CFG(QPHY_V7_PCS_UFS_RX_HSGEAR_CAPABILITY, 0x05),
> +};
> +
> +static const struct qmp_phy_cfg hawi_ufsphy_cfg = {
> + .lanes = 2,
> +
> + .offsets = &qmp_ufs_offsets_v7,
> + .max_supported_gear = UFS_HS_G5,
> +
> + .tbls = {
> + .serdes = hawi_ufsphy_serdes,
> + .serdes_num = ARRAY_SIZE(hawi_ufsphy_serdes),
> + .tx = hawi_ufsphy_tx,
> + .tx_num = ARRAY_SIZE(hawi_ufsphy_tx),
> + .rx = hawi_ufsphy_rx,
> + .rx_num = ARRAY_SIZE(hawi_ufsphy_rx),
> + .pcs = hawi_ufsphy_pcs,
> + .pcs_num = ARRAY_SIZE(hawi_ufsphy_pcs),
> + },
> +
> + .tbls_hs_overlay[0] = {
> + .pcs = hawi_ufsphy_g5_pcs,
> + .pcs_num = ARRAY_SIZE(hawi_ufsphy_g5_pcs),
> + .max_gear = UFS_HS_G5,
> + },
[Severity: High]
Does this configuration need a fallback overlay for Gear 4?
Looking at qmp_ufs_get_gear_overlay(), if the UFS controller negotiates Gear 4
(or lower) with the connected UFS device, it will return -EINVAL because the
only overlay provided here has max_gear = UFS_HS_G5:
for (idx = NUM_OVERLAY - 1; idx >= 0; idx--) {
max_gear = cfg->tbls_hs_overlay[idx].max_gear;
/* Skip if the table is not available */
if (max_gear == 0)
continue;
/* Direct matching, bail */
if (qmp->submode == max_gear)
return idx;
/* If no direct matching, the lowest gear is the best matching */
if (max_gear < floor_max_gear) {
ret = idx;
floor_max_gear = max_gear;
}
}
return ret;
Without an overlay where max_gear < 5, it fails to find a fallback. If the
overlay fails to apply, critical hardware configurations like
QPHY_V7_PCS_UFS_PLL_CNTL and the HSGEAR capabilities are omitted since they
are only present in the G5 overlay and not in the base hawi_ufsphy_pcs table.
Will this cause UFS link failure and render the storage unusable for any gear
below G5?
> +
> + .vreg_list = hawi_ufsphy_vreg_l,
> + .num_vregs = ARRAY_SIZE(hawi_ufsphy_vreg_l),
> + .regs = ufsphy_v7_regs_layout,
> +};
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260806161301.1010876-1-palash.kambar@oss.qualcomm.com?part=2
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
next prev parent reply other threads:[~2026-08-06 16:56 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-06 16:12 [PATCH v6 0/2] Add Hawi UFS PHY and Controller support palash.kambar
2026-08-06 16:12 ` palash.kambar
2026-08-06 16:13 ` [PATCH v6 1/2] dt-bindings: phy: qcom,sc8280xp-qmp-ufs-phy: Add Hawi UFS PHY compatible palash.kambar
2026-08-06 16:13 ` palash.kambar
2026-08-06 16:13 ` [PATCH v6 2/2] phy: qcom-qmp-ufs: Add UFS PHY support on Hawi palash.kambar
2026-08-06 16:13 ` palash.kambar
2026-08-06 16:56 ` sashiko-bot [this message]
2026-08-06 16:56 ` sashiko-bot
2026-08-07 12:33 ` [PATCH v6 0/2] Add Hawi UFS PHY and Controller support Vinod Koul
2026-08-07 12:33 ` Vinod Koul
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260806165637.8E41A1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=linux-phy@lists.infradead.org \
--cc=linux-scsi@vger.kernel.org \
--cc=neil.armstrong@linaro.org \
--cc=olteanv@gmail.com \
--cc=palash.kambar@oss.qualcomm.com \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=vkoul@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.