Subject: Re: CVS commit: syssrc
To: None <scw@netbsd.org, thorpej@zembu.com>
From: Chris Torek <torek@BSDI.COM>
List: tech-kern
Date: 12/01/2000 16:16:50
Config (well, really, subr_autoconf.c and the defines I put in
sys/device.h) has three "notions" of device-present-ness:

UNSUPP: foodev at bus0 addr 0x1234 unsupported
 - meaning: "I found a device of type `foo', and I know for sure that
	we do not support it at all yet"
UNCONF: foodev at bus0 addr 0x1234 not configured
 - "I found a device of type `foo', and could not find a driver
	that claims it; perhaps you need to configure one in"
QUIET:	foodev at bus0 addr 0x1234
 - not really needed for anything; there for symmetry, really, since
   the "print" function is also called from config_attach().

It did not have a notion of "I found a device here, but ignore it
and say nothing".  I added this to BSD/OS recently, to kill off
"broadcast responders" in specific drivers: a cfdriver with a NULL
attach (and a size of 0) means "ignore".  Here is the comment and
code I added near the top of config_found:

	cd = cf->cf_driver;

	/*
	 * Some devices have a bad habit of responding at multiple
	 * addresses on a given bus.  The SCSI code deals with this
	 * by marking particular targets as "this responds to all
	 * units so just look at unit 0", and the scsi target driver
	 * then probes just unit 0.  Now we have Ethernet PHYs that
	 * can do the same sort of thing.  Rather than gimmick the
	 * MII probe code to start at 1 if there is a Lucent PHY
	 * (which we will not know until we probe for it!), we simply
	 * allow a "special" driver with a NULL "attach" function
	 * to mean "this is a phantom device".
	 */
	if (cd->cd_attach == NULL)
		return;

	... as before

So, I would say if you want to get the system to shut up about the
xyz controller you have at bus X addr Y, but for some reason do not
want to remove the xyz controller entirely, you should just add the
above and then configure:

	phantom0 at busX addr Y

where "phantom" is a device that always matches, but with a very
low priority.  Its driver is pretty minimal (consists solely of a
match function and a "cfdriver" structure) so it does not cost
much.  By using a low priority, you can even leave it in when you
decide to start using the xyz device.

Chris