Hi Rafael, Stephen, "Rafael J. Wysocki" <rjw@xxxxxxxxxxxxx> wrote on Mon, 03 Dec 2018 23:00:20 +0100: > On Monday, December 3, 2018 4:38:46 PM CET Miquel Raynal wrote: > > Hi Lorenzo, > > > > Lorenzo Pieralisi <lorenzo.pieralisi@xxxxxxx> wrote on Mon, 3 Dec 2018 > > 10:27:08 +0000: > > > > > [+Rafael, Sudeep] > > > > > > On Fri, Nov 23, 2018 at 03:18:24PM +0100, Miquel Raynal wrote: > > > > Add suspend and resume callbacks. The priority of these are > > > > "_noirq()", to workaround early access to the registers done by the > > > > PCI core through the ->read()/->write() callbacks at resume time. > > > > > > > > Signed-off-by: Miquel Raynal <miquel.raynal@xxxxxxxxxxx> > > > > --- > > > > drivers/pci/controller/pci-aardvark.c | 52 +++++++++++++++++++++++++++ > > > > 1 file changed, 52 insertions(+) > > > > > > > > diff --git a/drivers/pci/controller/pci-aardvark.c b/drivers/pci/controller/pci-aardvark.c > > > > index 108b3f15c410..7ecf1ac4036b 100644 > > > > --- a/drivers/pci/controller/pci-aardvark.c > > > > +++ b/drivers/pci/controller/pci-aardvark.c > > > > @@ -1108,6 +1108,55 @@ static int advk_pcie_setup_clk(struct advk_pcie *pcie) > > > > return ret; > > > > } > > > > > > > > +static int __maybe_unused advk_pcie_suspend(struct device *dev) > > > > +{ > > > > + struct advk_pcie *pcie = dev_get_drvdata(dev); > > > > + > > > > + advk_pcie_disable_phy(pcie); > > > > + > > > > + clk_disable_unprepare(pcie->clk); > > > > > > I have noticed it is common practice, still, I would like to check whether > > > it is allowed to call functions that may sleep in a NOIRQ suspend/resume > > > callback ? > > > > You are right this is weird. I double checked and for instance, > > pcie-mediatek.c, pci-tegra.c and pci-imx6.c do the exact same thing. There are > > probably other cases where drivers call functions that may sleep from a NOIRQ > > context. I am interested to know if this is valid and if not, what is the > > alternative? > > > > Yes, it is valid. _noirq means that the high-level action handlers will not be > invoked for interrupts occurring during that period, but that doesn't apply to > timer interrupts. > > IOW, don't expect *your* IRQ handler to be invoked then (if this is not a timer > IRQ), but you can sleep. > > Thanks, > Rafael > Thank you both for the enlightenment. Thanks, Miquèl