Re: newbus flaw

From: John-Mark Gurney (gurney_j_at_efn.org)
Date: 05/12/04

  • Next message: Dag-Erling Smørgrav: "Re: newbus flaw"
    Date: Tue, 11 May 2004 18:02:40 -0700
    To: Dag-Erling Smørgrav <des@des.no>
    
    

    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."
    _______________________________________________
    freebsd-arch@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
    

  • Next message: Dag-Erling Smørgrav: "Re: newbus flaw"

    Relevant Pages

    • Re: global data via module howto
      ... : M. Warner Losh wrote: ... In common case we have a driver for "bus": ... : If child could work on several buses it declares itself several times: one for each ...
      (freebsd-hackers)
    • Re: global data via module howto
      ... In common case we have a driver for "bus" ... If child could work on several buses it declares itself several times ... In common case I'll put DRIVER_MODULE in a child ...
      (freebsd-hackers)
    • Re: global data via module howto
      ... I am working on porting irda support for USB devices from NetBSD. ... In common case we have a driver for "bus": ... : If child could work on several buses it declares itself several times: one for each ...
      (freebsd-hackers)
    • Re: global data via module howto
      ... : extern int x; ... : DRIVER_MODULE for each 'bus'. ... In common case we have a driver for "bus" with many ... If child could work on several buses it declares itself several times one for each ...
      (freebsd-hackers)
    • newbus flaw
      ... At some later point, during a bus rescan, the attach ... When the driver is unloaded, the device is detached, but it remains on ... the bus's list of child devices. ... The first time you load the module, you get foo0; ...
      (freebsd-arch)