Re: simple pnp bios io resources bug makes system unusable

[torvalds@transmeta.com (Linus Torvalds)]

In article <20030701223050.GA19402@neo.rr.com>,
Adam Belay  <ambx1@neo.rr.com> wrote:
>
>The pnpbios is reserving the complete range of every possible
>io port.  This causes device activation to fail for every device
>that needs an io port because that resource will always appear
>busy.

No, I don't think that's what it is doing at all. Quite the reverse, in
fact.

Look:

>On Mon, Jun 30, 2003 at 11:38:17PM -0400, CarlosRomero wrote:
>> 
>> cat /sys/devices/pnp0/00\:0c/resources
>> io 0x00000000-0xffffffff

This means that "io" was zero, but more importantly, it means that "len"
was zero too.

>> fixup: check for null io base, other devices are now able to initialize.
>
>Unfortunatly it's not quite that simple.

It _is_ that simple, but the code should check for "len" being zero, ie
the fix looks like it should be just a simple

	if (!len)
		return;

and that should fix it.

>Below are two examples that both use a base of 0 in a valid way.

Yes, and clearly they don't have "len == 0".

>Currently I'm leaning toward this logic...
>if we have any of the following situations
>- 0x00000000 for base and 0xffffffff for end
>- 0x00000000 for base and 0x00000000 for end
>- 0xffffffff for base and 0xffffffff for end
>then the resource range can be considered disabled.

I would suggest:

 - "len == 0"		=>  obviously disabled (both IO and memory)
 - "end < base"		=>  obviously disabled due to overflow crap
 - "end >= 0x10003"	=>  IO disabled (yeah, non-x86 can have IO above
			    that range in PCI, but I think it's undefined
			    behaviour)

all three should be cases of "obviously we can't validly have such a
resource", and the "len == 0" case should trivially fix the case that
CarlosRomero saw.

			Linus