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

[Krzysztof Kozlowski]

On 20/10/2026 10:02, Selvarasu Ganesan wrote:
>>>>>> +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.

I started to ignore overly long answers, because to me that means
contributor expects me to devote a lot of time to their contribution. Or
second option: LLM proxy. There is even a trend where people paste
prompts or LLM-chat-confirmation-like answers. I often do not correct
even such cases, just put the ignore list.


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

Please use the naming expressed in on of the rules for writing bindings,
so one matching the compatible or fallback compatible.


Best regards,
Krzysztof