Messages in this thread | | | Date | Wed, 1 Sep 1999 12:19:08 +0200 | From | Martin Mares <> | Subject | Re: PATCH: PCI changes for pre-2.3.16-1 |
| |
Hello,
> On any system where we go through the pain of forcibly initializing all > the devices and setting up the bridges, you go and change the allocations > afterward. And with a bug, no less -- you should release the resource > you had before munging res->{start,end}. > > I suggest instead fixing this with a PCI_FIXUP_HEADER that sets start+end > if needed, and let the target dependant code notice the start==0 and > assign the resource then.
You're right, I'll do it this way.
> I'm also not happy with this, though it can be hacked around after > pci_scan_bus returns, if you force me to. > > The recent PCI reorg was a good thing, but within days we're slipping > back into a mode that will require every PCI target except x86 to > re-implement the entire PCI probing and setup process just to get > around x86-isms.
These are not x86-isms, this code works well on any architecture where the bus ranges are set up by firmware. This is the same philosophy as we already had for base addresses and IRQ's -- the generic code expects everything is set up right, but gives arch-specific routines a chance to change it as needed.
I agree that the pci_read_bridge_bases function does nothing useful on architectures doing their own address assignments, but at last it doesn't do any harm :) Now, as we have asm/pci.h, we can easily declare the basic characteristics of the PCI access on that architecture there and put a few ifdefs to pci.c.
> I would much rather see the pci_scan_bus not do this bus range > probing thing and make x86 set up what it needs in pcibios_fixup_bus.
If it were only x86, I'd agree, but it isn't.
> Please consider the attached.
I'll look at it tomorrow as soon as I get some sleep :-)
Have a nice fortnight -- Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth "Don't take life too seriously -- you'll never get out of it alive."
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |