[lkml]   [2003]   [Mar]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] [PATCH] Device removal callback
    On Sun, Mar 09, 2003 at 04:11:02PM -0800, Greg KH wrote:
    > On Sun, Mar 09, 2003 at 01:14:13PM -0500, Ben Collins wrote:
    > >
    > > So I added a new callback to the device stucture called remove. This
    > > callback is done when device_del is about to remove a device from the
    > > tree. I've used this internally to make sure I can walk the list of
    > > children myself, and also do some other cleanups.
    > But don't you really want to remove the children before you remove the
    > parent? If you do this patch, then the remove() function will have to
    > clean up the children first, right? Can we handle the core recursion
    > with the current locks properly?

    Actually, with this patch, the dev->remove(dev) is called before the
    driver model does any cleanup. So you can cleanup children at that
    point, and the parent device is still sane.

    The reason for this is I would like to be able to unregister a node's
    device from several places without worrying about other things that need
    to be done. One call.

    > Yes, for USB we still have a list of a device's children, as we need
    > them for various things, and the current driver model only has a parent
    > pointer, not a child pointer (which is good, as for USB we can have
    > multiple children). So in the function where we know a USB device is
    > disconnected, we walk our list of children and disconnect them in a
    > depth-first order. With this patch I don't see how it helps me push
    > code into the driver core.

    I haven't looked into USB in depth, but consider this. Without the
    patch, to cleanup a device:

    void ieee1394_remove_node(struct node_entry *ne)

    list_for_each(..., &ne->device.children) {


    Then to remove a device, this function must always be called, so that
    the unit-directories get removed. What happens if the PCI bus gets
    yanked out from underneath us? How does the OHCI card's callbacks get me
    back down to this point? Without a lot of extra infrastructure, the
    nodes and unit directories get left hanging.

    Instead I now do this, with the patch.

    void ieee1394_remove_node(struct device *dev)
    list_for_each(..., &ne->device.children) {

    /* Where the dev is created */
    ne->device.remove = ieee1394_remove_node;

    Now, no matter where it's called from, doing...


    ...will make sure my remove callback is executed, so the children
    devices get unregistered aswell. I extend this to the host device
    and I have a recursive remocal scheme that is safe no matter where my
    devices get unregistered. Whole lot simpler that adding in a lot of
    failsafe's and checks.

    Debian -
    Linux 1394 -
    Subversion -
    Deqo -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:33    [W:0.022 / U:5.368 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site