Re: [PATCH V2] PCI: rcar: Add the initialization of PCIe link in resume_noirq

[Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>]

On Fri, Mar 08, 2019 at 11:17:38AM -0600, Bjorn Helgaas wrote:

[...]

> > >> +static int rcar_pcie_resume_noirq(struct device *dev)
> > >> +{
> > >> +	struct rcar_pcie *pcie = dev_get_drvdata(dev);
> > >> +
> > >> +	if (rcar_pci_read_reg(pcie, PMSR) &&
> > >> +	    !(rcar_pci_read_reg(pcie, PCIETCTLR) & DL_DOWN))
> > >> +		return 0;
> > >> +
> > >> +	/* Re-establish the PCIe link */
> > >> +	rcar_pci_write_reg(pcie, CFINIT, PCIETCTLR);
> > >> +	return rcar_pcie_wait_for_dl(pcie);
> > >> +}
> > >> +
> > >> +static const struct dev_pm_ops rcar_pcie_pm_ops = {
> > >> +	.resume_noirq = rcar_pcie_resume_noirq,
> > >> +};
> > > 
> > > I think there's the beginning of a convention to use #ifdef
> > > CONFIG_PM_SLEEP around the ops themselves [1].  Otherwise I think
> > > we'll get a warning about unused code when CONFIG_PM_SLEEP is unset.
> > 
> > Only if I used SET_NOIRQ_SYSTEM_SLEEP_PM_OPS() , but I set the
> > resume_noirq directly.
> 
> Fair enough.  I guess in this case if CONFIG_PM_SLEEP is unset, you
> set the pointer, which avoids the "unused function" warning, but we
> just never use that function pointer.
> 
> My intent is to avoid needless differences when possible, so when I
> review things like this I look at how other drivers do things.  It
> looks like all the other controllers use
> SET_NOIRQ_SYSTEM_SLEEP_PM_OPS() or similar:
> 
>   git grep -A3 "static.*dev_pm_ops" drivers/pci/controller
> 
> In the rcar case you only need the resume_fn, not the suspend_fn, so
> SET_NOIRQ_SYSTEM_SLEEP_PM_OPS() does a little more than you need and
> you'd have to pass NULL for suspend_fn.  I didn't check them all
> (suspend_noirq, freeze_noirq, poweroff_noirq), but at least for
> suspend_noirq, all users check for NULL before calling through the
> .suspend_noirq() function pointer, so I think that should be safe.

It is a matter of consistency across drivers, yes, but that's something
I can easily solve with a clean-up patch on top of Marek's one.

I would merge this patch as-is and convert all the drivers to a uniform
convention (which one I shall see).

On a side note, this patch looks like a fix to me (even though it is
not trivial for me to add a sensible Fixes: tag) and should be treated
as such, so it should go in one of the upcoming -rc* (and I float the
idea of sending it to stable kernels on which S2R is basically broken).

Lorenzo