Intel Extensible Firmware Interface - Manual (Page 64)

Extensible Firmware Interface Specification
2-24 12/01/02 Version 1.10
The device driver that connects to the device handle in Figure 2-11 must have installed a Driver
Binding Protocol on its own image handle. The Driver Binding Protocol contains three functions
called
Supported() , Start() , and Stop() . The Supported() function tests to see if the
driver supports a given controller. In this example, the driver will check to see if the device handle
supports the Device Path Protocol and the XYZ I/OProtocol. If a driver’s
Supported()
function passes, then the driver can be connected to the controller by calling the driver’s Start()
function. The Start() function is what actually adds the additional I/Oprotocols to a device
handle. In this example, the Block I/OProtocol is being installed. To provide symmetry, the
Driver Binding Protocol also has a
Stop() function that forces the driver to stop managing a
device handle. This will cause the device driver to uninstall any protocol interfaces that were
installed in
Start() .
The Supported() , Start() , and Stop() functions of the EFI Driver Binding Protocol are
required to make use of the boot service OpenProtocol() to get a protocol interface and the
boot service CloseProtocol() to release a protocol interface. OpenProtocol() and
CloseProtocol() update the handle database maintained by the system firmware to track
which drivers are consuming protocol interfaces. The information in the handle database can be
used to retrieve information about both drivers and controllers. The new boot service
OpenProtocolInformation() can be used to get the list of components that are currently
consuming a specific protocol interface.
2.5.5 Bus Drivers
Bus drivers and device drivers are virtually identical from the EFI Driver Model’s point of view.
The only difference is that a bus driver creates new device handles for the child controllers that the
bus driver discovers on its bus. As a result, bus drivers are slightly more complex than device
drivers, but this in turn simplifies the design and implementation of device drivers. There are two
major types of bus drivers. The first creates handles for all child controllers on the first call to
Start() . The other type allows the handles for the child controllers to be created across multiple
calls to Start() . This second type of bus driver is very useful in supporting a rapid boot
capability. It allows a few child handles or even one child handle to be created. On buses that take
a long time to enumerate all of their children (e.g. SCSI), this can lead to a very large timesaving in
booting a platform. Figure 2-12 shows the tree structure of a bus controller before and after
Start() is called. The dashed line coming into the bus controller node represents a link to the
bus controller’s parent controller. If the bus controller is a Host Bus Controller, then it will not
have a parent controller. Nodes A, B, C ,D, and E represent the child controllers of the bus
controller.