Messages in this thread | | | From | Jesse Barnes <> | Subject | Re: Possible issue with dangling PCI BARs | Date | Thu, 13 Dec 2007 12:04:17 -0800 |
| |
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
| |