lkml.org 
[lkml]   [2002]   [Aug]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [patch 2.5.31] transparent PCI-to-PCI bridges
Date
>On Mon, Aug 26, 2002 at 10:12:24PM +0200, Benjamin Herrenschmidt wrote:
>> While we are at it, I still think the loop copying parent resource
>> pointers in the case of a transparent bridge should copy the 4
>> resource pointers of the parent and not only 3.
>
>I agree that hardcoding the resource numbers is bad.
>Instead, I suggest the following:
>s/bus->resource[0]/bus->io/
>s/bus->resource[1]/bus->mem/
>s/bus->resource[2]/bus->pref_mem/
>s/bus->resource[3]//
>
>There are only 3 _bus_ resources - the PCI works this way.
>
>Please don't propose your arch specific hacks to generic code.

I still don't agree, nothing in the _PCI_ force you to have
only 3 resources. a PCI 2 PCI bridge has 3 resources, here we
agree, but absolutely _nothing_ prevents a host bridge for
exposing more than one memory range, and that DOES happen
in a few real world cases like on pmac.

So we have this situation:

- Most of the common PCI code can deal with an arbitrary
number & ordering of resources in the pci_bus structure
- The pci_bus structure already holds 4 resource pointers
- Copying the all 4 instead of just 3 will not have any
side effect on machines that expose only 2 or 3 host bridge
resources.

I really don't understand your point here. Nothing defines
that a host bridge has to comply with the resource layout of
a PCI<->PCI bridge, why limit ourselves arbitrarily here ?
Especially since we _already_ have 4, not 3 resource slots
in the pci_bus structure...

Ben.


-
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/

\
 
 \ /
  Last update: 2005-03-22 13:28    [W:0.063 / U:0.560 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site