3.10.1 Device driver

The Start() service of a device driver installs protocol(s) directly onto the controller handle that was passed into the Start() service. The protocol(s) installed by the device driver use the I/O services that are provided by the bus I/O protocol that is installed on the controller handle. For example, a device driver for a USB device uses the service of the USB I/O Protocol, and a device driver for a PCI controller uses the services of the PCI I/O Protocol. In other words, the PCI I/O Protocol is consumed by a driver for a PCI option ROM card. This process is called "consuming the bus I/O abstraction."

The following are the main objectives of the device driver:

  • Initialize the controller.

  • Install an I/O protocol on the device that can be used directly or indirectly by UEFI-conformant system firmware to boot an operating system.

It does not make sense to write device drivers for devices that cannot be used to boot a platform. The following table provides the list of standard I/O protocols that the UEFI Specification defines for different classes of devices. If multiple protocols are listed, that does not necessarily mean that all the protocols must be produced. Please see later sections of the guide and the UEFI Specification for details on which protocols are required and which are optional.

Table 11-I/O protocols produced in the Start() function for different device classes
Class of device Protocol(s) created in the Start section of the driver
Block Oriented Device EFI_BLOCK_IO2_PROTOCOL
EFI_BLOCK_IO_PROTOCOL
EFI_STORAGE_SECURITY_COMMAND_PROTOCOL
File System EFI_SIMPLE_FILE_SYSTEM_PROTOCOL
Non block oriented or file system based boot device EFI_LOAD_FILE_PROTOCOL
LAN Universal Network Driver Interface (UNDI)
EFI_NETWORK_INTERFACE_IDENTIFIER_PROTOCOL
EFI_SIMPLE_NETWORK_PROTOCOL
EFI_MANAGED_NETWORK_PROTOCOL
EFI_VLAN_CONFIG_PROTOCOL
EFI_BIS_PROTOCOL
Graphics Display EFI_GRAPHICS_OUTPUT_PROTOCOL
EFI_EDID_DISCOVERED_PROTOCOL
EFI_EDID_ACTIVE_PROTOCOL
Text Console EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL
Character based I/O device EFI_SERIAL_IO_PROTOCOL
Keyboard EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL
EFI_SIMPLE_TEXT_INPUT_PROTOCOL
Mouse EFI_SIMPLE_POINTER_PROTOCOL
Tablet EFI_ABSOLUTE_POINTER_PROTOCOL
USB Host Controller EFI_USB2_HC_PROTOCOL EFI_USB_HC_PROOCOL
SCSI Host Controller EFI_EXT_SCSI_PASS_TRU_PROTOCOL
EFI_SCSI_PASS_THRU_PROTOCOL
SATA Controller EFI_ATA_PASS_THRU_PROTOCOL
Credential Provider for User Authentication EFI_USER_CREDENTIAL2_PROTOCOL

The fundamental definition of a UEFI device driver is that it does not create any child handles. This difference distinguishes a device driver from a bus driver.

The definition of a device driver can be confusing because it is often necessary to write a driver that creates child handles. This necessity makes the driver a bus driver by definition, even though the driver may not be managing a hardware bus in the classical sense (such as a PCI, SCSI, USB, or Fibre Channel bus).

Even though a device driver does not create child handles, the device managed by the device driver could still become a "parent." The protocol(s) produced by a device driver on a controller handle may be consumed by a bus driver that produces child handles. In this case, the controller handle that is managed by a device driver is a parent controller. This scenario happens quite often.

For example, the EFI_USB2_HC_PROTOCOL is produced by a device driver called the USB host controller driver. The protocol is consumed by the USB bus driver. The USB bus driver creates child handles that contain the USB_IO_PROTOCOL. The USB host controller driver that produced the EFI_USB2_HC_PROTOCOL has no knowledge of the child handles that are produced by the USB bus driver.