Re: [PATCH v2 2/2] dt-bindings: usb: snps,dwc3: Add 'snps,global-regs-starting-offset' quirk

Krzysztof Kozlowski
2023-04-14T09:08:57Z

On 13/04/2023 04:53, Stanley Chang[昌育德] wrote:
>
>>
>> On Tue, Apr 11, 2023 at 10:30 PM Stanley Chang
>> <stanley_chang@realtek.com> wrote:
>>>
>>> Add a new 'snps,global-regs-starting-offset' DT to dwc3 core to remap
>>> the global register start address
>>>
>>> The RTK DHC SoCs were designed the global register address offset at
>>> 0x8100. The default address is at DWC3_GLOBALS_REGS_START (0xc100).
>>> Therefore, add the property of device-tree to adjust this start address.
>>>
>>> Signed-off-by: Stanley Chang <stanley_chang@realtek.com>
>>> ---
>>> Documentation/devicetree/bindings/usb/snps,dwc3.yaml | 7 +++++++
>>> 1 file changed, 7 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
>>> b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
>>> index be36956af53b..5cbf3b7ded04 100644
>>> --- a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
>>> +++ b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
>>> @@ -359,6 +359,13 @@ properties:
>>> items:
>>> enum: [1, 4, 8, 16, 32, 64, 128, 256]
>>>
>>> + snps,global-regs-starting-offset:
>>> + description:
>>> + value for remapping global register start address. For some dwc3
>>> + controller, the dwc3 global register start address is not at
>>> + default DWC3_GLOBALS_REGS_START (0xc100). This property is
>> added to
>>> + adjust the address.
>>
>> We already have 'reg' or using a specific compatible to handle differences. Use
>> one of those, not a custom property. Generally, properties should be used for
>> things that vary per board, not fixed in a given SoC.
>>
>> Rob
>>
>
> The default offset is fixed by macro DWC3_GLOBALS_REGS_START, and it is not specified by reg.

Are you saying that reg points to XHCI registers and the gap between
them and DWC3_GLOBALS_REGS_START is different on some implementations of
this IP?

> The dwc3/core is a general driver for every dwc3 IP of SoCs,
> and vendor's definition and compatible should specify on its parent.

Not entirely. It's how currently it is written, but not necessarily
correct representation. The parent is only glue part which for some
non-IP resources.

> If we add a specific compatible to dwc3/core driver, then it will break this rule.

What rule? The rule is to have specific compatibles, so now you are
breaking it.

> Therefore, I use a property to adjust this offset.
> If no define this property, it will use default offset. So it will not affect other board.

Best regards,
Krzysztof