[PATCH 2/2] dt-bindings: usb: rockchip,dwc3: Move RK3399 to its own schema

Felipe Balbi balbi at kernel.org
Fri Dec 23 02:34:26 PST 2022


Rob Herring <robh at kernel.org> writes:

> On Tue, Dec 20, 2022 at 1:37 AM Felipe Balbi <balbi at kernel.org> wrote:
>>
>> Rob Herring <robh at kernel.org> writes:
>>
>> > The rockchip,dwc3.yaml schema defines a single DWC3 node, but the RK3399
>> > uses the discouraged parent wrapper node and child 'generic' DWC3 node.
>>
>> Why discouraged? Splitting those two separate devices (yes, they are
>> separate physical modules) has greatly simplified e.g. power management
>> and encapsulation of the core module.
>
> Sometimes they are separate and that's fine, but often it's just
> different clocks, resets, etc. and that's no different from every
> other block.

Right, then the argument is that all other blocks are not modelling the
HW as they should :)

> If there's wrapper registers or something clearly extra, then I agree
> a wrapper parent node makes sense.

There's always wrapper-specific registers. Some wrappers even add custom
functionality. IIRC Qcom added a HW-based URB "scheduler" or some sort.

> Otherwise, for cases like RK3399, I don't think it does, but we're
> stuck with it now.
>
> Also, we have this pattern pretty much nowhere else and DWC3 is not
> special.

No, it's not. But it could just be the first example of the driver
actually modelling the underlying HW.

In any case, I was just curious with your opinion that this model is
discouraged, as it's not stated anywhere in the kernel's documentation.

Happy holidays

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 857 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-rockchip/attachments/20221223/53374ebb/attachment.sig>


More information about the Linux-rockchip mailing list