From: MkfsSion <mkfssion@mkfssion.com>
To: qemu-devel@nongnu.org
Cc: MkfsSion <mkfssion@mkfssion.com>, Hongren Zheng <i@zenithal.me>,
Gerd Hoffmann <kraxel@redhat.com>,
"Canokeys.org" <contact@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 [thread overview]
Message-ID: <20220625142138.19363-1-mkfssion@mkfssion.com> (raw)
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 <i@zenithal.me>
Signed-off-by: YuanYang Meng <mkfssion@mkfssion.com>
---
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,
};
--
2.36.1
next reply other threads:[~2022-06-25 14:23 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-25 14:21 MkfsSion [this message]
2022-06-25 14:26 ` [PATCH v4] docs/system/devices/canokey: Document limitations on usb-ehci MkfsSion
2022-06-28 2:21 ` Hongren Zheng
2022-06-28 2:17 ` [PATCH v4 1/2] hw: canokey: Remove HS support as not compliant to the spec Hongren Zheng
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220625142138.19363-1-mkfssion@mkfssion.com \
--to=mkfssion@mkfssion.com \
--cc=contact@canokeys.org \
--cc=i@zenithal.me \
--cc=kraxel@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).