B1.4.1 Device can be enumerated and automatically disabled
Each device connected to an expansion bus must be able to supply its own unique ID. The following are the specific requirements for Plug and Play device IDs:
-
Each separate function or device on the system board must be separately enumerated; therefore, each must provide a device ID in the manner required in the current Plug and Play specification for the bus it uses.
-
If a device on an expansion card is enumerated, it must have a unique ID and its own resources according to the current device ID requirements for the bus to which the card is connected. This includes devices that are separately enumerated on multifunction cards or multifunction chips.
-
Requirements and clarifications for automatic device configuration, resource allocation, and dynamic disable capabilities for legacy components such as serial and parallel ports, as defined in Legacy Plug and Play Guidelines at http://www.microsoft.com/hwdev/tech/pnp.
Dynamic disable capabilities must be supported for all devices. All devices must be capable of being automatically disabled by the system. Also, disabling the device must result in the freeing of all its resources for use by other devices.
The following are exceptions to the requirements for a unique Plug and Play ID:
-
Legacy devices attached to the Industry Standard Architecture (ISA) bus on the system board set do not have unique Plug and Play IDs—for example, serial ports, parallel ports, or PS/2-compatible port devices. The method for device identification is defined in Plug and Play ISA Specification, Version 1.0a, and the ACPI specification. Itanium-based systems must comply with ACPI 2.0; x86-based systems must comply with ACPI 1.0b.
-
Standard system devices. The system can reserve static resources for devices such as programmable interrupt controllers (PICs) 1 and 2, timer (8254-2), keyboard controller (8042), real-time clock, DMA page registers, and DMA controllers 1 and 2. For IA-32 systems, these fixed resources are located at I/O addresses under 100h and can also include a NMI.
-
Devices that are completely invisible to the operating system, such as out-of-band systems management devices or I2O hidden devices; however, these devices still must properly reserve resources using ACPI methods to avoid potential conflicts.
-
Some multifunction devices (such as Super I/O) might include devices that do not have unique Plug and Play IDs or unique PCI Subsystem IDs, but that are supported by drivers provided with Windows.
-
A device such as a multifunction PCI device that supports a number of functions but uses only a single set of relocatable resources does not have to provide separate identifiers for each function included on the device.
-
Some devices are completely invisible to or are not managed by the operating system, such as out-of-band systems management devices or I2O system and I2O hidden devices. Such devices are exempt from this requirement, but these devices still must properly reserve resources using ACPI methods to avoid potential conflicts.
If an OEM uses a proprietary mechanism to assign asset or serial numbers to hardware, this information must be available to the operating system using Windows hardware instrumentation technology, as defined in the Windows Hardware Instrumentation Implementation Guidelines, Version 1.0 (WHIIG).
See additional notes in specific device-class requirements.
B1.4.2 Software does not replace system components
See A5.1.1
Driver or software installation must not replace any Microsoft-authored operating system components.
Notice that each Windows product has a unique set of files protected under system file protection.
For information about protected operating system files, see SfcGetNextProtectedFile and SfcIsFileProtected APIs in the Microsoft Platform SDK.
If the manufacturer’s INF copies any files supplied by the operating system, those files must be copied from the Windows product disk (or preinstalled source files), unless the component is a licensed, redistributable component.
Driver must not use initialization files (INI) for configuration settings.
B1.4.3 Loading the driver does not reduce or eliminate functionality of other devices installed on the system B1.4.4 Device is functional without restarting the system
Device installation does not cause the system to stop running or reboot (unless reboot is required by the operating system) without user interaction.
It is acceptable to require rebooting for the primary hard disk controller. ATA drives need not implement Cable Select (CS) settings. In all cases, however, changing configuration settings must not require the end user to make jumper changes.
B1.4.5 Device and driver comply with ACPI and power management specifications
See A1.1.2
Device and driver comply with ACPI specification, Default Device Class Power Management Reference Specification, and other relevant device class power management specification.
(See additional notes in specific device-class requirements)
B1.4.5.1 Graphics adapter and all other devices correctly implement D3 state
Implement D3 state such that the operating system can correctly hibernate and resume from all sleep states supported by the system.
B1.4.5.2 – See B7.1.4.4 B1.4.5.3 The device must be fully functional upon resume from S3.
Every device must be tested on an S3-compliant system to verify that the device allows the system to successfully enter and resume from the S3 sleep state.
B1.4.7 DELETED B1.4.8 DELETED B1.4.9 DELETED B1.4.10 DELETED B1.4.11 DELETED B1.4.12 Hot-plugging does not damage system or device
To provide reliable support for hot-plugging capabilities, the following requirements must be met.
B1.4.12.1 USB, IEEE 1394, and PC Card devices and buses support hot-plugging.
USB, IEEE 1394, and PC Card specifications all support hot-plugging. A device designed to use any of these connections must support being added or removed while the system is fully powered on.
B1.4.12.2 Windows Server 2003, Standard Edition: System supports hot-plugging for any PCI devices that use ACPI-based methods.
Hot-plugging is not required for PCI devices. Windows supports dynamic enumeration, installation, and removal of PCI devices only if there is a supported hardware insert/remove notification mechanism. An example of an appropriate notification mechanism such as a bus standard is that provided by CardBus bus controllers. Other implementations, such as those for docking stations and hot-plugging of PCI devices, must comply with the hardware insert/remove notification mechanism as defined in Section 5.6.3 of the ACPI 1.0b specification. It should be noted that systems implementing hot-pluggable PCI capabilities compliant with the PCI Hot-Plug Specification, Revision 1.0, must still provide the hardware insert/remove notification mechanism as defined in Section 5.6.3 of ACPI 1.0b.
B1.4.12.3 All removable media support media status notification.
See B10.1.4.3.
|
