On Mon, 14 Sep 2015, Igor Kotrasinski wrote:
> When close to transfer limit for a frame, transfer() decreases
> data length to send to limit. This can cause an erroneous short
> packet transfer to be simulated.
I don't see how that could happen.
> Rework transfer logic to decrease data to tranfer to multiple of
> maxpacket.
>
> Signed-off-by: Igor Kotrasinski <i.kotrasinsk@xxxxxxxxxxx>
> ---
> drivers/usb/gadget/udc/dummy_hcd.c | 12 ++++++++----
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/usb/gadget/udc/dummy_hcd.c b/drivers/usb/gadget/udc/dummy_hcd.c
> index 183e368..552c533 100644
> --- a/drivers/usb/gadget/udc/dummy_hcd.c
> +++ b/drivers/usb/gadget/udc/dummy_hcd.c
> @@ -1313,10 +1313,14 @@ top:
> if (unlikely(len == 0))
> is_short = 1;
> else {
> - /* not enough bandwidth left? */
> - if (limit < ep->ep.maxpacket && limit < len)
> - break;
> - len = min_t(unsigned, len, limit);
> + /* not enough bandwidth left?
> + * only send multiple of maxpacket to avoid
> + * unwarranted short packet.
> + */
> + if (limit < len) {
> + len = limit;
> + len -= (len % ep->ep.maxpacket);
> + }
> if (len == 0)
> break;
>
I don't think this patch is needed. It looks like the new code does
exactly the same thing as the old code. In particular, if limit >= len
then both the old and new code both do nothing. If limit < len then:
Old code: If limit < ep->ep.maxpacket then break.
Otherwise set len = limit, and later on (just after the
end of this patch) len will be rounded down to a multiple
of ep->ep.maxpacket.
New code: len = limit rounded down to a multiple of
ep->ep.maxpacket. If this is 0 -- i.e.,
if limit < ep->ep.maxpacket -- then break.
Thus they end up doing the same thing.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
