From: Bjorn Helgaas <helgaas@kernel.org>
To: Marek Vasut <marek.vasut+renesas@mailbox.org>
Cc: linux-pci@vger.kernel.org,
"Krzysztof Wilczyński" <kwilczynski@kernel.org>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Geert Uytterhoeven" <geert+renesas@glider.be>,
"Lad Prabhakar" <prabhakar.mahadev-lad.rj@bp.renesas.com>,
"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
"Magnus Damm" <magnus.damm@gmail.com>,
"Manivannan Sadhasivam" <mani@kernel.org>,
"Rob Herring" <robh@kernel.org>,
"Yoshihiro Shimoda" <yoshihiro.shimoda.uh@renesas.com>,
linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org
Subject: Re: [PATCH] PCI: rcar-host: Validate IO/MEM resource count in DT ranges property
Date: Mon, 5 Oct 2026 18:37:58 -0500 [thread overview]
Message-ID: <20261005233758.GA646371@bhelgaas> (raw)
In-Reply-To: <20261003073701.354551-1-marek.vasut+renesas@mailbox.org>
On Sat, Oct 03, 2026 at 09:35:59AM +0200, Marek Vasut wrote:
> The R-Car Gen3 PCIEC controller supports up to 4 memory area mappings.
> Count the IO and MEM ranges described in DT 'ranges' property of the
> controller DT node, and in case there are more than 4, refuse to probe
> the controller driver, because such DT does not describe valid hardware
> configuration. Do the IO and MEM counting early to avoid controller
> configuration rollback in case of failure.
>
> Fixes: 5d2917d469fa ("PCI: rcar: Convert to DT resource parsing API")
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
> ---
> Cc: "Krzysztof Wilczyński" <kwilczynski@kernel.org>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> Cc: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Cc: Lorenzo Pieralisi <lpieralisi@kernel.org>
> Cc: Magnus Damm <magnus.damm@gmail.com>
> Cc: Manivannan Sadhasivam <mani@kernel.org>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-pci@vger.kernel.org
> Cc: linux-renesas-soc@vger.kernel.org
> ---
> drivers/pci/controller/pcie-rcar-host.c | 31 +++++++++++++++++++++++++
> 1 file changed, 31 insertions(+)
>
> diff --git a/drivers/pci/controller/pcie-rcar-host.c b/drivers/pci/controller/pcie-rcar-host.c
> index cd9171eebc289..4bcc8c3051ac4 100644
> --- a/drivers/pci/controller/pcie-rcar-host.c
> +++ b/drivers/pci/controller/pcie-rcar-host.c
> @@ -341,6 +341,32 @@ static void rcar_pcie_force_speedup(struct rcar_pcie *pcie)
> (macsr & LINK_SPEED) == LINK_SPEED_5_0GTS ? "5" : "2.5");
> }
>
> +static int rcar_pcie_validate_resource_count(struct rcar_pcie_host *host)
> +{
> + struct pci_host_bridge *bridge = pci_host_bridge_from_priv(host);
> + struct rcar_pcie *pcie = &host->pcie;
> + struct resource_entry *win;
> + int i = 0;
> +
> + resource_list_for_each_entry(win, &bridge->windows) {
> + struct resource *res = win->res;
> + unsigned long type = resource_type(res);
> +
> + if (!res->flags)
> + continue;
> +
> + if (type == IORESOURCE_IO || type == IORESOURCE_MEM)
> + i++;
> +
> + if (i > RCAR_PCI_MAX_RESOURCES)
> + return dev_err_probe(pcie->dev, -ENOSPC,
> + "Too many IO/MEM entries in DT 'ranges' property, limit is %d\n",
> + RCAR_PCI_MAX_RESOURCES);
> + }
> +
> + return 0;
> +}
> +
> static void rcar_pcie_hw_enable(struct rcar_pcie_host *host)
> {
> struct rcar_pcie *pcie = &host->pcie;
> @@ -947,6 +973,11 @@ static int rcar_pcie_probe(struct platform_device *pdev)
> host = pci_host_bridge_priv(bridge);
> pcie = &host->pcie;
> pcie->dev = dev;
> +
> + err = rcar_pcie_validate_resource_count(host);
> + if (err)
> + return err;
I guess you did this here to avoid rolling back controller config, but
the code would be a lot more readable if it checked the index at the
point where it might exceed the array bound, e.g., (I think) in
rcar_pcie_set_outbound().
This is for an invalid DT, which is unlikely. What if
rcar_pcie_set_outbound() just printed a warning and ignored any excess
windows?
> platform_set_drvdata(pdev, host);
>
> for (i = 0; i < ARRAY_SIZE(rcar_pcie_supplies); i++) {
> --
> 2.53.0
>
prev parent reply other threads:[~2026-10-05 23:37 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-03 7:35 [PATCH] PCI: rcar-host: Validate IO/MEM resource count in DT ranges property Marek Vasut
2026-10-03 7:42 ` sashiko-bot
2026-10-05 23:37 ` Bjorn Helgaas [this message]
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=20261005233758.GA646371@bhelgaas \
--to=helgaas@kernel.org \
--cc=bhelgaas@google.com \
--cc=geert+renesas@glider.be \
--cc=kwilczynski@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=magnus.damm@gmail.com \
--cc=mani@kernel.org \
--cc=marek.vasut+renesas@mailbox.org \
--cc=prabhakar.mahadev-lad.rj@bp.renesas.com \
--cc=robh@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.