Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754758Ab3EARRi (ORCPT ); Wed, 1 May 2013 13:17:38 -0400 Received: from mail-ob0-f170.google.com ([209.85.214.170]:52365 "EHLO mail-ob0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751051Ab3EARRa (ORCPT ); Wed, 1 May 2013 13:17:30 -0400 MIME-Version: 1.0 In-Reply-To: <20130430072147.GA37866@bingao-desk1.fm.intel.com> References: <20130430072147.GA37866@bingao-desk1.fm.intel.com> From: Bjorn Helgaas Date: Wed, 1 May 2013 11:17:10 -0600 Message-ID: Subject: Re: x86/pci/mrst: force all pci config toward 0:0:0, 0:2:0 and 0:3:0 to type 1 To: Bin Gao Cc: Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , "x86@kernel.org" , Jacob Pan , Jesse Barnes , Greg Kroah-Hartman , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2610 Lines: 66 On Tue, Apr 30, 2013 at 1:21 AM, Bin Gao wrote: > x86/pci/mrst: force all pci config access toward 0:0:0, 0:2:0 and 0:3:0 to type 1 > > For real pci devices 0:0:0, 0:2:0 and 0:3:0, there is either no pci shim, or > no guarantee of data correctness of offset 256-4k. So for whatever reason, > Linux kernel should not do MMCFG pci config access to those devices. Instead, > always use type 1 for those devices. > > Signed-off-by: Bin Gao > --- > arch/x86/pci/mrst.c | 10 ++++++---- > 1 files changed, 6 insertions(+), 4 deletions(-) > > diff --git a/arch/x86/pci/mrst.c b/arch/x86/pci/mrst.c > index 6eb18c4..0e0fabf 100644 > --- a/arch/x86/pci/mrst.c > +++ b/arch/x86/pci/mrst.c > @@ -141,6 +141,11 @@ static int pci_device_update_fixed(struct pci_bus *bus, unsigned int devfn, > */ > static bool type1_access_ok(unsigned int bus, unsigned int devfn, int reg) > { > + if (bus == 0 && (devfn == PCI_DEVFN(2, 0) > + || devfn == PCI_DEVFN(0, 0) > + || devfn == PCI_DEVFN(3, 0))) > + return 1; Is there any possibility of multi-function devices at bus 0, device 0, 2, or 3? What about bridges -- can any of these be a bridge? If either of those could happen, these checks could be too specific. Is there a doc that identifies these cases where config mechanism #1 should be used instead of MMCONFIG? Bjorn > + > /* This is a workaround for A0 LNC bug where PCI status register does > * not have new CAP bit set. can not be written by SW either. > * > @@ -150,10 +155,7 @@ static bool type1_access_ok(unsigned int bus, unsigned int devfn, int reg) > */ > if (reg >= 0x100 || reg == PCI_STATUS || reg == PCI_HEADER_TYPE) > return 0; > - if (bus == 0 && (devfn == PCI_DEVFN(2, 0) > - || devfn == PCI_DEVFN(0, 0) > - || devfn == PCI_DEVFN(3, 0))) > - return 1; > + > return 0; /* langwell on others */ > } > > -- > 1.7.4.4 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/