diff mbox

[net-next,1/2] PCI: Add PCI quirk to disable L0s ASPM state for 82575 and 82598

Message ID 20090304020308.15176.40527.stgit@lost.foo-projects.org
State Not Applicable, archived
Delegated to: David Miller
Headers show

Commit Message

Kirsher, Jeffrey T March 4, 2009, 2:03 a.m. UTC 
From: Alexander Duyck <alexander.h.duyck@intel.com>

This patch is intended to disable L0s ASPM link state for 82598 (ixgbe)
parts due to the fact that it is possible to corrupt TX data when coming
back out of L0s on some systems.  The workaround had been added for 82575
(igb) previously, but did not use the ASPM api.  This quirk uses the ASPM
api to prevent the ASPM subsystem from re-enabling the L0s state.

Instead of adding the fix in igb to the ixgbe driver as well it was
decided to move it into a pci quirk.  It is necessary to move the fix out
of the driver and into a pci quirk in order to prevent the issue from
occuring prior to driver load to handle the possibility of the device being
passed to a VM via direct assignment.

Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
CC: linux-pci <linux-pci@vger.kernel.org>
CC: Matthew Wilcox <willy@linux.intel.com>
CC: Jesse Barnes <jbarnes@virtuousgeek.org>
---

 drivers/pci/quirks.c |   25 +++++++++++++++++++++++++
 1 files changed, 25 insertions(+), 0 deletions(-)


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Matthew Wilcox March 4, 2009, 4:05 a.m. UTC | #1 
On Tue, Mar 03, 2009 at 06:03:09PM -0800, Jeff Kirsher wrote:
> From: Alexander Duyck <alexander.h.duyck@intel.com>
> 
> This patch is intended to disable L0s ASPM link state for 82598 (ixgbe)
> parts due to the fact that it is possible to corrupt TX data when coming
> back out of L0s on some systems.  The workaround had been added for 82575
> (igb) previously, but did not use the ASPM api.  This quirk uses the ASPM
> api to prevent the ASPM subsystem from re-enabling the L0s state.
> 
> Instead of adding the fix in igb to the ixgbe driver as well it was
> decided to move it into a pci quirk.  It is necessary to move the fix out
> of the driver and into a pci quirk in order to prevent the issue from
> occuring prior to driver load to handle the possibility of the device being
> passed to a VM via direct assignment.

Thanks for the explanation, it handles my immediate question of "why do
it in a quirk?"  It does, however, raise the very interesting question
about what to do about other devices which have issues that are currently
handled in the driver that can't be handled by the driver in a VM.  
I don't have a good example to hand right now, but I bet I can spot one
when I'm less tired.

> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> CC: linux-pci <linux-pci@vger.kernel.org>
> CC: Matthew Wilcox <willy@linux.intel.com>
> CC: Jesse Barnes <jbarnes@virtuousgeek.org>

I'm not going to ack this patch at this point, let's just give it a day.
FWIW, Jesse is not going to be able to review patches this week.
David Miller March 6, 2009, 12:31 a.m. UTC | #2 
From: Matthew Wilcox <matthew@wil.cx>
Date: Tue, 3 Mar 2009 21:05:26 -0700

> I'm not going to ack this patch at this point, let's just give it a day.

More than a day has passed, how long are we going to let this
patch sit and rot?

Do we have to wait until Jesse gets back?  That doesn't sound
reasonable to me.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Matthew Wilcox March 6, 2009, 1:02 a.m. UTC | #3 
On Thu, Mar 05, 2009 at 04:31:08PM -0800, David Miller wrote:
> From: Matthew Wilcox <matthew@wil.cx>
> Date: Tue, 3 Mar 2009 21:05:26 -0700
> 
> > I'm not going to ack this patch at this point, let's just give it a day.
> 
> More than a day has passed, how long are we going to let this
> patch sit and rot?
> 
> Do we have to wait until Jesse gets back?  That doesn't sound
> reasonable to me.

A lot of the discussion on this happened face-to-face; Jeff, Linus and I
were all at the same conference this week.  I have put it in a pci fixes
tree, which I now have to pull apart again because one of the earlier
patches needs to be dropped.  I'm getting on a plane tonight and flying
home, so I'll be pushing this fix to Linus tomorrow.

Sorry for not keeping you in the loop on this one.
David Miller March 6, 2009, 1:44 a.m. UTC | #4 
From: Matthew Wilcox <matthew@wil.cx>
Date: Thu, 5 Mar 2009 18:02:07 -0700

> On Thu, Mar 05, 2009 at 04:31:08PM -0800, David Miller wrote:
> > From: Matthew Wilcox <matthew@wil.cx>
> > Date: Tue, 3 Mar 2009 21:05:26 -0700
> > 
> > > I'm not going to ack this patch at this point, let's just give it a day.
> > 
> > More than a day has passed, how long are we going to let this
> > patch sit and rot?
> > 
> > Do we have to wait until Jesse gets back?  That doesn't sound
> > reasonable to me.
> 
> A lot of the discussion on this happened face-to-face; Jeff, Linus and I
> were all at the same conference this week.  I have put it in a pci fixes
> tree, which I now have to pull apart again because one of the earlier
> patches needs to be dropped.  I'm getting on a plane tonight and flying
> home, so I'll be pushing this fix to Linus tomorrow.
> 
> Sorry for not keeping you in the loop on this one.

Ok, sounds good to me.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index f20d553..1a7c48d 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -23,6 +23,7 @@ 
 #include <linux/acpi.h>
 #include <linux/kallsyms.h>
 #include <linux/dmi.h>
+#include <linux/pci-aspm.h>
 #include "pci.h"
 
 int isa_dma_bridge_buggy;
@@ -1749,6 +1750,30 @@  static void __devinit quirk_e100_interrupt(struct pci_dev *dev)
 }
 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_ANY_ID, quirk_e100_interrupt);
 
+/*
+ * The 82575 and 82598 may experience data corruption issues when transitioning
+ * out of L0S.  To prevent this we need to disable L0S on the pci-e link
+ */
+static void __devinit quirk_disable_aspm_l0s(struct pci_dev *dev)
+{
+	dev_info(&dev->dev, "Disabling L0s\n");
+	pci_disable_link_state(dev, PCIE_LINK_STATE_L0S);
+}
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x10a7, quirk_disable_aspm_l0s);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x10a9, quirk_disable_aspm_l0s);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x10b6, quirk_disable_aspm_l0s);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x10c6, quirk_disable_aspm_l0s);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x10c7, quirk_disable_aspm_l0s);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x10c8, quirk_disable_aspm_l0s);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x10d6, quirk_disable_aspm_l0s);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x10db, quirk_disable_aspm_l0s);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x10dd, quirk_disable_aspm_l0s);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x10e1, quirk_disable_aspm_l0s);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x10ec, quirk_disable_aspm_l0s);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x10f1, quirk_disable_aspm_l0s);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x10f4, quirk_disable_aspm_l0s);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x1508, quirk_disable_aspm_l0s);
+
 static void __devinit fixup_rev1_53c810(struct pci_dev* dev)
 {
 	/* rev 1 ncr53c810 chips don't set the class at all which means