Re: [PATCH v6 1/2] arm64: dts: qcom: Add support for usb nodes on Shikra

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The USB PHY nodes (QMP and QUSB2) use unsupported compatible strings without driver support or generic fallbacks.
- [Medium] The `usb_qmpphy` node provides an incompatible set of `reset-names` and `clock-names` for QCOM QMP combo PHYs.
--

--- Patch [1]: [PATCH v6 1/2] arm64: dts: qcom: Add support for usb nodes on Shikra ---
commit 1acb18d251027fe95cb37671784abeadb72b31a3
Author: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>

arm64: dts: qcom: Add support for usb nodes on Shikra

This commit adds support for both USB controllers and their respective phys on
the Shikra platform.

> diff --git a/arch/arm64/boot/dts/qcom/shikra.dtsi b/arch/arm64/boot/dts/qcom/shikra.dtsi
> index 4e5bc9e17c8ed..b5cc159e5dcd4 100644
> --- a/arch/arm64/boot/dts/qcom/shikra.dtsi
> +++ b/arch/arm64/boot/dts/qcom/shikra.dtsi

[ ... ]

> @@ -442,6 +443,85 @@ gcc: clock-controller@1400000 {
>  			#power-domain-cells = <1>;
>  		};
>  
> +		usb_1_hsphy: phy@1613000 {
> +			compatible = "qcom,shikra-qusb2-phy";

[Severity: Medium]
Are these compatible strings supported by any driver upstream?

It looks like "qcom,shikra-qusb2-phy" does not have driver support or generic
fallbacks, which might prevent the PHY node and dependent DWC3 controller from
probing successfully when enabled by a board file.

> +			reg = <0x0 0x01613000 0x0 0x180>;

[ ... ]

> +		usb_qmpphy: phy@1615000 {
> +			compatible = "qcom,shikra-qmp-usb3-dp-phy";

[Severity: Medium]
Similarly, does the "qcom,shikra-qmp-usb3-dp-phy" compatible string have
driver support or a fallback?

> +			reg = <0x0 0x01615000 0x0 0x2000>;
> +
> +			clocks = <&gcc GCC_USB3_PRIM_PHY_COM_AUX_CLK>,
> +				 <&gcc GCC_USB3_PRIM_CLKREF_EN>,
> +				 <&gcc GCC_AHB2PHY_USB_CLK>,
> +				 <&gcc GCC_USB3_PRIM_PHY_PIPE_CLK>;
> +			clock-names = "aux",
> +				      "ref",
> +				      "cfg_ahb",
> +				      "pipe";
> +
> +			resets = <&gcc GCC_USB3PHY_PHY_PRIM_SP0_BCR>,
> +				 <&gcc GCC_USB3_DP_PHY_PRIM_BCR>,
> +				 <&gcc GCC_USB3_PHY_PRIM_SP0_BCR>;
> +			reset-names = "phy_phy",
> +				      "dp_phy",
> +				      "phy";

[Severity: Medium]
Do these reset names match what the driver expects for a QMP Combo PHY?

The QMP Combo PHY driver typically requires reset controls named "phy" and
"common".

If the driver attempts to find these resets and cannot due to the names
"phy_phy", "dp_phy", and "phy" provided here, will it fail probing with
-ENOENT?

> +
> +			#clock-cells = <1>;
> +			#phy-cells = <1>;

[ ... ]

> +		usb_2_hsphy: phy@1617000 {
> +			compatible = "qcom,shikra-qusb2-phy";

[Severity: Medium]
Does this node also need an upstream-supported compatible string or a generic
fallback?

> +			reg = <0x0 0x01617000 0x0 0x180>;
> +
> +			clocks = <&gcc GCC_AHB2PHY_USB_CLK>,

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260729-shikra-usb-v6-dt-v6-0-72ffb4796a08@oss.qualcomm.com?part=1