* Canokey core currently using 16 bytes as maximum packet size for
* EP, but to run the device in full-speed a 64 bytes maximum 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.

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

On Thu, Jun 23, 2022 at 09:58:43PM +0800, MkfsSion wrote:
> * Canokey core currently using 16 bytes as maximum packet size for
> * EP, but to run the device in full-speed a 64 bytes maximum 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.

Hi, the commit message body should not be prefixed with `* '.

And the commit message header could be more formal like
`Remove HS support as not compliant to the spec'

I actually discussed this bug with mkfssion in private conversation,
To provide more information about the bug for the mailing list,
let me give a reproducible scenario:

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.

mkfssion could include the example above in his/her
commit message to provide more context on this patch.

Also I suggest adding the ehci limitation to the doc
in a separate patch to form a patch set.

> 
> 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
>