From: sashiko-bot@kernel.org
To: "Marek Vasut" <marex@nabladev.com>
Cc: neil.armstrong@linaro.org, linux-phy@lists.infradead.org,
robh@kernel.org, conor+dt@kernel.org, devicetree@vger.kernel.org,
vkoul@kernel.org, olteanv@gmail.com
Subject: Re: [PATCH 5/8] dt-bindings: usb: dwc3: Document ST STM32MP2 DWC3 xHCI USB controller
Date: Wed, 12 Aug 2026 01:08:55 +0000 [thread overview]
Message-ID: <20260812010856.712B71F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260812010157.1772849-6-marex@nabladev.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] Missing reference to DWC3 core schema causes valid USB properties to be rejected.
- [Low] The `resets` property is missing a `maxItems` constraint.
--
--- Patch [5]: [PATCH 5/8] dt-bindings: usb: dwc3: Document ST STM32MP2 DWC3 xHCI USB controller ---
commit df84943476bf67384e16624668aaadbaba67875b
Author: Marek Vasut <marex@nabladev.com>
dt-bindings: usb: dwc3: Document ST STM32MP2 DWC3 xHCI USB controller
The ST STM32MP2 SoC contains single instance of DWC3 USB controller with
glue logic wrapper around it controlled by syscon. Document the glue
logic and DWC3 controller.
> diff --git a/Documentation/devicetree/bindings/usb/st,stm32mp25-dwc3.yaml b/Documentation/devicetree/bindings/usb/st,stm32mp25-dwc3.yaml
> new file mode 100644
> index 0000000000000..e377efef43503
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/st,stm32mp25-dwc3.yaml
> @@ -0,0 +1,108 @@
[ ... ]
> + phy-names:
> + minItems: 1
> + items:
> + - const: usb2-phy
> + - const: usb3-phy
> +
> + resets:
> + minItems: 1
[Severity: Low]
Does this resets definition need a maxItems constraint?
Without an upper bound, dt-schema allows an arbitrary number of reset items,
which might let invalid hardware configurations silently pass validation.
> +
> + st,syscfg:
[ ... ]
> +required:
> + - compatible
> + - reg
> + - clocks
> + - clock-names
> + - interrupts
> + - phys
> + - phy-names
> + - resets
> + - st,syscfg
> +
> +unevaluatedProperties: false
[Severity: Medium]
Will this strict constraint cause valid USB or DWC3 core properties to be
rejected?
Since the schema does not include a reference to the core DWC3 schema (such
as allOf: - $ref: snps,dwc3.yaml#), only the explicitly listed properties
are permitted.
Standard properties like maximum-speed, usb-role-switch, or child nodes
intended for the DWC3 core will fail validation when checked.
> +
> +examples:
> + - |
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260812010157.1772849-1-marex@nabladev.com?part=5
WARNING: multiple messages have this Message-ID (diff)
From: sashiko-bot@kernel.org
To: "Marek Vasut" <marex@nabladev.com>
Cc: neil.armstrong@linaro.org, linux-phy@lists.infradead.org,
robh@kernel.org, conor+dt@kernel.org, devicetree@vger.kernel.org,
vkoul@kernel.org, olteanv@gmail.com
Subject: Re: [PATCH 5/8] dt-bindings: usb: dwc3: Document ST STM32MP2 DWC3 xHCI USB controller
Date: Wed, 12 Aug 2026 01:08:55 +0000 [thread overview]
Message-ID: <20260812010856.712B71F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260812010157.1772849-6-marex@nabladev.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] Missing reference to DWC3 core schema causes valid USB properties to be rejected.
- [Low] The `resets` property is missing a `maxItems` constraint.
--
--- Patch [5]: [PATCH 5/8] dt-bindings: usb: dwc3: Document ST STM32MP2 DWC3 xHCI USB controller ---
commit df84943476bf67384e16624668aaadbaba67875b
Author: Marek Vasut <marex@nabladev.com>
dt-bindings: usb: dwc3: Document ST STM32MP2 DWC3 xHCI USB controller
The ST STM32MP2 SoC contains single instance of DWC3 USB controller with
glue logic wrapper around it controlled by syscon. Document the glue
logic and DWC3 controller.
> diff --git a/Documentation/devicetree/bindings/usb/st,stm32mp25-dwc3.yaml b/Documentation/devicetree/bindings/usb/st,stm32mp25-dwc3.yaml
> new file mode 100644
> index 0000000000000..e377efef43503
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/st,stm32mp25-dwc3.yaml
> @@ -0,0 +1,108 @@
[ ... ]
> + phy-names:
> + minItems: 1
> + items:
> + - const: usb2-phy
> + - const: usb3-phy
> +
> + resets:
> + minItems: 1
[Severity: Low]
Does this resets definition need a maxItems constraint?
Without an upper bound, dt-schema allows an arbitrary number of reset items,
which might let invalid hardware configurations silently pass validation.
> +
> + st,syscfg:
[ ... ]
> +required:
> + - compatible
> + - reg
> + - clocks
> + - clock-names
> + - interrupts
> + - phys
> + - phy-names
> + - resets
> + - st,syscfg
> +
> +unevaluatedProperties: false
[Severity: Medium]
Will this strict constraint cause valid USB or DWC3 core properties to be
rejected?
Since the schema does not include a reference to the core DWC3 schema (such
as allOf: - $ref: snps,dwc3.yaml#), only the explicitly listed properties
are permitted.
Standard properties like maximum-speed, usb-role-switch, or child nodes
intended for the DWC3 core will fail validation when checked.
> +
> +examples:
> + - |
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260812010157.1772849-1-marex@nabladev.com?part=5
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
next prev parent reply other threads:[~2026-08-12 1:08 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-12 0:55 [PATCH 0/8] arm64: dts: phy: st: usb: Add STM32MP2 USB support Marek Vasut
2026-08-12 0:55 ` Marek Vasut
2026-08-12 0:55 ` [PATCH 1/8] dt-bindings: phy: Document ST STM32MP25 USB2-FEMTO PHY Marek Vasut
2026-08-12 0:55 ` Marek Vasut
2026-08-12 1:05 ` sashiko-bot
2026-08-12 1:05 ` sashiko-bot
2026-08-12 2:45 ` Rob Herring (Arm)
2026-08-12 2:45 ` Rob Herring (Arm)
2026-08-12 10:15 ` Krzysztof Kozlowski
2026-08-12 10:15 ` Krzysztof Kozlowski
2026-08-12 10:56 ` Marek Vasut
2026-08-12 10:56 ` Marek Vasut
2026-08-12 11:22 ` Krzysztof Kozlowski
2026-08-12 11:22 ` Krzysztof Kozlowski
2026-08-12 0:55 ` [PATCH 2/8] phy: stm32: Add support for " Marek Vasut
2026-08-12 0:55 ` Marek Vasut
2026-08-12 1:12 ` sashiko-bot
2026-08-12 1:12 ` sashiko-bot
2026-08-12 0:55 ` [PATCH 3/8] dt-bindings: usb: generic-ehci: Document access-controllers property Marek Vasut
2026-08-12 0:55 ` Marek Vasut
2026-08-12 1:10 ` sashiko-bot
2026-08-12 1:10 ` sashiko-bot
2026-08-12 0:55 ` [PATCH 4/8] dt-bindings: usb: generic-ohci: " Marek Vasut
2026-08-12 0:55 ` Marek Vasut
2026-08-12 0:55 ` [PATCH 5/8] dt-bindings: usb: dwc3: Document ST STM32MP2 DWC3 xHCI USB controller Marek Vasut
2026-08-12 0:55 ` Marek Vasut
2026-08-12 1:08 ` sashiko-bot [this message]
2026-08-12 1:08 ` sashiko-bot
2026-08-12 0:55 ` [PATCH 6/8] usb: dwc3: dwc3-generic-plat: Add ST STM32MP2 DWC3 xHCI USB controller glue Marek Vasut
2026-08-12 0:55 ` Marek Vasut
2026-08-12 1:11 ` sashiko-bot
2026-08-12 1:11 ` sashiko-bot
2026-08-12 0:55 ` [PATCH 7/8] arm64: dts: st: Add USB nodes on stm32mp231 Marek Vasut
2026-08-12 0:55 ` Marek Vasut
2026-08-12 0:55 ` [PATCH 8/8] arm64: dts: st: Add USB nodes on stm32mp251 Marek Vasut
2026-08-12 0:55 ` Marek Vasut
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=20260812010856.712B71F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=linux-phy@lists.infradead.org \
--cc=marex@nabladev.com \
--cc=neil.armstrong@linaro.org \
--cc=olteanv@gmail.com \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=vkoul@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.