Re: [PATCH 05/11] PCI: rcar-gen4: Split reusable hardware initialization

[Koichiro Den]

On Tue, Sep 22, 2026 at 11:15:48PM +0200, Marek Vasut wrote:
> On 9/18/26 5:20 AM, Koichiro Den wrote:
> 
> [...]
> 
> > +++ b/drivers/pci/controller/dwc/pcie-rcar-gen4.c
> > @@ -178,23 +178,18 @@ static int rcar_gen4_pcie_common_init(struct rcar_gen4_pcie *rcar)
> >   	u32 val;
> >   	int ret;
> > -	ret = clk_bulk_prepare_enable(DW_PCIE_NUM_CORE_CLKS, dw->core_clks);
> > -	if (ret) {
> > -		dev_err(dw->dev, "Enabling core clocks failed\n");
> > +	ret = reset_control_assert(dw->core_rsts[DW_PCIE_PWR_RST].rstc);
> > +	if (ret)
> >   		return ret;
> > -	}
> > -	if (!reset_control_status(dw->core_rsts[DW_PCIE_PWR_RST].rstc)) {
> > -		reset_control_assert(dw->core_rsts[DW_PCIE_PWR_RST].rstc);
> > -		/*
> > -		 * R-Car V4H Reference Manual R19UH0186EJ0130 Rev.1.30 Apr.
> > -		 * 21, 2025 page 585 Figure 9.3.2 Software Reset flow (B)
> > -		 * indicates that for peripherals in HSC domain, after
> > -		 * reset has been asserted by writing a matching reset bit
> > -		 * into register SRCR, it is mandatory to wait 1ms.
> > -		 */
> > -		fsleep(1000);
> > -	}
> > +	/*
> > +	 * R-Car V4H Reference Manual R19UH0186EJ0130 Rev.1.30 Apr.
> > +	 * 21, 2025 page 585 Figure 9.3.2 Software Reset flow (B)
> > +	 * indicates that for peripherals in HSC domain, after
> > +	 * reset has been asserted by writing a matching reset bit
> > +	 * into register SRCR, it is mandatory to wait 1ms.
> > +	 */
> > +	fsleep(1000);
> 
> This fsleep here should only happen if the reset wasn't asserted before.
> Is removal of reset_control_status() correct ?

You're right. Looking at the code again, adding the recovery path doesn't at all
justify removing the reset_control_status() check. I'll fix it and restore that
condition.

Thanks for the review!

Best regards,
Koichiro

> 
> >   	val = readl(rcar->base + PCIEMSR0);
> >   	if (rcar->drvdata->mode == DW_PCIE_RC_TYPE) {
> [...]