From owner-freebsd-hackers  Tue Jan 27 00:52:46 1998
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id AAA13199
          for hackers-outgoing; Tue, 27 Jan 1998 00:52:46 -0800 (PST)
          (envelope-from owner-freebsd-hackers@FreeBSD.ORG)
Received: from ns1.yes.no (ns1.yes.no [195.119.24.10])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA13189
          for <hackers@freebsd.org>; Tue, 27 Jan 1998 00:52:42 -0800 (PST)
          (envelope-from eivind@bitbox.follo.net)
Received: from bitbox.follo.net (bitbox.follo.net [194.198.43.36])
	by ns1.yes.no (8.8.7/8.8.7) with ESMTP id IAA05632
	for <hackers@freebsd.org>; Tue, 27 Jan 1998 08:52:40 GMT
Received: (from eivind@localhost)
	by bitbox.follo.net (8.8.6/8.8.6) id JAA00677;
	Tue, 27 Jan 1998 09:52:38 +0100 (MET)
Message-ID: <19980127095238.14229@follo.net>
Date: Tue, 27 Jan 1998 09:52:38 +0100
From: Eivind Eklund <eivind@yes.no>
To: hackers@FreeBSD.ORG
Subject: Proposed patch to src/sys/i386/isa/isa.c
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.88e
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk

The patch below make the autoconfig-system drop probing/attaching devices
twice if a previous probe/attach succeeded.  This let you specify a device
twice in a kernel config file (with different IO-addresses), and then use
the first one that is detected.

Example:
device ed0 at isa? port 0x300 net irq  3 iomem 0xd8000 vector edintr
device ed0 at isa? port 0x220 net irq 10 iomem 0xd8000 vector edintr

Putting the above in my kernel config file will let me use two different
brands of NE2000-clones without doing any changes - whichever probes true
will become ed0.  (If both are present, the first is preferred).

If nobody protests, I'm going to commit the patch in a couple of days.  (It
shouldn't make anything worse for any case.)

Index: src/sys/i386/isa/isa.c
===================================================================
RCS file: /home/ncvs/src/sys/i386/isa/isa.c,v
retrieving revision 1.108
diff -u -r1.108 isa.c
--- isa.c       1997/11/30 09:44:28     1.108
+++ isa.c       1998/01/27 08:30:13
@@ -137,6 +137,14 @@
        if (tmpdvp->id_alive) {
                char const *whatnot;
 
+               /*
+                * Check for device driver & unit conflict/
+                */
+               if (tmpdvp->id_driver == dvp->id_driver &&
+                   tmpdvp->id_unit == dvp->id_unit) {
+                       return 1;
+               }
+
                whatnot = checkbits & CC_ATTACH ? "attach" : "prob";
                /*
                 * Check for I/O address conflict.  We can only check the

<dreamy>
Now, if we had a test to see if a particular IRQ is active, we could have a
GENERIC that just let our users plug in any clone and it would just work...
</dreamy>

Is there any particular reason we can't catch IRQs during a probe?  Ie, my
driver could tell the kernel "now I'm going to try to prod this card and
make it create an interrupt.  I think it is on IRQ such-and-such." Then
prod, then sleep 100ms (or whatever), then ask the kernel "Hey, did the IRQ
come as I said it would?"

For many devices, the prod phase is easy, but AFAIK none of our current
drivers do the above (which suggest to me that the kernel part of it is
missing).

Eivind.