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

On 18/09/2026 15:36, Selvarasu Ganesan wrote:

On 9/18/2026 3:24 PM, Krzysztof Kozlowski wrote:

quoted

On Wed, Sep 16, 2026 at 05:52:28PM +0530, Selvarasu Ganesan wrote:

quoted

+maintainers:
+  - Krzysztof Kozlowski [off-list ref]
+  - Selvarasu Ganesan [off-list ref]
+
+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.

quoted

+
+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