[PATCH AUTOSEL 6.18] phy: qcom: m31-eusb2: Make USB repeater optional

[sashiko-bot at kernel.org]

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

Pre-existing issues:
- [High] The error path in m31eusb2_phy_init() incorrectly returns 0 (success) after an initialization failure, discarding the actual error code.
- [High] Return values of PHY hardware initialization sequences are ignored in m31eusb2_phy_init().
--

commit be42870353c78e4db57cfea8eea743473035b9a6
Author: Wesley Cheng <wesley.cheng at oss.qualcomm.com>
Subject: phy: qcom: m31-eusb2: Make USB repeater optional

A repeater is not required for the PHY to function. On systems with
multiple PHY instances connected to a multi-port controller, some PHYs
may be unconnected. All PHYs must still probe successfully even without
attached repeaters, otherwise the controller probe fails.

Link: https://patch.msgid.link/20260302-phy-qcom-m31-eusb2-make-repeater-optional-v2-1-dbf714c72056@oss.qualcomm.com

> diff --git a/drivers/phy/qualcomm/phy-qcom-m31-eusb2.c b/drivers/phy/qualcomm/phy-qcom-m31-eusb2.c
> index 0a0d2d9fc8464..a1d0a8e368bfc 100644
> --- a/drivers/phy/qualcomm/phy-qcom-m31-eusb2.c
> +++ b/drivers/phy/qualcomm/phy-qcom-m31-eusb2.c
> @@ -283,7 +283,7 @@ static int m31eusb2_phy_probe(struct platform_device *pdev)
>  
>  	phy_set_drvdata(phy->phy, phy);
>  
> -	phy->repeater = devm_of_phy_get_by_index(dev, dev->of_node, 0);
> +	phy->repeater = devm_phy_optional_get(dev, NULL);
>  	if (IS_ERR(phy->repeater))
>  		return dev_err_probe(dev, PTR_ERR(phy->repeater),
>  				     "failed to get repeater\n");

[Severity: High]
This isn't a bug introduced by this patch, but in m31eusb2_phy_init(), the
return values of PHY hardware initialization sequences are ignored:

drivers/phy/qualcomm/phy-qcom-m31-eusb2.c:m31eusb2_phy_init() {
	...
	m31eusb2_phy_write_sequence(phy, data->setup_seq, data->setup_seq_nregs);
	m31eusb2_phy_write_readback(phy->base,
				    USB_PHY_HS_PHY_CTRL_COMMON0, FSEL,
				    FIELD_PREP(FSEL, data->fsel));
	m31eusb2_phy_write_sequence(phy, data->override_seq, data->override_seq_nregs);
	m31eusb2_phy_write_sequence(phy, data->reset_seq, data->reset_seq_nregs);

	return 0;
	...
}

Can this cause unpredictable USB bus behavior or controller lockups if a
hardware write readback mismatch occurs and the PHY core proceeds with a
misconfigured PHY?

[Severity: High]
This is also a pre-existing issue, but the error path in m31eusb2_phy_init()
incorrectly returns 0 (success) after an initialization failure:

drivers/phy/qualcomm/phy-qcom-m31-eusb2.c:m31eusb2_phy_init() {
	...
	ret = clk_prepare_enable(phy->clk);
	if (ret) {
		dev_err(&uphy->dev, "failed to enable ref clock, %d\n", ret);
		goto disable_repeater;
	}
	...
disable_repeater:
	phy_exit(phy->repeater);
disable_vreg:
	regulator_bulk_disable(M31_EUSB_NUM_VREGS, phy->vregs);

	return 0;
}

If the initialization sequence fails (e.g., clk_prepare_enable or phy_init
fails), it jumps to these cleanup labels. Since the function unconditionally
returns 0, the error code is discarded. 

Could this mask initialization failures and lead to system hangs (e.g., 
synchronous external aborts) or broken USB functionality when the controller
attempts to use an unclocked or unpowered PHY?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260831133314.4125787-501-sashal@kernel.org?part=1