Re: REGRESSION - System does not resume from suspend

[Pavel Machek <pavel@ucw.cz>]

[-- Attachment #1: Type: text/plain, Size: 2516 bytes --]

On Wed 2019-02-06 23:19:18, Rafael J. Wysocki wrote:
> On Wed, Feb 6, 2019 at 10:20 PM Pavel Machek <pavel@ucw.cz> wrote:
> >
> > Hi!
> >
> > > Since kernel version 4.19, my computer is unable to resume from suspend to
> > > RAM. I've run git bisect and filed bug report at
> > > https://bugzilla.kernel.org/show_bug.cgi?id=201519
> > > three months ago, however, I received no reaction. Bug is still present in
> > > 5.0-rc5 kernel version. Is there any possibility to fix this?
> >
> > Thanks for all the work bisecting / etc... Note that you can get patch
> > reverted if it causes regression, but it needs to be done over
> > email. (If maintainer does not reply, up-to Linus).
> >
> > For the record, patch is:
> >
> > git bisect output:
> > c62ec4610c40bcc44f2d3d5ed1c312737279e2f3 is the first bad commit
> > commit c62ec4610c40bcc44f2d3d5ed1c312737279e2f3
> > Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > Date:   Tue May 22 13:02:17 2018 +0200
> >
> >     PM / core: Fix direct_complete handling for devices with no
> >     callbacks
> > ...
> >     Link: https://bugzilla.kernel.org/show_bug.cgi?id=199693
> >         Fixes: 08810a4119aa (PM / core: Add NEVER_SKIP and
> >         SMART_PREPARE driver flags)
> >  Reported-by: Thomas Martitz <kugel@rockbox.org>
> >  Tested-by: Thomas Martitz <kugel@rockbox.org>
> >                     Cc: 4.15+ <stable@vger.kernel.org> # 4.15+
> >  Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> >  Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
> >  Reviewed-by: Johan Hovold <johan@kernel.org>
> >
> > And the patch was tagged for stable, which sounds like a lot of fun.
> 
> Not really.  This just restored previous behavior as the commit log says.
> 
> If the system breaks after this one, it most likely didn't work before
> commit 08810a4119aa which was in 4.15 and c62ec4610c40bcc44f2 first
> appeared in 4.17-rc1.
> 
> Unfortunately, it cannot be reverted without breaking other systems
> that used to work before commit 08810a4119aa.

So what is going on there?

If some devices need one behaviour and other devices need second
behaviour, we can just add the flag for the driver, right?

Because we know that Jaroslav's system can suspend, so this is fixable.

Jaroslav -- can you find out which device has problem?

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]