From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932957Ab1KKQOo (ORCPT ); Fri, 11 Nov 2011 11:14:44 -0500 Received: from mx1.redhat.com ([209.132.183.28]:6687 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932163Ab1KKQOn (ORCPT ); Fri, 11 Nov 2011 11:14:43 -0500 From: Matthew Garrett To: linux-kernel@vger.kernel.org Subject: [V2] Disable ASPM on various devices Date: Fri, 11 Nov 2011 11:14:18 -0500 Message-Id: <1321028064-644-1-git-send-email-mjg@redhat.com> X-SA-Do-Not-Run: Yes X-SA-Exim-Connect-IP: 209.6.41.104 X-SA-Exim-Mail-From: mjg@redhat.com X-SA-Exim-Scanned: No (on cavan.codon.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org If the firmware has given us control of PCIe capabilities then it's valid for an operating system to configure ASPM more aggressively than the firmware did. A small number of devices object to this and exhibit various failure modes. Windows provides a mechanism to disable ASPM in the driver, indicated by the Needs=PciASPMOptOut statement in the .inf file. Trawling through Windows drivers has indicated the following set of hardware that disables ASPM in Windows but doesn't currently disable it in Linux. It makes sense for us to mimic Windows in this situation. (V2: send the version that actually builds)