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

[Selvarasu Ganesan <selvarasu.g@samsung.com>]

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@kernel.org>
>> +  - Selvarasu Ganesan <selvarasu.g@samsung.com>
>> +
>> +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 
(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 
of_match_table. We referred to qcom,snps-dwc3 as a helpful reference for 
this approach.

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,

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.


Thanks,
Selva


> Filename should be then samsung,exynos8855-dwc3.yaml.
>
>> +
>> +  reg:
>> +    maxItems: 1
>> +
>> +  power-domains:
>> +    maxItems: 1
>> +
>> +  interrupts:
>> +    maxItems: 1
>> +
>> +  clocks:
>> +    description: |
>> +      Several clocks are used, depending on the variant. Typical ones are:
>> +       - ref: Reference clock for SOF/ITP generation.
>> +       - bus: Bus (APB) clock for register access.
> You have only one variant, no? Or you mean one SoC has different
> variants?
>
>> +    minItems: 1
>> +    maxItems: 4
> Nope, you to list items.
>
>> +
>> +  clock-names:
>> +    minItems: 1
>> +    maxItems: 4
>> +
>> +required:
>> +  - compatible
>> +  - reg
>> +  - clocks
>> +  - clock-names
>> +  - interrupts
>> +
>> +allOf:
>> +  - $ref: snps,dwc3-common.yaml#
>> +
>> +  - if:
>> +      properties:
>> +        compatible:
>> +          contains:
>> +            const: samsung,exynos8855-dwc3
>> +    then:
>> +      properties:
>> +        clocks:
>> +          minItems: 2
>> +          maxItems: 2
> How can it be two if you have ONLY one device in the binding and that
> device has between 1 and 4?
>
> This entire if is redundant, no? How many clocks do you actually have
> there?
>
>> +        clock-names:
>> +          items:
>> +            - const: ref
>> +            - const: bus
>> +
>> +unevaluatedProperties: false
> Best regards,
> Krzysztof