linux-kernel - Re: [PATCH 3/5] PCI: revert preparing for wakeup in runtime-suspend finalization

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, 29 Jan 2013 02:15:30 +0100
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Bjorn Helgaas <bhelgaas@...gle.com>
Cc:	Konstantin Khlebnikov <khlebnikov@...nvz.org>,
	linux-kernel@...r.kernel.org, e1000-devel@...ts.sourceforge.net,
	linux-pci@...r.kernel.org, Dave Airlie <airlied@...hat.com>,
	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>
Subject: Re: [PATCH 3/5] PCI: revert preparing for wakeup in runtime-suspend finalization

On Monday, January 28, 2013 04:17:42 PM Bjorn Helgaas wrote:
> [+cc Rafael]
> 
> On Fri, Jan 18, 2013 at 4:42 AM, Konstantin Khlebnikov
> <khlebnikov@...nvz.org> wrote:
> > This patch effectively reverts commit 42eca2302146fed51335b95128e949ee6f54478f
> > ("PCI: Don't touch card regs after runtime suspend D3")
> >
> > | This patch checks whether the pci state is saved and doesn't attempt to hit
> > | any registers after that point if it is.
> >
> > This seems completely wrong. Yes, PCI configuration space has been saved by
> > driver, but this doesn't means that all job is done and device has been
> > suspended and ready for waking up in the future.
> >
> > For example driver e1000e for ethernet in my thinkpad x220 saves pci-state
> > but device cannot wakeup after that, because it needs some ACPI callbacks
> > which usually called from pci_finish_runtime_suspend().
> >
> > | Optimus (dual-gpu) laptops seem to have their own form of D3cold, but
> > | unfortunately enter it on normal D3 transitions via the ACPI callback.
> >
> > Hardware which disappears from the bus unexpectedly is exception, so let's
> > handle it as an exception. Its driver should set device state to D3cold and
> > the rest code will handle it properly.
> 
> Functions in D3cold don't have power, so it's completely expected that
> they would disappear from the bus and not respond to config accesses.
> Maybe Dave was referring to D3hot, where functions *should* respond to
> config accesses.  I dunno.
> 
> Just to be clear, it sounds like 42eca230 caused a regression on your
> e1000e device?  If so, I guess we should revert it unless you and Dave
> can figure out a better patch that fixes both your e1000e device and
> the Optimus issue.

Yes, if there's a regression, let's revert it, but I'd like the regression
to be described clearly.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
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/