Re: [PATCH v2 1/3] arm64: dts: qcom: hamoa: Number usb_2 HS port as port@0

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The commit message establishes a broken Devicetree API contract by promoting the use of `port@1` for a downstream USB root hub physical port connection (e.g., an M.2 BT slot), which violates Devicetree topologies and schemas.
--

--- Patch [1]: [PATCH v2 1/3] arm64: dts: qcom: hamoa: Number usb_2 HS port as port@0 ---
commit 26a61b5c5bcc296d009783e2231b6c4b9b5fd3ef
Author: Wei Deng <wei.deng@oss.qualcomm.com>

arm64: dts: qcom: hamoa: Number usb_2 HS port as port@0

This patch assigns a port number to the existing high-speed data bus port in
the usb_2 DWC3 controller by wrapping it in a ports node and renaming it to
port@0. The commit message states this aligns with the snps,dwc3 binding
convention. It also claims this reserves port@1 for USB root hub physical
connections like an M.2 Key E Bluetooth slot.

> Adding a port number also reserves port@1 for USB root hub physical
> port connections (e.g. an M.2 Key E USB BT slot) that can be described
> in board device tree files.

[Severity: Medium]
Does this description conflict with standard Devicetree topologies for USB
devices?

Standard USB downstream devices are typically modeled as direct children of
the USB controller using function-based names (e.g., bluetooth@1), rather
than being modeled as OF graph endpoints.

If board developers follow this guidance and place a port@1 node inside the
ports node, won't it trigger schema validation errors? 

The snps,dwc3-common.yaml schema strictly defines port@1 in the OF graph as
a Super-Speed data bus, which conflicts with this being an HS-only controller.

Could the commit message be updated to avoid suggesting OF graph routing for
logical USB bus topologies?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260723-hamoa-m2-dts-v2-v2-0-82254ac101fb@oss.qualcomm.com?part=1