Re: [PATCH v2 3/3] PCI: ultrarisc: allow DP1000 driver to build as module

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Missing `.remove` callback leaves the PCI root bus registered, causing a use-after-free on module unload.
--

commit 14ef8e08324f6393567996c3e1dc0b2cadbcfc0a
Author: Jia Wang <wangjia@ultrarisc.com>

PCI: ultrarisc: allow DP1000 driver to build as module

This commit changes the driver registration from builtin_platform_driver()
to module_platform_driver(). This allows the driver to be built and
dynamically loaded or unloaded as a kernel module.

> diff --git a/drivers/pci/controller/dwc/pcie-ultrarisc.c b/drivers/pci/controller/dwc/pcie-ultrarisc.c
> --- a/drivers/pci/controller/dwc/pcie-ultrarisc.c
> +++ b/drivers/pci/controller/dwc/pcie-ultrarisc.c
> @@ -225,7 +225,7 @@ static struct platform_driver ultrarisc_pcie_driver = {
>  	},
>  	.probe = ultrarisc_pcie_probe,
>  };
> -builtin_platform_driver(ultrarisc_pcie_driver);
> +module_platform_driver(ultrarisc_pcie_driver);

[Severity: High]
By switching to module_platform_driver(), this driver can now be unloaded
dynamically. However, since ultrarisc_pcie_driver lacks a .remove callback,
will unloading the module leave the active PCI root bus, IRQ domains, and
child devices registered?

If devres automatically frees the struct ultrarisc_pcie memory and unmaps
MMIO registers on module unload while the PCI subsystem still retains
pointers to them, could this result in a use-after-free and kernel panic
during subsequent PCI config space accesses?

>  
>  MODULE_DESCRIPTION("UltraRISC DP1000 DWC PCIe host controller");
>  MODULE_LICENSE("GPL");

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260706-ultrarisc-pci-clk-v2-0-2f3fb6fba66b@ultrarisc.com?part=3