Re: [PATCH v2 2/3] dt-bindings: usb: Introduce samsung,snps-dwc3

[Krzysztof Kozlowski]

On 18/09/2026 15:36, Selvarasu Ganesan wrote:
> 
> On 9/18/2026 3:24 PM, Krzysztof Kozlowski wrote:
>> On Wed, Sep 16, 2026 at 05:52:28PM +0530, Selvarasu Ganesan wrote:
>>> +maintainers:
>>> +  - Krzysztof Kozlowski <krzk@xxxxxxxxxx>
>>> +  - Selvarasu Ganesan <selvarasu.g@xxxxxxxxxxx>
>>> +
>>> +description:
>>> +  Describes the DWC3 USB controller block implemented on Samsung Exynos SoCs.
>>> +
>>> +select:
>>> +  properties:
>>> +    compatible:
>>> +      contains:
>>> +        const: samsung,snps-dwc3
>>> +  required:
>>> +    - compatible
>> This select is not needed.
>>
>>> +
>>> +properties:
>>> +  compatible:
>>> +    items:
>>> +      - enum:
>>> +          - samsung,exynos8855-dwc3
>>> +      - const: samsung,snps-dwc3
>> And this fallback is not really accurate. Samsung does not have snps
>> device, because snps is a vendor. Anyway, generic fallbacks should go
>> away, drop, so you are left with samsung,exynos8855-dwc3 only.
> 
> Hi Krzysztof,
> 
> Thanks for your review comments.
> And We apologize for our repeated below explanation, but we wanted to 
> ensure our intentions were clear for each point to avoid any 
> misunderstanding.
> 
> The original intent of the generic fallback was to support existing 
> Exynos dwc3 bindings from a parent/child representation from 

How does it support existing bindings? I don't understand. There is no
such fallback in existing bindings.

> (samsung,exynos-dwc3.yaml), and upcoming SoCs (Exynos 8865, 9955, and 
> 9965) can use this flattened representation without requiring a unique 
> compatible string for every project in the dwc3-generic-plat driver 

I did not forbid you to use fallbacks, so I do not understand why you
would need unique compatible for every device in the driver.

This is already heavily documented and explained in beginners docs.
Please read writing bindings docs and maybe also DTS101 slides. I even
gave the talk DTS101 two months ago in your timezone...


> of_match_table. We referred to qcom,snps-dwc3 as a helpful reference for 
> this approach.

When people argue with me, they use more often poor examples as
reference, not the good ones. Interesting pattern.

And why you did not take the proper example you even mentioned here -
Documentation/devicetree/bindings/usb/samsung,exynos-dwc3.yaml - as
reference?

Anyway, existing bug is not a reason to add new bug, don't you think?



> 
> As seen in samsung,exynos-dwc3.yaml, our existing bindings already 
> support multiple SoCs with diverse clock requirements within a single 
> file. Similarly, we plan to use a single flattened Samsung binding to 
> manage these diverse clock requirements. for different SoCs.
> 
> Regarding the migration for current and future SoCs, would you prefer,

I do not understand how any of this is relevant to my review comment.

> 
> Option A: A single flattened binding file using a common fallback 
> compatible string (instead of samsung,snps-dwc3) to minimize 
> of_match_table entries, and if/then constraints to handle diverse clock 
> requirements.
> Option B: Separate binding files for each individual SoCs.
> 
> Could you please let us know your preferred approach? Once confirmed, we 
> will address your other review comments based on the selected approach.

You do not have other bindings. You have one device. If you have more,
then post more. We are not making reviews based on imaginary future things.

Best regards,
Krzysztof