Freigeben über


Device.Buscontroller Requirements

Device.BusController.Bluetooth.Base

Bluetooth Controller - Generic radio tests

Related Requirements
Device.BusController.Bluetooth.Base.4LeSpecification
Device.BusController.Bluetooth.Base.LeStateCombinations
Device.BusController.Bluetooth.Base.LeWhiteList
Device.BusController.Bluetooth.Base.MicrosoftBluetoothStack
Device.BusController.Bluetooth.Base.NoBluetoothLEFilterDriver
Device.BusController.Bluetooth.Base.OnOffStateControllableViaSoftware
Device.BusController.Bluetooth.Base.RadioScanIntervalSettings
Device.BusController.Bluetooth.Base.Scatternet
Device.BusController.Bluetooth.Base.SimultaneousBrEdrAndLeTraffic
Device.BusController.Bluetooth.Base.SpecificInformationParameters
Device.BusController.Bluetooth.Base.SupportsBluetooth21AndEdr

Device.BusController.Bluetooth.Base.4LeSpecification

Bluetooth controllers must support the Bluetooth 4.0 specification requirements

Target Feature
Device.BusController.Bluetooth.Base
Applies to
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

The Bluetooth controller must comply with the Basic Rate (BR) and Low Energy (LE) Combined Core Configuration Controller Parts and Host/Controller Interface (HCI) Core Configuration requirements outlined in the Compliance Bluetooth Version 4.0 specifications.

Additional Information

Enforcement Date
Mar. 01, 2012

Device.BusController.Bluetooth.Base.LeStateCombinations

Bluetooth controllers must support a minimum set of LE state combinations.

Target Feature
Device.BusController.Bluetooth.Base
Applies to
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

The Bluetooth controller must allow the spec LE state combinations (as allowed in section [Vol 6] Part B, Section 1.1.1 of the Bluetooth version 4.0 spec):Only the following states are not required to be supported:0x0000000000800000 Active Scanning State and Initiating State combination supported.0x0000000004000000 Passive Scanning state and Slave Role combination supported.0x0000000008000000 Active Scanning state and Slave Role combination supported.

Additional Information

Enforcement Date
Mar. 01, 2012

Device.BusController.Bluetooth.Base.LeWhiteList

Bluetooth controllers must support a minimum LE white list size of 25 entries.

Target Feature
Device.BusController.Bluetooth.Base
Applies to
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

The Bluetooth controller must support a minimum of 25 entries in its white list for remote Low Energy (LE) devices.

Additional Information

Enforcement Date
Mar. 01, 2012

Device.BusController.Bluetooth.Base.MicrosoftBluetoothStack

Must test using Microsoft's Bluetooth stack

Target Feature
Device.BusController.Bluetooth.Base
Applies to
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

The Bluetooth controllers must be tested with Microsoft's Bluetooth stack when submitting for hardware certification.

Additional Information

Enforcement Date
Mar. 01, 2012

Device.BusController.Bluetooth.Base.NoBluetoothLEFilterDriver

Bluetooth LE filter drivers are not allowed to load on BTHLEENUM.SYS

Target Feature
Device.BusController.Bluetooth.Base
Applies to
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

To ensure a uniform experience across Windows Store Apps using the Bluetooth LE (GATT) WinRT API, filter drivers shall not be loaded on BTHLEENUM.SYS.

Additional Information

Business Justification
The GATT WinRT API provided for communication over Bluetooth LE is closely coupled to the driver implementing GATT support for the inbox Bluetooth stack, BTHLEENUM.SYS. All Windows Store Apps that use the Microsoft WinRT API for GATT rely on this interface to be work as originally implemented, thus there shall not be any 3rd party components that may intentionally or inadvertently affect this interface.
Enforcement Date
Jun. 26, 2013

Device.BusController.Bluetooth.Base.OnOffStateControllableViaSoftware

Bluetooth controllers On/Off state must be controllable via software

Target Feature
Device.BusController.Bluetooth.Base
Applies to
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

For Certifying Bluetooth controllers for Windows 8.1:

When turning the radio off , Bluetooth controllers shall be powered down to its lowest supported power state and no transmission/reception shall take place. Windows will terminate Bluetooth activity by unloading the inbox protocol drivers and their children, submitting the HCI_Reset command to the controller, and then setting the controller to the D3 logical power state, allowing bus drivers to power down the radio as appropriate. The radio can be completely powered off if a bus-supported method is available to turn the radio back on. No additional vendor software control components will be supported.

On turning the radio back on, the Windows Bluetooth stack shall resume the device to D0, allowing bus drivers to restart the device. The Windows Bluetooth stack shall then reinitialize the Bluetooth components of the controller.

Bluetooth Radio Management in Windows 8.1 shall only be enabled for internal Bluetooth 4.0 controllers.

For Windows 8 Certified controllers on upgrade to Windows 8.1:

On upgrade to Windows 8.1, previous DLL support for Bluetooth 4.0 controllers shall be ignored and the Bluetooth controller is expected to be, at a minimum, in a state where there is no transmission/reception from the antenna.

For Certifying Bluetooth controllers for Windows 8 only:

The previous requirement remains unchanged.

Bluetooth controllers On/Off state shall be controllable via software as described in Bluetooth Software Radio Switch The Off state is defined, at a minimum, as disabling the antenna component of the Bluetooth module so there can be no transmission/reception. There must not be any hardware-only switches to control power to the Bluetooth radio.

The radio must maintain on/off state across sleep and reboot.

Additional Information

Business Justification
The Windows 8.1 implementation of Bluetooth Radio Management provides for an improved Radio Management experience while decreasing the work needed by our IHV and OEM partners.
Enforcement Date
Jun. 26, 2013

Device.BusController.Bluetooth.Base.RadioScanIntervalSettings

Bluetooth controllers must use radio scan interval values as set by Windows

Target Feature
Device.BusController.Bluetooth.Base
Applies to
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

To ensure a uniform experience that balances power usage with responsiveness for users in reconnect scenarios, Bluetooth controllers must use the Page Scan Interval and LE Scan Interval values as set by Windows at all times.

Additional Information

Enforcement Date
Jun. 26, 2013

Device.BusController.Bluetooth.Base.Scatternet

Bluetooth host controller supports Bluetooth scatternet

Target Feature
Device.BusController.Bluetooth.Base
Applies to
Windows 7 Client x86, x64
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

The Bluetooth host controller must support at least two concurrent piconets (also known as a scatternet). The host controller must also be able to allow the host to join a device that is requesting a connection to the existing piconet when the local radio is the master of that piconet. This requirement is described in the Specification of the Bluetooth System, Version 2.1 + Enhanced Data Rate (EDR) (Baseband Specification), Section 8.6.6. Design Notes: The scatternet support should follow the enhanced scatternet support errata that are defined by the Bluetooth Special Interest Group (SIG).

Additional Information

Enforcement Date
Jun. 01, 2006

Device.BusController.Bluetooth.Base.SimultaneousBrEdrAndLeTraffic

Bluetooth controllers must support simultaneous BR/EDR and LE traffic.

Target Feature
Device.BusController.Bluetooth.Base
Applies to
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

Bluetooth controllers must allow the simultaneous use of both Basic Rate (BR)/Enhanced Data Rate (EDR) and Low Energy (LE) radios.

Additional Information

Enforcement Date
Mar. 01, 2012

Device.BusController.Bluetooth.Base.SpecificInformationParameters

Bluetooth host controller implements specific Informational parameters to provide accurate information about the host controller's capabilities

Target Feature
Device.BusController.Bluetooth.Base
Applies to
Windows 7 Client x86, x64
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

The manufacturer fixes the informational parameters, which provide valuable information about the Bluetooth device and the capabilities of the host controller. Bluetooth host controllers must implement the HCl_Read_Local_Version_Information command and HCI_Read_Local_Supported_Features command as described in the Specification of the Bluetooth System, Version2.1 + Enhanced Data Rate (EDR), Part E, Section 7.4. Required support includes the mechanism for reporting the supported version and features.

Additional Information

Enforcement Date
Jun. 01, 2006

Device.BusController.Bluetooth.Base.SupportsBluetooth21AndEdr

Bluetooth controllers must support the Bluetooth 2.1+EDR specification requirements

Target Feature
Device.BusController.Bluetooth.Base
Applies to
Windows 7 Client x86, x64

Description

The Bluetooth host controller must comply with the requirements that are outlined in the Specification of the Bluetooth System Version 2.1 + Enhanced Data Rate (EDR).

Additional Information

Enforcement Date
Jun. 01, 2009

Device.BusController.Bluetooth.NonUSB

Bluetooth Controller - NonUSB connected radios

Related Requirements
Device.BusController.Bluetooth.NonUSB.Performance
Device.BusController.Bluetooth.NonUSB.ScoSupport

Device.BusController.Bluetooth.NonUSB.Performance

Non-USB Bluetooth controllers must achieve at least a throughput of 700kbps

Target Feature
Device.BusController.Bluetooth.NonUSB
Applies to
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

Non-USB Bluetooth controllers must achieve at least a throughput of 700 kbps at the RFCOMM layer.

Additional Information

Enforcement Date
Mar. 01, 2012

Device.BusController.Bluetooth.NonUSB.ScoSupport

Non-USB connected Bluetooth controllers use sideband channel for SCO

Target Feature
Device.BusController.Bluetooth.NonUSB
Applies to
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

In order to ensure a high quality audio experience All non-USB connected Bluetooth controllers must use a sideband channel for SCO (e.g. SCO over an I2S/PCM interface)

Additional Information

Enforcement Date
Mar. 01, 2012

Device.BusController.Bluetooth.USB

Bluetooth Controller - USB connected radios

Related Requirements
Device.BusController.Bluetooth.USB.ScoDataTransportLayer

Device.BusController.Bluetooth.USB.ScoDataTransportLayer

Bluetooth host controllers support the SCO data transport layer as specified in the Bluetooth 2.1+EDR specifications

Target Feature
Device.BusController.Bluetooth.USB
Applies to
Windows 7 Client x86, x64
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

The Bluetooth host controller must comply with the Synchronous Connection Oriented (SCO)-USB requirements that are outlined in the Specification of the Bluetooth System, Version 2.1 + Enhanced Data Rate (EDR), Part A, Section 3.5.

Additional Information

Enforcement Date
Jun. 26, 2013

Device.BusController.I2C

These requirements apply only to I2C controller silicon vendors. System manufacturers may optionally run these tests but may need hardware customization.

Related Requirements
Device.BusController.I2C.CancellationOfIO
Device.BusController.I2C.ClockStretching
Device.BusController.I2C.HCKTestability
Device.BusController.I2C.IdlePowerManagement
Device.BusController.I2C.LockUnlockIOCTL
Device.BusController.I2C.NACK
Device.BusController.I2C.SPBRead
Device.BusController.I2C.SPBSequenceIOCTL
Device.BusController.I2C.SPBWrite
Device.BusController.I2C.Stress

Device.BusController.I2C.CancellationOfIO

I2C Controller and Controller Drivers support cancellation of I/O Requests

Target Feature
Device.BusController.I2C
Applies to
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

The I2C controller and associated controller driver must conform to the SPB framework and support the following:

Driver implements SPB request cancelation logic for read/write/sequence I/O.

Additional Information

Enforcement Date
Jun. 26, 2013

Device.BusController.I2C.ClockStretching

I2C Controller and Controller Drivers support peripheral clock stretching

Target Feature
Device.BusController.I2C
Applies to
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

The I2C controller and associated controller driver must conform to the SPB framework and support the following:

Controller can sustain peripheral holding clock for at least 2 seconds during read, write and sequence I/O.

Additional Information

Enforcement Date
Jun. 26, 2013

Device.BusController.I2C.HCKTestability

Systems with I2C Controllers must expose correct ACPI table information and I2C pin-outs to enable HCK testability.

Target Feature
Device.BusController.I2C
Applies to
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

The objective of this requirement is to enable the controller to be testable by the HCK framework.

Details:

Controller under test must provide I2C external connectivity pin-out(SCL,SDA and GND)

Update ACPI to correctly describe HCK test peripheral drivers and its connection to I2C controller under test.

Other peripheral devices on the same I2C controller under test must be disabled when running HCK tests.

Additional Information

Business Justification
Enable WITT based testing to empower I2C controller silicon partners to automate testing of their controller hardware/firmware/driver and ensure that it meets HCK requirements. By using hardware based testing, the silicon partner can quickly stress all aspects of the I2C controller and associated driver providing a higher quality bar
Enforcement Date
Jun. 26, 2013

Device.BusController.I2C.IdlePowerManagement

I2C Controller and Controller Drivers support Idle Power Management

Target Feature
Device.BusController.I2C
Applies to
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

The I2C controller and associated controller driver must conform to the SPB framework and support the following:

Controller should go to D3 state after idle for more than 1 second when screen is on.

Controller should not go to D3 state after idle less than 1 second when screen is on to avoid aggressive Dx transition.

Controller should go to D3 state after idle for more than 100ms when screen is off.

Controller takes less than 75ms (50+ 25 to account for the timer granularity of 15ms) to resume from D3 to D0 state

Additional Information

Enforcement Date
Jun. 26, 2013

Device.BusController.I2C.LockUnlockIOCTL

I2C Controller and Controller Drivers support Lock/Unlock IOCTL

Target Feature
Device.BusController.I2C
Applies to
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

If stop condition is supported, the I2C controller and associated controller driver must conform to the SPB framework and support the following:

Supports arbitrary number of read/write operations inside Lock/Unlock pair.

Generate Start condition for the first I/O in the lock/unlock sequence, restart condition for subsequent I/O, and stop condition when Unlock is called.

Additional Information

Enforcement Date
Jun. 26, 2013

Device.BusController.I2C.NACK

I2C Controller and Controller Drivers support peripheral NACK

Target Feature
Device.BusController.I2C
Applies to
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

The I2C controller and associated controller driver must conform to the SPB framework and support the following:

Controller can detect address NACK bus condition and return STATUS_NO_SUCH_DEVICE for request.

Controller can detect device NACK during a write operation, complete the request with STATUS_SUCCESS and information bytes is set to a number of bytes that is less than what was intended to be written

Controller can detect device NACK during a write operation of a sequence IOCTL, complete the request with STATUS_SUCCESS and information bytes is set to number of bytes that is less than what was intended to be written.

Additional Information

Exceptions
Once we see the V2 silicon, we will need to validate if all sequences are required or if some need to be changed to optional.
Enforcement Date
Jun. 26, 2013

Device.BusController.I2C.SPBRead

I2C Controller and Controller Drivers support SPB Read operations correctly

Target Feature
Device.BusController.I2C
Applies to
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

The I2C controller and associated controller driver must conform to the SPB framework and support the following when reading data from an I2C peripheral:

Must support reading from standard (100Kbps), fast (400kbps) and fast plus (1Mbps) peripheral targets. High Speed (3.4MHz) is optional but must pass all HCK requirements for I2C if implemented in the I2C controller and controller driver.

Must support read size from 1 to 4096 bytes (4KBytes).

Sizes larger than 4KBytes must succeed or fail with STATUS_NOT_SUPPORTED.

SPB read is mapped into Start, Read Data, NACK and Stop I2C conditions.

Fail any unsupported data size read request with STATUS_INVALID_PARAMETER and not cause any bus activities.

Additional Information

Enforcement Date
Jun. 26, 2013

Device.BusController.I2C.SPBSequenceIOCTL

I2C Controller and Controller Drivers support SPB Sequence IOCTL correctly

Target Feature
Device.BusController.I2C
Applies to
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

The I2C controller and associated controller driver must confirm to the SPB framework and support the following:

Supports any arbitrary I/O sequences: write-read, read-write, write-write, read-read and complex combined such as write-read-read-write-write

SPB sequence IOCTL is mapped into Start, I/O sequence 1, Restart .I/O sequence N, Stop I2C conditions.

Controller needs to examine the sequence and determine if it is supported or fail with STATUS_INVALID_PARAMETER before causing any bus activities.

Support any valid parameters (e.g. DelayInUs) and memory format(SIMPLE, MDL, Buffer list etc.) as defined by SPB.

Additional Information

Exceptions
Once we see the V2 silicon, we will need to validate if all sequences are required or if some need to be changed to option
Enforcement Date
Jun. 26, 2013

Device.BusController.I2C.SPBWrite

I2C Controller and Controller Drivers support SPB Write operations correctly

Target Feature
Device.BusController.I2C
Applies to
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

The I2C controller and associated controller driver must confirm to the SPB framework and support the following when writing to an I2C peripheral:

Must support writing to standard (100Kbps), fast (400kbps) and fast plus (1Mbps) peripheral targets. High Speed (3.4MHz) is optional but must pass all HCK requirements for I2C if implemented in the I2C controller and controller driver.

Must supports write size from 1 to 4096 bytes (4KBytes).

Sizes larger than 4KBytes must succeed or fail with STATUS_NOT_SUPPORTED.

SPB write is mapped into Start, Write Data and Stop I2C conditions.

Fail any unsupported data size write request with STATUS_INVALID_PARAMETER and not cause any bus activities.

Additional Information

Enforcement Date
Jun. 26, 2013

Device.BusController.I2C.Stress

I2C Controller and Controller Driver operates correctly and recovers from bus hangs or faults under prolonged stress conditions

Target Feature
Device.BusController.I2C
Applies to
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

The I2C controller and associated controller driver must confirm to the SPB framework and support the following:

Supports bus recovery when peripheral is hung (watchdog mechanism).

Sustain multiple targets stress for more than 1 hour.

Additional Information

Enforcement Date
Jun. 26, 2013

Device.BusController.NearFieldProximity

Near Field Proximity is a set of short range wireless technologies to enable communication between a personal computer and a device.

Related Requirements
Device.BusController.NearFieldProximity.NFCCertification
Device.BusController.NearFieldProximity.NFCControllerNCICompliance
Device.BusController.NearFieldProximity.ProviderImplementation
Device.BusController.NearFieldProximity.ProximityReliability
Device.BusController.NearFieldProximity.RangeOfActuation
Device.BusController.NearFieldProximity.SessionEstablishmentPerformance
Device.BusController.NearFieldProximity.TaptoSetupScenario
Device.BusController.NearFieldProximity.TapToUseScenarios

Device.BusController.NearFieldProximity.NFCCertification

NFC Implementations must receive NFC certification

Target Feature
Device.BusController.NearFieldProximity
Applies to
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

An NFP provider that implements air interface specifications incorporated by NFC Forum by reference as approved specifications must receive Certification from the NFC Forum, inclusive of:

Wave 1 compliance

SNEP compliance

Additional Information

Enforcement Date
Jun. 01, 2010

Device.BusController.NearFieldProximity.NFCControllerNCICompliance

Devices that implement NFC technology must be compliant with the NFC Controller Interface Specification

Target Feature
Device.BusController.NearFieldProximity
Applies to
Windows 8.1 Client x86, x64

Description

An NFC controller in a system or device must be compliant with the NFC Controller Interface (NCI) Specification 1.0 or later. The NFCForum-TS-NCI-1.0 technical specification defines a transport independent communication protocol, using RF Interfaces, to enable a standardized way to communicate between the NFC Controller (NFCC) and a Device Host (DH).

The NFCForum-TS-NCI-1.0 Technical Specification is available at https://www.nfc-forum.org/specs/

Additional Information

Enforcement Date
Jun. 26, 2013

Device.BusController.NearFieldProximity.ProviderImplementation

Device proximity adheres to the Proximity Provider model

Target Feature
Device.BusController.NearFieldProximity
Applies to
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

Any technology that implements the GUID_DEVINTERFACE_PROXIMITYPROVIDER device driver interface specified in the 'Windows 8 Near Field Proximity Implementation Specification' document is defined as an NFP provider and must meet all the design and implementation requirements laid out within the spec as well as all other applicable NFP certification requirements. The spec can be found at:https://go.microsoft.com/fwlink/?LinkId=237135

Additional Information

Enforcement Date
Mar. 01, 2012

Device.BusController.NearFieldProximity.ProximityReliability

Proximity provider meets session reliability requirements

Target Feature
Device.BusController.NearFieldProximity
Applies to
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

An NFP provider must support performant completion of Windows scenarios. Within a period of 2.5 minutes the devices must be able to establish 95 successful sessions out of 100 attempts. The test scenario consists of:

Provide two machines to carry out the test with a test app.

Tap the two machines together.

Validate that a session is established between the two devices within one second.

Repeat from step 2.

Attempt this 100 times

A pass is recorded if at least 95 sessions are established.

Additional Information

Enforcement Date
Mar. 01, 2012

Device.BusController.NearFieldProximity.RangeOfActuation

Proximity technology meets range of actuation

Target Feature
Device.BusController.NearFieldProximity
Applies to
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

An NFP provider must support an effective operating volume to enable users to successfully use NFP technology with Windows in 95 times out of 100 attempts for all tap and do scenarios. Refer to the most current version of the 'Windows 8 Near Field Proximity Implementation Specification' document for detailed placement guidance, as well as acceptable, minimum, and maximum values for the required effective operating volume. The spec can be found at:https://go.microsoft.com/fwlink/?LinkId=237135

Additional Information

Enforcement Date
Mar. 01, 2012

Device.BusController.NearFieldProximity.SessionEstablishmentPerformance

Proximity technology establishes a session in 0.5 second

Target Feature
Device.BusController.NearFieldProximity
Applies to
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

An NFP provider must support the creation of sessions within 0.5 seconds from the point of being detected within the effective operating volume. As a point of information, the baseline expected performance in this test for NFC is as follows:

One instance of the same app on two systems attempt to establish a session.

During the session establishment, the total data transferred at the SNEP layer should be no more than 11kb.

The expected worst-case transfer rate for NFC is 106kbps, so the total time required at the air interface should be 11kb/106kbps, so 0.103 seconds of time.

The remaining 0.307 seconds of time is for buffering and latency in the busses and stacks.

Additional Information

Enforcement Date
Mar. 01, 2012

Device.BusController.NearFieldProximity.TaptoSetupScenario

Provider must support the handling of the tap and setup scenario

Target Feature
Device.BusController.NearFieldProximity
Applies to
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

An NFP provider must unwrap the out-of-band pairing information from the transmission format so that only the out-of-band pairing information is presented to Windows. Detailed guidance and requirements are further defined in the most current version of the 'Windows 8 Near Field Proximity Implementation Specification' document. The spec can be found at:https://go.microsoft.com/fwlink/?LinkId=237135

Additional Information

Enforcement Date
Mar. 01, 2012

Device.BusController.NearFieldProximity.TapToUseScenarios

Provider must support the handling of the tap and use scenarios

Target Feature
Device.BusController.NearFieldProximity
Applies to
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

An NFP provider must support the end-to-end NFP use cases of tap and use, tap and launch, tap and share, tap and acquire, and tap and receive. Details are further defined in the most current version of the 'Windows 8 Near Field Proximity Implementation Specification' document. The spec can be found at:https://go.microsoft.com/fwlink/?LinkId=237135

Additional Information

Enforcement Date
Mar. 01, 2012

Device.BusController.SdioController

Related Requirements
Device.BusController.SdioController.ComplyWithIndustrySpec
Device.BusController.SdioController.WdfKmdfDriver

Device.BusController.SdioController.ComplyWithIndustrySpec

SDIO Controller Complies with industry Standard

Target Feature
Device.BusController.SdioController
Applies to
Windows 7 Client x86, x64
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)
Windows Server 2012 R2 x64
Windows Server 2008 x86, x64,
Windows Server 2008 Release 2 x64
Windows Server 2012 x64

Description

Secure Digital I/O (SDIO) host controllers must comply with PCI 2.3 or later requirements for that interface. For PCI configuration registers and interface information, see the SD Host Controller Specification, Version 1.0, Appendix A.

Additional Information

Enforcement Date
Jun. 01, 2007

Device.BusController.SdioController.WdfKmdfDriver

SDIO Controller driver must be a WDF KMDF Implementation

Target Feature
Device.BusController.SdioController
Applies to
Windows 7 Client x86, x64
Windows 8 Client x86, x64
Windows 8.1 Client x86, x64
Windows Server 2012 R2 x64
Windows Server 2008 x86, x64,
Windows Server 2008 Release 2 x64
Windows Server 2012 x64

Description

The SDIO Controller driver must be written using the Windows Driver Framework (WDF) Kernel Mode Driver Framework for the driver's implementation.

Additional Information

Enforcement Date
Jun. 01, 2007

Device.BusController.UART

The requirements apply only to silicon vendors. UART controller drivers are recommended to use SerCXV2.

Related Requirements
Device.BusController.UART.Cancellation
Device.BusController.UART.DMA
Device.BusController.UART.FlowControl
Device.BusController.UART.FlushFIFO
Device.BusController.UART.HCKTestability
Device.BusController.UART.IdlePowerManagement
Device.BusController.UART.Performance
Device.BusController.UART.ReadWrite
Device.BusController.UART.Stress
Device.BusController.UART.SupportedBaudRates

Device.BusController.UART.Cancellation

UART Controller and Controller Drivers support cancellation of Read and Write requests

Target Feature
Device.BusController.UART
Applies to
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

The UART controller and associated controller driver must confirm to the Serial framework and support the following:

Controller implements necessary logic to support I/O cancellation

Additional Information

Exceptions
Once we see the V2 silicon, we will need to validate if all sequences are required or if some need to be changed to optional.
Enforcement Date
Jun. 26, 2013

Device.BusController.UART.DMA

UART Controller and Controller Drivers require DMA support for appropriate DMA Transactions

Target Feature
Device.BusController.UART
Applies to
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

The UART controller and associated controller driver must confirm to the Serial framework and support the following:

Peripheral driver can issue read and write request to the controller max at 5K data size.

Additional Information

Enforcement Date
Jun. 26, 2013

Device.BusController.UART.FlowControl

UART Controller and Controller Drivers support setting flow control on and off

Target Feature
Device.BusController.UART
Applies to
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

The UART controller and associated controller driver must confirm to the Serial framework and support the following:

Driver implements support for IOCTL_SERIAL_GET_HANDFLOW and IOCTL_SERIAL_SET_HANDFLOW IOCTLs and flow control settings

Additional Information

Enforcement Date
Jun. 26, 2013

Device.BusController.UART.FlushFIFO

UART Controller and Controller Drivers support Flush FIFOs

Target Feature
Device.BusController.UART
Applies to
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

The UART controller and associated controller driver must confirm to the Serial framework and support the ability to Flush FIFO queues.

Additional Information

Enforcement Date
Jun. 26, 2013

Device.BusController.UART.HCKTestability

Systems with UART Controllers must expose correct ACPI table information and UART pin-outs to enable HCK testability

Target Feature
Device.BusController.UART
Applies to
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

The objective of this requirement is to enable the UART controller to be testable by the HCK framework.

Details:

Controller under test must provide UART external connectivity pin-out(Rx,Tx, RTS, CTS and GND)

Describe HCK UART test peripheral driver and its connection to UART controller under test in device s firmware.

Additional Information

Enforcement Date
Jun. 26, 2013

Device.BusController.UART.IdlePowerManagement

UART Controller and Controller Drivers support Idle Power Management

Target Feature
Device.BusController.UART
Applies to
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

The UART controller and associated controller driver must confirm to the Serial framework and support the following:

Controller transitions to Dx state when there is no pending I/O in the controller for 200 ms.

Additional Information

Enforcement Date
Jun. 26, 2013

Device.BusController.UART.Performance

UART Controller and Controller Drivers has a measured baud rate that matches the expected value

Target Feature
Device.BusController.UART
Applies to
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

The UART controller and associated controller driver must confirm to the Serial framework that the measured baud rate matches the expected value .

Additional Information

Enforcement Date
Jun. 26, 2013

Device.BusController.UART.ReadWrite

UART Controller and Controller Drivers support read/write Unicode(8 bits) data

Target Feature
Device.BusController.UART
Applies to
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

The UART controller and associated controller driver must confirm to the Serial framework and support the following when reading data from an UART peripheral:

Support IOCTL_SERIAL_SET_LINE_CONTROL and IOCTL_SERIAL_GET_LINE_CONTROL and be able to transfer data according to the data length settings(8 bits).

Additional Information

Enforcement Date
Jun. 26, 2013

Device.BusController.UART.Stress

UART Controller and Controller Driver operates correctly (and recovers appropriately from bus errors) under prolonged stress conditions

Target Feature
Device.BusController.UART
Applies to
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

The UART controller and associated controller driver must confirm to the Serial framework and support the following:

Sustain stress test passes for at least 1 hour.

Additional Information

Enforcement Date
Jun. 26, 2013

Device.BusController.UART.SupportedBaudRates

UART Controller and Controller Drivers support basic baud rate 115200 and faster speed for higher bandwidth communications

Target Feature
Device.BusController.UART
Applies to
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

The UART controller and associated controller driver must confirm to the Serial framework and support the following:

Driver supports IOCTL_SERIAL_SET_BAUD_RATE and IOCTL_SERIAL_GET_BAUD_RATE IOCTL.

Driver should fail baud rate setting for non-supported baud rate and is able perform I/O using the baud rate set.

Additional Information

Enforcement Date
Jun. 26, 2013

Device.BusController.UsbController

Requirements that apply to USB Controllers

Related Requirements
Device.BusController.UsbController.ImplementAtLeastOneXhciSpcStructForUSB2
Device.BusController.UsbController.MaintainDeviceStateOnResumeS1andS3
Device.BusController.UsbController.MustResumeWithoutForcedReset
Device.BusController.UsbController.PreserveDeviceStateAfterDisableEnable
Device.BusController.UsbController.SpecificationCompliance
Device.BusController.UsbController.SuperSpeedConnectorsSupportHighFullLow
Device.BusController.UsbController.SupportSelectiveSuspend
Device.BusController.UsbController.TestedUsingMicrosoftUsbStack
Device.BusController.UsbController.UsbifCertification
Device.BusController.UsbController.XhciAc64Bit
Device.BusController.UsbController.XhciAddInCardsMapPortsConsistently
Device.BusController.UsbController.XhciAddInCardsReportInternalDevices
Device.BusController.UsbController.XhciSupportDebuggingOnAllExposedPorts
Device.BusController.UsbController.XhciSupportMsiMsixInterrupts
Device.BusController.UsbController.XhciSupportsMinimum31Streams
Device.BusController.UsbController.XhciSupportsRuntimePowerManagement
Device.BusController.UsbController.XhciVersionCompliant

Device.BusController.UsbController.ImplementAtLeastOneXhciSpcStructForUSB2

xHCI Controllers implement at least one xHCI Supported Protocol Capability structure for USB 2.0

Target Feature
Device.BusController.UsbController
Applies to
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)
Windows Server 2012 R2 x64
Windows Server 2012 x64

Description

Extensible Host Controller Interface (xHCI) controllers implement at least one xHCI Supported Protocol Capability structure for USB 2.0 as described in section 7.2 of the xHCI Specification.This affects backward compatibility with USB 2.0.

Additional Information

Enforcement Date
Dec. 01, 2010

Device.BusController.UsbController.MaintainDeviceStateOnResumeS1andS3

USB host controller maintains device state on resume from S1 or S3

Target Feature
Device.BusController.UsbController
Applies to
Windows 7 Client x86, x64
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)
Windows Server 2012 R2 x64
Windows Server 2008 Release 2 x64
Windows Server 2012 x64

Description

For the host controller to maintain the device state, the USB host controller must not issue a USB bus reset on a system sleep state transition from S3 to S0 or from S1 to S0. USB host controllers that are integrated or embedded into the south bridge chipset must decouple the USB bus reset from the PCI bus reset to reduce resume time. Resume operations from S1 or S3 must not generate USB bus resets. A USB bus reset is a reset signal that is sent over the USB bus to USB devices that are connected to the USB host controller. Systems that have a USB keyboard attached are allowed to perform USB bus resets to unlock the system by using a password when the system resumes from S3.For security purposes, the BIOS in a mobile system is allowed to issue a USB bus reset if the system is attached to a docking station that has a hard disk drive (HDD) that is password-locked on first resume. A reset of the HDD password is allowed whether or not the mobile system is docked. The following scenarios are allowed:

Undocked systems with a password-enabled HDD

Docked systems with a password-enabled HDD

Addition or removal of an HDD

If the docking station does not have a native HDD or the docking station does not have a password, the BIOS must not issue a USB bus reset.It is acceptable to allow the controller to lose power in S3 when the system is on battery power.Design Notes: See the Enhanced Host Controller Interface Specification for Universal Serial Bus, Revision 1.0, Appendix A.This requirement does not apply to Systems that Support Connected Standby.

Additional Information

Enforcement Date
Jun. 01, 2007

Device.BusController.UsbController.MustResumeWithoutForcedReset

All USB host controllers work properly upon resume from sleep, hibernation or restart without a forced reset.

Target Feature
Device.BusController.UsbController
Applies to
Windows 7 Client x86, x64
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)
Windows Server 2012 R2 x64
Windows Server 2008 Release 2 x64
Windows Server 2012 x64

Description

All USB host controllers work properly upon resume from sleep, hibernation or restart without a forced reset of the USB host controllerDesign Notes:A reset of the entire USB Host Controller results in significantly increased time that it takes for all USB devices to become available after system resume since there could be only one device at address 0 at a time, this enumeration has to be serialized for all USB devices on the bus. We have also seen that resetting the host controller can lead to an illegal SE1 signal state on some host controllers, which in turn can cause some USB devices to hang or drop off the bus. Moreover, devices cannot maintain any private state across sleep resume as that state will be lost on reset.

Additional Information

Enforcement Date
Jun. 01, 2010

Device.BusController.UsbController.PreserveDeviceStateAfterDisableEnable

USB controller preserves device states after a disable and re-enable

Target Feature
Device.BusController.UsbController
Applies to
Windows 7 Client x86, x64
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)
Windows Server 2012 R2 x64
Windows Server 2008 Release 2 x64
Windows Server 2012 x64

Description

If a USB controller is disabled and then re-enabled, all devices that were attached to the controller before the USB controller was disabled are required to be present after the USB controller is re-enabled.

Additional Information

Enforcement Date
Jun. 01, 2009

Device.BusController.UsbController.SpecificationCompliance

USB host controller that supports USB functionality complies with the appropriate specification

Target Feature
Device.BusController.UsbController
Applies to
Windows 7 Client x86, x64
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)
Windows Server 2012 R2 x64
Windows Server 2008 Release 2 x64
Windows Server 2012 x64

Description

Host controllers that provide USB 1.1 functionality but don't provide USB 2.0 or USB 3.0 functionality must comply with either the Open Host Controller Interface (OHCI) Specification for USB or the Universal Host Controller Interface (UHCI) Design Guide, Revision 1.1. Host controllers that provide USB 2.0 functionality but don't provide USB 3.0 functionality must comply with the Enhanced Host Controller Interface Specification (EHCI) for Universal Serial Bus 2.0. EHCI host controllers must comply with the Enhanced Host Controller Interface Specification for Universal Serial Bus, Revision 1.0 or later.

Additional Information

Enforcement Date
Jun. 01, 2006

Device.BusController.UsbController.SuperSpeedConnectorsSupportHighFullLow

Exposed Super Speed capable connectors support high, full and low speed USB devices

Target Feature
Device.BusController.UsbController
Applies to
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)
Windows Server 2012 R2 x64
Windows Server 2012 x64

Description

Extensible Host Controller Interface (xHCI) controllers are backward-compatible with high-speed, full-speed, and low-speed USB devices. "Backward compatible" means that all USB devices enumerate and function at their intended speeds.This requirement ensures that low-, full-, and high-speed devices continue to work when xHCI controllers become more prevalent in systems. Design Notes: Integrated rate-matching (TT) hubs can be used to achieve this backward compatibility.

Additional Information

Enforcement Date
Dec. 01, 2010

Device.BusController.UsbController.SupportSelectiveSuspend

USB Host Controller supports selective suspend

Target Feature
Device.BusController.UsbController
Applies to
Windows 7 Client x86, x64
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)
Windows Server 2012 R2 x64
Windows Server 2008 Release 2 x64
Windows Server 2012 x64

Description

A USB host controller can selectively suspend devices that support the selective suspend feature.

Additional Information

Enforcement Date
Jun. 01, 2009

Device.BusController.UsbController.TestedUsingMicrosoftUsbStack

xHCI Controllers must be tested with Microsoft's xHCI Stack installed

Target Feature
Device.BusController.UsbController
Applies to
Windows 7 Client x86, x64
Windows 8 Client x86, x64
Windows 8.1 Client x86, x64
Windows Server 2012 R2 x64
Windows Server 2008 Release 2 x64
Windows Server 2012 x64

Description

Extensible Host Controller Interface (xHCI) Controllers must be tested with Microsoft's xHCI stack installed and enabled on a Windows system.Note: During USB-IF self testing a specific USB Test Stack is installed for testing purposes, this is expected and acceptable.

Additional Information

Enforcement Date
Mar. 01, 2012

Device.BusController.UsbController.UsbifCertification

USB Host Controller is USB IF certified

Target Feature
Device.BusController.UsbController
Applies to
Windows 7 Client x86, x64
Windows 8 Client x86, x64
Windows 8.1 Client x86, x64
Windows Server 2012 R2 x64
Windows Server 2008 Release 2 x64
Windows Server 2012 x64

Description

Starting June 1, 2011, USB host controllers must pass USB Implementers Forum (IF) testing.For details see the following link:https://msdn.microsoft.com/windows/hardware/gg463175.aspxNote: Since USB-IF is currently not certifying controllers for Windows on ARM systems, the Windows on ARM controllers are exempt from needing to get full USB-IF certification. Instead the WoA controllers are expected to pass all Windows Hardware Certification tests which include eventing, loop back and registers tests that get run as part of USB-IF certification.

Additional Information

Exceptions
Systems that Support Connected Standby may pass a subset of USB-IF tests instead of being USB-IF certified, since USB-IF does not certify Systems that Support Connected Standby.
Enforcement Date
Jun. 01, 2011

Device.BusController.UsbController.XhciAc64Bit

xHCI Controllers set the AC64 bit in the HCCPARAMS register to 1

Target Feature
Device.BusController.UsbController
Applies to
Windows 8 Client x86, x64
Windows 8.1 Client x86, x64
Windows Server 2012 R2 x64
Windows Server 2012 x64

Description

xHCI Controllers set the AC64 bit in the HCCPARAMS register to 1 as described in Section 5.3.6 of the xHCI specification.Therefore the controller must support:

64-bit addressing, described in section 5.3.6, and

64-bit register access, described in section 5.1.

Design notes:Checking for AC64 to be set is a simple register check in the compliance driver.To test 64-bit addressing, we will need to require the WLK user's client system to have at least 6GB of RAM. The test will use MmAllocateContiguousMemorySpecifyCache to get physical memory above 4GB. It will validate in some way that the controller can access this memory area.The test will try writing one or more registers using a 64-bit register access and reading back using 64-bit register access to confirm that registers are updated correctly. An example of a reasonable register to test is: "Event Ring Segment Table Base Address Register (ERSTBA)" (section 5.3.2.3.2).If AC64 is not set, there is nothing to test.

Additional Information

Exceptions
This Requirement does NOT apply to Systems that Support Connected Standby.
Enforcement Date
Dec. 01, 2010

Device.BusController.UsbController.XhciAddInCardsMapPortsConsistently

xHCI add in cards must map USB 3.0 and USB 2.0 ports consistently

Target Feature
Device.BusController.UsbController
Applies to
Windows 8 Client x86, x64
Windows 8.1 Client x86, x64
Windows Server 2012 R2 x64
Windows Server 2012 x64

Description

Consistent USB 2.0 and USB 3.0 port mapping is required to help the operating system to effectively manage the ports. Note: This requirement only applies to add-in cards because port mapping for integrated xHCI controllers should be performed via Advanced Configuration and Power Interface (ACPI). For more information, see the SYSFUND 226 requirement.For Extensible Host Controller Interface (xHCI) add-in cards (where "add-in card" is defined as a card that is not integrated onto the motherboard), the complexity of this requirement varies significantly depending on whether the add-in card contains any internal (integrated or embedded) hubs. If there are no internal hubs, then the port numbering must correlate as given in xHCI v1.x Specification. That is, the first USB 3.0 port must be connected to the same connector as the first 2.0 port, the second with the second, and so on. For example, if the USB 2.0 ports are numbered 1 and 2, and the USB 3.0 ports are numbered 3 and 4, ports 1 and 3 must map to the same connector, and ports 2 and 4 must map to the same connector. For more information, see the xHCI v1.x Specification, sections 4.24.2.1 and 4.24.2.2. If the host does not have any internal hubs, then the remaining text of this requirement can be ignored.However, if there are internal hubs (either integrated or embedded), then the requirement is more involved. Note that strictly speaking, XHCI specification does not allow such hubs for add-in cards because the port mapping information cannot be communicated to the software via ACPI. But through this requirement, we are allowing such hubs and defining the required port mapping. However, this mechanism has some limitations and it does not allow arbitrary configurations that are allowed for integrated controllers when described by ACPI.For add-in cards, xHCI host controllers may implement "integrated hubs" and/or "embedded hubs" as defined in xHCI specification sections 4.24.2.1 and 4.24.2.2. Embedded hubs need not be limited to being on the system board. However, the following limitations apply:

Embedded hubs of add-in cards must be USB 3.0 hubs (this limitation is unique to the scenario of this requirement and not part of the xHCI specification).

An add-in card may have at most 1 integrated hub.

If an add-in card has an integrated hub, it must have only 1 USB2 protocol port on the root hub. This port is the port connected to the integrated hub.

An add-in xHCI card that implements an integrated hub must set the Integrated Hub Implemented (IHI) bit in the USB 2.0 xHCI Supported Protocol Capability structure to '1' for the root hub port connected to an integrated hub (refer to section 7.2.2.1.3.2 of the xHCI specification).

All integrated or embedded hubs must be marked non-removable in their parent ports.

The implementation of integrated hubs determines the External Ports of the controller. External Ports are a concept defined in section 4.24.2 of the xHCI specification to order ports so that they can be mapped to connectors. In all cases, let there be n USB2 protocol External Ports numbered 1 to n, and m USB3 protocol External Ports numbered n+1 to n+m. External Port numbers are assigned to meet the following properties (not defined in the xHCI specification). Note that integrated hubs must be USB 2.0 hubs.

If the xHCI implements an integrated hub, then n, the number of USB2 protocol External Ports, equals the number of downstream facing ports on the integrated hub.

Otherwise, n equals the number of downstream facing USB2 protocol ports on the root hub.

m, the number of USB3 protocol External Ports, equals the number of downstream facing USB3 protocol ports on the root hub.

Assign External Port numbers such that External Ports 1 through n are USB2 protocol ports and External Ports n+1 through n+m are USB3 protocol external ports, and the ordering ports within each protocol is preserved.

If embedded hub(s) are not present: The USB2 protocol External Ports and USB3 protocol External Ports must be mapped to connectors using the "default" mapping described in section 4.24.2.2 of the xHCI specification under the heading "When an Embedded hub is not implemented".If embedded hub(s) are present: The embedded hubs must be USB 3.0 hubs. First determine the connector mapping as it would be without any embedded hubs, using the "default" mapping from section 4.24.2.2 of the xHCI specification. For each embedded hub, both upstream ports must be connected to the same connector. The embedded hubs' downstream ports map to new connectors in the same way as the ports of a non-embedded USB 3.0 hub.Non-exposed connectors: Devices embedded in the host controller must be marked non-removable in their parent ports. If, according to the connector mapping above, a non-removable peripheral device's connector is shared with a second port, the second port must not be connected or connectable to any device. On the other hand, any connector whose port(s) are all marked as removable is considered to be an exposed connector, i.e. it must be physically connectable.Note that if there is no ACPI information, a root hub cannot have both an embedded USB2 device and an integrated USB2 hub; instead, the embedded device must be attached to the integrated hub.

Additional Information

Exceptions
This Requirement does NOT apply to Systems that Support Connected Standby
Enforcement Date
Dec. 01, 2010

Device.BusController.UsbController.XhciAddInCardsReportInternalDevices

xHCI controller add in cards correctly report internally attached devices

Target Feature
Device.BusController.UsbController
Applies to
Windows 8 Client x86, x64
Windows 8.1 Client x86, x64
Windows Server 2012 R2 x64
Windows Server 2012 x64

Description

Extensible Host Controller Interface (xHCI) controllers must indicate internally attached devices by setting the device removable (DR) bit in the PORTSC register to 1 for every port that has an internally attached device. This applies to controllers that do not have ACPI information. For more information, see section 5.4.8 of the xHCI Specification.

This requirement will prevent the operating system from flagging non-removable devices as removable.

Add-in cards are defined as host controllers that are not integrated onto the motherboard.

Design Notes:Note: This requirement only applies to add-in cards because port mapping for integrated xHCI controllers should be performed via Advanced Configuration and Power Interface (ACPI).

Additional Information

Enforcement Date
Dec. 01, 2010

Device.BusController.UsbController.XhciSupportDebuggingOnAllExposedPorts

xHCI Controllers support USB debugging on all exposed ports

Target Feature
Device.BusController.UsbController
Applies to
Windows 8 Client x86, x64
Windows 8.1 Client x86, x64
Windows Server 2012 R2 x64
Windows Server 2012 x64

Description

Extensible Host Controller Interface (xHCI) host controllers are debug-capable on all ports. Ports that have embedded non-removable devices attached do not need to report debug capability.

USB debugging is defined in section 7.6 of the xHCI specification.

This requirement does not apply to add-in card host controllers.

This requirement is effective as of June 2012.

Additional Information

Enforcement Date
Jun. 01, 2012

Device.BusController.UsbController.XhciSupportMsiMsixInterrupts

xHCI Controllers support MSI and/or MSI-X interrupts

Target Feature
Device.BusController.UsbController
Applies to
Windows 8 Client x86, x64
Windows 8.1 Client x86, x64
Windows Server 2012 R2 x64
Windows Server 2012 x64

Description

Extensible Host Controller Interface (xHCI) controllers support Message Signaled Interrupts (MSI) and MSI-X interrupts as defined in section 6.8 of the PCI Local Bus Specification, revision 3.0 and section 5.2.6 of the xHCI Specification.

Additional Information

Exceptions
This Requirement does NOT apply to Systems that Support Connected Standby
Enforcement Date
Dec. 01, 2010

Device.BusController.UsbController.XhciSupportsMinimum31Streams

xHCI controller must support at least 31 primary streams per endpoint

Target Feature
Device.BusController.UsbController
Applies to
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)
Windows Server 2012 R2 x64
Windows Server 2012 x64

Description

Refer to the eXtensible Host Controller Interface specification, section 4.12.2.This requirement is for the MaxPSASize in the HCCPARAMS to be set to 4 at the minimum to enable ultimate data transfer rate with UAS devices. Storage devices based on the USB Attached SCSI Protocol (UASP) will utilize streams to achieve faster data transfer rates. To enable the best experience with these devices, every xHCI controller will need to support at least 31 primary streams.

Additional Information

Enforcement Date
Mar. 01, 2012

Device.BusController.UsbController.XhciSupportsRuntimePowerManagement

USB xHCI host controllers support runtime power management including, if implemented, runtime wake

Target Feature
Device.BusController.UsbController
Applies to
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

All USB xHCI host controllers must support runtime power management, as required by the eXtensible Host Controller Interface specification, version 1.0, Section 4.15.Runtime is defined as the system working state (S0), including the Connected Standby sub-state of S0 if the controller is tested on a system that supports Connected Standby.Power management of the host controller encompasses software-initiated idle power down (controller low power state such as D3), software-initiated power up, and, optionally, hardware-initiated wake signaling.If the xHCI controller is reported to support runtime wake signaling, it must be able to wake itself successfully upon any of the following events:A) Any port detecting device wake signaling, orB) Any port detecting connect, disconnect, or overcurrent, when the corresponding PORTSC Wake on Xxx bit is set to '1'.For more details, see Section 4.15 of the xHCI specification.To report whether the controller supports runtime wake signaling:- For add-in controllers, the controller's PCI configuration space must accurately report whether the controller is capable of waking up via PME. Note: reporting that the controller supports waking up via PME implies that the controller can both successfully perform PCI wake at runtime, and successfully wake the system from a system low power state, in accordance with the appropriate PCI specification.- For integrated controllers, the ACPI _S0W object must report whether the controller is capable of runtime wake signaling.

Additional Information

Enforcement Date
Mar. 01, 2012

Device.BusController.UsbController.XhciVersionCompliant

USB 3.0 controllers are XHCI version compliant

Target Feature
Device.BusController.UsbController
Applies to
Windows 7 Client x86, x64
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)
Windows Server 2012 R2 x64
Windows Server 2008 Release 2 x64
Windows Server 2012 x64

Description

Effective June 1, 2012, USB 3.0 controllers must comply with the Extensible Host Controller Interface (xHCI) Specification version 1.0. and any USB-IF Errata that are released by the USB-IF.

Additional Information

Enforcement Date
Jun. 01, 2012