From owner-freebsd-hackers  Fri Jan 12 06:46:15 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id GAA13684
          for hackers-outgoing; Fri, 12 Jan 1996 06:46:15 -0800 (PST)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id GAA13677
          for <freebsd-hackers@freebsd.org>; Fri, 12 Jan 1996 06:46:06 -0800 (PST)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id BAA09888; Sat, 13 Jan 1996 01:42:59 +1100
Date: Sat, 13 Jan 1996 01:42:59 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199601121442.BAA09888@godzilla.zeta.org.au>
To: bde@zeta.org.au, se@zpr.uni-koeln.de
Subject: Re: PnP problem...
Cc: freebsd-hackers@freebsd.org
Sender: owner-hackers@freebsd.org
Precedence: bulk

>} Hmm.  How do the ISA probes avoid rediscovering PCI/EISA devices?  What

>Well, that's easy, actually :)

>The ISA driver probe will find a conflict with 
>ressources reserved by the earlier PCI probe. 

>This makes the PCI probe win :)

I'd like to avoid ordering dependencies like that.

>And that is the right thing to do, since it is
>most likely, that the PCI driver will be able
>to correctly setup interrupts, for example, or
>it may choose to use memory mapped I/O instead
>of the traditional port I/O of the ISA variant.

We were thinking about doing the ISA probe first since the ISA
devices can't be moved and the other drivers might need to know
where they are in order to keep out of their way.  Is this actually
a consideration for PCI?

>} 0-0x3ff :-).  I think ISA probes will have to be just as invasive as

>Well, yes. You never know how many address bits 
>an ISA device actually decodes ...

Oops, 0-0xffff :-)

>(This might be a prameter to the confict check:
>let it know, how many address bits the adapter 
>is known to decode (e.g. 10) and make all tests
>modulo 2^N).

Do we want to handle things like the sio3 vs S3 card conflict
automatically?  Presumably, for sio3, sio would return iobase = 0x2e8,
length = 8, decoding = 10 bits (worst case must be assumed unless
overridden).  syscons would have a harder time deciding whether
there is an S3 using 0x2e8-0x2ef.

Bruce