From: Christian Lamparter <chunkeey@googlemail.com>
To: Sujith <m.sujith@gmail.com>
Cc: "linux-wireless" <linux-wireless@vger.kernel.org>,
"ath9k-devel" <ath9k-devel@lists.ath9k.org>,
Jouni Malinen <j@w1.fi>
Subject: Re: [RFC/WIP 00/33] ath9k_htc AP mode
Date: Sat, 22 Jan 2011 13:48:57 +0100 [thread overview]
Message-ID: <201101221348.57720.chunkeey@googlemail.com> (raw)
In-Reply-To: <19770.20402.711305.279934@gargle.gargle.HOWL>
On Saturday 22 January 2011 04:32:02 Sujith wrote:
> Sujith wrote:
> > Sujith wrote:
> > > What about hardware that doesn't report any kind of TX status information at all ?
> > > Currently, there is no way to determine whether the frame has actually gone out,
> > > all that can be known is that it was pushed to the target.
> >
> > Am curious how carl9170 gets the TX status ?
> > Is there a separate endpoint ?
>
> I looked a bit into carl9170 and it looks like the TX status
> is obtained as incoming data through the CMD endpoint, am I correct ?
yes and no ;).
The tx status is obtained from the (RX-) DATA [stream/] endpoint.
The (USB?) CMD endpoint is only being used for fatal 0xc6
watchdog events [which are generated by the bootloader].
> And the cookie is used to match the status information with the approporiate
> packet ?
The driver also gets the used ac queue index from the tx feedback message.
So it knows in which tx_status queue it has to look, but that's only
a minor detail.
> Though for ath9k_htc this would mean changes in both the host and FW,
> the host has to queue up packets in some kind of queue and process them
> on reception of status interrupts. The FW has to be changed to actually
> deliver the TX status information. :)
You only have to have a sane tx status if the IEEE80211_TX_CTL_REQ_TX_STATUS
flag is set. In all other cases, the IEEE80211_TX_STAT_ACK handling is
*optional*. In fact if you don't set the TX_STAT_ACK flag, mac80211 will
automatically do the right thing when it sees that a STA has become
"temporarily" unavailable.
> It does make it a bit neat to have such a mechanism. And for AP mode,
> I would think that it's kinda essential unless someone comes with an
> ingenious way of solving the PS race for drivers that don't set
> IEEE80211_HW_REPORTS_TX_ACK_STATUS. :-)
Sure, IEEE80211_HW_REPORTS_TX_ACK_STATUS would be the way to go.
Especially because IEEE80211_HW_PS_NULLFUNC_STACK also benefits
from it.
Best regards,
Chr
next prev parent reply other threads:[~2011-01-22 12:53 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-21 2:55 [RFC/WIP 00/33] ath9k_htc AP mode Sujith
2011-01-21 3:15 ` Sujith
2011-01-21 21:26 ` Christian Lamparter
2011-01-22 2:56 ` Sujith
[not found] ` <19770.18332.859418.283909@gargle.gargle.HOWL>
2011-01-22 3:32 ` Sujith
2011-01-22 12:48 ` Christian Lamparter [this message]
2011-01-22 16:58 ` Sujith
2011-01-23 9:11 ` Johannes Berg
2011-01-23 10:01 ` Sujith
2011-01-23 10:05 ` 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=201101221348.57720.chunkeey@googlemail.com \
--to=chunkeey@googlemail.com \
--cc=ath9k-devel@lists.ath9k.org \
--cc=j@w1.fi \
--cc=linux-wireless@vger.kernel.org \
--cc=m.sujith@gmail.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 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).