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@ti.com> 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