linux-kernel - Re: [PATCH] apple-gmux: Restore switch registers on suspend/resume

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]

Date:	Tue, 10 Jul 2012 08:35:37 -0500
From:	Seth Forshee <seth.forshee@...onical.com>
To:	Arun Raghavan <arun.raghavan@...labora.co.uk>
Cc:	Matthew Garrett <mjg@...hat.com>,
	platform-driver-x86@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] apple-gmux: Restore switch registers on suspend/resume

On Tue, Jul 10, 2012 at 09:09:53AM +0530, Arun Raghavan wrote:
> After suspend and resume, the values of these registers seem to change
> from what they were at suspend time, potentially preventing the actual
> output lines from being enabled post-resume. This saves relevant state
> at suspend and restores it when resumed.
> 
> This is at least required on the MacBook Pro 8.2 when the Intel GPU is
> manually selected in GRUB config before the kernel is loaded.

I've got a couple of problems with this. The first is that the backlight
update_status callback isn't an appropriate place to do this. Adding
suspend/resume ops for the pnp_driver would be better.

But the more serious concern is whether or not its safe to simply
restore the register values. I know that the reverse engineering work
done on the gmux has revealed a particular sequence for selecting the
active GPU. A brute force restoration of the registers disregards this
sequencing, which doesn't seem like a good idea.

Seth
--
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/