#
0e6b20b9 |
| 30-Apr-2023 |
Hongren (Zenithal) Zheng <i@zenithal.me> |
hw/usb/canokey: change license to GPLv2+
Apache license is considered by some to be not compatible with GPLv2+. Since QEMU as combined work is GPLv2-only, these two files should be made compatible.
hw/usb/canokey: change license to GPLv2+
Apache license is considered by some to be not compatible with GPLv2+. Since QEMU as combined work is GPLv2-only, these two files should be made compatible.
Reported-by: "Daniel P. Berrangé" <berrange@redhat.com> Link: https://lore.kernel.org/qemu-devel/ZEpKXncC%2Fe6FKRe9@redhat.com/ Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Acked-By: canokeys.org (http://canokeys.org) <contact@canokeys.org> Acked-by: YuanYang Meng <mkfssion@mkfssion.com> Signed-off-by: Hongren (Zenithal) Zheng <i@zenithal.me> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
show more ...
|
Revision tags: v8.0.0, v7.2.0 |
|
#
927b968d |
| 25-Jun-2022 |
MkfsSion <mkfssion@mkfssion.com> |
hw: canokey: Remove HS support as not compliant to the spec
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
hw: canokey: Remove HS support as not compliant to the spec
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> Reviewed-by: Hongren (Zenithal) Zheng <i@zenithal.me> Message-Id: <20220625142138.19363-1-mkfssion@mkfssion.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
show more ...
|
#
10425630 |
| 13-Jun-2022 |
Hongren (Zenithal) Zheng <i@zenithal.me> |
hw/usb/canokey: fix compatibility of qemu-xhci
XHCI wont poll interrupt IN endpoint if NAKed, and needs wakeup
Suggested-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Hongren (Zenithal) Zhen
hw/usb/canokey: fix compatibility of qemu-xhci
XHCI wont poll interrupt IN endpoint if NAKed, and needs wakeup
Suggested-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Hongren (Zenithal) Zheng <i@zenithal.me> Message-Id: <YqcqSHNpI7sXRNpZ@Sun> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
show more ...
|
#
ada270cd |
| 13-Jun-2022 |
Hongren (Zenithal) Zheng <i@zenithal.me> |
hw/usb/canokey: Fix CCID ZLP
CCID could send zero-length packet (ZLP) if we invoke two data_in, two packets would be concated and we could not distinguish them.
The CANOKEY_EMU_EP_CTAPHID is import
hw/usb/canokey: Fix CCID ZLP
CCID could send zero-length packet (ZLP) if we invoke two data_in, two packets would be concated and we could not distinguish them.
The CANOKEY_EMU_EP_CTAPHID is imported from canokey-qemu.h
Reported-by: MkfsSion <myychina28759@gmail.com> Signed-off-by: Hongren (Zenithal) Zheng <i@zenithal.me> Message-Id: <YqcqGz0s3+LE42ms@Sun> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
show more ...
|
#
d37d0e0e |
| 19-May-2022 |
Hongren (Zenithal) Zheng <i@zenithal.me> |
hw/usb/canokey: Add trace events
Signed-off-by: Hongren (Zenithal) Zheng <i@zenithal.me> Message-Id: <YoY6RoDKQIxSkFwL@Sun> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
|
#
d7d34918 |
| 19-May-2022 |
Hongren (Zenithal) Zheng <i@zenithal.me> |
hw/usb: Add CanoKey Implementation
This commit added a new emulated device called CanoKey to QEMU.
CanoKey implements platform independent features in canokey-core https://github.com/canokeys/canok
hw/usb: Add CanoKey Implementation
This commit added a new emulated device called CanoKey to QEMU.
CanoKey implements platform independent features in canokey-core https://github.com/canokeys/canokey-core, and leaves the USB implementation to the platform.
In this commit the USB part was implemented in QEMU using QEMU's USB APIs, therefore the emulated CanoKey can communicate with the guest OS using USB.
Signed-off-by: Hongren (Zenithal) Zheng <i@zenithal.me> Message-Id: <YoY6Mgph6f6Hc/zI@Sun> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
show more ...
|