From owner-freebsd-mobile  Mon Nov  3 17:07:48 1997
Return-Path: <owner-freebsd-mobile>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id RAA19668
          for mobile-outgoing; Mon, 3 Nov 1997 17:07:48 -0800 (PST)
          (envelope-from owner-freebsd-mobile)
Received: from word.smith.net.au (vh1.gsoft.com.au [203.38.152.122])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA19663
          for <freebsd-mobile@freebsd.org>; Mon, 3 Nov 1997 17:07:43 -0800 (PST)
          (envelope-from mike@word.smith.net.au)
Received: from word.smith.net.au (localhost.gsoft.com.au [127.0.0.1])
	by word.smith.net.au (8.8.7/8.8.5) with ESMTP id LAA00412;
	Tue, 4 Nov 1997 11:33:36 +1030 (CST)
Message-Id: <199711040103.LAA00412@word.smith.net.au>
X-Mailer: exmh version 2.0zeta 7/24/97
To: Nate Williams <nate@mt.sri.com>
cc: Mike Smith <mike@smith.net.au>, freebsd-mobile@freebsd.org
Subject: Re: problems after PAO -> 2.2.5 stable 
In-reply-to: Your message of "Mon, 03 Nov 1997 09:28:33 PDT."
             <199711031628.JAA07134@rocky.mt.sri.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 04 Nov 1997 11:33:34 +1030
From: Mike Smith <mike@smith.net.au>
Sender: owner-freebsd-mobile@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> >  - the card _can't_ do it (it has no idea what IRQ is actually being
> >    generated)
> 
> Is that true?  How do you know that it doesn't know which IRQ is being
> used via the driver?

I must be slow; I can only see one window here:

 - The card is supported by a driver for "normal" ISA cards.
 - The driver ignores the IRQ passed in the isa_device structure and
   instead reads an IRQ value from the card.
 - The card reports its configured IRQ based on the config index 
   selected.

The obvious culprit here then is the driver, which is our problem.
Does the ep driver do this?

In any other case, how can it matter what the card thinks?  If it wants 
to generate an interrupt, it has exactly one pin it can wiggle; 
regardless of what it thinks the pin is connected to, it's what the 
pcic does with it that matters.  I was suspecting that the pcic was 
trying to be smart, but now you've shot that down, and Guido has 
demonstrated that it's not a problem for him either.

mike