On Thursday, December 13, 2007 3:20 Benjamin Herrenschmidt wrote: > > > Supporting pci_enable_device_io / pci_enable_device_mmio / > > > pci_iomap_io / pci_iomap_mmio seems to cover pretty much all the > > > use cases we have. > > > > > > The users we have right now that are: > > > > > > - pata_cs5520 (can be dealt with easily) > > > - old IDE (with the new resource handling for > > > legacy IDE can use pci_enable_device_io I think, ditto > > > pci/cs5520) > > > - scx200_acb (looks like a simple substitution works) > > > - lpfc pci_enable_device_mmio > > > - qla2xxx pci_enable_device ? (enables IO and MMIO) > > I may have not fully undestood you in my previous reply. You are > proposing replacing pci_enable_device_bars() with a pair of > pci_enable_device_io/mem ? > > I think that would be a good idea indeed.
Yeah, that seems like a reasonable compromise. Though in practice I'd expect the full disable decode approach to work fairly well too. I mean, if we really end up failing to allocate space for the device with the root drive on it, there are probably bigger issues than just failing to get a few bytes of I/O space for it... OTOH like Robert said, many devices really only need either MMIO or IO space enabled, not both, so having separate enable/disable routines for them makes a lot of sense. Jesse -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/