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 |