[RFC][PATCH] PCI: rcar-gen4: Add missing PM ops

[RFC][PATCH] PCI: rcar-gen4: Add missing PM ops

[Marek Vasut]

The R-Car Gen4 PCIe controller is part of a power domain. On R-Car S4
and V4H, this is an always-on power domain which is not shut down in
suspend. On R-Car V4M, this is a dedicated A2PCIPHY power domain,
which is shut down during suspend, and the controller loses state,
which prevents the PCIe from working after resume.

Fix this by adding generic suspend/resume noirq ops for the controller,
which tear the link down on suspend, and restart it on resume. Use the
same PM ops on all of R-Car Gen4 to gracefully suspend and resume the
PCIe link on V4H and S4 too.

Test case which demonstrates the problem on R-Car V4M:
"
$ hexdump -vC /sys/bus/pci/devices/0000:00:00.0/config > /tmp/pre
$ echo s2idle > /sys/power/mem_sleep
$ echo platform > /sys/power/pm_test
$ echo mem > /sys/power/state
$ hexdump -vC /sys/bus/pci/devices/0000:00:00.0/config > /tmp/post
$ diff -Naru /tmp/pre /tmp/post
...
-00000000  12 19 32 00 07 05 10 00  00 00 04 06 00 00 01 00
+00000000  12 19 32 00 07 05 10 00  00 00 00 ff 00 00 80 00
                                          ^^^^^
                                    Class 0604->00ff
"

Fixes: 0d0c551011df ("PCI: rcar-gen4: Add R-Car Gen4 PCIe controller support for host mode")
Reported-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: "Krzysztof Wilczyński" <kwilczynski@kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Koichiro Den <den@valinux.co.jp>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
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: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-pci@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
NOTE: Depends on series
      https://lore.kernel.org/linux-pci/20260903205153.283553-1-marek.vasut+renesas@mailbox.org/
NOTE: I am sending this as an RFC, because I would like to get
      a TB from Geert before this might get applied
---
 drivers/pci/controller/dwc/pcie-rcar-gen4.c | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/drivers/pci/controller/dwc/pcie-rcar-gen4.c b/drivers/pci/controller/dwc/pcie-rcar-gen4.c
index 5690dc32f47e0..3bfb2bd53fe3b 100644
--- a/drivers/pci/controller/dwc/pcie-rcar-gen4.c
+++ b/drivers/pci/controller/dwc/pcie-rcar-gen4.c
@@ -909,6 +909,22 @@ static int rcar_gen4_pcie_ltssm_control(struct rcar_gen4_pcie *rcar, bool enable
 	return 0;
 }
 
+static int rcar_gen4_pcie_suspend_noirq(struct device *dev)
+{
+	struct rcar_gen4_pcie *rcar = dev_get_drvdata(dev);
+	struct dw_pcie *dw = &rcar->dw;
+
+	return dw_pcie_suspend_noirq(dw);
+}
+
+static int rcar_gen4_pcie_resume_noirq(struct device *dev)
+{
+	struct rcar_gen4_pcie *rcar = dev_get_drvdata(dev);
+	struct dw_pcie *dw = &rcar->dw;
+
+	return dw_pcie_resume_noirq(dw);
+}
+
 static struct rcar_gen4_pcie_drvdata drvdata_r8a779f0_pcie = {
 	.ltssm_control = r8a779f0_pcie_ltssm_control,
 	.mode = DW_PCIE_RC_TYPE,
@@ -952,10 +968,14 @@ static const struct of_device_id rcar_gen4_pcie_of_match[] = {
 };
 MODULE_DEVICE_TABLE(of, rcar_gen4_pcie_of_match);
 
+DEFINE_NOIRQ_DEV_PM_OPS(rcar_gen4_pcie_pm_ops,
+			rcar_gen4_pcie_suspend_noirq, rcar_gen4_pcie_resume_noirq);
+
 static struct platform_driver rcar_gen4_pcie_driver = {
 	.driver = {
 		.name = "pcie-rcar-gen4",
 		.of_match_table = rcar_gen4_pcie_of_match,
+		.pm = &rcar_gen4_pcie_pm_ops,
 		.probe_type = PROBE_PREFER_ASYNCHRONOUS,
 	},
 	.probe = rcar_gen4_pcie_probe,
-- 
2.53.0

Re: [RFC][PATCH] PCI: rcar-gen4: Add missing PM ops

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Unconditional calls to host-specific suspend/resume functions crash when the controller operates in Endpoint (EP) mode.
- [High] Suspend/resume deadlock and unsafe GFP_KERNEL allocation via request_firmware() in the resume_noirq path.
--

commit 5af3966526dc17abac6d2f1a9c20afb491499031
Author: Marek Vasut <marek.vasut+renesas@mailbox.org>

PCI: rcar-gen4: Add missing PM ops

The commit adds suspend/resume PM ops to fix an issue where the controller
loses state during suspend on R-Car V4M. It registers generic suspend and
resume handlers to gracefully tear down and restart the PCIe link across
all R-Car Gen4 platforms.

> diff --git a/drivers/pci/controller/dwc/pcie-rcar-gen4.c b/drivers/pci/controller/dwc/pcie-rcar-gen4.c
> index fbe465a29068f..8c3e41e9a8ba1 100644
> --- a/drivers/pci/controller/dwc/pcie-rcar-gen4.c
> +++ b/drivers/pci/controller/dwc/pcie-rcar-gen4.c
> @@ -849,6 +849,22 @@ static int rcar_gen4_pcie_ltssm_control(struct rcar_gen4_pcie *rcar, bool enable
>  	return 0;
>  }
>  
> +static int rcar_gen4_pcie_suspend_noirq(struct device *dev)
> +{
> +	struct rcar_gen4_pcie *rcar = dev_get_drvdata(dev);
> +	struct dw_pcie *dw = &rcar->dw;
> +
> +	return dw_pcie_suspend_noirq(dw);

[Severity: High]
Does this crash when the controller operates in Endpoint mode?

Since the driver registers rcar_gen4_pcie_pm_ops for all matched devices,
including those in Endpoint mode (e.g., "renesas,rcar-gen4-pcie-ep"), this
unconditionally routes the suspend operation to the host-specific
dw_pcie_suspend_noirq() without verifying the controller mode.

In Endpoint mode, dw_pcie_host_init() is never called, leaving the Root
Port (pci->pp) structures uninitialized. If dw_pcie_suspend_noirq() is
called in Endpoint mode, it will dereference pci->pp.bridge which is
strictly NULL:

drivers/pci/controller/dwc/pcie-designware-host.c:dw_pcie_suspend_noirq() {
    ...
	if (!pci_host_common_d3cold_possible(pci->pp.bridge, &pme_capable))
		return 0;
    ...
}

It will also dereference pci->pp.ops during the link-down fallback path:

drivers/pci/controller/dwc/pcie-designware-host.c:dw_pcie_suspend_noirq() {
    ...
stop_link:
    ...
	if (pci->pp.ops->deinit)
		pci->pp.ops->deinit(&pci->pp);
    ...
}

> +}
> +
> +static int rcar_gen4_pcie_resume_noirq(struct device *dev)
> +{
> +	struct rcar_gen4_pcie *rcar = dev_get_drvdata(dev);
> +	struct dw_pcie *dw = &rcar->dw;
> +
> +	return dw_pcie_resume_noirq(dw);

[Severity: High]
Can this cause a suspend/resume deadlock due to unsafe GFP_KERNEL allocations?

When dw_pcie_resume_noirq() is called, it restarts the link which
ultimately invokes request_firmware() in the resume_noirq phase:

dw_pcie_resume_noirq()
  dw_pcie_start_link()
    rcar_gen4_pcie_start_link()
      rcar_gen4_pcie_ltssm_control()
        rcar_gen4_pcie_download_phy_firmware()
          request_firmware(&fw, RCAR_GEN4_PCIE_FIRMWARE_NAME, dw->dev);

Executing request_firmware() in a noirq phase is strictly unsafe because
device interrupts (including those for storage controllers) are disabled.
If the firmware is not cached, the request will hang indefinitely waiting
for filesystem I/O that cannot complete without interrupts. Even if
cached, request_firmware() allocates memory using GFP_KERNEL, which can
trigger page reclaim and block on disk I/O, similarly deadlocking the
system.

> +}
> +
>  static struct rcar_gen4_pcie_drvdata drvdata_r8a779f0_pcie = {
>  	.ltssm_control = r8a779f0_pcie_ltssm_control,
>  	.mode = DW_PCIE_RC_TYPE,

[ ... ]

> @@ -892,10 +908,14 @@ static const struct of_device_id rcar_gen4_pcie_of_match[] = {
>  };
>  MODULE_DEVICE_TABLE(of, rcar_gen4_pcie_of_match);
>  
> +DEFINE_NOIRQ_DEV_PM_OPS(rcar_gen4_pcie_pm_ops,
> +			rcar_gen4_pcie_suspend_noirq, rcar_gen4_pcie_resume_noirq);
> +
>  static struct platform_driver rcar_gen4_pcie_driver = {
>  	.driver = {
>  		.name = "pcie-rcar-gen4",
>  		.of_match_table = rcar_gen4_pcie_of_match,
> +		.pm = &rcar_gen4_pcie_pm_ops,
>  		.probe_type = PROBE_PREFER_ASYNCHRONOUS,
>  	},
>  	.probe = rcar_gen4_pcie_probe,

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

Re: [RFC][PATCH] PCI: rcar-gen4: Add missing PM ops

[Geert Uytterhoeven]

Hi Marek,

On Sun, 6 Sept 2026 at 19:32, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> The R-Car Gen4 PCIe controller is part of a power domain. On R-Car S4
> and V4H, this is an always-on power domain which is not shut down in
> suspend. On R-Car V4M, this is a dedicated A2PCIPHY power domain,
> which is shut down during suspend, and the controller loses state,
> which prevents the PCIe from working after resume.
>
> Fix this by adding generic suspend/resume noirq ops for the controller,
> which tear the link down on suspend, and restart it on resume. Use the
> same PM ops on all of R-Car Gen4 to gracefully suspend and resume the
> PCIe link on V4H and S4 too.
>
> Test case which demonstrates the problem on R-Car V4M:
> "
> $ hexdump -vC /sys/bus/pci/devices/0000:00:00.0/config > /tmp/pre
> $ echo s2idle > /sys/power/mem_sleep
> $ echo platform > /sys/power/pm_test
> $ echo mem > /sys/power/state
> $ hexdump -vC /sys/bus/pci/devices/0000:00:00.0/config > /tmp/post
> $ diff -Naru /tmp/pre /tmp/post
> ...
> -00000000  12 19 32 00 07 05 10 00  00 00 04 06 00 00 01 00
> +00000000  12 19 32 00 07 05 10 00  00 00 00 ff 00 00 80 00
>                                           ^^^^^
>                                     Class 0604->00ff
> "
>
> Fixes: 0d0c551011df ("PCI: rcar-gen4: Add R-Car Gen4 PCIe controller support for host mode")
> Reported-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>

Thanks, the output of "lspci -v" is now the same before and after
s2idle.
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>

I don't have a setup for endpoint mode, so I could not verify or refute
Sashiko's claim that suspend will crash in endpoint mode.

> --- a/drivers/pci/controller/dwc/pcie-rcar-gen4.c
> +++ b/drivers/pci/controller/dwc/pcie-rcar-gen4.c

> @@ -952,10 +968,14 @@ static const struct of_device_id rcar_gen4_pcie_of_match[] = {
>  };
>  MODULE_DEVICE_TABLE(of, rcar_gen4_pcie_of_match);
>
> +DEFINE_NOIRQ_DEV_PM_OPS(rcar_gen4_pcie_pm_ops,
> +                       rcar_gen4_pcie_suspend_noirq, rcar_gen4_pcie_resume_noirq);
> +
>  static struct platform_driver rcar_gen4_pcie_driver = {
>         .driver = {
>                 .name = "pcie-rcar-gen4",
>                 .of_match_table = rcar_gen4_pcie_of_match,
> +               .pm = &rcar_gen4_pcie_pm_ops,

pm_sleep_ptr(&rcar_gen4_pcie_pm_ops)

>                 .probe_type = PROBE_PREFER_ASYNCHRONOUS,
>         },
>         .probe = rcar_gen4_pcie_probe,

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [RFC][PATCH] PCI: rcar-gen4: Add missing PM ops

[Marek Vasut]

On 9/7/26 12:26 PM, Geert Uytterhoeven wrote:

Hello Geert,

> On Sun, 6 Sept 2026 at 19:32, Marek Vasut
> <marek.vasut+renesas@mailbox.org> wrote:
>> The R-Car Gen4 PCIe controller is part of a power domain. On R-Car S4
>> and V4H, this is an always-on power domain which is not shut down in
>> suspend. On R-Car V4M, this is a dedicated A2PCIPHY power domain,
>> which is shut down during suspend, and the controller loses state,
>> which prevents the PCIe from working after resume.
>>
>> Fix this by adding generic suspend/resume noirq ops for the controller,
>> which tear the link down on suspend, and restart it on resume. Use the
>> same PM ops on all of R-Car Gen4 to gracefully suspend and resume the
>> PCIe link on V4H and S4 too.
>>
>> Test case which demonstrates the problem on R-Car V4M:
>> "
>> $ hexdump -vC /sys/bus/pci/devices/0000:00:00.0/config > /tmp/pre
>> $ echo s2idle > /sys/power/mem_sleep
>> $ echo platform > /sys/power/pm_test
>> $ echo mem > /sys/power/state
>> $ hexdump -vC /sys/bus/pci/devices/0000:00:00.0/config > /tmp/post
>> $ diff -Naru /tmp/pre /tmp/post
>> ...
>> -00000000  12 19 32 00 07 05 10 00  00 00 04 06 00 00 01 00
>> +00000000  12 19 32 00 07 05 10 00  00 00 00 ff 00 00 80 00
>>                                            ^^^^^
>>                                      Class 0604->00ff
>> "
>>
>> Fixes: 0d0c551011df ("PCI: rcar-gen4: Add R-Car Gen4 PCIe controller support for host mode")
>> Reported-by: Geert Uytterhoeven <geert+renesas@glider.be>
>> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
> 
> Thanks, the output of "lspci -v" is now the same before and after
> s2idle.
> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
> 
> I don't have a setup for endpoint mode, so I could not verify or refute
> Sashiko's claim that suspend will crash in endpoint mode.

Same here (thus far).

>> --- a/drivers/pci/controller/dwc/pcie-rcar-gen4.c
>> +++ b/drivers/pci/controller/dwc/pcie-rcar-gen4.c
> 
>> @@ -952,10 +968,14 @@ static const struct of_device_id rcar_gen4_pcie_of_match[] = {
>>   };
>>   MODULE_DEVICE_TABLE(of, rcar_gen4_pcie_of_match);
>>
>> +DEFINE_NOIRQ_DEV_PM_OPS(rcar_gen4_pcie_pm_ops,
>> +                       rcar_gen4_pcie_suspend_noirq, rcar_gen4_pcie_resume_noirq);
>> +
>>   static struct platform_driver rcar_gen4_pcie_driver = {
>>          .driver = {
>>                  .name = "pcie-rcar-gen4",
>>                  .of_match_table = rcar_gen4_pcie_of_match,
>> +               .pm = &rcar_gen4_pcie_pm_ops,
> 
> pm_sleep_ptr(&rcar_gen4_pcie_pm_ops)
Will do in V2.

Re: [RFC][PATCH] PCI: rcar-gen4: Add missing PM ops

[Koichiro Den]

On Mon, Sep 07, 2026 at 12:26:42PM +0200, Geert Uytterhoeven wrote:
> Hi Marek,
> 
> On Sun, 6 Sept 2026 at 19:32, Marek Vasut
> <marek.vasut+renesas@mailbox.org> wrote:
> > The R-Car Gen4 PCIe controller is part of a power domain. On R-Car S4
> > and V4H, this is an always-on power domain which is not shut down in
> > suspend. On R-Car V4M, this is a dedicated A2PCIPHY power domain,
> > which is shut down during suspend, and the controller loses state,
> > which prevents the PCIe from working after resume.
> >
> > Fix this by adding generic suspend/resume noirq ops for the controller,
> > which tear the link down on suspend, and restart it on resume. Use the
> > same PM ops on all of R-Car Gen4 to gracefully suspend and resume the
> > PCIe link on V4H and S4 too.
> >
> > Test case which demonstrates the problem on R-Car V4M:
> > "
> > $ hexdump -vC /sys/bus/pci/devices/0000:00:00.0/config > /tmp/pre
> > $ echo s2idle > /sys/power/mem_sleep
> > $ echo platform > /sys/power/pm_test
> > $ echo mem > /sys/power/state
> > $ hexdump -vC /sys/bus/pci/devices/0000:00:00.0/config > /tmp/post
> > $ diff -Naru /tmp/pre /tmp/post
> > ...
> > -00000000  12 19 32 00 07 05 10 00  00 00 04 06 00 00 01 00
> > +00000000  12 19 32 00 07 05 10 00  00 00 00 ff 00 00 80 00
> >                                           ^^^^^
> >                                     Class 0604->00ff
> > "
> >
> > Fixes: 0d0c551011df ("PCI: rcar-gen4: Add R-Car Gen4 PCIe controller support for host mode")
> > Reported-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
> 
> Thanks, the output of "lspci -v" is now the same before and after
> s2idle.
> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
> 
> I don't have a setup for endpoint mode, so I could not verify or refute
> Sashiko's claim that suspend will crash in endpoint mode.

Hi Marek, Geert,

I have reproduced the NULL pointer dereference at pci->pp.ops->deinit on R-Car
S4 Spider in EP mode with CONFIG_PCIE_DW_HOST=y.

(I used next-20260904 with this patch and the following fix applied:
 "buffer: fix NULL dereference of bh->b_folio in __bh_submit()")

[  102.467803] PM: suspend entry (s2idle)
[  102.495431] Filesystems sync: 0.027 seconds
[  102.499213] Freezing user space processes
[  102.502243] Freezing user space processes completed (elapsed 0.002 seconds)
[  102.502783] OOM killer disabled.
[  102.503013] Freezing remaining freezable tasks
[  102.505171] Freezing remaining freezable tasks completed (elapsed 0.001 seconds)
[  102.508276] GFP mask restricted
[  102.554124] renesas_eth_sw e6880000.ethernet tsn0: Link is Down
[  102.557676] PM: suspend of devices complete after 49.149 msecs
[  102.558098] PM: start suspend of devices complete after 52.385 msecs
[  102.562380] PM: late suspend of devices complete after 3.853 msecs
[  102.564497] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008
[  102.565156] Mem abort info:
[  102.565344]   ESR = 0x0000000096000004
[  102.565591]   EC = 0x25: DABT (current EL), IL = 32 bits
[  102.565938]   SET = 0, FnV = 0
[  102.566140]   EA = 0, S1PTW = 0
[  102.566347]   FSC = 0x04: level 0 translation fault
[  102.566665] Data abort info:
[  102.566856]   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
[  102.567212]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[  102.567541]   GCS = 0, Overlay = 0, DirtyBit = 0
[  102.567842] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000487961000
[  102.568260] [0000000000000008] pgd=0000000000000000, p4d=0000000000000000
[  102.568747] Internal error: Oops: 0000000096000004 [#1]  SMP
[  102.569124] Modules linked in: sch_fq_codel
[  102.569417] CPU: 1 UID: 0 PID: 1837 Comm: bash Not tainted 7.3.0-rc1-next-20260904-ep-00002-gb46bcc4e34bb #3 PREEMPT
[  102.570107] Hardware name: Renesas Spider CPU and Breakout boards based on r8a779f0 (DT)
[  102.570632] pstate: 40400009 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[  102.571086] pc : dw_pcie_suspend_noirq+0x5c/0x258
[  102.571414] lr : dw_pcie_suspend_noirq+0x58/0x258
[  102.571725] sp : ffff80008504b970
[  102.571944] x29: ffff80008504b9b0 x28: 0000000000000000 x27: ffff800082baccd8
[  102.572416] x26: ffff800082cddcf8 x25: ffff800082bacce8 x24: 0000000000000000
[  102.572887] x23: ffff8000809f3b88 x22: ffff000440377310 x21: ffff800082d0f000
[  102.573358] x20: ffff000440c58410 x19: ffff000442418080 x18: 000000000000000a
[  102.573829] x17: 000000040044ffff x16: 041000f2b5503510 x15: 0000000000000000
[  102.574299] x14: ffff000444ffbda0 x13: 00000000000001e1 x12: 0000000000000000
[  102.574769] x11: 00000000000000c0 x10: 0000000000000af0 x9 : ffff8000808520cc
[  102.575240] x8 : ffff8004397b2000 x7 : 0000000000000eae x6 : 00000000050f95a1
[  102.575710] x5 : 0000000000000eaf x4 : fffffffffffff000 x3 : 0000000000000001
[  102.576180] x2 : 0000000000010000 x1 : 0000000000000000 x0 : 0000000000000000
[  102.576651] Call trace:
[  102.576818]  dw_pcie_suspend_noirq+0x5c/0x258 (P)
[  102.577133]  rcar_gen4_pcie_suspend_noirq+0x18/0x28
[  102.577457]  pm_generic_suspend_noirq+0x30/0x50
[  102.577764]  genpd_finish_suspend+0x48/0x178
[  102.578053]  genpd_suspend_noirq+0x30/0x90
[  102.578326]  dpm_run_callback+0x5c/0x2f8
[  102.578590]  device_suspend_noirq+0x74/0x260
[  102.578874]  dpm_noirq_suspend_devices+0x190/0x2a8
[  102.579192]  dpm_suspend_noirq+0x28/0xa8
[  102.579455]  suspend_devices_and_enter+0x310/0x6e8
[  102.579778]  pm_suspend+0x328/0x3f8
[  102.580012]  state_store+0x84/0x110
[  102.580247]  kobj_attr_store+0x14/0x28
[  102.580504]  sysfs_kf_write+0x80/0xa0
[  102.580758]  kernfs_fop_write_iter+0x12c/0x200
[  102.581055]  vfs_write+0x1f8/0x388
[  102.581289]  ksys_write+0x64/0x108
[  102.581517]  __arm64_sys_write+0x1c/0x38
[  102.581780]  invoke_syscall.constprop.0+0x44/0x110
[  102.582102]  el0_svc_common.constprop.0+0x3c/0xe0
[  102.582415]  do_el0_svc+0x20/0x30
[  102.582640]  el0_svc+0x34/0x1c8
[  102.582855]  el0t_64_sync_handler+0x98/0xe0
[  102.583134]  el0t_64_sync+0x170/0x178
[  102.583388] Code: b4000061 aa1303e0 d63f0020 f9404e60 (f9400401)
[  102.583793] ---[ end trace 0000000000000000 ]---
[  102.584102] Kernel panic - not syncing: Oops: Fatal exception
[  102.584479] SMP: stopping secondary CPUs
[  102.584822] Kernel Offset: disabled
[  102.585052] CPU features: 0x0,40000000,0040002a,01180a42,0800e01b
[  102.585451] Memory Limit: none
[  102.585659] Rebooting in 30 seconds..

    [drivers/pci/controller/dwc/pcie-designware-host.c]
    1225 int dw_pcie_suspend_noirq(struct dw_pcie *pci)
    1226 {
    ...
    1286         pci->pp.skip_pwrctrl_off = pme_capable;
    1287         dw_pcie_stop_link(pci);
  > 1288         if (pci->pp.ops->deinit)
    1289                 pci->pp.ops->deinit(&pci->pp);
    1290

Best regards,
Koichiro

> 
> > --- a/drivers/pci/controller/dwc/pcie-rcar-gen4.c
> > +++ b/drivers/pci/controller/dwc/pcie-rcar-gen4.c
> 
> > @@ -952,10 +968,14 @@ static const struct of_device_id rcar_gen4_pcie_of_match[] = {
> >  };
> >  MODULE_DEVICE_TABLE(of, rcar_gen4_pcie_of_match);
> >
> > +DEFINE_NOIRQ_DEV_PM_OPS(rcar_gen4_pcie_pm_ops,
> > +                       rcar_gen4_pcie_suspend_noirq, rcar_gen4_pcie_resume_noirq);
> > +
> >  static struct platform_driver rcar_gen4_pcie_driver = {
> >         .driver = {
> >                 .name = "pcie-rcar-gen4",
> >                 .of_match_table = rcar_gen4_pcie_of_match,
> > +               .pm = &rcar_gen4_pcie_pm_ops,
> 
> pm_sleep_ptr(&rcar_gen4_pcie_pm_ops)
> 
> >                 .probe_type = PROBE_PREFER_ASYNCHRONOUS,
> >         },
> >         .probe = rcar_gen4_pcie_probe,
> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> -- 
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds

Re: [RFC][PATCH] PCI: rcar-gen4: Add missing PM ops

[Marek Vasut]

On 9/7/26 3:46 PM, Koichiro Den wrote:

Hello Den-san,

> I have reproduced the NULL pointer dereference at pci->pp.ops->deinit on R-Car
> S4 Spider in EP mode with CONFIG_PCIE_DW_HOST=y.
> 
> (I used next-20260904 with this patch and the following fix applied:
>   "buffer: fix NULL dereference of bh->b_folio in __bh_submit()")

[...]

>      [drivers/pci/controller/dwc/pcie-designware-host.c]
>      1225 int dw_pcie_suspend_noirq(struct dw_pcie *pci)
>      1226 {
>      ...
>      1286         pci->pp.skip_pwrctrl_off = pme_capable;
>      1287         dw_pcie_stop_link(pci);
>    > 1288         if (pci->pp.ops->deinit)
>      1289                 pci->pp.ops->deinit(&pci->pp);
>      1290

Thank you for your help with the endpoint part.

The fix turns out to be very simple -- the suspend/resume handling is 
specific to the PCIe controller in RC mode, so I added a conditional to 
invoke those host (RC) suspend/resume operations only if the controller 
is in that mode, and I sent a V2.

This RC-only fix in V2 is also in line with what MX6 and DRA7xx PCIe 
controllers do.

-- 
Best regards,
Marek Vasut