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

[Philipp Zabel]

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.

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?

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.

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.

regards
Philipp