All of lore.kernel.org
 help / color / mirror / Atom feed
From: Artur Skawina <art.08.09@gmail.com>
To: Christian Lamparter <chunkeey@web.de>
Cc: Artur Skawina <art.08.09@gmail.com>, linux-wireless@vger.kernel.org
Subject: Re: [RFC][RFT][PATCH] p54usb: rx refill revamp
Date: Thu, 22 Jan 2009 20:19:16 +0100	[thread overview]
Message-ID: <4978C6B4.80601@gmail.com> (raw)
In-Reply-To: <200901221701.59190.chunkeey@web.de>

Christian Lamparter wrote:
> On Thursday 22 January 2009 16:52:44 Artur Skawina wrote:
>> Christian Lamparter wrote:
>>> On Thursday 22 January 2009 06:40:56 Artur Skawina wrote:
>>> was this with your patch to use rx_refills urb pool for tx, or without?
>> just your patch plus the fixes that i needed to get it to work, all
>> of them were in that email. The subject said RFT... ;)
>> [the line #s were off, because of some extra printks logging the queue len]
>>
> all right, could you please put a commit message in your mail as well?

I thought you had already merged the changes, but i see you only took the
first hunk. There's no point in splitting the commit, as the intermediate
result wouldn't work. You can add my s-o-b, if you feel that's necessary.
This last version seems fine, just one thing: I can't convince myself
that not queuing the work after an urb fails with urb->status==true is
safe -- what if some temporary error condition causes the rx queue to
drain? Nothing will resubmit the urbs. 
Wouldn't a usb_poison_anchored_urbs() instead of usb_kill_anchored_urbs()
in p54u_free_urbs() prevent p54u_rx_refill from resubmitting, and that early
return in the completion could then go? Or did i miss a case where it's
needed, other than stop()?

artur

  reply	other threads:[~2009-01-22 19:19 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-21 13:50 [RFC][RFT][PATCH] p54usb: rx refill revamp Christian Lamparter
2009-01-21 16:04 ` Artur Skawina
2009-01-21 18:24   ` Christian Lamparter
2009-01-21 19:32     ` Artur Skawina
2009-01-21 20:56       ` Christian Lamparter
2009-01-21 23:22         ` Artur Skawina
2009-01-22 15:00           ` Christian Lamparter
2009-01-22 15:43             ` Artur Skawina
2009-01-22 21:39               ` Christian Lamparter
2009-01-22 21:45                 ` Artur Skawina
2009-01-22 22:12                   ` Christian Lamparter
2009-01-22  5:40       ` Artur Skawina
2009-01-22 15:09         ` Christian Lamparter
2009-01-22 15:52           ` Artur Skawina
2009-01-22 16:01             ` Christian Lamparter
2009-01-22 19:19               ` Artur Skawina [this message]
2009-01-22 21:02                 ` Christian Lamparter
2009-01-22 22:05                   ` Artur Skawina
2009-01-22 22:39                     ` Christian Lamparter
2009-01-22 22:51                       ` Artur Skawina
2009-01-23  1:11                     ` Artur Skawina
2009-01-21 20:06 ` Larry Finger
2009-01-21 20:51   ` Christian Lamparter

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=4978C6B4.80601@gmail.com \
    --to=art.08.09@gmail.com \
    --cc=chunkeey@web.de \
    --cc=linux-wireless@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.