linux-kernel - Re: [linux-pm] "i8042: Can't reactivate AUX port" after s2ram on 3.4-rc2

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:	Mon, 16 Apr 2012 18:17:21 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Mikko Vinni <mmvinni@...oo.com>
Cc:	Bjorn Helgaas <bhelgaas@...gle.com>,
	"linux-input@...r.kernel.org" <linux-input@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Allen Kay <allen.m.kay@...el.com>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>
Subject: Re: [linux-pm] "i8042: Can't reactivate AUX port" after s2ram on 3.4-rc2

On Monday, April 16, 2012, Mikko Vinni wrote:
> From: Rafael J. Wysocki
> 
> >>  OK, I know.  There simply are fewer BARs for bridges (and PCIe ports)
> >>  and here we're attempting to overwrite the secondary status register.  
> > Sigh.
> >> 
> >>  Well, I guess we should only retry the writes to BARs for Type 0 headers.
> > 
> > Which is done by the appended updated patch.  Can you please give it a try?
> 
> 
> Ok, I tested v4 and also v3, which is in 3.4-rc3. On this laptop both versions
> work equally: touchpad works after resume (no help for the card reader
> problem, though).

[...]

> Difference from v3:
> --- /tmp/v3-uniq        2012-04-16 09:57:42.880521878 +0300
> +++ /tmp/v4-uniq        2012-04-16 09:58:03.880545386 +0300
> @@ -1019,11 +1018,11 @@
>        1 Booting Node 0 Processor 1 APIC 0x1
>        1 CPU1 is up
>        1 ACPI: Waking up from system sleep state S3
> -     11 pcieport 0000:00:02.0: restoring config space at offset 0x1c (was 0x20005151, writing 0x5151)
> +      1 pcieport 0000:00:02.0: restoring config space at offset 0x1c (was 0x20005151, writing 0x5151)

OK, so clearly we need to prevent the writes into the secondary status register
of the PCIe port from being repreated pointlessly.

Can you please test the appended patch from completness on top of 3.4-rc3?

Rafael


---
 drivers/pci/pci.c |   18 +++++++++++-------
 1 file changed, 11 insertions(+), 7 deletions(-)

Index: linux/drivers/pci/pci.c
===================================================================
--- linux.orig/drivers/pci/pci.c
+++ linux/drivers/pci/pci.c
@@ -1015,13 +1015,17 @@ void pci_restore_state(struct pci_dev *d
 	pci_restore_pcie_state(dev);
 	pci_restore_ats_state(dev);
 
-	pci_restore_config_space(dev, 10, 15, 0);
-	/*
-	 * The Base Address register should be programmed before the command
-	 * register(s)
-	 */
-	pci_restore_config_space(dev, 4, 9, 10);
-	pci_restore_config_space(dev, 0, 3, 0);
+	if (dev->hdr_type == PCI_HEADER_TYPE_NORMAL) {
+		pci_restore_config_space(dev, 10, 15, 0);
+		/*
+		 * The Base Address register should be programmed before the
+		 * command register(s)
+		 */
+		pci_restore_config_space(dev, 4, 9, 10);
+		pci_restore_config_space(dev, 0, 3, 0);
+	} else {
+		pci_restore_config_space(dev, 0, 15, 0);
+	}
 
 	pci_restore_pcix_state(dev);
 	pci_restore_msi_state(dev);
--
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/