Re: [PATCH v8 2/4] arm64: dts: nuvoton: ma35d1: add USB controllers and dual-port PHY node

[Joey Lu <a0987203069@gmail.com>]

On 11/9/2026 3:16 PM, sashiko-bot@kernel.org wrote:
> 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 <a0987203069@gmail.com>
>
> 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.
>
>> 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
> [ ... ]
>
>> @@ -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.
dwc2 register size: valid. dwc2 places the per-endpoint FIFOs at
0x1000 + n * 0x1000 (EPFIFO() in hw.h), so a 0x1000 window cuts them off.
The USB0 region in the MA35D1 spec is 0x4020_0000-0x4024_0000, so in v8 I'll
change it to reg = <0x0 0x40200000 0x0 0x40000>. I checked the other USB 
nodes
(EHCI0/1, OHCI0/1) against the spec; their 0x1000 ranges are correct, so
only this node changes.

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy