Writing Device Drivers

Detach Entry Point

The driver's detach entry point can be called with these commands:

It is strongly recommended to fully implement support for all detach commands.

Note the following uses are possible:

During Dynamic Reconfiguration, there are two possible detach scenarios.

  1. All the devices on the detaching system board receive a DDI_DETACH, and all other devices keep running; or

  2. All the devices on the detaching system board receive a DDI_DETACH. All other devices receive a DDI_SUSPEND followed by a DDI_RESUME.

DDI_DETACH and DDI_SUSPEND are discussed in more detail below, with emphasis on common errors in device drivers that support these commands.


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;
static void

XX_start_timeout(struct xx *un)


    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;

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

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

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


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

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

    un->un_buf = NULL;


System power management and the Dynamic Reconfiguration framework pass the command DDI_SUSPEND to the detach(9E) driver entry point to request that the driver save the device hardware state. The driver may fail the suspend operation if outstanding operations cannot be completed soon or aborted, or if non-cancellable callbacks are outstanding, in which case the system will abort the suspend operation. Note that the driver instance may already have been power managed using DDI_PM_SUSPEND.

To process the DDI_SUSPEND command, the driver must:

  1. Set a suspended flag to block new operations.

  2. Wait until outstanding operations have completed, or abort them if they can be restarted.

  3. Block further operations from being initiated until the device is resumed (except for dump(9E) requests). Refer to sample code in Writing Device Drivers and the bst sample driver.

  4. Cancel pending callouts such as timeout callbacks, and quiesce or destroy other driver threads.

  5. Save any volatile hardware state in memory. This state includes the contents of device registers, and can also include downloaded firmware.

Chapter 8, Power Management describes in more detail some special power management considerations.

DDI_SUSPEND is always followed by DDI_RESUME. There may or may not be power interruption.