All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org>
To: Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org>
Cc: Michael Trimarchi
	<michael-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>,
	Felipe Balbi <balbi-l0cyMroinI0@public.gmane.org>,
	gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org,
	linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	nsekhar-l0cyMroinI0@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [RFC PATCH] usb: dwc3: ep0: Fix mem corruption on OUT transfers of more than 512 bytes
Date: Wed, 10 Jun 2015 11:03:59 +0530	[thread overview]
Message-ID: <5577CC47.1000706@ti.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1506091320160.1324-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>

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-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Kishon Vijay Abraham I <kishon@ti.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Michael Trimarchi <michael@amarulasolutions.com>,
	Felipe Balbi <balbi@ti.com>, <gregkh@linuxfoundation.org>,
	<linux-omap@vger.kernel.org>, <nsekhar@ti.com>,
	<linux-kernel@vger.kernel.org>, <linux-usb@vger.kernel.org>
Subject: Re: [RFC PATCH] usb: dwc3: ep0: Fix mem corruption on OUT transfers of more than 512 bytes
Date: Wed, 10 Jun 2015 11:03:59 +0530	[thread overview]
Message-ID: <5577CC47.1000706@ti.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1506091320160.1324-100000@iolanthe.rowland.org>

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

  parent reply	other threads:[~2015-06-10  5:33 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-09 14:35 [RFC PATCH] usb: dwc3: ep0: Fix mem corruption on OUT transfers of more than 512 bytes Kishon Vijay Abraham I
2015-06-09 14:35 ` Kishon Vijay Abraham I
     [not found] ` <CAOf5uwmVRaHbiHaRsiwKjCbxg5BxjyP8WPq9whrtK-UdSsL47w@mail.gmail.com>
2015-06-09 14:44   ` Kishon Vijay Abraham I
2015-06-09 14:44     ` Kishon Vijay Abraham I
2015-06-09 14:59     ` Alan Stern
2015-06-09 14:59       ` Alan Stern
     [not found]       ` <Pine.LNX.4.44L0.1506091057100.1324-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
2015-06-09 15:08         ` Kishon Vijay Abraham I
2015-06-09 15:08           ` Kishon Vijay Abraham I
     [not found]           ` <55770173.7060801-l0cyMroinI0@public.gmane.org>
2015-06-09 15:16             ` Alan Stern
2015-06-09 15:16               ` Alan Stern
     [not found]               ` <Pine.LNX.4.44L0.1506091114340.1324-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
2015-06-09 16:14                 ` Kishon Vijay Abraham I
2015-06-09 16:14                   ` Kishon Vijay Abraham I
2015-06-09 17:24                   ` Alan Stern
2015-06-09 17:24                     ` Alan Stern
     [not found]                     ` <Pine.LNX.4.44L0.1506091320160.1324-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
2015-06-10  5:33                       ` Kishon Vijay Abraham I [this message]
2015-06-10  5:33                         ` Kishon Vijay Abraham I
2015-06-09 17:16       ` Felipe Balbi
2015-06-09 17:16         ` Felipe Balbi
     [not found]     ` <5576FBBA.4000905-l0cyMroinI0@public.gmane.org>
2015-06-11 18:57       ` Michael Trimarchi
2015-06-11 18:57         ` Michael Trimarchi

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=5577CC47.1000706@ti.com \
    --to=kishon-l0cymroini0@public.gmane.org \
    --cc=balbi-l0cyMroinI0@public.gmane.org \
    --cc=gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=michael-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org \
    --cc=nsekhar-l0cyMroinI0@public.gmane.org \
    --cc=stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.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.