From: ShengYi Hung <aokblast@FreeBSD.org>
To: Michael Tokarev <mjt@tls.msk.ru>
Cc: qemu-trivial@nongnu.org, QEMU Development <qemu-devel@nongnu.org>
Subject: Re: [PATCH] hid: fix incorrect return value for hid.
Date: Thu, 18 Sep 2025 16:35:07 +0800 [thread overview]
Message-ID: <m2ldmc40qs.fsf@FreeBSD.org> (raw)
In-Reply-To: <89ef2af7-d79d-4460-9c01-9127f906ee51@tls.msk.ru> (Michael Tokarev's message of "Thu, 18 Sep 2025 09:14:47 +0300")
Hello Michael:
Thanks for your review and reply, I sent the mail to qemud-devel about a
month ago but didn't receive any reply. Therefore, I send the mail to
qemu-trivial again and forget CC to qemu-devel. I will be careful next
time.
The consequence is that if the guest operating system want to check the
actual transfer length of a transfer, it may be regarded as a failed
transfer since the actual transfer length is zero originally.
Here is an example from FreeBSD:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=288968.
I have workarounded this issue by ignore any error from hid_write.
Interestingly, Parallel seems to share the same issue and can be
addressed with the same fix.
Michael Tokarev <mjt@tls.msk.ru> writes:
> Please always send all patches to qemu-devel@ (cc'd)
> (in this case, in addition to qemu-trivial@).
>
> On 15.09.2025 20:57, ShengYi Hung wrote:
>> The return value of hid_keyboard_write is used to set the packet's actual_length
>> and pass to xhci directly to allow guest know how many byte actually processed.
>> Therefore, return 1 to indicate a successful transfer or it will be
>> considered as a wrong xfer.
>> Signed-off-by: ShengYi Hung <aokblast@FreeBSD.org>
>> ---
>> hw/input/hid.c | 1 +
>> 1 file changed, 1 insertion(+)
>> diff --git a/hw/input/hid.c b/hw/input/hid.c
>> index 76bedc1844..de24cd0ef0 100644
>> --- a/hw/input/hid.c
>> +++ b/hw/input/hid.c
>> @@ -478,6 +478,7 @@ int hid_keyboard_write(HIDState *hs, uint8_t *buf, int len)
>> ledstate |= QEMU_CAPS_LOCK_LED;
>> }
>> kbd_put_ledstate(ledstate);
>> + return 1;
>> }
>> return 0;
>> }
>
> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru>
>
> and queued up to the trivial-patches tree.
>
> It's an interesting one, I wonder what the consequences are -
> for having this at 0 all the time, and for actually making it 1.
> Did we miss a byte somewhere with current code?
>
> Thanks,
>
> /mjt
--
Best Regards.
ShengYi Hung.
next prev parent reply other threads:[~2025-09-18 8:35 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-15 17:57 [PATCH] hid: fix incorrect return value for hid ShengYi Hung
2025-09-18 6:14 ` Michael Tokarev
2025-09-18 8:35 ` ShengYi Hung [this message]
-- strict thread matches above, loose matches on Subject: below --
2025-08-21 18:57 ShengYi Hung
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=m2ldmc40qs.fsf@FreeBSD.org \
--to=aokblast@freebsd.org \
--cc=mjt@tls.msk.ru \
--cc=qemu-devel@nongnu.org \
--cc=qemu-trivial@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.