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.