On Thu, Dec 13, 2018 at 03:30:00PM +0100, Miquel Raynal wrote: > Hi Lorenzo, > > > > If that's really the case, then I can see how one device and it's > > > children are suspended and the irq for it is disabled but the providing > > > devices (clk, regulator, bus controller, etc.) are still fully active > > > and not suspended but in fact completely usable and able to service > > > interrupts. If that all makes sense, then I would answer the question > > > with a definitive "yes it's all fine" because the clk consumer could be > > > in the NOIRQ phase of its suspend but the clk provider wouldn't have > > > even started suspending yet when clk_disable_unprepare() is called. > > > > That's a very good summary and address my concern, I still question this > > patch correctness (and many others that carry out clk operations in S2R > > NOIRQ phase), they may work but do not tell me they are rock solid given > > your accurate summary above. > > I understand your concern but I don't see any alternative right now > and a deep rework of the PM core to respect such dependency is not > something that can be done in a reasonable amount of time. With > regard to this constraint, do you think it is worth blocking the > series? I think we agree that, depending on what HW/SW driver manage this PCI controller clocks, this driver may well become broken, the driver itself has no idea what's behind the clock API and can end up waiting for an event forever. This does not leave me in a comfortable position to merge code that I know has flaws. I won't merge it for v4.21, I need more time (and feedback) to understand what can be done to make this driver (and many others) more robust. Thanks, Lorenzo
