linux-kernel - Re: [RFC PATCH] PCIe: Add PCIe runtime D3cold support

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: <201204172310.38816.rjw@sisk.pl>
Date:	Tue, 17 Apr 2012 23:10:38 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	huang ying <huang.ying.caritas@...il.com>
Cc:	"Yan, Zheng" <zheng.z.yan@...el.com>, bhelgaas@...gle.com,
	linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org,
	linux-pm@...r.kernel.org, Lin Ming <ming.m.lin@...el.com>,
	Zhang Rui <rui.zhang@...el.com>,
	ACPI Devel Mailing List <linux-acpi@...r.kernel.org>
Subject: Re: [RFC PATCH] PCIe: Add PCIe runtime D3cold support

On Tuesday, April 17, 2012, huang ying wrote:
> On Tue, Apr 17, 2012 at 5:30 AM, Rafael J. Wysocki <rjw@...k.pl> wrote:
> >> >> +     return 0;
> >> >> +}
> >> >> +
> >> >> +static int pcie_port_runtime_resume(struct device *dev)
> >> >> +{
> >> >> +     struct pci_dev *pdev = to_pci_dev(dev);
> >> >> +
> >> >> +     pci_restore_state(pdev);
> >> >> +     if (pdev->runtime_d3cold)
> >> >> +             msleep(100);
> >> >
> >> > What's _that_ supposed to do?
> >>
> >> When resume from d3cold, PCIe main link will be powered on again, it
> >> will take quite some time before the main link go into L0 state.
> >> Otherwise, accessing devices under the port may return wrong result.
> >
> > OK, but this is generic code and as per the standard the link should have been
> > reestablished at this point already.
> >
> > Please don't put some nonstandard-platform-specific quirks like this into
> > code that's supposed to handle _every_ PCIe system.
> 
> After checking PCIe spec, I found that the 100ms here has its standard origin :)
> 
> In PCI Express Base Specification Revision 2.0:
> 
> Section 6.6.1 Conventional Reset
> 
> "
> To allow components to perform internal initialization, system
> software must wait for at least
> 100 ms from the end of a Conventional Reset of one or more devices
> before it is permitted to
> issue Configuration Requests to those devices
> "
> 
> But I think we should move the 100ms delay here to PCIe bus code or
> PCIe/ACPI code, because that is needed by all PCIe devices for D3cold
> support.

I think it should be sufficient to wait for the PME message to arrive at
the root port (which will cause the PME interrupt to appear), at which
point the device that sent it should be able to receive configuration
requests.

At this point, I need to konw what exactly happens when the GPE is triggered
by WAKE#.

Thanks,
Rafael
--
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/