On 08/13/2012 02:58 PM, Betty Dall wrote:
>
> I checked the PCI specification, and Peter is right that function
> numbers can be sparse. Please go with version 1 of the patch, as Andi
> suggested. I will follow up by looking at why the three scans are not
> consistent and send a patch, if
On Sat, 2012-08-11 at 03:43 -0700, Andi Kleen wrote:
> On Fri, Aug 10, 2012 at 04:57:02PM -0700, 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 0x. If
On Sat, 2012-08-11 at 03:43 -0700, Andi Kleen wrote:
On Fri, Aug 10, 2012 at 04:57:02PM -0700, 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 0x. If the function
On 08/13/2012 02:58 PM, Betty Dall wrote:
I checked the PCI specification, and Peter is right that function
numbers can be sparse. Please go with version 1 of the patch, as Andi
suggested. I will follow up by looking at why the three scans are not
consistent and send a patch, if appropriate.
> 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:
This was only for some AMD northbridges, since it worked there it should
be ok. The code is obsolete
On 08/12/2012 08:23 PM, Khalid Aziz wrote:
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:
Unless we can prove that that is invalid *for that
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 0x. If the function does not have a
valid VENDOR_ID, then the remaining function numbers do not have
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 0x. If the function does not have a
valid VENDOR_ID, then the remaining function numbers do not have
On 08/12/2012 08:23 PM, Khalid Aziz wrote:
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:
Unless we can prove that that is invalid *for that
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:
This was only for some AMD northbridges, since it worked there it should
be ok. The code is obsolete
On Fri, Aug 10, 2012 at 04:57:02PM -0700, 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 0x. If the function does not have a
> > valid VENDOR_ID, then the
On Fri, Aug 10, 2012 at 04:57:02PM -0700, 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 0x. If the function does not have a
valid VENDOR_ID, then the remaining
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 0x. If the function does not have a
> valid VENDOR_ID, then the remaining function numbers do not have to be
> scanned because functions are
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 0x. If the function does not have a
valid VENDOR_ID, then the remaining function numbers do not have to be
scanned because functions are
From: Andi Kleen
According to the Intel PCI experts it's not safe to check any
other field than vendor ID for 0x when doing PCI scans
to see if the device exists.
Several of the early PCI scans violated this. I changed
them all to always check the vendor ID first.
v2: Change some continues
Thanks Betty. All fixed. I'll post a v2.
-Andi
--
a...@linux.intel.com -- Speaking for myself only.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Andi,
On Wed, 2012-08-08 at 15:17 -0700, Andi Kleen wrote:
> From: Andi Kleen
>
> According to the Intel PCI experts it's not safe to check any
> other field than vendor ID for 0x when doing PCI scans
> to see if the device exists.
>
> Several of the early PCI scans violated this. I
Hi Andi,
On Wed, 2012-08-08 at 15:17 -0700, Andi Kleen wrote:
From: Andi Kleen a...@linux.intel.com
According to the Intel PCI experts it's not safe to check any
other field than vendor ID for 0x when doing PCI scans
to see if the device exists.
Several of the early PCI scans
Thanks Betty. All fixed. I'll post a v2.
-Andi
--
a...@linux.intel.com -- Speaking for myself only.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Andi Kleen a...@linux.intel.com
According to the Intel PCI experts it's not safe to check any
other field than vendor ID for 0x when doing PCI scans
to see if the device exists.
Several of the early PCI scans violated this. I changed
them all to always check the vendor ID first.
v2:
From: Andi Kleen
According to the Intel PCI experts it's not safe to check any
other field than vendor ID for 0x when doing PCI scans
to see if the device exists.
Several of the early PCI scans violated this. I changed
them all to always check the vendor ID first.
Signed-off-by: Andi Kleen
From: Andi Kleen a...@linux.intel.com
According to the Intel PCI experts it's not safe to check any
other field than vendor ID for 0x when doing PCI scans
to see if the device exists.
Several of the early PCI scans violated this. I changed
them all to always check the vendor ID first.
22 matches
Mail list logo
