From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-bw0-f46.google.com ([209.85.214.46]:55583 "EHLO mail-bw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752275Ab1AVMx5 (ORCPT ); Sat, 22 Jan 2011 07:53:57 -0500 Received: by bwz15 with SMTP id 15so2372903bwz.19 for ; Sat, 22 Jan 2011 04:53:56 -0800 (PST) From: Christian Lamparter To: Sujith Subject: Re: [RFC/WIP 00/33] ath9k_htc AP mode Date: Sat, 22 Jan 2011 13:48:57 +0100 Cc: "linux-wireless" , "ath9k-devel" , Jouni Malinen References: <19768.62903.947245.576431@gargle.gargle.HOWL> <19770.18332.859418.283909@gargle.gargle.HOWL> <19770.20402.711305.279934@gargle.gargle.HOWL> In-Reply-To: <19770.20402.711305.279934@gargle.gargle.HOWL> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Message-Id: <201101221348.57720.chunkeey@googlemail.com> Sender: linux-wireless-owner@vger.kernel.org List-ID: 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christian Lamparter Date: Sat, 22 Jan 2011 13:48:57 +0100 Subject: [ath9k-devel] [RFC/WIP 00/33] ath9k_htc AP mode In-Reply-To: <19770.20402.711305.279934@gargle.gargle.HOWL> References: <19768.62903.947245.576431@gargle.gargle.HOWL> <19770.18332.859418.283909@gargle.gargle.HOWL> <19770.20402.711305.279934@gargle.gargle.HOWL> Message-ID: <201101221348.57720.chunkeey@googlemail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ath9k-devel@lists.ath9k.org 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