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