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 Message-ID: <19980127095238.14229@follo.net>
next in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980127095238.14229>