Writing Device Drivers

DDI_DETACH Command

The DDI_DETACH operation is the inverse of DDI_ATTACH. The DDI_DETACH handling should only deallocate the data structures for the specified instance. Driver global resources must only be deallocated in _fini(9E). Since instances are assigned in arbitrary order, the driver must be able to handle out-of-sequence presentation of instances. In fact, no assumption should be made about the instance number.

The DDI_DETACH command code should perform the following actions.

  1. Check whether DDI_DETACH is safe.

    The driver can assume that the device has been closed before DDI_DETACH is issued. However, there may be outstanding callbacks that cannot be cancelled, or the device may not currently be in a state that permits it to be reliably shut down and restarted later. While timeouts or callbacks are still active, proper locking must be enforced.

    The driver should not block while waiting for callback completion or for the device to become idle.

    Devices that maintain some state after a close operation must be carefully analyzed. When a driver not currently in use is automatically unloaded (for example, because the system memory is low) and later automatically reloaded when the user opens the device, this might cause undesirable operation.

    For example, a tape driver that supports non-rewinding tape access might fail the detach operation when the tape head is not at the beginning of the tape. If the drive is powered down, the head position will be lost.

  2. Shut down the device and disable interrupts.

    A device needs enough hardware information/support to be able to shut off and restart interrupts. This may already be coded in the driver as a function of the existing detach routines.

  3. Remove any interrupts registered with the system.

  4. Cancel any outstanding timeouts and callbacks.

  5. Quiesce or remove any driver threads.

  6. Deallocate memory resources.

    The driver should be unloadable without memory leaks.

  7. Unmap any mapped device registers.

  8. Execute ddi_set_driver_private(dip, NULL).

  9. Free the softstate structure for this instance.

When there is failure during detach, the driver must decide whether to continue the detach and return success or undo the detach actions completed to that point and return failure. Undoing might be risky and it is usually preferable to continue the detach operation.

DDI_DETACH may be followed by power interruption; any further references to the device will need to be preceeded by a DDI_ATTACH.

Note the following when using timeout() routines:

The timeout routine should take the form of:

static void
 
XX_timeout(caddr_t arg)
{
    struct xx *un = (struct un *)arg;
    mutex_enter(&un->un_lock);
 
    .....
 
    XX_start_timeout(un);
 
    mutex_exit(&un->un_lock);
}
static void

XX_start_timeout(struct xx *un)

{
ASSERT(MUTEX_HELD(&un->un_lock));

    if ((un->un_tid == 0) && ((un->un_flags & XXSTOP) ==
                0)){un->un_tid = timeout(XX_to, arg, ticks);
 
    }
}
static void

XX_stop_timeout(struct xx *un)

{
int     tid;
mutex_enter(&un->un_lock);

    if ((tid = un->un_tid) != 0) {

    /* do not reschedule timeout */
 
        un->un_flags |= XXSTOP;
 
        /* do not hold across untimeout() */
 
        mutex_exit(&un->un_lock);
        (void) untimeout(tid);
        mutex_enter(&un->un_lock);
 
        un->un_flags &= ~XXSTOP;
        mutex_exit(&un->un_lock);
    } else {
        mutex_exit(&un->un_lock);
    }   
}

When deallocating memory, always verify first that the pointer is valid:

#if NONONONO

kmem_free(un->un_buf, un->un_buf_len);
#else
if (un->un_buf) {

    kmem_free(un->un_buf, un->un_buf_len);

    un->un_buf = NULL;
}   
#endif