Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933211AbbFIQOU (ORCPT ); Tue, 9 Jun 2015 12:14:20 -0400 Received: from devils.ext.ti.com ([198.47.26.153]:37751 "EHLO devils.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933156AbbFIQON (ORCPT ); Tue, 9 Jun 2015 12:14:13 -0400 Message-ID: <557710CE.5050304@ti.com> Date: Tue, 9 Jun 2015 21:44:06 +0530 From: Kishon Vijay Abraham I User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Alan Stern CC: Michael Trimarchi , Felipe Balbi , , , , , Subject: Re: [RFC PATCH] usb: dwc3: ep0: Fix mem corruption on OUT transfers of more than 512 bytes References: In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1466 Lines: 38 Hi, On Tuesday 09 June 2015 08:46 PM, Alan Stern wrote: > On Tue, 9 Jun 2015, Kishon Vijay Abraham I wrote: > >>> Why not just make the bounce buffer size the same as the maxpacket >>> size? In other words, 1024 bytes instead of 512, for ep0 on a USB-3 >>> device. >> >> It would still be possible for the host to send data more than 1024 bytes no? > > Yes. > >> When working with DFU gadget, I've seen host sends data upto 4KB. Changing the >> bounce buffer size might not be able to fix all the cases IMO. The actual fix >> will be something like [1] >> >> [1] -> http://comments.gmane.org/gmane.linux.kernel/1883688 > > But with a bounce buffer that's only 512 bytes long, you can never send > an entire packet's worth of data. If the bounce buffer is 1024 bytes for control endpoint, 512 bytes should be sufficient to send entire packet right? > then you can send the entire first packet. When that's done, you can > send the second packet. And so on. It wouldn't be quite as fast, but > for ep0 that shouldn't matter. right! this is a variant of what I tried to implement in chained TRB [1]. $subject tries just to avoid memory corruption instead of actually trying to receive all the data. Thanks Kishon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/