pci_bus_for_each_resource, transparent bridges and rsrc_nonstatic.c

[Bjorn Helgaas]

On Mon, 2010-03-29 at 21:47 +0200, Dominik Brodowski wrote:

> On the PCI root bus on the x86 architecture, the risk of hitting
> some strange system devices which aren't protected by either ACPI
> resource tables or properly requested resources is too big. In
> the past, we were protected by the PCI root bridge being set to
> &iomem_resource or &ioport_resource. However, on systems where CRS
> is enabled, this no longer is true. Therefore, only loop over the
> first (non-subtractive) resources of the upstream PCI bus brdige.
> 
> CC: Jesse Barnes <jbarnes at virtuousgeek.org>
> CC: Bjorn Helgaas <bjorn.helgaas at hp.com>
> Signed-off-by: Dominik Brodowski <linux at dominikbrodowski.net>
> 
> diff --git a/drivers/pcmcia/rsrc_nonstatic.c b/drivers/pcmcia/rsrc_nonstatic.c
> index 39c89e1..ad68e53 100644
> --- a/drivers/pcmcia/rsrc_nonstatic.c
> +++ b/drivers/pcmcia/rsrc_nonstatic.c
> @@ -940,7 +940,8 @@ static int nonstatic_autoadd_resources(struct pcmcia_socket *s)
>  		return -EINVAL;
>  #endif
>  
> -	pci_bus_for_each_resource(s->cb_dev->bus, res, i) {
> +	for (i = 0; i < PCI_BRIDGE_RESOURCE_NUM; i++) {
> +		res = s->cb_dev->bus->resource[i];
>  		if (!res)
>  			continue;

I think you are just trying to avoid allocating resources that are
likely to collide with a system device we don't know about.  But I don't
think any of this code expresses that intent very clearly.

Avoiding this kind of collision only requires that you identify the
range you want to avoid; it has nothing to do with whether a bridge
window is &iomem_resource or &ioport_resource or whether it is
subtractively decoded.  Obviously, you have something more in mind,
since 9713ab28 already avoids ports < 0x100.  

Here's a topology where I think you would want to pay attention to the
subtractively decoded window forwarded to bus 01:

  host bridge window [io  0x4000-0x4fff] to bus 00
    00:00.0 PCI bridge to bus 01 (subtractive decode mode)
      01:00.0 CardBus bridge to bus 02

As an aside, even if the BIOS provided perfect ACPI resource
information, Linux would happily ignore almost all of it, since the
Linux/ACPI core doesn't even look at those resource descriptions, and
while PNPACPI does evaluate _CRS methods, it never puts any of the
information in the resource trees.  It's only when a driver claims a
device and reserves its resources that those resources become visible to
the rest of the system.  So it's all well and good to acknowledge that
BIOSes often have bugs, but we're on pretty shaky ground in Linux, too.

Bjorn