Re: [PATCH 2/4] usb: gadget: dummy_hcd: fix false overflow on bounded IN
From: Alan Stern
Date: Fri Aug 07 2026 - 17:24:44 EST
On Fri, Aug 07, 2026 at 09:54:36AM +0200, Igor Skalkin wrote:
> In transfer(), the IN short-packet path reports -EOVERFLOW when
> dev_len > host_len.
>
> For IN transfers this is a valid bounded completion: the host asked for
> host_len bytes and the transfer is limited by the host buffer. It is not
> an overflow condition.
I don't know what you mean by this. It is true that transfers are
limited by the size of the host buffer. Nevertheless, when a device
tries to send a packet containing more data than the buffer can hold,
the result is a -EOVERFLOW error, by definition.
If it weren't, what do you think _would_ constitute an overflow error?
> Treat bounded IN short completion as success.
Absolutely not. This is completely wrong. NAK.
> This fixes spurious failures in usbtest bulk IN varying-length cases.
What spurious failures?
Alan Stern
>
> Assisted-by: OpenCode:claude-sonnet-5
> Signed-off-by: Igor Skalkin <igor.skalkin@xxxxxxxxxxxxxxxx>
> ---
> drivers/usb/gadget/udc/dummy_hcd.c | 10 ++++++----
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/usb/gadget/udc/dummy_hcd.c b/drivers/usb/gadget/udc/dummy_hcd.c
> index 29f671c7b319..5384806347ab 100644
> --- a/drivers/usb/gadget/udc/dummy_hcd.c
> +++ b/drivers/usb/gadget/udc/dummy_hcd.c
> @@ -1486,11 +1486,13 @@ static int transfer(struct dummy_hcd *dum_hcd, struct urb *urb,
> req->req.status = 0;
> *status = 0;
> } else if (to_host) {
> + /*
> + * Host requested fewer bytes than the gadget
> + * request currently has pending. This is a
> + * normal bounded IN transfer, not overflow.
> + */
> req->req.status = 0;
> - if (dev_len > host_len)
> - *status = -EOVERFLOW;
> - else
> - *status = 0;
> + *status = 0;
> } else {
> *status = 0;
> if (host_len > dev_len)
> --
> 2.49.0
>