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

[Krzysztof Kozlowski]

On 30/08/2026 15:17, George Moussalem wrote:
> On 8/30/26 13:41, Krzysztof Kozlowski wrote:
>> 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.
> 
> The issue stems from collapsing the snps and dwc nodes into one: the
> same clock was passed as "mock_utmi" in snps and as "ref" in the dwc
> child node. In the flattened model, this causes two issues:
> 1. the core driver gets the ref clock by name ("ref") but you would
> break the binding by changing the clock name from mock_utmi to ref and
> perhaps causes backwards compatibility issues.

Driver can also take mock_utmi if this is exactly the same clock input.

> 2. Even if you change the clock name, the new qcom glue layer sets
> ignore_clocks_and_resets to true in the probe_data struct which means
> the core driver doesn't acquire and manage the clocks/resets.

That's a driver problem and can be solved in the driver.

> 
>>
>> 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.
> 
> That was possible in the 'old' way because it was allowed to pass the
> same clock as both the mock_utmi and ref clock, albeit in different
> nodes targeting snps and dwc respectively.
> 
> To solve it in the driver itself means we'd need to create compatible
> specific match data structs which currently aren't in the driver and all

Which is standard way for all the drivers. DT is not a way of workaround
for driver problems.

> SoCs that require it (at least the ones in this series) wouldn't be able
> to just use qcom,snps-dwc as the fallback. This would increase
> complexity of the driver (which now is nice and simple) and would
> require a change to the bindings too.
> In addition, for some SoCs such as IPQ6018, we'd need two compatibles
> because it has two USB controllers and only one of them requires setting
> the ref clock.
> 
> Kindly advise so I can adjust v-next of the series accordingly.
You did not describe the actual hardware problem. So far you said that
combining DTS nodes and specific driver code needs this property, but
these are not valid reasons. If your driver behaves not as you wish,
e.g. passes ignore_clocks_and_resets, then just change that. Or handle
that different clock.

Otherwise what is needed is to describe actual hardware configuration,
hardware problem being represented by this DT property.

Best regards,
Krzysztof