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
