linux-kernel - Re: [Intel-gfx] [PATCH] drm/i915: fix failure to power off after hibernate

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150227121504.GA30560@boom>
Date:	Fri, 27 Feb 2015 14:15:04 +0200
From:	David Weinehall <david.weinehall@...ux.intel.com>
To:	intel-gfx@...ts.freedesktop.org
Cc:	Imre Deak <imre.deak@...el.com>,
	Bjørn Mork <bjorn@...k.no>,
	linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
	stable@...r.kernel.org, Daniel Vetter <daniel.vetter@...el.com>
Subject: Re: [Intel-gfx] [PATCH] drm/i915: fix failure to power off after
 hibernate

On Thu, Feb 26, 2015 at 09:01:27PM +0100, Daniel Vetter wrote:
> On Thu, Feb 26, 2015 at 08:50:48PM +0200, Imre Deak wrote:

[snip]
> > 
> > The problem seems to be that after the kernel puts the device into D3
> > the BIOS still tries to access it, or otherwise assumes that it's in D0.
> > This is clearly bogus, since ACPI mandates that devices are put into D3
> > by the OSPM if they are not wake-up sources. In the future we want to
> > unify more of the driver's runtime and system suspend paths, for example
> > by skipping all the system suspend/hibernation hooks if the device is
> > runtime suspended already. Accordingly for all other platforms the goal
> > is still to properly power down the device during hibernation.

[snip]
> 
> If we see more of these troublesome machines we might need to apply an
> even bigger hammer like gen < 5 or so. But as long as there's just 1
> report I think this is the right approach.
> 
> Bjorn, as soon as we have your tested-by that this work we can apply this
> and shovel it through the backporting machinery.

Isn't there a risk that this will negatively impact machines using gen4
that *don't* have a buggy BIOS?  Wouldn't a quirk tied to the laptop
or BIOS version be better suited -- or possibly a parameter that can be
passed to the driver, which would make it easier to test if others
suffering from similar symptoms on other systems suffer from the same
issue or not?

Just my 2¢.


Kind regards, David Weinehall
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/