Date: Tue, 11 May 2004 18:02:40 -0700 From: John-Mark Gurney <gurney_j@efn.org> To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= <des@des.no> Cc: dfr@freebsd.org Subject: Re: newbus flaw Message-ID: <20040512010240.GD601@funkthat.com> In-Reply-To: <xzp4qqn6n9v.fsf@dwp.des.no> References: <xzp4qqn6n9v.fsf@dwp.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
Dag-Erling Smørgrav wrote this message on Tue, May 11, 2004 at 16:39 +0200:
> When the driver is unloaded, the device is detached, but it remains on
> the bus's list of child devices. The next time the module is loaded,
> its DEVICE_IDENTIFY method is called again, and incorrectly adds a
> second child device to the bus, because it does not know that one
> already exists.
>
> There is no way for DEVICE_IDENTIFY to check if a matching child
> already exists on the bus, or for the module's event handler to unlist
> the child when unloading.
As someone else points out, this is already a known case and was discusses
on -arch a while back.
You are incorrect in assuming you can't find out if another child already
exists.. Usually this is a problem of properly allocating resources so
that you know the other child exists. Since you are using identify, you
already don't have a "self describing" bus, which means that you have
to either use hints, or another method to make sure that your device
doesn't already exist.
For example, in my adv717xa driver, part of the zoran driver, I do the
following in my _probe routine to prevent probing and attaching to the
same chip.
/* Make sure this isn't already attached */
if (sibs == NULL)
device_get_children(iicbus, &sibs, &sibcnt);
for (j = 0; j < sibcnt; j++) {
if (device_get_state(sibs[j]) >= DS_ATTACHED
&& device_get_driver(sibs[j]) == drv
&& ((struct adv717xa_softc *)
device_get_softc(sibs[j]))->adv_slvaddr
== chips[i].addr) {
device_printf(dev, "already attached at %s\n",
device_get_nameunit(sibs[j]));
break;
}
}
This should not be a problem because the i2c bus should either
do proper resource allocation for the id, which when I try to probe, I
allocate the chip id, and that fails, preventing it's creation...
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040512010240.GD601>