Re: [PATCH v4 2/4] PCI: rzg3s-host: Use shared reset controls for power domain resets

[Lad, Prabhakar]

Hi Philipp,

Thank you for the review.

On Wed, Jun 3, 2026 at 9:16 AM Philipp Zabel <p.zabel@xxxxxxxxxxxxxx> wrote:
>
> On Di, 2026-06-02 at 20:50 +0100, Prabhakar wrote:
> > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@xxxxxxxxxxxxxx>
> >
> > Switch to shared reset controls for PCIe power resets to prepare for
> > RZ/V2H(P) support. On this platform, multiple PCIe controllers share
> > the same reset line, requiring shared ownership of the reset control.
> >
> > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@xxxxxxxxxxxxxx>
> > Reviewed-by: Claudiu Beznea <claudiu.beznea.uj@xxxxxxxxxxxxxx>
> > Tested-by: Claudiu Beznea <claudiu.beznea.uj@xxxxxxxxxxxxxx>
> > ---
> > v3->v4:
> > - Added RB/TB tags.
> >
> > v2->v3:
> > - No change.
> >
> > v1->v2:
> > - Updated commit message.
> > ---
> >  drivers/pci/controller/pcie-rzg3s-host.c | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/pci/controller/pcie-rzg3s-host.c b/drivers/pci/controller/pcie-rzg3s-host.c
> > index d86e7516dcc2..a5192e4b58df 100644
> > --- a/drivers/pci/controller/pcie-rzg3s-host.c
> > +++ b/drivers/pci/controller/pcie-rzg3s-host.c
> > @@ -1276,9 +1276,9 @@ static int rzg3s_pcie_resets_prepare_and_get(struct rzg3s_pcie_host *host)
> >       for (i = 0; i < data->num_cfg_resets; i++)
> >               host->cfg_resets[i].id = data->cfg_resets[i];
> >
> > -     ret = devm_reset_control_bulk_get_exclusive(host->dev,
> > -                                                 data->num_power_resets,
> > -                                                 host->power_resets);
> > +     ret = devm_reset_control_bulk_get_shared(host->dev,
> > +                                              data->num_power_resets,
> > +                                              host->power_resets);
> >       if (ret)
> >               return ret;
> >
>
> I have a few questions about this.
>
> Can you move rzg3s_pcie_resets_prepare_and_get() and
> rzg3s_pcie_power_resets_deassert() up before setting
> RZG3S_SYSC_FUNC_ID_MODE and RZG3S_SYSC_FUNC_ID_RST_RSM_B in
> rzg3s_pcie_probe() without ill effect?
>
> Can you move rzg3s_pcie_power_resets_deassert() up before setting
> RZG3S_SYSC_FUNC_ID_MODE and RZG3S_SYSC_FUNC_ID_RST_RSM_B
> rzg3s_pcie_resume_noirq()?
>
> Those would have the same effect as the reset already being deasserted
> by the other controller.
>
Yes to both. I have reordered the sequences as suggested, and it works
perfectly without any ill effects.

The RZG3S_SYSC_FUNC_ID_MODE and RZG3S_SYSC_FUNC_ID_RST_RSM_B
properties configure registers belonging entirely to the System
Controller (SYSC) block, whereas the power reset "aresetn" belongs
directly to the PCIe 0/1 controllers.

> Is the "power-on" mentioned in the comment about the delay in
> rzg3s_pcie_power_resets_deassert() the same for both controllers or are
> they powered on individually? Specifically, when the first controller
> deasserts the resets during resume, is it guaranteed that the necessary
> delay has also passed for the second controller, which is resumed
> later?
>
Because "aresetn" is shared at the SoC silicon level, whichever
controller finishes its resume routine first handles the physical
de-assertion sequence and absorbs the 5ms fsleep() stabilization
penalty. When the second controller triggers its resume sequence, the
reset framework safely intercepts the request, increments the
deassert_count reference counter.

The delay is the same for both controllers. Since the reset is shared
between the controllers the one which comes up first adheres to the
delay and de-asserts. When the second one comes up it just waits for
the delay, and the de-assert operation doesn't happen (instead, the
counter gets incremented) because the reset is already de-asserted by
the first controller.

> Can the reset_control_bulk_assert(..., host->power_resets) be moved
> down past setting RZG3S_SYSC_FUNC_ID_RST_RSM_B in
> rzg3s_pcie_suspend_noirq() and in the rzg3s_pcie_resume_noirq() error
> path without issue? That would have the same effect as the reset still
> being held deasserted by the other controller.
>
Yes, as mentioned, RZG3S_SYSC_FUNC_ID_RST_RSM_B configures registers
in the system controller.

The only downside is that up until both controllers execute their
suspend routines, the reset line will remain in a de-asserted state.
However, this is expected behavior for a shared reset topology and
ensures neither controller disrupts the operational state of the other
during a power-down sequence.

Logs:
root@rzv2h-evk:~# lspci
0000:00:00.0 PCI bridge: Renesas Technology Corp. Device 003b
0000:01:00.0 Non-Volatile memory controller: YEESTOR Microelectronics
Co., Ltd Device ef25 (rev 01)
0001:00:00.0 PCI bridge: Renesas Technology Corp. Device 003b
0001:01:00.0 Non-Volatile memory controller: MAXIO Technology
(Hangzhou) Ltd. NVMe SSD Controller MAP1202 (DRAM-less) (rev 01)
root@rzv2h-evk:~#
root@rzv2h-evk:~#
root@rzv2h-evk:~#
root@rzv2h-evk:~# echo mem > /sys/power/state
[   56.187674] PM: suspend entry (s2idle)
[   56.192194] Filesystems sync: 0.000 seconds
[   56.203463] Freezing user space processes
[   56.210884] Freezing user space processes completed (elapsed 0.002 seconds)
[   56.217890] OOM killer disabled.
[   56.221149] Freezing remaining freezable tasks
[   56.226901] Freezing remaining freezable tasks completed (elapsed
0.001 seconds)
[   56.234336] printk: Suspending console(s) (use no_console_suspend to debug)
[   56.281005] renesas-gbeth 15c40000.ethernet end1: Link is Down
[   56.281829] renesas-gbeth 15c30000.ethernet end0: Link is Down
[   63.409122] rzg3s-pcie-host 13400000.pcie: PCIe link status [0x110034e]
[   63.700160] rzg3s-pcie-host 13410000.pcie: PCIe link status [0x10030e]
[   63.915436] dwmac4: Master AXI performs fixed burst length
[   63.915549] renesas-gbeth 15c30000.ethernet end0: No Safety
Features support found
[   63.915681] renesas-gbeth 15c30000.ethernet end0: IEEE 1588-2008
Advanced Timestamp supported
[   63.915908] renesas-gbeth 15c30000.ethernet end0: configuring for
phy/rgmii-id link mode
[   63.924556] dwmac4: Master AXI performs fixed burst length
[   63.924659] renesas-gbeth 15c40000.ethernet end1: No Safety
Features support found
[   63.924778] renesas-gbeth 15c40000.ethernet end1: IEEE 1588-2008
Advanced Timestamp supported
[   63.924996] renesas-gbeth 15c40000.ethernet end1: configuring for
phy/rgmii-id link mode
[   63.936404] nvme nvme0: 4/0/0 default/read/poll queues
[   63.936559] nvme nvme1: 4/0/0 default/read/poll queues
[   63.937729] nvme nvme1: Ignoring bogus Namespace Identifiers
[   64.032789] OOM killer enabled.
[   64.036185] Restarting tasks: Starting
[   64.042572] Restarting tasks: Done
[   64.046083] random: crng reseeded on system resumption
[   64.051750] PM: suspend exit
root@rzv2h-evk:~#
root@rzv2h-evk:~# lspci[   66.985040] renesas-gbeth 15c30000.ethernet
end0: Link is Up - 1Gbps/Full - flow control rx/tx
[   66.985076] renesas-gbeth 15c40000.ethernet end1: Link is Up -
1Gbps/Full - flow control rx/tx

0000:00:00.0 PCI bridge: Renesas Technology Corp. Device 003b
0000:01:00.0 Non-Volatile memory controller: YEESTOR Microelectronics
Co., Ltd Device ef25 (rev 01)
0001:00:00.0 PCI bridge: Renesas Technology Corp. Device 003b
0001:01:00.0 Non-Volatile memory controller: MAXIO Technology
(Hangzhou) Ltd. NVMe SSD Controller MAP1202 (DRAM-less) (rev 01)
root@rzv2h-evk:~#

> The power_resets are initially deasserted in rzg3s_pcie_probe(), but
> never asserted in .remove. This unbalances the deassertion counter if
> one controller is unbound and rebound while the other still holds the
> reset requested, which would cause the reset to never be asserted
> during suspend.
>
Since this driver explicitly sets .suppress_bind_attrs = true in its
platform_driver structure, manual unbind and rebind operations are
completely disabled for this controller.

Cheers,
Prabhakar