[PATCH] PCI: mediatek: fix W=1 snpringf warnings

[Bjorn Helgaas]

On Mon, Mar 02, 2026 at 05:46:48PM -0800, Ryder Lee wrote:
> Fix the following errors in W=1 builds.
> 
>   $ make W=1 drivers/pci/controller/pcie-mediatek.o
>     CALL    scripts/checksyscalls.sh
>     DESCEND objtool
>     INSTALL libsubcmd_headers
>     CC      drivers/pci/controller/pcie-mediatek.o
>   drivers/pci/controller/pcie-mediatek.c: In function ‘mtk_pcie_parse_port’:
>   drivers/pci/controller/pcie-mediatek.c:963:43: error: ‘%d’ directive output may be truncated writing between 1 and 10 bytes into a region of size 6 [-Werror=format-truncation=]
>     963 |         snprintf(name, sizeof(name), "port%d", slot);
> 	|                                           ^~
>   drivers/pci/controller/pcie-mediatek.c:963:38: note: directive argument in the range [0, 2147483647]
>     963 |         snprintf(name, sizeof(name), "port%d", slot);
> 	|                                      ^~~~~~~~
>   drivers/pci/controller/pcie-mediatek.c:963:9: note: ‘snprintf’ output between 6 and 15 bytes into a destination of size 10
>     963 |         snprintf(name, sizeof(name), "port%d", slot);
> 	|         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ...

> +++ b/drivers/pci/controller/pcie-mediatek.c
> @@ -953,7 +953,7 @@ static int mtk_pcie_parse_port(struct mtk_pcie *pcie,
>  	struct mtk_pcie_port *port;
>  	struct device *dev = pcie->dev;
>  	struct platform_device *pdev = to_platform_device(dev);
> -	char name[10];
> +	char name[20];
>  	int err;

FYI, from internal Sashiko review while backporting this:

[Severity: High]
This is a pre-existing issue, but looking at the error paths around port
parsing, is there a missing IRQ teardown that could lead to a use-after-free
or resource leak?

When mtk_pcie_parse_port() successfully parses a port, mtk_pcie_setup_irq()
allocates an IRQ domain and registers a chained IRQ handler that keeps a
pointer to the port struct.

If a subsequent initialization step fails, such as parsing another port in
mtk_pcie_setup() or pci_host_probe() failing in mtk_pcie_probe(), the probe
function aborts and returns an error:

mtk_pcie_setup() {
    ...
    err = mtk_pcie_parse_port(pcie, child, slot);
    if (err)
        return err;
    ...
}

The error paths, such as the put_resources label in mtk_pcie_probe() which
calls mtk_pcie_put_resources(), will free the memory of the port struct but
fail to unregister the chained IRQ handler or remove the IRQ domain.

Because of this, a freed port pointer remains registered as the handler data.
If the shared interrupt fires, could mtk_pcie_intr_handler() dereference this
freed pointer and crash?

Additionally, if platform_get_irq() fails in mtk_pcie_setup_irq(), it looks
like the function returns an error without destroying the just-created
port->irq_domain:

mtk_pcie_setup_irq() {
    ...
    if (port->irq < 0)
        return port->irq;
    ...
}

Would it be appropriate to add proper teardown functions to these error paths
to unregister the handlers and clean up the domains?