Calling this a "regression" rather than a method to work around a badly implemented BIOS is silly.
This is not a "regression". You can claim that I'm wrong, but you can't prove it because I am not wrong. This problem impacts a very tiny subset of systems with a bad BIOS implementation that keeps ASPM control within the BIOS. If you read the patch it becomes clear that this behavior is by design meaning that it is A: not a regression and B: exactly what I implied when I said that it impacts a limited number of machines if any.
Change the code such that we
explicitly clear ASPM if the FADT indicates that ASPM isn't supported,
and make sure we tidy up appropriately on device removal in order to deal
with the hotplug case. If ASPM is disabled because the BIOS doesn't hand
over control then we won't touch the registers.- http://git.kernel.org/?p=linux/kerne...ec550c13b8fe72ACPI FADT declares the system doesn't support PCIe ASPM, so disable it
Something of interest to all of your readers would be that this patch actually fixed problems with systems crashing when ASPM was enabled on systems where the BIOS registered that it wasn't available.
The patch that Michael is calling a regression actually corrected those issues.
Read about it here: https://bugzilla.redhat.com/show_bug.cgi?id=681017
More here: http://lwn.net/Articles/449648/
Even more here: http://lwn.net/SubscriberLink/449448/95c739f46051924f/
This site has NO credibility, none .. zero.In the latter case, the system may simply lock up - a state with even worse latency characteristics combined with surprisingly bad power use. So this workaround may be welcomed by users who have seen their battery life decline significantly, but it is not a proper solution to the problem.