linux-kernel - Re: [PATCH] ACPI / PCI: Make _SxD/

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, 1 May 2012 10:11:41 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
cc:	"Oleksij Rempel (fishor)" <bug-track@...her-privat.net>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Len Brown <lenb@...nel.org>,
	ACPI Devel Mailing List <linux-acpi@...r.kernel.org>,
	Linux PM list <linux-pm@...r.kernel.org>,
	<linux-pci@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>,
	Andrey Rahmatullin <wrar@...r.name>,
	Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [PATCH] ACPI / PCI: Make _SxD/_SxW check follow ACPI 4.0a spec

On Tue, 1 May 2012, Rafael J. Wysocki wrote:

> > I mean not just the mapping.
> > I mean PCI:PME_SUP field.  If it PME(D0+,D1-,D2-,D3hot+,D3cold+), and 
> > acpi trying to avoid D3 states for this device. then is is same like 
> > PME(D0+,D1-,D2-)? Or not?
> 
> Yes, if _S3D or _S3W are present.  If they are not present and _PRW is,
> that means "don't care".
> 
> > According to spec.:
> > 7.2 Device Power Management Objects (page 287)
> > _S3D - Highest D-state supported by the device in the S3 state
> > _S3W - Lowest D-state supported by the device in the S3 state which can 
> > wake the system.
> > by definition if _S3W is specified then we can assume, the device can 
> > wake? But _SxW is not defined.
> 
> The device can wake up the system if _PRW is present for it (and for
> PCIe devices even that is not formally necessary).
> 
> > Are there any other method to forbid the system use broken state, after 
> > device was actually produced? Usual BIOS flash utility will probably no 
> > rewrite the PCIs EEPROM. Only hope is ACPI, what is correct method to do 
> > define it by ACPI?
> 
> Define _S3D that will return 2 (for example) and _PRW returning 3 as the
> deepest sleep state the system may be woken up from.  Then, we'll use
> D2 (after the @subject patch).
> 
> The drawback is that the kernel will then think the device can wake up
> the system.

There also remains a question about runtime power states and resume.

Oleksij, with your patch, which state does the controller get put into
during runtime suspend, D2 or D3?  (You may need to enable runtime
suspend by doing

	echo auto >/sys/bus/pci/devices/0000:00:1d.0/power/control

in order to test this.)  And if the controller is in runtime suspend,
does it resume correctly when you plug in a new USB device?

I'm pretty sure that without the patch, the controller gets put into D3 
and resume does work.

Alan Stern

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