[PATCH v3 4/4] phy: qcom: qmp-usbc: Add support for "phy" reset used on Shikra

[sashiko-bot at kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] Unconditionally adding the 'phy' reset to `usb3dpphy_reset_l` breaks the driver probe for existing QCS615 platforms.
--

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

phy: qcom: qmp-usbc: Add support for "phy" reset used on Shikra

This patch adds the "phy" reset to the usb3dpphy_reset_l array. This extra
reset is needed for the operation of the QMP Phy on the Shikra platform.

> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-usbc.c b/drivers/phy/qualcomm/phy-qcom-qmp-usbc.c
> index c342479a37980..067e7f6e56424 100644
> --- a/drivers/phy/qualcomm/phy-qcom-qmp-usbc.c
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp-usbc.c
[ ... ]
>  static const char * const usb3dpphy_reset_l[] = {
> -	"phy_phy", "dp_phy",
> +	"phy_phy", "dp_phy", "phy",

[Severity: Critical]
Will adding this reset unconditionally cause a probe failure for existing
QCS615 platforms?

The length of the usb3dpphy_reset_l array is used by ARRAY_SIZE() to define
the num_resets value for the configuration. Since qmp_usbc_reset_init()
fetches these resets using devm_reset_control_bulk_get_exclusive(), it
strictly requires all requested resets to be present in the device tree.

If an older device tree only defines the two original resets, phy_phy and
dp_phy, won't the driver fail to find the third reset and return -ENOENT,
causing the probe to abort?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260526184401.3959717-1-pratham.pratap@oss.qualcomm.com?part=4