Hi, On Wed, Jul 27, 2011 at 09:20:02AM +0530, Jassi Brar wrote: > On Tue, Jul 26, 2011 at 8:36 PM, Felipe Balbi <balbi@xxxxxx> wrote: > > Hi, > > > > On Wed, Jul 20, 2011 at 09:48:53AM -0700, Pandita, Vikram wrote: > >> > This *today happens to be only UMS* is my exact point here. > >> > Can you guarantee no other function driver will ever expect only > >> > full packet xfers and treat short as errors ? > >> > > >> > >> We are trying to test if short_not_ok may not be needed at all. But > >> all gadgets need to be tested on MUSB for that. > >> We will need wider help from MUSB maintainer/author(anand g) to > >> determine if removing short_not_ok is fine on MUSB for _all_ gadgets. > >> > >> To be safe we only enable for UMS use case today that is definitely > >> working fine. > >> > >> Time for Maintainer/author to pitch in !! > > > > I'm thinking on allowing this patch to go in if nobody has really strong > > arguments against it. The real fix, though, would need a bigger re-write > > of the endpoint IRQ handling and that would need more time to write and > > stabilize. Together with the huge amount of HW issues MUSB has, it's > > quite a task (been there, done that). > > Please note that I never objected to the _code_. > > I just think if the _comments_ could be made UMS agnostic... for ex if it works > for other protocols just fine(quite possible) in future the reader > might wonder what > is UMS specific about the code snippet. for sure, makes sense to me. Vikram, do you want to update the comment to remove UMS mentions ? Most likely UASP will have the same deal, btw. -- balbi
Attachment:
signature.asc
Description: Digital signature
