From: Mattias Nissler <mattias.nissler@gmx.de>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: Ivo van Doorn <ivdoorn@gmail.com>,
rt2400-devel <rt2400-devel@lists.sourceforge.net>,
linux-wireless <linux-wireless@vger.kernel.org>,
Stefano Brivio <stefano.brivio@polimi.it>
Subject: Re: tx_status reporting of RTS/CTS frames
Date: Thu, 13 Dec 2007 19:56:44 +0100 [thread overview]
Message-ID: <1197572204.7489.7.camel@localhost> (raw)
In-Reply-To: <1197545672.6558.238.camel@johannes.berg>
On Thu, 2007-12-13 at 12:34 +0100, Johannes Berg wrote:
> > rt2x00 devices have some flags in the TX descriptor that basically tell
> > the device to send a burst of frames, optionally requesting to wait for
> > an ack (i.e. CTS in the case of an RTS frame) for any of them.
>
> Interesting. I can't the place where that is set though, can you point
> me to it?
For each frame, rt2x00 creates a txdata_entry_desc structure (see
rt2x00lib_write_tx_desc()), which holds all the information that is
written to the actual tx descriptors (format of these varies among the
different devices we support, but the information in the tx descriptors
is roughly the same). See rt61pci_write_tx_desc() for an example of how
the information is stored into the actual tx descriptor, but that's
rather boring.
The bits you're interested in are ENTRY_TXD_ACK and ENTRY_TXD_BURST.
BURST tells the device the next frame is part of the same burst (also
note that we have to set the correct IFS), i.e. the next frame goes out
directly after the current one (respecting the IFS of course). The
TXD_ACK bit means the hardware should wait for an ack of some kind (e.g.
CTS for RTS frames).
Mattas
next prev parent reply other threads:[~2007-12-13 18:56 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-11 22:42 tx_status reporting of RTS/CTS frames Mattias Nissler
2007-12-12 17:15 ` Johannes Berg
2007-12-12 19:49 ` Mattias Nissler
2007-12-13 11:34 ` Johannes Berg
2007-12-13 18:56 ` Mattias Nissler [this message]
2007-12-13 19:14 ` Johannes Berg
2007-12-23 21:18 ` Ivo van Doorn
2007-12-14 5:20 ` Jouni Malinen
2007-12-14 12:10 ` Johannes Berg
2007-12-23 21:17 ` Ivo van Doorn
2007-12-23 21:29 ` Johannes Berg
2007-12-23 21:50 ` Ivo van Doorn
2007-12-23 21:54 ` Johannes Berg
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=1197572204.7489.7.camel@localhost \
--to=mattias.nissler@gmx.de \
--cc=ivdoorn@gmail.com \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=rt2400-devel@lists.sourceforge.net \
--cc=stefano.brivio@polimi.it \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).