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

[Selvarasu Ganesan]

On 9/18/2026 7:16 PM, Krzysztof Kozlowski wrote:
> 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 at kernel.org>
>>>> +  - Selvarasu Ganesan <selvarasu.g at 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
> How does it support existing bindings? I don't understand. There is no
> such fallback in existing bindings.


Sorry for the misunderstanding, Yes there is no such a fallback in 
existing bindings.

Our intention was to use new proposed generic fallback compatible string 
that will support USB dwc3 flatted node for all Samsung soc when those 
are migrated in the future without adding SoC specific compatible string 
in driver.

Agreed, Here using generic fallback name (samsung,snps-dwc3 as a 
reference of qcom,snps-dwc3) is incorrect as snps is vendor not a device.

As per DTS101 slide , Now we clear that the future Exynos SoCs could 
use  samsung,exynos8855-dwc3 as a fallback when they are compatible with 
the Exynos8855 hardware definition, rather than introducing a generic 
samsung,snps-dwc3 fallback. The dedicated compatible would still 
describe any SoC specific differences, such as clocks.

And Understood that we were mixing the current Exynos8855 binding with 
the longer term migration plan for the existing Exynos SoCs and future 
SoCs.

We will drop the generic fallback and use SoC specific compatible 
samsung,exynos8855-dwc3 (vendor,device), following 
samsung,exynos-dwc3.yaml as the reference.

Regarding the binding filename, if the flattened representation is 
expected to support multiple Exynos SoCs where there is only differences 
in clock in the future, similar to how samsung,exynos-dwc3.yaml covers 
multiple SoCs with the legacy (parent and child) node representation, 
should we use a common binding filename for the flattened representation 
instead of a SoC specific name like samsung,exynos8855-dwc3.yaml.
For example,
     samsung,exynos-dwc3-flattened.yaml.


>
>> (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.


The intention was to avoid adding separate compatible entries to 
dwc3_generic_of_match[] for each Exynos SoC.

We understand that adding SoC specific compatibles is the correct 
approach, as follow in samsung,exynos-dwc3.yaml.


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

Thanks for pointing out the DTS101 slids, and we referred again the 
binding documentation including DTS101 slids for further clarification 
on the using of fallback.

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

Agreed and As we mentioned in above comment, we will use the existing 
samsung,exynos-dwc3.yaml as the reference for the Samsung binding and 
drop the qcom,snps-dwc3 reference.

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

Understood. As mentioned above, we are mixing the current Exynos8855 
binding with the longer term migration plan and will keep this binding 
focused on Exynos8855 only and handle other SoCs when they are actually 
migrated.

Thanks,
Selva


>
> Best regards,
> Krzysztof