Messages in this thread |  | | Date | Wed, 28 Aug 2002 10:35:38 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: [patch 2.5.31] transparent PCI-to-PCI bridges |
| |
On Wed, 28 Aug 2002, Benjamin Herrenschmidt wrote:
> >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.
I agree. There is absolutely no reason to artificially limit the "bus" structure to only three resoruces (and with hardcoded behaviour at that).
There are examples of bridges that are very common and that can bridge at least four resources: every single CarsBus bridge does that _today_. Right now Linux only uses three of the 4 resources, but that's because we've never needed to use more. The fourth one is allocated in case some cardbus driver were to want to use it..
In fact, even regular PCI bridges often bridge more than three resources: many have things like VGA pass-through etc, which would actually add up to at least _five_ regions that they bridge (the regular three, and the added VGA IO and MEM regions). Again, Linux doesn't actually care about this right now, but again it is absolutely _wrong_ to artificially limit Linux internally to some made-up (and wrong) notion of what a bridge is.
In short: if anything, we may at some point make the number of resources _larger_, not smaller.
Linus
- 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/
|  |