From: Khalid Aziz <khalid.aziz@hp.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Betty Dall <betty.dall@hp.com>, Andi Kleen <andi@firstfloor.org>,
x86@kernel.org, linux-kernel@vger.kernel.org,
Andi Kleen <ak@linux.intel.com>
Subject: Re: [PATCH] x86, pci: Fix all early PCI scans to check the vendor ID first
Date: Sun, 12 Aug 2012 21:23:01 -0600 [thread overview]
Message-ID: <50287315.5010203@hp.com> (raw)
In-Reply-To: <50259FCE.4070205@zytor.com>
On 08/10/2012 05:57 PM, H. Peter Anvin wrote:
> On 08/09/2012 03:34 PM, Betty Dall wrote:
>> I thought this should be a break instead of a continue since the code
>> does a break if the class is 0xffffffff. If the function does not have a
>> valid VENDOR_ID, then the remaining function numbers do not have to be
>> scanned because functions are required to be implemented in order (no
>> skipping a function number.)
>>
> Is that true? This is certainly not true in PCI in general: there is
> required to be a function 0, but there is no guarantee that functions
> 1-7 don't have gaps.
If that is the case, there is a problem in the original code in
arch/x86/kernel/aperture_64.c.The original code already stops scanning
functions the first time it finds an invalid PCI class:
206 for (func = 0; func < 8; func++) {
207 u32 class, cap;
208 u8 type;
209 class = read_pci_config(bus, slot, func,
210 PCI_CLASS_REVISION);
211 if (class == 0xffffffff)
212 break;
--
====================================================================
Khalid Aziz
khalid.aziz@hp.com
next prev parent reply other threads:[~2012-08-13 3:23 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-08 22:17 [PATCH] x86, pci: Fix all early PCI scans to check the vendor ID first Andi Kleen
2012-08-09 22:34 ` Betty Dall
2012-08-09 23:41 ` Andi Kleen
2012-08-10 23:57 ` H. Peter Anvin
2012-08-11 10:43 ` Andi Kleen
2012-08-13 21:58 ` Betty Dall
2012-08-13 22:01 ` H. Peter Anvin
2012-08-13 3:23 ` Khalid Aziz [this message]
2012-08-13 3:24 ` H. Peter Anvin
2012-08-13 4:15 ` Andi Kleen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50287315.5010203@hp.com \
--to=khalid.aziz@hp.com \
--cc=ak@linux.intel.com \
--cc=andi@firstfloor.org \
--cc=betty.dall@hp.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.