pci_bus_for_each_resource, transparent bridges and rsrc_nonstatic.c

[Dominik Brodowski]

Hey,

On Mon, Mar 22, 2010 at 01:08:35PM -0700, Bjorn Helgaas wrote:
> > So, what should we do? 
> 
> Let's back up a bit.  I don't know enough about PCMCIA, and I don't
> see the problem yet.  We have the 00:1e.0 bridge leading to bus 04,
> and 04:06.0 is a CardBus bridge.  These three windows are the ranges
> positively decoded and forwarded by the 00:1e.0 bridge:
> 
>   yenta_cardbus 0000:04:06.0: pcmcia: parent PCI bridge I/O window: 0x1000 - 0x1fff
>   yenta_cardbus 0000:04:06.0: pcmcia: parent PCI bridge Memory window: 0xd2000000 - 0xd40fffff
>   yenta_cardbus 0000:04:06.0: pcmcia: parent PCI bridge Memory window: 0xd0000000 - 0xd1ffffff
> 
> But the bridge is in subtractive-decode mode, so it *also* forwards
> anything it sees that is unclaimed by other devices on bus 00, which
> means the 04:06.0 CardBus bridge will also see these ranges:
> 
>   yenta_cardbus 0000:04:06.0: pcmcia: parent PCI bridge I/O window: 0x0 - 0xcf7
>   yenta_cardbus 0000:04:06.0: pcmcia: parent PCI bridge I/O window: 0xd00 - 0xffff
>   yenta_cardbus 0000:04:06.0: pcmcia: parent PCI bridge Memory window: 0xa0000 - 0xbffff
>   yenta_cardbus 0000:04:06.0: pcmcia: parent PCI bridge Memory window: 0xc0000000 - 0xfebfffff
> 
> Why do you care whether these additional ranges are excluded?  They
> should be just as usable as the first three.

Quoting rsrc_nonstatic.c:

        /* If this is the root bus, the risk of hitting
         * some strange system devices which aren't protected
         * by either ACPI resource tables or properly requested
         * resources is too big. [...]
         */

Or, as Alan put it -- when it came to I/O resources in the 0x100-0x3ff area:

	"Which crashes older thinkpads, some ATI chipset systems and
	 usually anything containing an NE2000 clone in ISA space."

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

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


Best,
	Dominik