From: Peter Chen <peter.chen@cixtech.com>
To: Krzysztof Kozlowski <krzk@kernel.org>
Cc: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
gregkh@linuxfoundation.org, pawell@cadence.com,
rogerq@kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
cix-kernel-upstream@cixtech.com
Subject: Re: [PATCH 2/2] dt-bindings: usb: cdns,usb3: Add support for USBSSP
Date: Mon, 2 Mar 2026 17:21:25 +0800 [thread overview]
Message-ID: <aaVWlfMPSZgy55Cc@nchen-desktop> (raw)
In-Reply-To: <20260302-vengeful-delicate-macaw-e8dc8c@quoll>
On 26-03-02 08:28:07, Krzysztof Kozlowski wrote:
>
> On Mon, Mar 02, 2026 at 11:03:34AM +0800, Peter Chen wrote:
> > Extend the Cadence USBSS DRD binding to also cover the USBSSP
> > controller by adding "cdns,usbssp" to the compatible enum.
> >
> > The USBSSP is the next-generation Cadence USB controller IP. It adds
> > SuperSpeed Plus (USB 3.1 gen2x1, 10 Gbps) support and uses an
> > XHCI-based device controller. The register layout and resource model
> > (otg/xhci/dev memory regions; host/peripheral/otg interrupts) are
> > identical to the USBSS, so both controllers share the same binding
> > and the same platform driver (cdns3-plat.c).
> >
> > Changes to the binding:
> > - compatible: const -> enum with cdns,usb3 and cdns,usbssp
> > - maximum-speed: add super-speed-plus
> > - Add USBSSP example
> >
> > This patch was developed with assistance from Anthropic Claude Opus 4.6.
>
> Use proper tag, but expect pushback of microslop crap.
Krzysztof, thanks for your reply.
I tried to add Assisted-by or Co-developed-by tag, neither can pass
checkpatch.pl check, it needs a valid email address. See below:
ERROR: Unrecognized email address: 'Claude (Anthropic Claude Opus 4.6)'
#45:
Assisted-by: Claude (Anthropic Claude Opus 4.6)
>
> >
> > Signed-off-by: Peter Chen <peter.chen@cixtech.com>
> > ---
> > .../devicetree/bindings/usb/cdns,usb3.yaml | 36 +++++++++++++++++--
> > 1 file changed, 33 insertions(+), 3 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/usb/cdns,usb3.yaml b/Documentation/devicetree/bindings/usb/cdns,usb3.yaml
> > index f454ddd9bbaa..f79333e7fc1f 100644
> > --- a/Documentation/devicetree/bindings/usb/cdns,usb3.yaml
> > +++ b/Documentation/devicetree/bindings/usb/cdns,usb3.yaml
> > @@ -4,14 +4,22 @@
> > $id: http://devicetree.org/schemas/usb/cdns,usb3.yaml#
> > $schema: http://devicetree.org/meta-schemas/core.yaml#
> >
> > -title: Cadence USBSS-DRD controller
> > +title: Cadence USBSS/USBSSP DRD controller
> >
> > maintainers:
> > - Pawel Laszczak <pawell@cadence.com>
> >
> > +description:
> > + Cadence USB dual-role controllers. USBSS (cdns,usb3) supports up to
> > + SuperSpeed (USB 3.0). USBSSP (cdns,usbssp) is the next generation with
> > + SuperSpeed Plus (USB 3.1 gen2x1) and XHCI-based device controller. Both
> > + share the same register layout and resource model.
>
> So are compatible or not?
>
Sorry for the misleading description. They are NOT fully compatible.
The register layout (OTG/XHCI/Device) and interrupts
(OTG/XHCI/Device/Wakeup) are the same, but register contents are
different, esp, the device (gadget) controllers are architecturally different:
- USBSS uses a custom gadget controller (cdns3_gadget_init)
- USBSSP uses an XHCI-based gadget controller (cdnsp_gadget_init)
I will fix the description in v2 to clearly state this difference.
> > +
> > properties:
> > compatible:
> > - const: cdns,usb3
> > + enum:
> > + - cdns,usb3
> > + - cdns,usbssp
>
> Why do we need another generic compatible?
>
> And why do you add it now to each of device schemas using this one?
Like explain above, the USBSSP has a different device/gadget controller
architecture from USBSS. The platform driver uses the compatible string
to select the correct gadget init function:
if (device_get_match_data(dev) == &cdnsp_plat)
cdns->gadget_init = cdnsp_gadget_init;
else
cdns->gadget_init = cdns3_gadget_init;
Without a distinct compatible, the driver cannot know which gadget
controller is present. This is a Cadence IP-level distinction (not
SoC-specific), so a generic compatible seems appropriate here. But
please let me know if you'd prefer a different approach.
> >
> > examples:
> > - |
> > + // USBSS example (SuperSpeed)
> > #include <dt-bindings/interrupt-controller/arm-gic.h>
> > bus {
> > #address-cells = <2>;
> > @@ -109,3 +118,24 @@ examples:
> > dr_mode = "otg";
> > };
> > };
> > + - |
> > + // USBSSP example (SuperSpeed Plus)
> > + #include <dt-bindings/interrupt-controller/arm-gic.h>
> > + bus {
>
> No, drop entire example. It's the same as other.
>
I original thought the user may copy SS binding doc to their
SSP dts file, and forget to change maximum-speed property,
so the maximum speed will be fixed at SS. If we don't need
to worry about it, I will delete at v2.
--
Best regards,
Peter
next prev parent reply other threads:[~2026-03-02 9:21 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-02 3:03 [PATCH 0/2] usb: cdns3: USBSSP platform driver support Peter Chen
2026-03-02 3:03 ` [PATCH 1/2] usb: cdns3: Add " Peter Chen
2026-03-02 7:31 ` Krzysztof Kozlowski
2026-03-02 11:05 ` Peter Chen
2026-03-04 23:07 ` kernel test robot
2026-03-04 23:29 ` kernel test robot
2026-03-08 11:38 ` kernel test robot
2026-03-11 6:52 ` Pawel Laszczak
2026-03-02 3:03 ` [PATCH 2/2] dt-bindings: usb: cdns,usb3: Add support for USBSSP Peter Chen
2026-03-02 7:28 ` Krzysztof Kozlowski
2026-03-02 9:21 ` Peter Chen [this message]
2026-03-02 9:27 ` Krzysztof Kozlowski
2026-03-02 10:59 ` Peter Chen
2026-03-04 10:02 ` Pawel Laszczak
2026-03-11 12:02 ` Peter Chen
2026-03-12 8:07 ` Pawel Laszczak
2026-03-02 7:29 ` Krzysztof Kozlowski
2026-03-02 9:33 ` Peter Chen
2026-03-02 9:03 ` Pawel Laszczak
2026-03-02 11:04 ` Peter Chen
2026-03-03 7:34 ` [PATCH 0/2] usb: cdns3: USBSSP platform driver support Pawel Laszczak
2026-03-03 10:54 ` Peter Chen
2026-03-04 8:22 ` Pawel Laszczak
2026-03-04 8:31 ` Peter Chen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aaVWlfMPSZgy55Cc@nchen-desktop \
--to=peter.chen@cixtech.com \
--cc=cix-kernel-upstream@cixtech.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=krzk+dt@kernel.org \
--cc=krzk@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=pawell@cadence.com \
--cc=robh@kernel.org \
--cc=rogerq@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox