In message <199811020726.QAA25609@hannya.spa.is.uec.ac.jp>, msaitoh writes: 

->  > 	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. ...

Given that the standard says a card should be able to use any interrupt even
though the IRQMASK says otherwise, I can see why the code works the way it
does now... However, are there good reasons *NOT* to use the card's IRQMASK 
from the CTE-tuple (as opposed to reasons we *DON'T* use it?).

My gut feeling (knowning very little about PCMCIA), would be to always use
the IRQMASK presented by the card unless that masks out all available IRQs
and then fall back to allocating from all available ones irrespective of the
IRQMASK in the CTE tuple.  Is this bad for some reason I'm not aware of?

If the above is acceptable, I'll whip up a patch to do just that.  If there
are reasons it's not, I'd like to hear them... In that case, maybe a PCMCIA
quirk that forces use of the IRQMASK on some cards should be created, and
cards like mine should be entered into the quirk table with said quirk.

[I'm interested in this for the ISA PCIC case on x86... I'm not sure how
 this would impact the other PCIC attachments, and welcome any insight
 on that as well...]

Comments, other ideas?
--rafal

----
Rafal Boni                                                  rafal@mediaone.net