[This is somewhat i386-specific, but because it's a question about the
device configuration process I think it belongs on tech-kern.]

I am presently hacking on the /sys/dev/isa/pss* driver.  As of now,
the PSS and WSS drivers are configured with the following lines in the
kernel config file:

pss0	at isa? port 0x220 irq 7 drq 6  # Personal Sound System
sp0	at pss0 port 0x530 irq 10 drq 0	# 	sound port driver
wss0	at isa? port 0x530 irq 10 drq 0	# Windows Sound System

I changed pssattach() so that it finds subdevices by calling:

config_scan(isascan, sc);

Once I got things working, I ran into trouble because both sp0 and
wss0 were configured successfully, but both of them try to talk to the
_same hardware_.  Obviously, this is NFG.

My solution was to eliminate the sp "driver" and replace it with the
WSS driver, so that now the kernel config file looks like:

pss0	at isa? port 0x220              # Personal Sound System
wss0	at pss0 port 0x530 irq 10 drq 0	# 	sound port driver
wss0	at isa? port 0x530 irq 10 drq 0	# Windows Sound System

/sys/dev/isa/files.isa is changed as follows:

--- files.isa~	Mon Jul 31 17:08:24 1995
+++ files.isa	Mon Jul 31 17:21:43 1995
@@ -186,11 +186,10 @@
 device	pss at isa {[port = -1], [size = 0],
 		    [iomem = -1], [iosiz = 0],
 		    [irq = -1], [drq = -1]}
-device	sp at pss: audio, isadma, ad1848
 file	dev/isa/pss.c			pss needs-flag
 
 # Microsoft Windows Sound System
-device	wss at isa: audio, isadma, ad1848
+device	wss at isa, pss: audio, isadma, ad1848
 file	dev/isa/wss.c			wss needs-flag
 
 # Gravis UltraSound & UltraSound MAX.

As a result, wssprobe() and wssattach() are only called ONCE; by
pssattach() if a PSS is found, by isascan() if it isn't.

Now I have to write a pssscan() function that is similar to isascan(),
but also programs PSS registers etc. once a match is found.  Or should
I use config_search and config_attach directly?

If I do this, though, I run into the following problem:

How can the WSS driver determine whether it is part of the PSS or
directly on the ISA bus?  This is necessary because the standalone WSS
can only be at one of four iobases, while the PSS is more flexible.
So I don't want wssprobe() verifying the iobase with WSS_PORT_VALID,
etc., if it's being called from the PSS.  I also don't want
wssattach() calling audio_hardware_attach() itself if it's been called
from the PSS.

AFAIK, my options are:

1) wssprobe() examines parent's struct device (e.g. compare
   pc->cf->cf_driver to &isacd)
2) pssscan() passes a flag in ia->ia_aux

My final questions are:

Which of the two options above should I choose?
Is this whole thing too gross, and if so how SHOULD I do it?

Is there any documentation for the config.new system (other than
subr_autoconf.c) ANYWHERE?  cs-tr.cs.berkely.edu seems to be
down/missing/gone.
-- 
Mike Long <mike.long@analog.com>           http://www.shore.net/~mikel
VLSI Design Engineer         finger mikel@shore.net for PGP public key
Analog Devices, CPD Division          CCBF225E7D3F7ECB2C8F7ABB15D9BE7B
Norwood, MA 02062 USA                assert(*this!=opinionof(Analog));