Re: [PATCH 1/9] dt-bindings: usb: qcom,snps-dwc3: Add ability to select UTMI as reference clock

[Krzysztof Kozlowski]

On Tue, Aug 25, 2026 at 02:42:26PM +0400, George Moussalem wrote:
> Add ability to select the UTMI clock as reference clock which is passed
> by the glue layer to the DWC3 core to calculate the reference clock
> period and frame length adjustment based on its clock rate.
> 
> In the flattened snsp-dwc3 model, it is currently not possible to pass a
> reference clock that differs from the default since:
> commit 613a2e655d4d ("usb: dwc3: core: Expose core driver as library")
> 
> This prevents moving chipsets such as IPQ5018, IPQ6018, IPQ5332, IPQ5424
> and IPQ9574 with a reference clock rate different from 19.2 MHz from
> moving to the flattened model.
> 
> The Qualcomm takes care of clock and resets management itself and sets
> the ignore_clocks_and_resets flag in dwc3_probe_data to true, so the
> core doesn't acquire the reference clock from the devicetree.
> 
> The existing DT property 'snps,quirk-ref-clk-period-ns' has been
> deprecated.

There is no such property.


> 
> So, add a property to select the UTMI clock used by many (if not all)
> Qualcomm USB controllers as the reference clock.
> 
> Signed-off-by: George Moussalem <george.moussalem@xxxxxxxxxxx>
> ---
>  Documentation/devicetree/bindings/usb/qcom,snps-dwc3.yaml | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/usb/qcom,snps-dwc3.yaml b/Documentation/devicetree/bindings/usb/qcom,snps-dwc3.yaml
> index ea60f7220afe..aa263dfd42a1 100644
> --- a/Documentation/devicetree/bindings/usb/qcom,snps-dwc3.yaml
> +++ b/Documentation/devicetree/bindings/usb/qcom,snps-dwc3.yaml
> @@ -155,6 +155,15 @@ properties:
>        HS/FS/LS modes are supported.
>      type: boolean
>  
> +  qcom,select-utmi-as-ref-clk:
> +    description:
> +      If present, pass the UTMI clock as the reference clock to the DWC3 core to
> +      use its clock rate to calculate the reference clock period and frame
> +      length adjustment in GUCTL and GFLADJ registers. This is needed when these
> +      values based on the standard clock rate deviate from the hardware default
> +      values. If not set, the hardware default values are used.

Sashiko comment seems valid. You describe Linux behavior. In your commit
msg you mention that clock cannot be passed since commit 613a2e655d4d,
which is a driver commit. So trivial answer would be: if issue was
caused by driver commit, then fix is within driver, not bindings.

Maybe there is different issue which is not purely-driver specific, but
I did not get that from description.

For example, if given SoC has different rates, then the SoC-specific DWC
compatible defines which clock to use and you do not need such property.

Best regards,
Krzysztof