On Sat, Jul 25, 2020 at 01:44:44PM +0300, Andy Shevchenko wrote: > On Sat, Jul 25, 2020 at 1:42 PM Andy Shevchenko > <andy.shevche...@gmail.com> wrote: > > On Sat, Jul 25, 2020 at 1:37 AM Bjorn Helgaas <helg...@kernel.org> wrote: > > > On Fri, Jul 24, 2020 at 11:16:55PM +0300, Andy Shevchenko wrote: > > ... > > > > If it's a bug that spi-topcliff-pch.c disables but never enables > > > wakeup, I think this should turn into two patches: > > > > > > 1) Fix the bug by enabling wakeup in suspend (or whatever the right > > > fix is), and > > > > > > 2) Convert to generic PM, which may involve removing the > > > wakeup-related code completely. > > > > Works for me. > > The only problem here, is that the 2nd is already in the Mark's tree > and he doesn't do rebases. > So, it will be the other way around. > Concluding from yours and Bjorn's suggestion, I will drop the device_wakeup_disable() call form .resume() and send the fix. I will also track the drivers who got similar upgrades and went un-noticed.
As Bjorn mentioned, the problem is that I don't have hardware to test, so I just replicated the legacy behaviour in generic by replacing pci_enable_wake(....,false) with device_wakeup_disable(). So, from now, while upgrading drivers with generic PM, should I completely drop the pci_enable_wake(....,false) calls if both .suspend() and .resume() try to wakeup-disable the device? Thanks Vaibhav Gupta > > -- > With Best Regards, > Andy Shevchenko
