From: Stanislaw Gruszka <sgruszka@redhat.com>
To: Jakub Kicinski <moorray@wp.pl>
Cc: "John W. Linville" <linville@tuxdriver.com>,
linux-wireless@vger.kernel.org, users@rt2x00.serialmonkey.com
Subject: Re: [rt2x00-users] [PATCH 3/5] rt2x00: rt2800usb: rework txstatus code
Date: Mon, 19 Mar 2012 15:29:06 +0100 [thread overview]
Message-ID: <20120319142905.GF6169@redhat.com> (raw)
In-Reply-To: <20120319141339.3596b6d8@north>
On Mon, Mar 19, 2012 at 02:13:39PM +0100, Jakub Kicinski wrote:
> > > > + if (rt2800usb_txstatus_pending(rt2x00dev) &&
> > > > + test_and_set_bit(TX_STATUS_READING, &rt2x00dev->flags))
> > >
> > > I would put a bang before that test_and...
> > I don't understand what you mean, perhaps you could post a patch
> > or provide code snipset here, so I could comment.
>
> If I understand correctly, status should be read again if there are
> pending entries and no one else has set TX_STATUS_READING yet. In that
> case return value of test_and_set_bit should be negated. I might be
> missing something though.
You are correct, this is another good catch! Fix is on the go.
> > I do not understand your objection here too. If rt2800usb_txstatus_pending()
> > will return true and if TX_STATUS_READING bit is not set, we will run hrtimer
> > to read status after 500 micro seconds. We exit the loop if kfifo is empty
> > and no entry timed out waiting to get corresponding TX status.
>
> Yes, I don't mean that this code is wrong. I just think that
> rt2800usb_async_read_tx_status have no chance of actually going past
> TX_STATUS_READING check. If every dma_done schedules reading and
> reading stops only when all pending entries have their statuses then
> call to rt2800usb_async_read_tx_status after we processed statuses is
> excessive.
>
> All that said, I haven't tested this hypothesis and may be completely
> wrong (again). Also I _don't_ mean that this call should be removed,
> just wanted to me sure I understand everything correctly ;-)
I think you have right. I'll review that carefully and remove those
lines if they are useless.
Thanks
Stanislaw
next prev parent reply other threads:[~2012-03-19 14:29 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-14 10:16 [PATCH 1/5] rt2x00: rt2800usb: move additional txdone into new function Stanislaw Gruszka
2012-03-14 10:16 ` [PATCH 2/5] rt2x00: rt2800usb: rework txdone code Stanislaw Gruszka
2012-03-14 10:16 ` [PATCH 3/5] rt2x00: rt2800usb: rework txstatus code Stanislaw Gruszka
2012-03-17 16:53 ` [rt2x00-users] " Jakub Kicinski
2012-03-19 7:52 ` Stanislaw Gruszka
2012-03-19 13:13 ` Jakub Kicinski
2012-03-19 14:29 ` Stanislaw Gruszka [this message]
2012-03-14 10:16 ` [PATCH 4/5] rt2x00: rt2800usb: do not check packedid for aggregated frames Stanislaw Gruszka
2012-03-14 10:16 ` [PATCH 5/5] rt2x00: rt2800usb: limit tx queues length Stanislaw Gruszka
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=20120319142905.GF6169@redhat.com \
--to=sgruszka@redhat.com \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=moorray@wp.pl \
--cc=users@rt2x00.serialmonkey.com \
/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.