From: Marek Vasut <marek.vasut@mailbox.org>
To: Conor Dooley <conor@kernel.org>
Cc: linux-usb@vger.kernel.org, Conor Dooley <conor+dt@kernel.org>,
Geert Uytterhoeven <geert+renesas@glider.be>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Rob Herring <robh@kernel.org>,
Thinh Nguyen <Thinh.Nguyen@synopsys.com>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-renesas-soc@vger.kernel.org
Subject: Re: [PATCH v7 1/2] dt-bindings: usb: dwc3: Document Renesas R-Car Gen5 DWC3 xHCI USB controller
Date: Wed, 9 Sep 2026 16:43:19 +0200 [thread overview]
Message-ID: <3b345291-b14d-45a4-818e-355b487c46a9@mailbox.org> (raw)
In-Reply-To: <aqE11WTb6EMhn6Tb@squawk>
On 9/9/26 12:32 PM, Conor Dooley wrote:
Hello Conor,
>> I could make only the ones which are currently used available, but that
>> would be confusing the implementers by suggesting that the other quirks are
>> not applicable even if they might be ; and this would likely turn into an
>> endless stream of schema updates, with random users enabling random quirks
>> they just used. I don't think that would be helpful.
>
> My understanding was that these things were effectively errata, so users
> should not be enabling them willy nilly - the vast majority of these are
> set in soc.dtsi files, and the couple dts users I checked were all SoCs
> for which there was only one board.
I agree with the careful application of these properties part.
However, I perceive them as tunables, not errata. If they were errata, I
would argue the errata quirks that apply to each controller instance in
each SoC should be derived from the compatible string. If they were
tunables, they should be DT properties.
> IMO it's far more confusing to suggest
> that a user has to figure out which of these may apply on their platform.
The way I interpret this is, that the user should keep the defaults and
not enable any of the additional quirks unless they really need them.
But the DT checker should not warn the user that the quirk is invalid,
because I do not think that is the case -- the quirk is not invalid, it
is only not necessary in the majority of cases.
> But of course, do what you want, they're your users.
How shall we proceed here ?
--
Best regards,
Marek Vasut
prev parent reply other threads:[~2026-09-09 16:52 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-03 21:30 [PATCH v7 1/2] dt-bindings: usb: dwc3: Document Renesas R-Car Gen5 DWC3 xHCI USB controller Marek Vasut
2026-09-03 21:30 ` [PATCH v7 2/2] usb: dwc3: dwc3-generic-plat: Add Renesas R-Car Gen5 DWC3 xHCI USB controller glue Marek Vasut
2026-09-03 21:39 ` sashiko-bot
2026-09-04 23:10 ` Thinh Nguyen
2026-09-04 15:32 ` [PATCH v7 1/2] dt-bindings: usb: dwc3: Document Renesas R-Car Gen5 DWC3 xHCI USB controller Conor Dooley
2026-09-04 16:24 ` Marek Vasut
2026-09-07 17:43 ` Conor Dooley
2026-09-08 20:58 ` Marek Vasut
2026-09-09 10:32 ` Conor Dooley
2026-09-09 14:43 ` Marek Vasut [this message]
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=3b345291-b14d-45a4-818e-355b487c46a9@mailbox.org \
--to=marek.vasut@mailbox.org \
--cc=Thinh.Nguyen@synopsys.com \
--cc=conor+dt@kernel.org \
--cc=conor@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=geert+renesas@glider.be \
--cc=gregkh@linuxfoundation.org \
--cc=krzk+dt@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=robh@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