3.3. Module Device Drivers

3.3.1. Using the new device message
3.3.2. Module finalisation

The driver should perform its required module initialisation. And in addition needs to register a message handler (see the section Section 8.3, “Receiving Messages”) with the USB system. The module may be loaded at any time even before the USB system and may remain resident after the USB system has been removed. The module should listen for the relevant service calls for USB core starting (Service_USB 16 - USB system module started) and stopping (Service_USB 17 - USB system module stopped).

3.3.1. Using the new device message

On receipt of the message, the device driver should check the relevant fields in the message data to ascertain if the device being offered can be handled by the driver. The driver should ignore the message if the type field is set to USBMSG_NEWDEV_CURRENTDRIVER to indicate the message is intended for currently attached drivers. The message is passed around first with the try field set to USBMSG_NEWDEV_TRY_VENDOR to see if there are any vendor specific drivers available, and then with the try field set to USBMSG_NEWDEV_TRY_CLASS to specify the message is intended for drivers for an specific class and subclass.

If the driver can service the device, it should claim the message to stop any further drivers being informed. The driver should do minimal device startup in the message handler to allow the USB system to continue.

3.3.2. Module finalisation

The module should listen for the device unplug message to ascertain when the device has been removed, and free all resources associated with the device.

The module should free all USB resources on exit, the USB system will not perform any automatic garbage collection. Any outstanding requests must either be cleared or allowed to complete before the module exits to avoid system errors