On Thu, 2007-12-13 at 10:24 +0000, Alan Cox wrote: > > The SIL680 for example has an MMIO BAR at BAR5. Control for that BAR is > via MMIO_EN which is a bit in PCI config register 0x8A. > > So if we disable the device because of a dangling BAR the users root file > system goes away. If we leave it as is we have to know the > firmware/hardware came up with that BAR disabled or how to control it at > a per device level.
Except that it's very likely that it will be assigned, whether it's used or not, either by the BIOS or the kernel during pci_assign_unassign_resources(). If we really have some devices where we -know- we can hide the thing totally, we can then do a quirk for these. We may be taking a small risk here, but what else do you propose ? The problem of dangling BARs is real... One option is for me to address it on powerpc and leave x86 alone as it might be more of an issue with random crazy embedded firmware for us than it is for x86. As I said, the workaround is completely self contained within arch code for now. > 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) Ok. Ben. -- 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/
