From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id F243A1A1DF6 for ; Tue, 20 Sep 2016 17:05:00 -0700 (PDT) Received: from [216.82.249.35] by server-16.bemta-12.messagelabs.com id 27/6E-25194-CAEC1E75; Wed, 21 Sep 2016 00:05:00 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrHIsWRWlGSWpSXmKPExsWSLvdKT3fNuYf hBlfm8FvsOXSU2YHRo3v2P5YAxijWzLyk/IoE1oxnp48xFzwRrjjy8xNLA+M3vi5GLg4hgeeM Em/uXGLvYuQEcvYwSlx+EQNiswnoSVxfdZoJxBYRMJdonX8FzBYWsJX41LMWKu4kceLibkYI2 0hi0ZuPzCA2i4CqxLF9T9hAbF4BX4lzE5+ygNiMAmIS30+tAetlFhCXuDR5EViNhICAxJI955 khbFGJl4//sULYihI9H9ezQ9TrSCzY/YkNwtaWWLbwNTPEfEGJkzOfsExgFJyFZOwsJC2zkLT MQtKygJFlFaNGcWpRWWqRrqGRXlJRZnpGSW5iZo6uIZCbm1pcnJiempOYVKyXnJ+7iREYzgxA sIPx/DTnQ4ySHExKorxyfA/ChfiS8lMqMxKLM+KLSnNSiw8xynBwKEnwWp95GC4kWJSanlqRl pkDjCyYtAQHj5IIr/dZoDRvcUFibnFmOkTqFKOilDjvU5A+AZBERmkeXBssmi8xykoJ8zICHS LEU5BalJtZgir/ilGcg1FJmDcEZDxPZl4J3PRXQIuZgBZv+fkAZHFJIkJKqoGx10Q9We1Lm8a BtvCZF8wNf1atSV/LVpz3XvD+3e6Xz5mP1sZqr7/66mZqwdY/iSKKbryT4j3nHDlmzTHb/8/1 oiyxYyvVDwVZ9u4z3sh38/39rMlOHdX7n1/o+NrtNuX8X7uljJdeqee9uP+7d3KPYLXPdXank z3dIZ/bc24pVvFPMQ3ie5OtxFKckWioxVxUnAgAizUPOOECAAA= X-Env-Sender: ykatayama1@lenovo.com X-Msg-Ref: server-4.tower-138.messagelabs.com!1474416297!53496848!1 X-Originating-IP: [103.30.234.46] X-StarScan-Received: X-StarScan-Version: 8.84; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23098 invoked from network); 21 Sep 2016 00:04:59 -0000 Received: from unknown (HELO apsmtp03.lenovo.com) (103.30.234.46) by server-4.tower-138.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 21 Sep 2016 00:04:59 -0000 Received: from APMAILCH03.lenovo.com (unknown [10.128.246.248]) by apsmtp03.lenovo.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA) id 7959_0980_d1402a82_9ce3_4e8f_a77a_b0bebfdcd58a; Wed, 21 Sep 2016 08:04:54 +0800 Received: from APMAILMBX03.lenovo.com ([fe80::fc60:7d0e:ecc3:f655]) by APMAILCH03.lenovo.com ([fe80::1466:c51d:1312:9271%14]) with mapi id 14.03.0248.002; Wed, 21 Sep 2016 08:04:55 +0800 From: Yosuke Katayama1 To: "edk2-devel@lists.01.org" Thread-Topic: [EDK2][USB IF]Mismatch between EDK2 and a USB vendor Thread-Index: AdITFZMHVZgoGvsCSa6tGMQRy/m9VwAhhnJA Date: Wed, 21 Sep 2016 00:04:54 +0000 Message-ID: <5F5B41F3CAC51543B46516F1A5F982DC24BCE1F7@APMAILMBX03.lenovo.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.128.115.10] MIME-Version: 1.0 Subject: [USB IF]Mismatch between EDK2 and a USB vendor X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2016 00:05:01 -0000 Content-Language: ja-JP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello,=20 This is relating to my previous post "[edk2] Is this a right place to discu= ss EDK2's USB IF implementation?"=20 We found a mismatch between EDK2 source code and our USB vendor's implement= ation. Could you give us your opinions? bInterfaceNumber , 9.6.5 Interface from Universal Serial Bus 3.1 Specificat= ion Rev 1.0 says; -- Number of this interface. Zero-based value identifying the index in the arr= ay 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 independ= ently turned on/off * Solution allows any combination of interfaces without= re-defining the interface number * One general lookup table can tell you w= hat 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 O= EM customers have never raised this issue -- As a result, the vendor's USB IF looks like below. =3D=3D=3D>Configuration Descriptor<=3D=3D=3D ... bNumInterfaces: 0x02 <<<< bConfigurationValue: 0x01 iConfiguration: 0x00 bmAttributes: 0xA0 -> Bus Powered -> Remote Wakeup ... =3D=3D=3D>Interface Descriptor<=3D=3D=3D ... bInterfaceNumber: 0x0C <<<< Interface Number starts fro= m 0x0C instead of 0. [comment from Yosuke] bAlternateSetting: 0x00 bNumEndpoints: 0x01 ... =3D=3D=3D>Interface Descriptor<=3D=3D=3D ... bInterfaceNumber: 0x0D <<<< bAlternateSetting: 0x00 bNumEndpoints: 0x00 ... and it hits the following ON_ERROR in UsbDesc.c. -- } else if (Setting->Desc.InterfaceNumber >=3D NumIf) { DEBUG (( EFI_D_ERROR, "UsbParseConfigDesc: mal-formated interface des= criptor\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, Yosuke