[PATCH v2 1/4] dt-bindings: usb: dwc3: Add Google Tensor G5 DWC3

Roy Luo royluo at google.com
Thu Oct 9 17:36:09 PDT 2025


On Thu, Oct 9, 2025 at 10:13 AM Conor Dooley <conor at kernel.org> wrote:
>
> On Wed, Oct 08, 2025 at 09:40:57PM -0700, Roy Luo wrote:
> > On Wed, Oct 8, 2025 at 1:58 PM Conor Dooley <conor at kernel.org> wrote:
> > >
> > > On Wed, Oct 08, 2025 at 05:59:57AM +0000, Roy Luo wrote:
>
> > > > +allOf:
> > > > +  - $ref: snps,dwc3-common.yaml#
> > > > +
> > > > +unevaluatedProperties: false
> > >
> > > So every property from snps,dwc3-common.yaml is valid here, with any of
> > > the permitted values?
> >
> > Conor,
> >
> > Appreciate the review.
> > Ack to all the comments, will fix them in the next patch.
> > And yes, every property from snps,dwc3-common.yaml is valid here.
> > You can find more context here [1], essentially the dwc3 glue would be
> > operating on the same platform device as the dwc3 core, hence all
> > properties are allowed.
> >
> > [1] https://lore.kernel.org/all/20250414-dwc3-refactor-v7-0-f015b358722d@oss.qualcomm.com/
>
> I find it exceedingly hard to believe that every property from that
> file, with every permitted value, is possible. AFAIU, the tensor g5 is a
> phone chip that's only used in pixel devices, not something that people
> can just buy and integrate into whatever device they feel like. There
> should be a vanishingly small number of possible configurations,
> possibly exactly one configuration. There are dozens of properties in
> the dwc3 common binding, of which at least 10 are for "quirks" or other
> sorts of hardware errata that are not going to be variable from one
> phone to another.

To my knowledge, the properties in snps,dwc3-common.yaml can generally
be categorized into two types:
- Function knobs: These properties translate directly to register writes that
  modify the controller's fundamental behavior. Most quirks fall into this
  category. For example, "snps,gfladj-refclk-lpm-sel-quirk" enables SOF counter.
- Tunable Values: These properties also map to register writes to influence
  hardware behavior, but they typically adjust performance or interoperability
  rather than essential function. While the hardware usually works fine with
  default settings, these values allow for optimization. For example,
  "tx-fifo-max-num" usually affects data throughput.

For DWC3 hardware errata and workarounds, my understanding is that they
are typically handled within the dwc3 driver, often involving a DWC3 revision
check (e.g. [1]), instead of in the device tree binding. While you may find
properties related to errata, they generally serve to enable or disable an
existing workaround (e.g. [2]).

For Pixel devices, it's shipped with a preferred configuration, but the hardware
is fundamentally capable of supporting other configurations since the properties
are backed by the SNPS DWC3 IP. Whether that's optimal is a different story.
I haven't tried toggling every single property but I'm not aware of any property
that obviously does not work on Tensor G5.

I hope this addresses your concern.

[1] https://github.com/torvalds/linux/commit/32a4a135847b1e600c64756b7c7c7a91eb2f0aa9
    (sorry I'm unable to find the kernel lore link for this commit)
[2] https://lore.kernel.org/all/1509455515-5992-1-git-send-email-rogerq@ti.com/

Regards,
Roy Luo



More information about the linux-phy mailing list