The following reply was made to PR kern/32938; it has been noted by GNATS.

From: "Charles M. Hannum" <mycroft@MIT.EDU>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@NetBSD.org, gnats-admin@NetBSD.org,
	netbsd-bugs@NetBSD.org, sverre@viewmark.com
Subject: Re: kern/32938: Remapping of PCMCIA IO addresses by the controller
Date: Thu, 11 May 2006 15:36:54 -0400

 On Thu, May 11, 2006 at 06:50:02PM +0000, Sverre Froyen wrote:
 >  Updated patch for src/sys/dev/pcmcia/pvmcia.c.  The new patch contains 
 >  comments from "The PCMCIA Developer's Guide" about the correct interpretation 
 >  of the iomask, start, and length CIS parameters, new code matching the 
 >  comments, and a couple of bug fixes.  Please verify that the removal of the 
 >  tests around line 715 does not cause compatibility problems (these tests were 
 >  removed in order to make the debug printout, just below the tests, appear 
 >  correct, it had no effect on the working of my modem card).
 
 I am not even vaguely convinced that the book is correct or complete.
 The definitive reference is, of course, the PCMCIA spec, and it is not
 written this way at all.  Also, implementing what happens to work with
 your modem card is totally inadequate -- I have at least 50 unique
 devices that I tested when writing the current code.
 
 There are three potential problems with the existing code:
 
 1) It doesn't round "length" up to a power of two when it uses it for
    alignment.  This is a bug.  Most cards specify the length as a power
    of 2, but I've seen one counterexample to this.
 
 2) It doesn't deal well with a length of 0.  I don't recall this being
    allowed by the spec, nor did it occur in the CIS of any of the 50+
    cards that I tested, but who knows?  At the very least it should be
    robust enough to not crash in bus_space_alloc() or something.
 
 3) The handling of "skew".  This occurs because IOAddrLines actually
    tells you how many address lines the device watches, and if it's less
    than 16, there may be multiple valid aliases -- e.g. a device with
    IOAddrLines=10 and a base address specified as 0x3f8 could be mapped
    at 0x3f8, 0x7f8, 0xbf8, 0xff8, 0x13f8, etc.  Unfortunately, there is
    currently no way to pass this information on to bus_space_alloc().  I
    inquired about this and suggested adding a "skew" parameter to the
    interface (probably on tech-kern) at the time, but nobody cared, so
    it was left open.
 
    It's possible that the only values of IOAddrLines that exist in the
    wild are 16, 10, 0 and log2(length), all of which are easy to special
    case, but special cases seem like a definitely wrong answer.
 
 Also:
 
 >  +		 * Set pf_mfc_iobase equal to start. This flags the case
 >  +		 * where the card specifies a fixed IO base address and the
 >  +		 * controller remaps that address.
 >  +		 * XXX Need to rethink this in the case of multiple IO
 >  +		 * spaces per function. Fail for now.
 
 This is not acceptable.  There are many such cards, including many
 CF/IDE/ATA/flash devices.  You cannot ignore them.