Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Medium] arm64: dts: nuvoton: ma35d1: usb@40200000 reg size 0x1000
truncates DWC2 FIFOs
--
commit aa9ff21b68491f1e002468f4d400c0d7fd2b192f
Author: Joey Lu [off-list ref]
arm64: dts: nuvoton: ma35d1: add USB controllers and dual-port PHY node
This commit adds the dual-port USB 2.0 phy, dwc2 gadget, and ehci/ohci host
controller nodes to the ma35d1 device tree and enables them on the som-256m
and iot-512m boards.
quoted hunk ↗ jump to hunk
diff --git a/arch/arm64/boot/dts/nuvoton/ma35d1.dtsi b/arch/arm64/boot/dts/nuvoton/ma35d1.dtsi
index 7228ad4735b5c..72a1659207fa7 100644
--- a/arch/arm64/boot/dts/nuvoton/ma35d1.dtsi
+++ b/arch/arm64/boot/dts/nuvoton/ma35d1.dtsi
[ ... ]
quoted hunk ↗ jump to hunk
@@ -431,5 +439,62 @@ mdio1: mdio {
#size-cells = <0>;
};
};
+
+ usb: usb@40200000 {
+ compatible = "snps,dwc2";
+ reg = <0x0 0x40200000 0x0 0x1000>;
[Severity: Medium]
Does the 0x1000 register size for usb@40200000 truncate the dwc2 per-endpoint
data fifo region?
A 0x1000 window only covers the core global, host, device, and power control
registers (offsets 0x000 through 0xe04), while the dwc2 driver defines
per-endpoint fifos starting at offset 0x1000:
drivers/usb/dwc2/hw.h:
#define EPFIFO(_a) HSOTG_REG(0x1000 + ((_a) * 0x1000))
dwc2_driver_probe() maps the exact length from reg via
devm_platform_get_and_ioremap_resource(). If the controller runs in slave/pio
mode, dwc2_hsotg_write_fifo() and dwc2_hsotg_rx_data() access these fifo
registers at offset 0x1000 and above, faulting outside the 4 kb mapping.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261109065606.62641-1-a0987203069@gmail.com?part=2