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/
This archive was generated by hypermail 2b29 : Sat Sep 07 2002 - 22:00:15 EST