Messages in this thread | | | From | Benjamin Herrenschmidt <> | Subject | Re: [patch 2.5.31] transparent PCI-to-PCI bridges | Date | Wed, 28 Aug 2002 12:03:51 +0200 |
| |
>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/
| |