Re: [PATCH v2] PCI: rcar-gen4: Isolate driver to ARM64

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [Medium] Unjustified COMPILE_TEST restriction due to incorrect commit message claim.

Pre-existing issues:
- [High] Missing return in error handling path leads to endpoint notification on a de-initialized endpoint.
--

--- Patch [1]: [PATCH v2] PCI: rcar-gen4: Isolate driver to ARM64 ---
commit 9fa6f24cbaf3124b832a16ce500ea61d355eb4f5
Author: Marek Vasut <marek.vasut+renesas@mailbox.org>

PCI: rcar-gen4: Isolate driver to ARM64

The driver includes linux/irqchip/arm-gic-v3.h which pulls in headers
which are available only on ARM and ARM64, on other architectures the
headers are not present and the driver fails to build. This driver is
used only on ARM64 hardware, isolate its build only to ARM64 to avoid
build failures on other architectures.

Link: https://lore.kernel.org/oe-kbuild-all/202607100310.iQw5m9Uo-lkp@intel.com/

> The driver includes linux/irqchip/arm-gic-v3.h which pulls in headers
> which are available only on ARM and ARM64, on other architectures the
> headers are not present and the driver fails to build.

[Severity: Medium]
Is this description accurate for the current tree?

A review of drivers/pci/controller/dwc/pcie-rcar-gen4.c confirms it does not
actually include linux/irqchip/arm-gic-v3.h or use GIC-specific macros. Does
restricting COMPILE_TEST strictly to ARM64 needlessly degrade cross-architecture
build testing coverage?

> diff --git a/drivers/pci/controller/dwc/Kconfig b/drivers/pci/controller/dwc/Kconfig
> index aa0b784c85b47..0d4bf8d4cf565 100644
> --- a/drivers/pci/controller/dwc/Kconfig
> +++ b/drivers/pci/controller/dwc/Kconfig
> @@ -344,7 +344,7 @@ config PCIE_RCAR_GEN4
>  
>  config PCIE_RCAR_GEN4_HOST
>  	tristate "Renesas R-Car Gen4 PCIe controller (host mode)"
> -	depends on ARCH_RENESAS || COMPILE_TEST
> +	depends on ARM64 && (ARCH_RENESAS || COMPILE_TEST)
>  	depends on PCI_MSI
>  	select PCIE_DW_HOST
>  	select PCIE_RCAR_GEN4
> @@ -355,7 +355,7 @@ config PCIE_RCAR_GEN4_HOST
>  
>  config PCIE_RCAR_GEN4_EP
>  	tristate "Renesas R-Car Gen4 PCIe controller (endpoint mode)"
> -	depends on ARCH_RENESAS || COMPILE_TEST
> +	depends on ARM64 && (ARCH_RENESAS || COMPILE_TEST)
>  	depends on PCI_ENDPOINT
>  	select PCIE_DW_EP
>  	select PCIE_RCAR_GEN4

[Severity: High]
This isn't a bug introduced by this patch, but is it intentional that the error
path in rcar_gen4_add_dw_pcie_ep() falls through without returning?

drivers/pci/controller/dwc/pcie-rcar-gen4.c:rcar_gen4_add_dw_pcie_ep() {
    ...
	ret = dw_pcie_ep_init_registers(ep);
	if (ret) {
		dev_err(dev, "Failed to initialize DWC endpoint registers\n");
		dw_pcie_ep_deinit(ep);
		rcar_gen4_pcie_ep_deinit(rcar);
	}

	pci_epc_init_notify(ep->epc);
    ...
}

If dw_pcie_ep_init_registers() fails, execution incorrectly falls through to
pci_epc_init_notify(), notifying any bound EPF devices that the endpoint is
ready. Since the hardware has just been de-initialized, could an EPF driver
attempting to interact with the EPC cause bus faults or use-after-free
conditions?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260714131957.38067-1-marek.vasut+renesas@mailbox.org?part=1