Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932426AbbFJFe2 (ORCPT ); Wed, 10 Jun 2015 01:34:28 -0400 Received: from arroyo.ext.ti.com ([192.94.94.40]:42434 "EHLO arroyo.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751206AbbFJFeR (ORCPT ); Wed, 10 Jun 2015 01:34:17 -0400 Message-ID: <5577CC47.1000706@ti.com> Date: Wed, 10 Jun 2015 11:03:59 +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: 1400 Lines: 37 Hi, On Tuesday 09 June 2015 10:54 PM, Alan Stern wrote: > On Tue, 9 Jun 2015, Kishon Vijay Abraham I wrote: > >>> 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? > > Yes, you're right. I had confused control endpoints with bulk > endpoints, where the maxpacket size is 1024. Sorry for the mistake. no problem. > >>> 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. > > Okay. If you take the $SUBJECT approach, I think it would be better > for an URB submission to fail than for the host controller to send only > part of the data. Could be but we also want to prevent mem corruption in the case of a faulty host to be more robust. 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/