[PATCH 0/5] usb: dwc3: xilinx: error handling and teardown fixes

Thinh Nguyen Thinh.Nguyen at synopsys.com
Tue Aug 25 17:22:38 PDT 2026


On Mon, Aug 10, 2026, Radhey Shyam Pandey wrote:
> This series improves error handling, resource teardown, and system sleep
> PM robustness in the dwc3-xilinx glue driver for ZynqMP and Versal
> platforms.
> 
> Patch 1 switches probe to device_get_match_data() and adds the direct
> property.h include instead of relying on of.h for that helper.
> 
> Patch 2 introduces struct dwc3_xlnx_platdata and moves ZynqMP and
> Versal setup behind plat->init(). The struct also defines an exit
> callback slot used by the later teardown patches.
> 
> Patch 3 fixes system suspend and resume PHY handling: suspend now
> powers off the PHY before phy_exit() and propagates errors; resume
> disables clocks if PHY reinitialization fails after they were enabled.
> 
> Patch 4 fixes ZynqMP init error paths. Reset handles are saved in
> driver private data and fall-through error labels re-assert only the
> resets already released before unwinding the PHY when init fails
> partway through reset deassert or PHY setup.
> 
> Patch 5 adds dwc3_xlnx_exit_zynqmp(), wires it as the ZynqMP platform
> exit callback, and calls plat->exit() from probe error paths after a
> successful plat->init() and from remove()/shutdown.
> 
> Radhey Shyam Pandey (5):
>   usb: dwc3: xilinx: use device_get_match_data() in probe
>   usb: dwc3: xilinx: add platform data struct with init callback
>   usb: dwc3: xilinx: fix system suspend and resume PHY handling
>   usb: dwc3: xilinx: re-assert resets on ZynqMP init error paths
>   usb: dwc3: xilinx: unwind ZynqMP platform init on probe failure and
>     remove
> 
>  drivers/usb/dwc3/dwc3-xilinx.c | 132 +++++++++++++++++++++++++--------
>  1 file changed, 100 insertions(+), 32 deletions(-)
> 
> 
> base-commit: 6b8c8af514d739d0335f5579b585e02babe8a727
> -- 
> 2.43.0
> 

These patches look good to me, do you plan to backport the fixes? If so,
can you Cc stable and re-order them so that the fixes patches go first?
Better yet, keep the fixes and new changes in separate series.

Thanks,
Thinh


More information about the linux-arm-kernel mailing list