[PATCH v7 1/2] dt-bindings: usb: dwc3: Document Renesas R-Car Gen5 DWC3 xHCI USB controller

[PATCH v7 1/2] dt-bindings: usb: dwc3: Document Renesas R-Car Gen5 DWC3 xHCI USB controller

[Marek Vasut]

The Renesas R-Car Gen5 SoC contains multiple instances of DWC3 USB
controller with glue logic wrapper around them. Document the glue
logic and DWC3 controller.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Rob Herring <robh@kernel.org>
Cc: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
Cc: linux-usb@vger.kernel.org
---
V2: Rework to use flat bindings for generic plat driver
V3: - Support one or two PHYs to correctly describe the hardware
    - Make maximum-speed optional
V4: - Use ref: snps,dwc3-common.yaml and drop generic dr_mode/maximum-speed/phys/phy-names
    - Switch to unevaluatedProperties: false
V5: - Limit maximum PHY count to 2
V6: No change
V7: No change
---
 .../bindings/usb/renesas,rcar-gen5-dwc3.yaml  | 76 +++++++++++++++++++
 1 file changed, 76 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/renesas,rcar-gen5-dwc3.yaml

diff --git a/Documentation/devicetree/bindings/usb/renesas,rcar-gen5-dwc3.yaml b/Documentation/devicetree/bindings/usb/renesas,rcar-gen5-dwc3.yaml
new file mode 100644
index 0000000000000..c8a770d7e0241
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/renesas,rcar-gen5-dwc3.yaml
@@ -0,0 +1,76 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/renesas,rcar-gen5-dwc3.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas R-Car Gen5 DWC3 xHCI USB controller
+
+maintainers:
+  - Marek Vasut <marek.vasut+renesas@mailbox.org>
+
+allOf:
+  - $ref: snps,dwc3-common.yaml#
+
+properties:
+  compatible:
+    items:
+      - const: renesas,r8a78000-dwc3
+      - const: renesas,rcar-gen5-dwc3
+
+  reg:
+    maxItems: 2
+
+  reg-names:
+    items:
+      - const: dwc3
+      - const: glue
+
+  clocks:
+    maxItems: 1
+
+  interrupts:
+    maxItems: 1
+
+  phys:
+    minItems: 1
+    maxItems: 2
+
+  phy-names:
+    minItems: 1
+    maxItems: 2
+
+  power-domains:
+    maxItems: 1
+
+  resets:
+    maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - reg-names
+  - clocks
+  - interrupts
+  - phys
+  - phy-names
+  - power-domains
+  - resets
+
+unevaluatedProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+    usb@c8800000 {
+        compatible = "renesas,r8a78000-dwc3", "renesas,rcar-gen5-dwc3";
+        reg = <0xc8800000 0x100000>, <0xc9c54000 0x2000>;
+        reg-names = "dwc3", "glue";
+        clocks = <&scmi_clk 336>;
+        interrupts = <GIC_SPI 795 IRQ_TYPE_LEVEL_HIGH>;
+        phys = <&usb30_phy>, <&mp_phy 2>;
+        phy-names = "usb2-phy", "usb3-phy";
+        power-domains = <&scmi_devpd 16>;
+        resets = <&scmi_reset 336>;
+    };
-- 
2.53.0

[PATCH v7 2/2] usb: dwc3: dwc3-generic-plat: Add Renesas R-Car Gen5 DWC3 xHCI USB controller glue

[Marek Vasut]

From: Thanh Quan <thanh.quan.xn@renesas.com>

The Renesas R-Car Gen5 SoC contains multiple instances of DWC3 USB
controller with glue logic wrapper around them. Extend the generic
DWC3 platform driver with Renesas R-Car Gen5 glue logic specifics.

Signed-off-by: Thanh Quan <thanh.quan.xn@renesas.com>
Co-developed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Rob Herring <robh@kernel.org>
Cc: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
Cc: linux-usb@vger.kernel.org
---
V2: Extend dwc3-generic-plat driver instead
V3: Handle maximum-speed as optional property, test for USB 3 PHY
    non-presence to determine whether the controller is USB 2 only,
    consider optional maximum-speed DT property, but if it is missing
    then default to maximum controller capabilities based on the
    presence of PHY phandles.
V4: No change
V5: - Drop superfluous code comment
    - Drop duplicate speed >= USB_SPEED_LOW test
V6: Reinstate speed >= USB_SPEED_LOW test to avoid triggering on USB_SPEED_UNKNOWN
V7: Drop wireless USB check
---
 drivers/usb/dwc3/dwc3-generic-plat.c | 51 ++++++++++++++++++++++++++++
 1 file changed, 51 insertions(+)

diff --git a/drivers/usb/dwc3/dwc3-generic-plat.c b/drivers/usb/dwc3/dwc3-generic-plat.c
index ca69ac0eb07ce..32497ab6f065e 100644
--- a/drivers/usb/dwc3/dwc3-generic-plat.c
+++ b/drivers/usb/dwc3/dwc3-generic-plat.c
@@ -71,6 +71,51 @@ static int dwc3_eic7700_init(struct dwc3_generic *dwc3g)
 	return 0;
 }
 
+static int dwc3_renesas_rcar_gen5_init(struct dwc3_generic *dwc3g)
+{
+	struct device *dev = dwc3g->dev;
+	struct platform_device *pdev = to_platform_device(dev);
+	enum usb_device_speed speed = usb_get_maximum_speed(dev);
+	bool usb2only = false;
+	void __iomem *glue;
+
+	/* No USB 3 PHY in DT means this is surely USB 2 controller */
+	if (device_property_match_string(dev, "phy-names", "usb3-phy") < 0)
+		usb2only = true;
+
+	if (speed >= USB_SPEED_LOW && speed <= USB_SPEED_HIGH)
+		usb2only = true;
+
+	glue = devm_platform_ioremap_resource_byname(pdev, "glue");
+	if (IS_ERR(glue))
+		return PTR_ERR(glue);
+
+	/*
+	 * The datasheet describes initialization procedure without full
+	 * information about the registers. Therefore, the source code is
+	 * based on the bare metal code shared by the board team.
+	 */
+	writew(0x211, glue + 0x26);
+
+	/* USB2 does need additional register programming. */
+	if (!usb2only)
+		return 0;
+
+	writew(0x11, glue + 0x81c);
+	writew(0x0, glue + 0x81a);
+	writew(0x1, glue + 0x802);
+
+	usleep_range(10000, 20000);
+
+	writew(0x0, glue + 0x802);
+	writew(0x1, glue + 0x2a);
+	writew(0x1, glue + 0x81a);
+
+	usleep_range(10000, 20000);
+
+	return 0;
+}
+
 static int dwc3_spacemit_k1_init(struct dwc3_generic *dwc3g)
 {
 	struct device *dev = dwc3g->dev;
@@ -231,11 +276,17 @@ static const struct dwc3_generic_config eic7700_dwc3 =  {
 	.properties = DWC3_DEFAULT_PROPERTIES,
 };
 
+static const struct dwc3_generic_config renesas_rcar_gen5_dwc3 = {
+	.init = dwc3_renesas_rcar_gen5_init,
+	.properties = DWC3_DEFAULT_PROPERTIES,
+};
+
 static const struct of_device_id dwc3_generic_of_match[] = {
 	{ .compatible = "spacemit,k1-dwc3", &spacemit_k1_dwc3},
 	{ .compatible = "spacemit,k3-dwc3", },
 	{ .compatible = "fsl,ls1028a-dwc3", &fsl_ls1028_dwc3},
 	{ .compatible = "eswin,eic7700-dwc3", &eic7700_dwc3},
+	{ .compatible = "renesas,rcar-gen5-dwc3", &renesas_rcar_gen5_dwc3},
 	{ .compatible = "starfive,jhb100-dwc3", },
 	{ /* sentinel */ }
 };
-- 
2.53.0

Re: [PATCH v7 1/2] dt-bindings: usb: dwc3: Document Renesas R-Car Gen5 DWC3 xHCI USB controller

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 3772 bytes --]

On Thu, Sep 03, 2026 at 11:30:12PM +0200, Marek Vasut wrote:
> The Renesas R-Car Gen5 SoC contains multiple instances of DWC3 USB
> controller with glue logic wrapper around them. Document the glue
> logic and DWC3 controller.
> 
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
> ---
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
> Cc: devicetree@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-renesas-soc@vger.kernel.org
> Cc: linux-usb@vger.kernel.org
> ---
> V2: Rework to use flat bindings for generic plat driver
> V3: - Support one or two PHYs to correctly describe the hardware
>     - Make maximum-speed optional
> V4: - Use ref: snps,dwc3-common.yaml and drop generic dr_mode/maximum-speed/phys/phy-names
>     - Switch to unevaluatedProperties: false
> V5: - Limit maximum PHY count to 2
> V6: No change
> V7: No change
> ---
>  .../bindings/usb/renesas,rcar-gen5-dwc3.yaml  | 76 +++++++++++++++++++
>  1 file changed, 76 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/usb/renesas,rcar-gen5-dwc3.yaml
> 
> diff --git a/Documentation/devicetree/bindings/usb/renesas,rcar-gen5-dwc3.yaml b/Documentation/devicetree/bindings/usb/renesas,rcar-gen5-dwc3.yaml
> new file mode 100644
> index 0000000000000..c8a770d7e0241
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/renesas,rcar-gen5-dwc3.yaml
> @@ -0,0 +1,76 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/usb/renesas,rcar-gen5-dwc3.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Renesas R-Car Gen5 DWC3 xHCI USB controller
> +
> +maintainers:
> +  - Marek Vasut <marek.vasut+renesas@mailbox.org>
> +
> +allOf:
> +  - $ref: snps,dwc3-common.yaml#
> +
> +properties:
> +  compatible:
> +    items:
> +      - const: renesas,r8a78000-dwc3
> +      - const: renesas,rcar-gen5-dwc3
> +
> +  reg:
> +    maxItems: 2
> +
> +  reg-names:
> +    items:
> +      - const: dwc3
> +      - const: glue
> +
> +  clocks:
> +    maxItems: 1
> +
> +  interrupts:
> +    maxItems: 1
> +
> +  phys:
> +    minItems: 1
> +    maxItems: 2
> +
> +  phy-names:
> +    minItems: 1
> +    maxItems: 2
> +
> +  power-domains:
> +    maxItems: 1
> +
> +  resets:
> +    maxItems: 1
> +
> +required:
> +  - compatible
> +  - reg
> +  - reg-names
> +  - clocks
> +  - interrupts
> +  - phys
> +  - phy-names
> +  - power-domains
> +  - resets
> +
> +unevaluatedProperties: false

I said this elsewhere today, but this binding has lots of "distasteful"
properties for things that should be determined from the compatible, so I
would appreciate it if you could use additionalProperties: false here
cite the ones you need to use explicitly. Sounds like dr_mode: true and
maximum-speed: true are all you'd need?

Cheers,
Conor.

> +
> +examples:
> +  - |
> +    #include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> +    usb@c8800000 {
> +        compatible = "renesas,r8a78000-dwc3", "renesas,rcar-gen5-dwc3";
> +        reg = <0xc8800000 0x100000>, <0xc9c54000 0x2000>;
> +        reg-names = "dwc3", "glue";
> +        clocks = <&scmi_clk 336>;
> +        interrupts = <GIC_SPI 795 IRQ_TYPE_LEVEL_HIGH>;
> +        phys = <&usb30_phy>, <&mp_phy 2>;
> +        phy-names = "usb2-phy", "usb3-phy";
> +        power-domains = <&scmi_devpd 16>;
> +        resets = <&scmi_reset 336>;
> +    };
> -- 
> 2.53.0
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v7 1/2] dt-bindings: usb: dwc3: Document Renesas R-Car Gen5 DWC3 xHCI USB controller

[Marek Vasut]

On 9/4/26 5:32 PM, Conor Dooley wrote:

Hello Conor,

[...]

>> +required:
>> +  - compatible
>> +  - reg
>> +  - reg-names
>> +  - clocks
>> +  - interrupts
>> +  - phys
>> +  - phy-names
>> +  - power-domains
>> +  - resets
>> +
>> +unevaluatedProperties: false
> 
> I said this elsewhere today, but this binding has lots of "distasteful"
> properties for things that should be determined from the compatible

Which properties would those be ? (it seems 
reg/clocks/interrupts/phys/power-domains/resets really need to be there 
as separate properties, but maybe I am missing the point?)

> , so I
> would appreciate it if you could use additionalProperties: false here
> cite the ones you need to use explicitly.

May I ask, what exactly is the rule of thumb for 
additionalProperties:false and unevaluatedProperties:false ? I seem to 
struggle with picking the right one for a while now.

> Sounds like dr_mode: true and
> maximum-speed: true are all you'd need?
Ah, I think this also answers my previous question a bit. And, as for 
limiting the properties that are really needed -- this pulls in the 
common DWC3 USB IP core properties, which all do apply to the DWC3 core. 
They might not be used on current hardware, but they are still valid for 
the DWC3 core (IP).

Thank you for your help !

Re: [PATCH v7 2/2] usb: dwc3: dwc3-generic-plat: Add Renesas R-Car Gen5 DWC3 xHCI USB controller glue

[Thinh Nguyen]

On Thu, Sep 03, 2026, Marek Vasut wrote:
> From: Thanh Quan <thanh.quan.xn@renesas.com>
> 
> The Renesas R-Car Gen5 SoC contains multiple instances of DWC3 USB
> controller with glue logic wrapper around them. Extend the generic
> DWC3 platform driver with Renesas R-Car Gen5 glue logic specifics.
> 
> Signed-off-by: Thanh Quan <thanh.quan.xn@renesas.com>
> Co-developed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
> ---
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
> Cc: devicetree@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-renesas-soc@vger.kernel.org
> Cc: linux-usb@vger.kernel.org
> ---
> V2: Extend dwc3-generic-plat driver instead
> V3: Handle maximum-speed as optional property, test for USB 3 PHY
>     non-presence to determine whether the controller is USB 2 only,
>     consider optional maximum-speed DT property, but if it is missing
>     then default to maximum controller capabilities based on the
>     presence of PHY phandles.
> V4: No change
> V5: - Drop superfluous code comment
>     - Drop duplicate speed >= USB_SPEED_LOW test
> V6: Reinstate speed >= USB_SPEED_LOW test to avoid triggering on USB_SPEED_UNKNOWN
> V7: Drop wireless USB check
> ---
>  drivers/usb/dwc3/dwc3-generic-plat.c | 51 ++++++++++++++++++++++++++++
>  1 file changed, 51 insertions(+)
> 
> diff --git a/drivers/usb/dwc3/dwc3-generic-plat.c b/drivers/usb/dwc3/dwc3-generic-plat.c
> index ca69ac0eb07ce..32497ab6f065e 100644
> --- a/drivers/usb/dwc3/dwc3-generic-plat.c
> +++ b/drivers/usb/dwc3/dwc3-generic-plat.c
> @@ -71,6 +71,51 @@ static int dwc3_eic7700_init(struct dwc3_generic *dwc3g)
>  	return 0;
>  }
>  
> +static int dwc3_renesas_rcar_gen5_init(struct dwc3_generic *dwc3g)
> +{
> +	struct device *dev = dwc3g->dev;
> +	struct platform_device *pdev = to_platform_device(dev);
> +	enum usb_device_speed speed = usb_get_maximum_speed(dev);
> +	bool usb2only = false;
> +	void __iomem *glue;
> +
> +	/* No USB 3 PHY in DT means this is surely USB 2 controller */
> +	if (device_property_match_string(dev, "phy-names", "usb3-phy") < 0)
> +		usb2only = true;
> +
> +	if (speed >= USB_SPEED_LOW && speed <= USB_SPEED_HIGH)
> +		usb2only = true;
> +
> +	glue = devm_platform_ioremap_resource_byname(pdev, "glue");
> +	if (IS_ERR(glue))
> +		return PTR_ERR(glue);
> +
> +	/*
> +	 * The datasheet describes initialization procedure without full
> +	 * information about the registers. Therefore, the source code is
> +	 * based on the bare metal code shared by the board team.
> +	 */
> +	writew(0x211, glue + 0x26);
> +
> +	/* USB2 does need additional register programming. */
> +	if (!usb2only)
> +		return 0;
> +
> +	writew(0x11, glue + 0x81c);
> +	writew(0x0, glue + 0x81a);
> +	writew(0x1, glue + 0x802);
> +
> +	usleep_range(10000, 20000);
> +
> +	writew(0x0, glue + 0x802);
> +	writew(0x1, glue + 0x2a);
> +	writew(0x1, glue + 0x81a);
> +
> +	usleep_range(10000, 20000);
> +
> +	return 0;
> +}
> +
>  static int dwc3_spacemit_k1_init(struct dwc3_generic *dwc3g)
>  {
>  	struct device *dev = dwc3g->dev;
> @@ -231,11 +276,17 @@ static const struct dwc3_generic_config eic7700_dwc3 =  {
>  	.properties = DWC3_DEFAULT_PROPERTIES,
>  };
>  
> +static const struct dwc3_generic_config renesas_rcar_gen5_dwc3 = {
> +	.init = dwc3_renesas_rcar_gen5_init,
> +	.properties = DWC3_DEFAULT_PROPERTIES,
> +};
> +
>  static const struct of_device_id dwc3_generic_of_match[] = {
>  	{ .compatible = "spacemit,k1-dwc3", &spacemit_k1_dwc3},
>  	{ .compatible = "spacemit,k3-dwc3", },
>  	{ .compatible = "fsl,ls1028a-dwc3", &fsl_ls1028_dwc3},
>  	{ .compatible = "eswin,eic7700-dwc3", &eic7700_dwc3},
> +	{ .compatible = "renesas,rcar-gen5-dwc3", &renesas_rcar_gen5_dwc3},
>  	{ .compatible = "starfive,jhb100-dwc3", },
>  	{ /* sentinel */ }
>  };
> -- 
> 2.53.0
> 

Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>

Thanks,
Thinh

Re: [PATCH v7 1/2] dt-bindings: usb: dwc3: Document Renesas R-Car Gen5 DWC3 xHCI USB controller

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 1897 bytes --]

On Fri, Sep 04, 2026 at 06:24:04PM +0200, Marek Vasut wrote:
> On 9/4/26 5:32 PM, Conor Dooley wrote:
> 
> Hello Conor,
> 
> [...]
> 
> > > +required:
> > > +  - compatible
> > > +  - reg
> > > +  - reg-names
> > > +  - clocks
> > > +  - interrupts
> > > +  - phys
> > > +  - phy-names
> > > +  - power-domains
> > > +  - resets
> > > +
> > > +unevaluatedProperties: false
> > 
> > I said this elsewhere today, but this binding has lots of "distasteful"
> > properties for things that should be determined from the compatible
> 
> Which properties would those be ? (it seems
> reg/clocks/interrupts/phys/power-domains/resets really need to be there as
> separate properties, but maybe I am missing the point?)

All the quirk properties is what I am talking about here. There's about
50 of them and I don't know if a single one should actually exist.

> > , so I
> > would appreciate it if you could use additionalProperties: false here
> > cite the ones you need to use explicitly.
> 
> May I ask, what exactly is the rule of thumb for additionalProperties:false
> and unevaluatedProperties:false ? I seem to struggle with picking the right
> one for a while now.

I would say, if all properties being imported apply to you device, use
unevaluated. If only some do, and there are some that will be
problematic or confusing if used, then additionalProperties: false and
citing the good ones explicit is clearer for users and prevents the bad
combos.

> 
> > Sounds like dr_mode: true and
> > maximum-speed: true are all you'd need?
> Ah, I think this also answers my previous question a bit. And, as for
> limiting the properties that are really needed -- this pulls in the common
> DWC3 USB IP core properties, which all do apply to the DWC3 core. They might
> not be used on current hardware, but they are still valid for the DWC3 core
> (IP).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v7 1/2] dt-bindings: usb: dwc3: Document Renesas R-Car Gen5 DWC3 xHCI USB controller

[Marek Vasut]

On 9/7/26 7:43 PM, Conor Dooley wrote:

Hello Conor,

>>>> +unevaluatedProperties: false
>>>
>>> I said this elsewhere today, but this binding has lots of "distasteful"
>>> properties for things that should be determined from the compatible
>>
>> Which properties would those be ? (it seems
>> reg/clocks/interrupts/phys/power-domains/resets really need to be there as
>> separate properties, but maybe I am missing the point?)
> 
> All the quirk properties is what I am talking about here. There's about
> 50 of them and I don't know if a single one should actually exist.

I cannot tell whether every one of them will ever be used or useful, but 
I also do not have a good argument to block most of them as they are 
tunables which apply to the DWC3 core itself.

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.

>>> , so I
>>> would appreciate it if you could use additionalProperties: false here
>>> cite the ones you need to use explicitly.
>>
>> May I ask, what exactly is the rule of thumb for additionalProperties:false
>> and unevaluatedProperties:false ? I seem to struggle with picking the right
>> one for a while now.
> 
> I would say, if all properties being imported apply to you device, use
> unevaluated. If only some do, and there are some that will be
> problematic or confusing if used, then additionalProperties: false and
> citing the good ones explicit is clearer for users and prevents the bad
> combos.

Thank you for this clarification, I will make a note of it.

Re: [PATCH v7 1/2] dt-bindings: usb: dwc3: Document Renesas R-Car Gen5 DWC3 xHCI USB controller

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 2430 bytes --]

On Tue, Sep 08, 2026 at 10:58:48PM +0200, Marek Vasut wrote:
> On 9/7/26 7:43 PM, Conor Dooley wrote:
> 
> Hello Conor,
> 
> > > > > +unevaluatedProperties: false
> > > > 
> > > > I said this elsewhere today, but this binding has lots of "distasteful"
> > > > properties for things that should be determined from the compatible
> > > 
> > > Which properties would those be ? (it seems
> > > reg/clocks/interrupts/phys/power-domains/resets really need to be there as
> > > separate properties, but maybe I am missing the point?)
> > 
> > All the quirk properties is what I am talking about here. There's about
> > 50 of them and I don't know if a single one should actually exist.
> 
> I cannot tell whether every one of them will ever be used or useful, but I
> also do not have a good argument to block most of them as they are tunables
> which apply to the DWC3 core itself.
> 
> 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. IMO it's far more confusing to suggest
that a user has to figure out which of these may apply on their platform.
But of course, do what you want, they're your users.

> 
> > > > , so I
> > > > would appreciate it if you could use additionalProperties: false here
> > > > cite the ones you need to use explicitly.
> > > 
> > > May I ask, what exactly is the rule of thumb for additionalProperties:false
> > > and unevaluatedProperties:false ? I seem to struggle with picking the right
> > > one for a while now.
> > 
> > I would say, if all properties being imported apply to you device, use
> > unevaluated. If only some do, and there are some that will be
> > problematic or confusing if used, then additionalProperties: false and
> > citing the good ones explicit is clearer for users and prevents the bad
> > combos.
> 
> Thank you for this clarification, I will make a note of it.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v7 1/2] dt-bindings: usb: dwc3: Document Renesas R-Car Gen5 DWC3 xHCI USB controller

[Marek Vasut]

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