HDK Technical Reference

Hotplug devices

DDI 8 provides an infrastructure that supports ``hotplug'' devices, which are devices that can be added to and removed from the configuration without rebooting the system or reloading the driver. MDI version 2 network adapter drivers and SDI version 4 HBA drivers that conform to DDI 8 and run on a PCI bus are hotplug-capable; the only additional requirements are:

Hotplug driver code must set the D_HOT flag in the driver's drvinfo(D4) structure.
Drivers code must include all subfunctions to config(D2) that are required for hotplug devices. See the manual page for details.
MDI drivers must call the mdi_hw_suspended(D3mdi) function in the CFG_SUSPEND subfunction and the mdi_hw_resumed(D3mdi) function in the CFG_RESUME subfunction.

In order to perform controller hotplug, the platform must provide a hotplug controller driver and concommitant circuitry. OEMs should use the HPCI interface to implement hotplug controller drivers.

The rest of this article provides background information about hotplug devices and how they function on SVR5 operating systems:

Architecture of the hotplug subsystem

The SVR5 hotplug architecture includes several components:

Hotplug Manager User Interface (HPMUI): The administrative interface through which the user requests that a hotplug device be added, removed, or replaced.
Hot Plug Controller Interface (HPCI): The primary component for the underlying management of controller drivers and other device drivers. The HPCI tracks system component information and manages actions that support the hotplug features. HPCI manages all interaction between the hotplug subsystem and the resource manager database and the specfs kernel subsystem that implements special device files.
Hot Plug Controller Driver (HPCD): Passes hotplug operation requests from the HPCI to the bus and passes events to the HPCI. The operating system includes an HPCD; customers can write their own HPCD for other platforms using the HPCI versioned interface and DDI 8mp. The manual pages for the $interface hpci are in the Section D2hpci manual pages, Section D3hpci manual pages, and Section D4hpci manual pages.
Bus: Information from the HPCD is passed on the bus to the appropriate socket(s). A socket is an abstraction that identifies the connection point for an adapter card, such as a PCI slot or a PC-Card socket.
Drivers: Information on the socket is passed to the MDI version 2 network adapter driver or the SDI version 4 HBA driver. Drivers written to conform to DDI versions 8 and 8mp contain all the coding required to support the hotplug feature.

DDI 8 changes for hotplug

The DDI 8/8mp versioned interfaces include the driver interface features required to support hotplug of devices. Primarily, this means implementing drivers that have ``instance independence''. This means that the driver state for each device instance is independent of all other instances, so that a new instance can be added at any time, or an instance can be removed and the remaining instances will continue independently. It is also critical that, when a driver is entered on behalf of a particular device instance, it does not access any hardware of another device instance; this allows the driver instances to be independently bound to different CPUs (or, on ccNUMA configurations CPU groups) in case of asymmetric I/O with different device instances constrained to different locations.

In DDI 8, instance independence is implemented with the config(D2) entry point, which is called once for each driver instance that is added or removed. The initialization loop to discover devices through the init(D2) and start(D2) entry point routines is obsoleted in DDI 8. Once the driver is initialized, it receives config( ) calls, at any time, and initializes each device independently. Each device instance is identified by its resource manager key.

With hotplug support, resource manager information is changed more dynamically. To prevent race conditions and ensure consistency, any access to a resource manager entry must be made as part of a resource manager transaction. The transaction is begun with a call to cm_begin_trans(D3) or cm_newkey(D3). Modifications are made with the cm_addval(D3) or cm_delval(D3) functions, and then the transaction is completed with a call to the cm_end_trans(D3) function. Changes made are not visible to the system until after the cm_end_trans( ) function executes. Only one transaction can be in progress at a time (except for read-only transactions). Requests to begin new transactions while a transaction is in progress will block until the previous transaction completes.