Re: [patch 2.5.31] transparent PCI-to-PCI bridges

From: Benjamin Herrenschmidt (benh@kernel.crashing.org)
Date: Wed Aug 28 2002 - 05:03:51 EST


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



This archive was generated by hypermail 2b29 : Sat Aug 31 2002 - 22:00:22 EST