Re: Possible issue with dangling PCI BARs

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/