All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Koichiro Den" <den@valinux.co.jp>
Cc: linux-pci@vger.kernel.org, devicetree@vger.kernel.org,
	robh@kernel.org, conor+dt@kernel.org,
	wsa+renesas@sang-engineering.com
Subject: Re: [PATCH v4 09/18] PCI: rcar-gen4: Add Root Port reset support
Date: Thu, 15 Oct 2026 03:44:55 +0000	[thread overview]
Message-ID: <sashiko-outbox-172223@kernel.org> (raw)
In-Reply-To: <20261015033103.3076869-10-den@valinux.co.jp>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] pci: rcar-gen4: PHY power leak on speed_control() failure
- [Medium] pci: rcar-gen4: memory leak of device_node refcount from of_msi_xlate
--

commit 50f3fefd40d6567632993d0a3d1141361fef7262
Author: Koichiro Den <den@valinux.co.jp>

PCI: rcar-gen4: Add Root Port reset support

Implement the host bridge reset_root_port() callback so PCI error
recovery can reset and reinitialize the R-Car controller. This also
provides the reset operation for the link-down handling added later.

> diff --git a/drivers/pci/controller/dwc/pcie-rcar-gen4.c b/drivers/pci/controller/dwc/pcie-rcar-gen4.c
> index cbd22e6bb44b9..54260e62293b1 100644
> --- a/drivers/pci/controller/dwc/pcie-rcar-gen4.c
> +++ b/drivers/pci/controller/dwc/pcie-rcar-gen4.c

[ ... ]

> @@ -661,14 +704,87 @@ static int rcar_gen4_pcie_host_setup(struct dw_pcie_rp *pp)
>  	return 0;
>  }
>  
> +static void rcar_gen4_pcie_quiesce_irqs(struct rcar_gen4_pcie *rcar)
> +{
> +	scoped_guard(raw_spinlock_irqsave, &rcar->app_lock) {
> +		rcar->reinit_pending = true;
> +		rcar_gen4_pcie_app_irq_sync_locked(rcar);
> +	}
> +}
> +
> +static void rcar_gen4_pcie_resume_irqs(struct rcar_gen4_pcie *rcar,
> +				       bool recovered)
> +{
> +	scoped_guard(raw_spinlock_irqsave, &rcar->app_lock) {
> +		rcar->reinit_pending = !recovered;
> +		rcar_gen4_pcie_app_irq_sync_locked(rcar);
> +	}
> +}
> +
> +/*
> + * R-Car Gen4 SoC PCIe controllers and R-Car Gen5 SoC PCIe4 controller have
> + * a single Root Port per instance, so the pci_dev is ignored and the whole
> + * controller is reset. The PCI core serializes the callers through its
> + * device locks.
> + */
> +static int rcar_gen4_pcie_reset_root_port(struct pci_host_bridge *bridge,
> +					  struct pci_dev *pdev)
> +{
> +	struct rcar_gen4_pcie *rcar = dev_get_drvdata(bridge->dev.parent);
> +	struct dw_pcie *dw = &rcar->dw;
> +	struct dw_pcie_rp *pp = &dw->pp;
> +	struct device *dev = dw->dev;
> +	int ret;
> +
> +	/* A failed resume may have left the controller powered down. */
> +	if (dw->suspended)
> +		return -EBUSY;
> +
> +	rcar_gen4_pcie_quiesce_irqs(rcar);
> +
> +	dw_pcie_stop_link(dw);
> +
> +	rcar_gen4_pcie_host_perst_assert(pp, true);
> +
> +	ret = rcar_gen4_pcie_common_reinit(rcar);
> +	if (ret)
> +		goto out;
> +
> +	ret = rcar_gen4_pcie_host_setup(pp);
> +	if (ret)
> +		goto out;

[Severity: Medium]
Does calling rcar_gen4_pcie_host_setup() on every Root Port reset lead to
a device_node refcount leak?

rcar_gen4_pcie_host_setup() calls rcar_gen4_pcie_host_msi_init(), which
calls rcar_gen4_pcie_host_msi_addr(). Inside rcar_gen4_pcie_host_msi_addr():

drivers/pci/controller/dwc/pcie-rcar-gen4.c:rcar_gen4_pcie_host_msi_addr() {
    ...
    of_msi_xlate(dev, &msi_node, 0);
    if (!msi_node)
        return -ENODEV;

    if (!of_device_is_compatible(msi_node, "arm,gic-v3-its"))
        return dev_err_probe(...);
    ...
}

of_msi_xlate() internally acquires a reference to the matched device node,
which requires the caller to release it using of_node_put(). Since
rcar_gen4_pcie_host_msi_addr() does not appear to release this reference,
won't this leak a kobject reference dynamically on every reset event?

> +
> +	ret = dw_pcie_setup_rc(pp);
> +	if (ret)
> +		goto out;
> +
> +	ret = dw_pcie_start_link(dw);
> +	if (ret)
> +		goto out;

[Severity: Medium]
If dw_pcie_start_link() fails, can this leave the PHY permanently powered
on?

It looks like rcar_gen4_pcie_start_link() powers on the PHY via
ltssm_control(..., true) before calling speed_control(). For Gen5 devices,
rcar_gen5_pcie_speed_control() can fail. If this occurs, the error is
returned without calling ltssm_control(..., false).

When dw_pcie_start_link() returns an error here, the code jumps to out:
which skips dw_pcie_stop_link(), leaving the PHY powered on. Is there
a missing power off in this error path?

> +
> +	/* Ignore errors, the link may come up later */
> +	dw_pcie_wait_for_link(dw);
> +	dev_dbg(dev, "Root Port reset completed\n");
> +
> +out:
> +	rcar_gen4_pcie_resume_irqs(rcar, !ret);
> +	if (ret)
> +		dev_err(dev, "Root Port reset failed (%d); interrupts stay masked until a reset succeeds\n",
> +			ret);
> +
> +	return ret;
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261015033103.3076869-1-den@valinux.co.jp?part=9

  reply	other threads:[~2026-10-15  3:44 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-15  3:30 [PATCH v4 00/18] PCI: rcar-gen4: Recover from link down and route Root Port interrupts Koichiro Den
2026-10-15  3:30 ` [PATCH v4 01/18] PCI: dwc: Add Renesas to the RAS DES VSEC list Koichiro Den
2026-10-15  3:36   ` sashiko-bot
2026-10-15  3:30 ` [PATCH v4 02/18] PCI: dwc: Factor out the PORT_LINK_DEBUG1 link-up check Koichiro Den
2026-10-15  3:34   ` sashiko-bot
2026-10-15  3:48   ` Shawn Lin
2026-10-15  3:30 ` [PATCH v4 03/18] PCI: rcar-gen4: Check live link status in link_up() Koichiro Den
2026-10-15  3:39   ` sashiko-bot
2026-10-15  3:30 ` [PATCH v4 04/18] dt-bindings: PCI: rcar-gen4: Add optional "aer" interrupt for R-Car Gen4 SoCs Koichiro Den
2026-10-15  3:37   ` sashiko-bot
2026-10-15  3:30 ` [PATCH v4 05/18] PCI: dwc: Export dw_handle_msi_irq() Koichiro Den
2026-10-15  3:37   ` sashiko-bot
2026-10-15  3:49   ` Shawn Lin
2026-10-15  3:30 ` [PATCH v4 06/18] PCI: rcar-gen4: Move deinitialization helpers before SoC initialization Koichiro Den
2026-10-15  3:37   ` sashiko-bot
2026-10-15  3:30 ` [PATCH v4 07/18] PCI: rcar-gen4: Assert resets when Gen5 SoC PHY initialization fails Koichiro Den
2026-10-15  3:38   ` sashiko-bot
2026-10-15  3:30 ` [PATCH v4 08/18] PCI: rcar-gen4: Separate hardware setup from resource acquisition Koichiro Den
2026-10-15  3:37   ` sashiko-bot
2026-10-15  3:30 ` [PATCH v4 09/18] PCI: rcar-gen4: Add Root Port reset support Koichiro Den
2026-10-15  3:44   ` sashiko-bot [this message]
2026-10-15  3:30 ` [PATCH v4 10/18] PCI: dwc: Free the MSI domain after the host .deinit() callback Koichiro Den
2026-10-15  3:44   ` sashiko-bot
2026-10-15  3:30 ` [PATCH v4 11/18] PCI: rcar-gen4: Take over the iMSI-RX interrupt Koichiro Den
2026-10-15  3:43   ` sashiko-bot
2026-10-15  3:30 ` [PATCH v4 12/18] PCI: rcar-gen4: Recover the Root Port on link down Koichiro Den
2026-10-15  3:41   ` sashiko-bot
2026-10-15  3:30 ` [PATCH v4 13/18] PCI: dwc: Let glue drivers hide the Root Port MSI capabilities Koichiro Den
2026-10-15  3:37   ` sashiko-bot
2026-10-15  4:11   ` Shawn Lin
2026-10-15  7:17     ` Koichiro Den
2026-10-15  3:30 ` [PATCH v4 14/18] PCI: rcar-gen4: Route Root Port AER to a virtual Root Port IRQ Koichiro Den
2026-10-15  3:42   ` sashiko-bot
2026-10-15  3:31 ` [PATCH v4 15/18] PCI: rcar-gen4: Route Root Port PME and bandwidth notifications Koichiro Den
2026-10-15  3:44   ` sashiko-bot
2026-10-15  3:31 ` [PATCH v4 16/18] arm64: dts: renesas: r8a779f0: Describe the PCIe AER interrupts Koichiro Den
2026-10-15  3:40   ` sashiko-bot
2026-10-15  3:31 ` [PATCH v4 17/18] arm64: dts: renesas: r8a779g0: " Koichiro Den
2026-10-15  3:43   ` sashiko-bot
2026-10-15  3:31 ` [PATCH v4 18/18] arm64: dts: renesas: r8a779h0: Describe the PCIe AER interrupt Koichiro Den
2026-10-15  3:41   ` sashiko-bot

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=sashiko-outbox-172223@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=den@valinux.co.jp \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=wsa+renesas@sang-engineering.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.