* 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.
Sugge
Suggested-by: Hongren (Zenithal) Zheng
Signed-off-by: MkfsSion
---
docs/system/devices/canokey.rst | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/docs/system/devices/canokey.rst b/docs/system/devices/canokey.rst
index 169f99b8eb..650702ad8a 100644
--- a/docs
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 USBD
Suggested-by: Hongren (Zenithal) Zheng
Signed-off-by: YuanYang Meng
---
docs/system/devices/canokey.rst | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/docs/system/devices/canokey.rst b/docs/system/devices/canokey.rst
index 169f99b8eb..650702ad8a 100644
--- a/doc
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 USBD
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 USBD
Suggested-by: Hongren (Zenithal) Zheng
Signed-off-by: YuanYang Meng
---
v4:
Adopt Zenithal's suggestion of repharsing the limitation
docs/system/devices/canokey.rst | 5 +
1 file changed, 5 insertions(+)
diff --git a/docs/system/devices/canokey.rst b/docs/system/devices/canokey.rst
On 2022/1/19 22:08, Markus Armbruster wrote:
> MkfsSion writes:
>
>> When using JSON syntax for -device, -set option can not find device
>> specified in JSON by id field. The following commandline is an example:
>>
>> $ qemu-system-x86_64 -device '{"i
ping
https://lore.kernel.org/qemu-devel/20211224072511.63894-1-mkfss...@mkfssion.com
"foo" defined
The patch adds device opts to device opts list when a device opts get
parsed.
Signed-off-by: MkfsSion
---
softmmu/vl.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/softmmu/vl.c b/softmmu/vl.c
index 620a1f1367..0dd5acbc1a 100644
--- a/softmmu/vl.c
+++ b/softmmu/v
Sorry, the patch is not well tested and it causes duplicate devices creation. I
have send another patch to the mailing list to fix the issue.
On 2021/12/21 16:25, Philippe Mathieu-Daudé wrote:
> Cc'ing Markus.
>
> On 12/20/21 09:45, MkfsSion wrote:
>> When using JSON synt
When using JSON syntax for -device, -set option can not find device
specified in JSON by id field. The following commandline is an example:
$ qemu-system-x86_64 -device '{"id":"foo"}' -set device.foo.bar=1
qemu-system-x86_64: -set device.foo.bar=1: there is no device "foo" defined
The patch adds
On 2021/12/21 19:26, Markus Armbruster wrote:> Two issues, and only looks
fixable.
>
> -device accepts either a QemuOpts or a JSON argument.
>
> It parses the former with qemu_opts_parse_noisily() into a QemuOpt
> stored in @qemu_device_opts.
>
> It parses the latter with qobject_from_json() in
When using JSON syntax for -device, -set option can not find device
specified in JSON by id field. The following commandline is an example:
$ qemu-system-x86_64 -device '{"id":"foo"}' -set device.foo.bar=1
qemu-system-x86_64: -set device.foo.bar=1: there is no device "foo" defined
The patch fixes
ping
https://lore.kernel.org/qemu-devel/20211229064421.5LPUBTk_b7lwFSu6jdh7beB7kZHoVtGGztQSJR1SClI@z/
15 matches
Mail list logo
