This fixes several problems with CIS as suggested by Justin Gibbs:

4) The cardbus CIS code treats the CIS_PTR as a mapping register if
   it is mentioned in the CIS.  I don't have a spec handy to understand
   why the CIS_PTR is mentioned in the CIS, but allocating a memory range
   for it is certainly bogus.  My patch ignores bar #6 to prevent the
   mapping.
   [The pccard spec says that BAR 0 and 7 (-1 and 6 in thic case since we
    did a minus one) is "reserved".  The off by 1 error has been fixed.
    also bar=5 is invalid for IO maps, so we check it.]

5) The CIS code allocated duplicate resources to those already found
   by cardbus_add_resources().  The fix is to pass in the bar computed
   from the CIS instead of the particular resource ID for that bar,
   so bus_generic_alloc_resource succeeds in finding the old resource.
   [fixed, also removed superfluous (and incorrect) writing back to the
    PCI config space.]

7) The CIS code seems to use the wrong bit to determine rather a particular
   register mapping is for I/O or memory space.  From looking at the
   two cards I have, it seems TPL_BAR_REG_AS should be 0x10 instead
   of 0x08.  Otherwise, all registers that should be I/O mapped gain
   a second mapping in memory space.
   [Oops, the spec does say 0x10..., fixed]

Submitted by: Justin Gibbs

1 files changed, 1 insertions, 1 deletions

diff --git a/sys/dev/cardbus/cardbus_cis.h b/sys/dev/cardbus/cardbus_cis.h
index 3fdc5f2..9268582 100644
--- a/sys/dev/cardbus/cardbus_cis.h
+++ b/sys/dev/cardbus/cardbus_cis.h
@@ -80,7 +80,7 @@ int cardbus_do_cis(device_t dev, device_t child);
 
 /* BAR */
 #define TPL_BAR_REG_ASI_MASK	0x07
-#define TPL_BAR_REG_AS		0x08
+#define TPL_BAR_REG_AS		0x10
 
 /* CISTPL_FUNC */
 #define TPL_FUNC_MF		0	/* multi function tuple */