pci_bus_for_each_resource, transparent bridges and rsrc_nonstatic.c

[Dominik Brodowski]

Hey,

On Mon, Mar 22, 2010 at 03:28:55PM -0700, Bjorn Helgaas wrote:
> On Monday 22 March 2010 02:51:21 pm Dominik Brodowski wrote:
> > On Mon, Mar 22, 2010 at 01:36:03PM -0700, Bjorn Helgaas wrote:
> > > > You can still use subtractive-decoded resources, but then you have to add
> > > > them to /etc/pcmcia/config.opts and run pcmcia-startup-bridges (or echo the
> > > > resource to a sysfs file).
> > > 
> > > It's too bad we still have such manual configuration.
> > 
> > Agreed.
> > 
> > > Is there still
> > > information there that we can't figure out automatically?
> > 
> > That's unknown to me -- are there any ISA-capable systems being sold? If so,
> > then I suspect the answer may be "yes".
> > 
> > > > Now, "usecrs" is only used on 2008-or-newer systems where we _hope_ that all
> > > > resource "consumers" are accounted for. So the problem might be mitigated.
> > > > However, I wouldn't dare to use ioports 0x0-0xff anyways for they usually
> > > > are used for onboard legacy devices...
> > > 
> > > Right.  But PCMCIA is at no greater risk than regular PCI, right?
> > > It looks like both will allocate only above PCIBIOS_MIN_IO (0x1000).
> > 
> > No, PCMCIA will happily allocate below this limit.
> 
> I saw "#define PCIBIOS_MIN_CARDBUS_IO PCIBIOS_MIN_IO" in yenta_socket.c
> and assumed it would take care of this, but I didn't look any deeper.
> 
> I'm still confused about why PCMCIA is "special" in this regard and
> why pci=use_crs breaks it.  Can you make up an example that illustrates
> the problem?

Consider the following case:

(1) The root PCI bus has _CRS I/O 0000-0cf7; 0d00-ffff "produced";

    the (transparent) PCI-PCI bridge offers, as bus resources, to
    downstream users 0x4000-0x4fff plus everything else because of
    subtractive decoding;

    there is a yenta-style PCI-CardBus/PCMCIA bridge below this
    PCI-PCI bridge.

(2) There are some I/O ports which react rather unfriendly to being read or
    written. Let's assume they're at 0x100-0x10f; and let's also assume that
    the BIOS writers forgot to mention them at all in the ACPI _CRS
    settings; no other part of the kernel knows about it.

0000-0cf7 : PCI Bus 0000:00
...
  00f0-00ff : fpu
  0170-0177 : 0000:00:1f.2


(3) A PCMCIA card is inserted. It needs an I/O port resource of size 8. The
    PCMCIA subsystem looks in its own resource database which I/O ports it
    may use; there, it finds not only 0x4000-0x4fff but (with a small
    exception) 0x0000-0xffff; as 0x0000-0x00ff are already assigned, it
    happily assigns the first free area -- 0x100-0x108 -- to the PCMCIA
    card.

0000-0cf7 : PCI Bus 0000:00
...
  00f0-00ff : fpu
  0100-0108 : pcmcia0.0
  0170-0177 : 0000:00:1f.2

(4) The PCMCIA card and the PCMCIA driver are set up to work with an IO
    resource at 0x100-0x108. As soon as they attempt to use this resource,
    bad things happen (lockups, etc.) because of the reasons spelled out at
    (2).

=> It is only an issue if the ACPI resource descriptions are incomplete. It
is worse for PCMCIA because it happily assigns resources below 0x1000, where
such system/platform devices usually listen to. And usecrs worsens the
situation also in another regard: on my own laptop (a pre-2008 model),
pci=use_crs makes the PCI-PCI bridge to be marked as "transparent", while
pci=nocrs means the PCI-PCI bridge is assumed to be "non-transparent".

Best,
	Dominik