From patchwork Sat Jun 25 14:21:37 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: MkfsSion X-Patchwork-Id: 12895384 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id EF04AC43334 for ; Sat, 25 Jun 2022 14:23:15 +0000 (UTC) Received: from localhost ([::1]:52846 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o56gs-0004aA-FH for qemu-devel@archiver.kernel.org; Sat, 25 Jun 2022 10:23:14 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:45818) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o56fl-0003t3-Uf for qemu-devel@nongnu.org; Sat, 25 Jun 2022 10:22:06 -0400 Received: from mail-108-mta25.mxroute.com ([136.175.108.25]:44097) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1o56fj-0000PA-6U for qemu-devel@nongnu.org; Sat, 25 Jun 2022 10:22:04 -0400 Received: from filter006.mxroute.com ([140.82.40.27] filter006.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta25.mxroute.com (ZoneMTA) with ESMTPSA id 1819b3da2ba00028a7.002 for (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256); Sat, 25 Jun 2022 14:21:56 +0000 X-Zone-Loop: 4802461cd02d89f31beb90c5ce58fb74cf487b3ba38d X-Originating-IP: [140.82.40.27] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mkfssion.com; s=x; h=Content-Transfer-Encoding:MIME-Version:Message-Id:Date :Subject:Cc:To:From:Sender:Reply-To:Content-Type:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=EqNlKr6yIv9MTP6XJewjMRBR6Y+N7XbK9fI0jnMDGvY=; b=Lb0ngfqy31H5/6F4Y2cvnutMDT Qe77R387gSVvBUbEo5bUqLCx01VK+xYJ9jwV/8tBVBm3B27NvIrE362/uUOWiv8FNVN6hBHSJX99S SiQtKxUOBOPY8+qIX2Wr6LPAlJdhrgRAwisuFgXsybUXvU/DxcaCEwJGG3U8BcYDOAefFrqqiQ8BI tlYw0LRQSTEmXJhkBNyN24zZ3FV76AhsAAdnLPL221CTpCjItfooPH89qvn6tW8a5wPRieF7m361A tOznhG3/WjdS08kOh8zCbg89yJX5OOldl0awN/tJWwEbzsI9S/DNfixP5wLT3tEQ3Mv0FXwXZQIlh 8By2pYZQ==; From: MkfsSion To: qemu-devel@nongnu.org Cc: MkfsSion , Hongren Zheng , Gerd Hoffmann , "Canokeys.org" Subject: [PATCH v4 1/2] hw: canokey: Remove HS support as not compliant to the spec Date: Sat, 25 Jun 2022 22:21:37 +0800 Message-Id: <20220625142138.19363-1-mkfssion@mkfssion.com> MIME-Version: 1.0 X-AuthUser: mkfssion@mkfssion.com Received-SPF: pass client-ip=136.175.108.25; envelope-from=mkfssion@mkfssion.com; helo=mail-108-mta25.mxroute.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" Canokey core currently using 16 bytes as maximum packet size for control endpoint, but to run the device in high-speed a 64 bytes maximum packet size is required according to USB 2.0 specification. Since we don't acutally need to run the device in high-speed, simply don't assign high member in USBDesc. When canokey-qemu is used with xhci, xhci would drive canokey in high speed mode, since the bcdUSB in canokey-core is 2.1, yet canokey-core set bMaxPacketSize0 to be 16, this is out of the spec as the spec said that ``The allowable maximum control transfer data payload sizes...for high-speed devices, it is 64 bytes''. In this case, usb device validation in Windows 10 LTSC 2021 as the guest would fail. It would complain USB\DEVICE_DESCRIPTOR_VALIDATION_FAILURE. Note that bcdUSB only identifies the spec version the device complies, but it has no indication of its speed. So it is allowed for the device to run in FS but comply the 2.1 spec. To solve the issue we decided to just drop the high speed support. This only affects usb-ehci as usb-ehci would complain speed mismatch when FS device is attached to a HS port. That's why the .high member was initialized in the first place. Meanwhile, xhci is not affected as it works well with FS device. Since everyone is now using xhci, it does no harm to most users. Suggested-by: Hongren (Zenithal) Zheng Signed-off-by: YuanYang Meng Reviewed-by: Hongren (Zenithal) Zheng --- hw/usb/canokey.c | 1 - 1 file changed, 1 deletion(-) diff --git a/hw/usb/canokey.c b/hw/usb/canokey.c index 4a08b1cbd7..6a7ab965a5 100644 --- a/hw/usb/canokey.c +++ b/hw/usb/canokey.c @@ -56,7 +56,6 @@ static const USBDesc desc_canokey = { .iSerialNumber = STR_SERIALNUMBER, }, .full = &desc_device_canokey, - .high = &desc_device_canokey, .str = desc_strings, };