From: Sergei Shtylyov <sshtylyov@ru.mvista.com>
To: David Brownell <david-b@pacbell.net>
Cc: Ajay Kumar Gupta <ajay.gupta@ti.com>,
linux-usb@vger.kernel.org, linux-omap@vger.kernel.org,
felipe.balbi@nokia.com
Subject: Re: [PATCH 2/3] usb: musb: fix bug in musb_start_urb
Date: Tue, 24 Feb 2009 18:50:27 +0300 [thread overview]
Message-ID: <49A41743.5090207@ru.mvista.com> (raw)
In-Reply-To: <200902231405.42762.david-b@pacbell.net>
Hello.
David Brownell wrote:
>>Ajay Kumar Gupta wrote:
>>>urb->transfer_buffer_length and urb->transfer_buffer should be
>>>updated based on urb->actual_length.For a fresh and first time urb,
>>>actual_length will be zero but for urbs which has been stopped and
>>>restarted (as bulk nak scheme does) actual_length may not be zero.
>>>Signed-off-by: Ajay Kumar Gupta <ajay.gupta@ti.com>
>> NAK, this is not a problem for the current driver since URBs do not ever
>>get restarted.
> Resolvable by changing the patch description to not say
> this is a "fix".
> However, since this is a two line change, I think I'll
> just merge this with the patch adding the bulk RX retry
> logic.
Yes, that's what should've been done from the start.
>>Also, musb_host_tx() doesn't update urb->actual_length --
>>please fix it too.
> That would be a good point if the retry patch touched
> any TX paths. But it doesn't.
If one teaches musb_start_urb() to restart, that one should at least be
consistent I think.
>>Also, you must not clear qh->iso_idx when restarting -- you
>>must not start ISO transfer all over again too. Also, you should not set
>>musb->ep0_state to MUSB_EP0_START again in this case (I agree that control
>>transfers will remain not restartable from an arbitatry place even then).
> But the [3/3] patch only adds NAK timeout support for
> bulk RX. And ISO transfers can't NAK in the first place.
> Plus, as noted in a comment you could see in this patch,
> this only touches (re)start for bulk/interrupt transfers.
> Not ISO; not control.
All I was asking for was a bit of consistency. Note that I have already
done all the changes that I requested for and can post them.
URB restart is also going to be used for the interrupt transfers BTW.
> - Dave
WBR, Sergei
prev parent reply other threads:[~2009-02-24 15:49 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-06 11:52 [PATCH 2/3] usb: musb: fix bug in musb_start_urb Ajay Kumar Gupta
[not found] ` <1233921146-4046-1-git-send-email-ajay.gupta-l0cyMroinI0@public.gmane.org>
2009-02-06 15:03 ` Sergei Shtylyov
2009-02-23 22:05 ` David Brownell
2009-02-24 15:50 ` Sergei Shtylyov [this message]
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=49A41743.5090207@ru.mvista.com \
--to=sshtylyov@ru.mvista.com \
--cc=ajay.gupta@ti.com \
--cc=david-b@pacbell.net \
--cc=felipe.balbi@nokia.com \
--cc=linux-omap@vger.kernel.org \
--cc=linux-usb@vger.kernel.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.