Re: [USB IF]Mismatch between EDK2 and a USB vendor

Yosuke Katayama1 <ykatayama1@...>

Hello Feng,

Thank you for the reply.

Please wait for creating the fix.

Currently the USB vendor is contacting USB organization to check if the vendor's interpretation of the IF spec is valid or not. I will let you know when the vendor has received the answer from the organization, then you can decide whether to fix or not.

What do you think of this plan?

PS: We are using XHCI.

Kind regards,
Yosuke Katayama

-----Original Message-----
From: Tian, Feng [mailto:feng.tian@...]
Sent: Wednesday, September 21, 2016 3:14 PM
To: Yosuke Katayama1; edk2-devel@...
Cc: Tian, Feng
Subject: RE: [EDK2][USB IF]Mismatch between EDK2 and a USB vendor

Hi, Katayama

We never receive such feedback on inconsecutive usb interface number. I agree EDKII usb driver should be able to handle this.

I am working on a fix, but I have no such device at hand. Could you help me verify it when the patch is ready?

PS: what host controller are you using? EHCI or XHCI?


-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@...] On Behalf Of Yosuke Katayama1
Sent: Wednesday, September 21, 2016 8:05 AM
To: edk2-devel@...
Subject: [edk2] [EDK2][USB IF]Mismatch between EDK2 and a USB vendor


This is relating to my previous post "[edk2] Is this a right place to discuss EDK2's USB IF implementation?"
We found a mismatch between EDK2 source code and our USB vendor's implementation. Could you give us your opinions?

bInterfaceNumber , 9.6.5 Interface from Universal Serial Bus 3.1 Specification Rev 1.0 says;
Number of this interface. Zero-based value identifying the index in the array of concurrent interfaces supported by this configuration.

Regarding this.
EDK2 source code (UsbDesc.c) says:
// If a configuration has several interfaces, these interfaces are
// numbered from zero to n...

The USB vendor says:
* Numbering is not necessarily consecutive * Each interface can be independently turned on/off * Solution allows any combination of interfaces without re-defining the interface number * One general lookup table can tell you what interface is assigned to what interface number.
* For these reasons, the interface definition is like this on our products.
* The interface definition has remained the same from the previous products, and other products before that.
* Current interface numbering is supported by all Microsoft OS * Other PC OEM customers have never raised this issue

As a result, the vendor's USB IF looks like below.

===>Configuration Descriptor<===
bNumInterfaces: 0x02 <<<<
bConfigurationValue: 0x01
iConfiguration: 0x00
bmAttributes: 0xA0 -> Bus Powered
-> Remote Wakeup
===>Interface Descriptor<===
bInterfaceNumber: 0x0C <<<< Interface Number starts from 0x0C instead of 0. [comment from Yosuke]
bAlternateSetting: 0x00
bNumEndpoints: 0x01

===>Interface Descriptor<===
bInterfaceNumber: 0x0D <<<<
bAlternateSetting: 0x00
bNumEndpoints: 0x00

and it hits the following ON_ERROR in UsbDesc.c.
} else if (Setting->Desc.InterfaceNumber >= NumIf) {
DEBUG (( EFI_D_ERROR, "UsbParseConfigDesc: mal-formated interface descriptor\n"));

UsbFreeInterfaceDesc (Setting);
goto ON_ERROR;

What do you think the vendor's implementation?
Also, have you ever had such a USB IF mismatch between EDK2 and USB vendors before? If so, how are you handling such cases in general?

Kind regards,
edk2-devel mailing list

Join { to automatically receive all group messages.