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.