All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Alok Tiwari <alok.a.tiwari@oracle.com>
Cc: thomas.petazzoni@bootlin.com, pali@kernel.org,
	lpieralisi@kernel.org, kwilczynski@kernel.org, mani@kernel.org,
	robh@kernel.org, bhelgaas@google.com, joyce.ooi@intel.com,
	alyssa@rosenzweig.io, jim2101024@gmail.com,
	florian.fainelli@broadcom.com,
	bcm-kernel-feedback-list@broadcom.com, rjui@broadcom.com,
	sbranden@broadcom.com, ryder.lee@mediatek.com,
	jianjun.wang@mediatek.com, sergio.paracuellos@gmail.com,
	matthias.bgg@gmail.com, angelogioacchino.delregno@collabora.com,
	marek.vasut+renesas@gmail.com, yoshihiro.shimoda.uh@renesas.com,
	geert+renesas@glider.be, magnus.damm@gmail.com,
	shawn.lin@rock-chips.com, heiko@sntech.de, michal.simek@amd.com,
	bharat.kumar.gogada@amd.com, will@kernel.org, kys@microsoft.com,
	haiyangz@microsoft.com, wei.liu@kernel.org, decui@microsoft.com,
	linus.walleij@linaro.org, thierry.reding@gmail.com,
	jonathanh@nvidia.com, rric@kernel.org,
	nirmal.patel@linux.intel.com, toan@os.amperecomputing.com,
	jonathan.derrick@linux.dev, linux-pci@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	linux-rpi-kernel@lists.infradead.org,
	linux-mediatek@lists.infradead.org,
	linux-renesas-soc@vger.kernel.org,
	linux-rockchip@lists.infradead.org, linux-hyperv@vger.kernel.org,
	linux-tegra@vger.kernel.org
Subject: Re: [PATCH RFC] PCI: Convert devm_pci_alloc_host_bridge() users to error-pointer returns
Date: Sun, 21 Sep 2025 18:19:46 +0100	[thread overview]
Message-ID: <87ms6nyb7x.wl-maz@kernel.org> (raw)
In-Reply-To: <20250921161434.1561770-1-alok.a.tiwari@oracle.com>

On Sun, 21 Sep 2025 17:14:07 +0100,
Alok Tiwari <alok.a.tiwari@oracle.com> wrote:
> 
> devm_pci_alloc_host_bridge() and pci_alloc_host_bridge() previously
> returned NULL on failure, forcing callers to special-case NULL handling
> and often hardcode -ENOMEM as the error.
> 
> This series updates devm_pci_alloc_host_bridge() to consistently return
> error pointers (ERR_PTR) with the actual error code, instead of NULL.
> All callers across PCI host controller drivers are updated to use
> IS_ERR_OR_NULL()/PTR_ERR() instead of NULL checks and hardcoded -ENOMEM.
> 
> Benefits:
>   - Standardizes error handling with Linux kernel ERR_PTR()/PTR_ERR()
>     conventions.
>   - Ensures that the actual error code from lower-level helpers is
>     propagated back to the caller.
>   - Removes ambiguity between NULL and error pointer returns.
>
> Touched drivers include:
>  cadence (J721E, cadence-plat)
>  dwc (designware, qcom)
>  mobiveil (layerscape-gen4, mobiveil-plat)
>  aardvark, ftpci100, ixp4xx, loongson, mvebu, rcar, tegra, v3-semi,
>  versatile, xgene, altera, brcmstb, iproc, mediatek, mt7621, xilinx,
>  plda, and others
> 
> This patch updates error handling across these host controller drivers
>  so that callers consistently receive ERR_PTR() instead of NULL.

Not quite.

> diff --git a/arch/mips/pci/pci-xtalk-bridge.c b/arch/mips/pci/pci-xtalk-bridge.c
> index e00c38620d14..c2c8ed8ecac1 100644
> --- a/arch/mips/pci/pci-xtalk-bridge.c
> +++ b/arch/mips/pci/pci-xtalk-bridge.c
> @@ -636,8 +636,8 @@ static int bridge_probe(struct platform_device *pdev)
>  	pci_set_flags(PCI_PROBE_ONLY);
>  
>  	host = devm_pci_alloc_host_bridge(dev, sizeof(*bc));
> -	if (!host) {
> -		err = -ENOMEM;
> +	if (IS_ERR_OR_NULL(host)) {
> +		err = PTR_ERR(host);

Under which circumstances can NULL still be returned? Because applying
PTR_ERR() to a NULL pointer looks like a pretty bad idea.

>  		goto err_remove_domain;
>  	}
>  

[...]

> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index f41128f91ca7..e627f36b7683 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -686,18 +686,18 @@ struct pci_host_bridge *devm_pci_alloc_host_bridge(struct device *dev,
>  
>  	bridge = pci_alloc_host_bridge(priv);
>  	if (!bridge)
> -		return NULL;
> +		return ERR_PTR(-ENOMEM);
>  
>  	bridge->dev.parent = dev;
>  
>  	ret = devm_add_action_or_reset(dev, devm_pci_alloc_host_bridge_release,
>  				       bridge);
>  	if (ret)
> -		return NULL;
> +		return ERR_PTR(ret);
>  
>  	ret = devm_of_pci_bridge_init(dev, bridge);
>  	if (ret)
> -		return NULL;
> +		return ERR_PTR(ret);
>  
>  	return bridge;
>  }
> @@ -3198,7 +3198,7 @@ struct pci_bus *pci_create_root_bus(struct device *parent, int bus,
>  
>  	bridge = pci_alloc_host_bridge(0);
>  	if (!bridge)
> -		return NULL;
> +		return ERR_PTR(-ENOMEM);
>  
>  	bridge->dev.parent = parent;
>  

And what about the code that comes after that if we fail to register
the bus? The remaining "return NULL", which will then be interpreted
as 0 in any user of this function, leading to a worse situation than
what we have now.

Also, things like pci_scan_root_bus() have the following pattern:

	b = pci_create_root_bus(parent, bus, ops, sysdata, resources);
	if (!b)
		return NULL;

which will end with prejudice given what you have introduced.

If you are going to touch this sort of things, at least make it
consistent, analyse *all* code paths, and provide documentation.

	M.

-- 
Jazz isn't dead. It just smells funny.


WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Alok Tiwari <alok.a.tiwari@oracle.com>
Cc: thomas.petazzoni@bootlin.com, pali@kernel.org,
	lpieralisi@kernel.org, kwilczynski@kernel.org, mani@kernel.org,
	robh@kernel.org, bhelgaas@google.com, joyce.ooi@intel.com,
	alyssa@rosenzweig.io, jim2101024@gmail.com,
	florian.fainelli@broadcom.com,
	bcm-kernel-feedback-list@broadcom.com, rjui@broadcom.com,
	sbranden@broadcom.com, ryder.lee@mediatek.com,
	jianjun.wang@mediatek.com, sergio.paracuellos@gmail.com,
	matthias.bgg@gmail.com, angelogioacchino.delregno@collabora.com,
	marek.vasut+renesas@gmail.com, yoshihiro.shimoda.uh@renesas.com,
	geert+renesas@glider.be, magnus.damm@gmail.com,
	shawn.lin@rock-chips.com, heiko@sntech.de, michal.simek@amd.com,
	bharat.kumar.gogada@amd.com, will@kernel.org, kys@microsoft.com,
	haiyangz@microsoft.com, wei.liu@kernel.org, decui@microsoft.com,
	linus.walleij@linaro.org, thierry.reding@gmail.com,
	jonathanh@nvidia.com, rric@kernel.org,
	nirmal.patel@linux.intel.com, toan@os.amperecomputing.com,
	jonathan.derrick@linux.dev, linux-pci@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	linux-rpi-kernel@lists.infradead.org,
	linux-mediatek@lists.infradead.org,
	linux-renesas-soc@vger.kernel.org,
	linux-rockchip@lists.infradead.org, linux-hyperv@vger.kernel.org,
	linux-tegra@vger.kernel.org
Subject: Re: [PATCH RFC] PCI: Convert devm_pci_alloc_host_bridge() users to error-pointer returns
Date: Sun, 21 Sep 2025 18:19:46 +0100	[thread overview]
Message-ID: <87ms6nyb7x.wl-maz@kernel.org> (raw)
In-Reply-To: <20250921161434.1561770-1-alok.a.tiwari@oracle.com>

On Sun, 21 Sep 2025 17:14:07 +0100,
Alok Tiwari <alok.a.tiwari@oracle.com> wrote:
> 
> devm_pci_alloc_host_bridge() and pci_alloc_host_bridge() previously
> returned NULL on failure, forcing callers to special-case NULL handling
> and often hardcode -ENOMEM as the error.
> 
> This series updates devm_pci_alloc_host_bridge() to consistently return
> error pointers (ERR_PTR) with the actual error code, instead of NULL.
> All callers across PCI host controller drivers are updated to use
> IS_ERR_OR_NULL()/PTR_ERR() instead of NULL checks and hardcoded -ENOMEM.
> 
> Benefits:
>   - Standardizes error handling with Linux kernel ERR_PTR()/PTR_ERR()
>     conventions.
>   - Ensures that the actual error code from lower-level helpers is
>     propagated back to the caller.
>   - Removes ambiguity between NULL and error pointer returns.
>
> Touched drivers include:
>  cadence (J721E, cadence-plat)
>  dwc (designware, qcom)
>  mobiveil (layerscape-gen4, mobiveil-plat)
>  aardvark, ftpci100, ixp4xx, loongson, mvebu, rcar, tegra, v3-semi,
>  versatile, xgene, altera, brcmstb, iproc, mediatek, mt7621, xilinx,
>  plda, and others
> 
> This patch updates error handling across these host controller drivers
>  so that callers consistently receive ERR_PTR() instead of NULL.

Not quite.

> diff --git a/arch/mips/pci/pci-xtalk-bridge.c b/arch/mips/pci/pci-xtalk-bridge.c
> index e00c38620d14..c2c8ed8ecac1 100644
> --- a/arch/mips/pci/pci-xtalk-bridge.c
> +++ b/arch/mips/pci/pci-xtalk-bridge.c
> @@ -636,8 +636,8 @@ static int bridge_probe(struct platform_device *pdev)
>  	pci_set_flags(PCI_PROBE_ONLY);
>  
>  	host = devm_pci_alloc_host_bridge(dev, sizeof(*bc));
> -	if (!host) {
> -		err = -ENOMEM;
> +	if (IS_ERR_OR_NULL(host)) {
> +		err = PTR_ERR(host);

Under which circumstances can NULL still be returned? Because applying
PTR_ERR() to a NULL pointer looks like a pretty bad idea.

>  		goto err_remove_domain;
>  	}
>  

[...]

> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index f41128f91ca7..e627f36b7683 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -686,18 +686,18 @@ struct pci_host_bridge *devm_pci_alloc_host_bridge(struct device *dev,
>  
>  	bridge = pci_alloc_host_bridge(priv);
>  	if (!bridge)
> -		return NULL;
> +		return ERR_PTR(-ENOMEM);
>  
>  	bridge->dev.parent = dev;
>  
>  	ret = devm_add_action_or_reset(dev, devm_pci_alloc_host_bridge_release,
>  				       bridge);
>  	if (ret)
> -		return NULL;
> +		return ERR_PTR(ret);
>  
>  	ret = devm_of_pci_bridge_init(dev, bridge);
>  	if (ret)
> -		return NULL;
> +		return ERR_PTR(ret);
>  
>  	return bridge;
>  }
> @@ -3198,7 +3198,7 @@ struct pci_bus *pci_create_root_bus(struct device *parent, int bus,
>  
>  	bridge = pci_alloc_host_bridge(0);
>  	if (!bridge)
> -		return NULL;
> +		return ERR_PTR(-ENOMEM);
>  
>  	bridge->dev.parent = parent;
>  

And what about the code that comes after that if we fail to register
the bus? The remaining "return NULL", which will then be interpreted
as 0 in any user of this function, leading to a worse situation than
what we have now.

Also, things like pci_scan_root_bus() have the following pattern:

	b = pci_create_root_bus(parent, bus, ops, sysdata, resources);
	if (!b)
		return NULL;

which will end with prejudice given what you have introduced.

If you are going to touch this sort of things, at least make it
consistent, analyse *all* code paths, and provide documentation.

	M.

-- 
Jazz isn't dead. It just smells funny.

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

  reply	other threads:[~2025-09-21 17:20 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-21 16:14 [PATCH RFC] PCI: Convert devm_pci_alloc_host_bridge() users to error-pointer returns Alok Tiwari
2025-09-21 16:14 ` Alok Tiwari
2025-09-21 17:19 ` Marc Zyngier [this message]
2025-09-21 17:19   ` Marc Zyngier
2025-09-21 19:50 ` kernel test robot
2025-09-22 10:55 ` AngeloGioacchino Del Regno
2025-09-22 10:55   ` AngeloGioacchino Del Regno

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ms6nyb7x.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=alok.a.tiwari@oracle.com \
    --cc=alyssa@rosenzweig.io \
    --cc=angelogioacchino.delregno@collabora.com \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=bharat.kumar.gogada@amd.com \
    --cc=bhelgaas@google.com \
    --cc=decui@microsoft.com \
    --cc=florian.fainelli@broadcom.com \
    --cc=geert+renesas@glider.be \
    --cc=haiyangz@microsoft.com \
    --cc=heiko@sntech.de \
    --cc=jianjun.wang@mediatek.com \
    --cc=jim2101024@gmail.com \
    --cc=jonathan.derrick@linux.dev \
    --cc=jonathanh@nvidia.com \
    --cc=joyce.ooi@intel.com \
    --cc=kwilczynski@kernel.org \
    --cc=kys@microsoft.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-hyperv@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=linux-rpi-kernel@lists.infradead.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=lpieralisi@kernel.org \
    --cc=magnus.damm@gmail.com \
    --cc=mani@kernel.org \
    --cc=marek.vasut+renesas@gmail.com \
    --cc=matthias.bgg@gmail.com \
    --cc=michal.simek@amd.com \
    --cc=nirmal.patel@linux.intel.com \
    --cc=pali@kernel.org \
    --cc=rjui@broadcom.com \
    --cc=robh@kernel.org \
    --cc=rric@kernel.org \
    --cc=ryder.lee@mediatek.com \
    --cc=sbranden@broadcom.com \
    --cc=sergio.paracuellos@gmail.com \
    --cc=shawn.lin@rock-chips.com \
    --cc=thierry.reding@gmail.com \
    --cc=thomas.petazzoni@bootlin.com \
    --cc=toan@os.amperecomputing.com \
    --cc=wei.liu@kernel.org \
    --cc=will@kernel.org \
    --cc=yoshihiro.shimoda.uh@renesas.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.