On Fri, Feb 4, 2011 at 3:53 PM, Sujith <m.sujith@xxxxxxxxx> wrote: > Vivek Natarajan wrote: >> So, will it be appropriate to add stop and wake queue while calling >> ath_drain_all_txq? > > Am not sure. I happened to look at that comment and thought it a bit > odd that the caller is expected to call wake_queues(). > >> Currently, flush() is called only when mac80211 is moving to off >> channel. Even if we call flush before sending nullfunc frame for power >> save, a question arises if it should be done with drop = true or >> false. If set as false, there is a possibility that the frames might >> be still around in the hw when nullfunc is sent and the same issue >> might pop up. > > "Still around in the hw" ? > > ath_drain_all_txq() will stop HW DMA first and then remove all the > pending frames in all HW queues and add them to the free buffer list. > This is true for retry_tx set as false(for ath_draintxq) but if the retry is set, I suppose the frame will be in the hw queue till all the hw retries(20) and sw retries(10) (200 retries in total)are over. This will take a lot of time for completion if the channel is busy. > When flush() is called, the driver would empty its HW queues and then > mac80211 would proceed to send the nullfunc frame. Isn't this the fix > that you require ? I am thinking of calling ath_drain_all_txq() in flush() and the only query is should the retry_tx be set. >> We were considering yet another approach too: >> In this case, if a nullfunc frame for PS comes to the driver when >> there are pending frames in the hw queue(the frames queued before >> 100ms and still pending because of highly noisy environment), silently >> drop the frame so that mac80211 will try once again after 100ms to go >> to PS. The issue that I face here is, ath9k does not know whether this >> frame is actually for PS or for fake sleep before scanning. > > Well, silently dropping frames is generally frowned upon. :) return -ENOMEM is what I meant though mac80211 does not check the return status here. Vivek. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
