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

["Rafael J. Wysocki" <rjw@sisk.pl>]

On Sunday, April 15, 2012, Rafael J. Wysocki wrote:
> On Sunday, April 15, 2012, Mikko Vinni wrote:
> > From: Rafael J. Wysocki:
> > 
> > >>  > Please change that dev_dbg() in pci_restore_state() into dev_info()
> > >>  > and see how many times it gets printed with the commit applied (not 
> > > reverted).
> > >> 
> > >> 
> > >>  I ran the dmesg through "uniq -c" and it looks like this:
> > >> 
> > >>        1 ACPI: Low-level resume complete
> > >>        1 PM: Restoring platform NVS memory
> > >>        1 Enabling non-boot CPUs ...
> > >>        1 Booting Node 0 Processor 1 APIC 0x1
> > >>        1 CPU1 is up
> > >>        1 ACPI: Waking up from system sleep state S3
> > >>       10 pcieport 0000:00:02.0: restoring config space at offset 0x7 (was 
> > > 0x20005151, writing 0x5151)
> > > 
> > > Well, yeah.  So the commit you bisected it to is total and utter crap.
> > > Most importantly, it retries the writes for all of the dwords in the 
> > > device's
> > > config space _including_ the status register (which by definition need not be
> > > the same as the written value).
> > > 
> > > I wonder if the appended patch helps?
> > 
> > It does. It seems there is a change only in the devices that refuse to wake up;
> > somehow writing too many times to them affects the rest of the machine.
> > So, for this machine your patch fixes the problem of the touchpad not working.
> 
> Good, thanks for the confirmation. :-)
> 
> > The write is now attempted (at most) 11 times, as shown below. Probably not
> > a huge deal.
> > 
> >       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)
> 
> Well, here you see that the PCI Express port is refusing to accept a new BAR value.
> It seems not to be operational and this probably is the reason why the device below
> the port don't respond later.
> 
> I'm not sure why that happens, though.

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.

Thanks,
Rafael