pci_bus_for_each_resource, transparent bridges and rsrc_nonstatic.c

[Bjorn Helgaas]

On Monday 22 March 2010 04:52:35 pm Dominik Brodowski wrote:
> 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:

Thanks!  Sorry to be so dense here ...

> (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).

We'd have exactly the same situation if we assigned I/O port 0x100
to a PCI device.  Why can't we use the same strategy PCI uses to
avoid it?

> => 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".

Sorry to be slow again...  The pci=use_crs and pci=nocrs options only
affect the PCI host bridge; they don't affect PCI-PCI bridges at all,
except that they change the set of resources available for subtractive-
decode PCI-PCI bridges to forward.  (Strictly speaking, they don't
affect the *behavior* of the PCI-PCI bridges, they only affect our
*idea* of what they're doing.)

I'm thinking of the code in pci_setup_device() where we set dev->transparent
based on the bridge's class code.  Obviously, you must be thinking
of something else.

My intention was that on pre-2008 systems like your laptop, my patches
would not change any behavior at all, unless you boot with "pci=use_crs".
Are you seeing an unexpected change on your system?

Bjorn