Messages in this thread | | | Date | Sat, 31 Aug 2002 17:12:27 +0400 | From | Ivan Kokshaysky <> | Subject | Re: [patch 2.5.31] transparent PCI-to-PCI bridges |
| |
On Sat, Aug 31, 2002 at 10:09:42AM +0200, Benjamin Herrenschmidt wrote: > >Seriously, I see some implementation issues with "arbitrary number of > >resources" approach. By now I don't know how to deal with them. > > Ok, well, you should have said that first ;)
:-) Well, probably I shouldn't care about it at all. The setup-bus.c could be considered as PCI-to-PCI bridge driver which deals _only_ with certain type of devices with fixed resource layout. If you can make your host bridge look like this, fine. You'll be able to use some nice tricks like reallocating host bridge resources. If not, it's your problem. But you're still able to use routines from setup-bus.c for any bus behind the PCI-PCI bridges.
> > Because what I'm asking (the change to pci_read_bridge_bases()) for > copying all transparent bridge resources will just not affect setup-bus, > so you shouldn't have a problem with it. Currently, setup-bus cannot deal > with my hosts already, copying all 4 resources won't make this worse ;)
Ok, ok, I give up. :-)
> If your arch can use setup-bus today, it won't be harmed as it won't > have anything in that 4th resource anyway.
True. Probably it's ok for 2.4, but it would be better to have something sane for 2.5. We have already agreed that 4 is not much better than 3. A single resource pointer and resource count fields would fork fine for PCI and CardBus bridges, but will break most platforms where root bus resources are randomly allocated structures. I tend to agree about #define.
Ivan. - 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/
| |