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

[Selvarasu Ganesan]

On 9/21/2026 12:26 PM, Selvarasu Ganesan wrote:
>
> 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@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.
>
>
> 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.


HI Krzysztof,

I am writing to kindly follow up on my previous inquiry regarding the 
binding filename for the flattened representation.

To recap, I would like to know if we should use a common binding 
filename, such as samsung,exynos-dwc3-flattened.yaml, instead of SoC 
specific names (e.g., samsung,exynos8855-dwc3.yaml). This would be 
consistent with how samsung,exynos-dwc3.yaml covers multiple SoCs in the 
legacy representation, especially if we expect to support multiple 
Exynos SoCs with only clock differences in the future.

I would appreciate your guidance or suggestions on the preferred naming 
convention for this implementation.

Thanks,
Selva
>
>
>>
>>> (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