> 	So, I think I know how to fix it, but I have several questions.
 > 
 > 	(1) I assume the IRQMASK in the CIS is the same format as the PCIC_
 > 	    ISA_INTR_ALLOC_MASK, namely a bit field with a 1 in bit N if IRQ
 > 	    N is a valid choice for this card??  If not, what is the format
 > 	    of this mask?
 > 
 > 	(2) Why wasn't the card's IRQMASK being used?  Was this just overlooked,
 > 	    or are there actually cards that present bogus masks (or don't have
 > 	    IRQMASKS) and hence this was decided to be ignored??
 > 
 > 	If the answer to (1) is "yes", and the answer to (2) is "we forgot",
 > 	I'll sned-pr a patch to i82365_isasubr.c that got my modem the right
 > 	IRQs under separate cover.

 The answer to (1) is "yes", and the answer to (2) is "we don't forget"

 PC Card standard March 1997, section 3.3.2.7 Volume 4 says:

	3.3.2.7: TPCE_IR: Interrupt Request Description Structure

	When the IRQ bit is set, it indecates that an interrupt description
	follows the I/O address bytes, if any. The interrupt request levels
	specfied by the Configuration Table Entry Tuple describe the
	preferred routing for the card's IREQ# line. Routing of the IREQ#
	interrupts is performed by the host system which actually determines
	the system interrupt level used. A client which is the sole consumer
	of the card's IREQ# interrupt may elect to route the IREQ# line to a
	level not specified by the Configuration Table Entry Tuple.
	A generic card configuration utility which is not the ultimate
	consumer of the card's IREQ# interrupt should only route to the
	specified interrupt levels. ...

----------------------------------------------------------
		SAITOH Masanobu (msaitoh@spa.is.uec.ac.jp,
		                 msaitoh@netbsd.org)
		University of Electro-Communications