On Mon, Mar 07, 2016 at 12:51:43PM +0100, Felix Fietkau wrote: > On 2016-03-07 12:14, Johannes Stezenbach wrote: > > FWIW, the mt7610u vendor driver > > doesn't support AP mode, while the mt7612u vendor driver does, > > but I didn't understand how their timing of sending buffered > > frames works. > Where can I find the most recent version of that vendor driver? > I can take a quick look at it. http://www.mediatek.com/en/downloads1/downloads/ or more specifically http://www.mediatek.com/en/downloads1/downloads/mt7612u/ > > Another concern is the handling of the TX status since there > > is also no TX_STAT interrupt. I remember from rt2800usb > > it was always problematic to ensure no FIFO items were lost, > > which is a problem for rt2800usb since it doesn't report > > TX status before it got it from the hardware. > > The mt7601u driver takes the approach to report IEEE80211_TX_STAT_ACK > > immediately after urb completion, and send the real > > status later from a delayed workqueue in mt7601u_tx_stat(). > > Could someone enlighten me if this approach is sane > > wrt to minstrel rate control? > When I started writing mt76 I did lots of experiments with trying to map > TX_STAT_FIFO data to individual frames and pretty much gave up, because > the status register was just too unreliable. Even in cases where it was > reliable, mapping the status info to frames is expensive on slower > embedded hardware, so I pretty much gave up on that approach and > extended the rate control API to support submitting tx status > information without the corresponding skb. > > This turned out to work quite well, and I think it might be worth using > to some extent even on drivers with proper skb tx status reporting, > since it has better cache footprint and has to run less code. > > I think the best approach is to try to map tx status info from > TX_STAT_FIFO in cases where IEEE80211_TX_CTL_REQ_TX_STATUS is set, and > just use ieee80211_tx_status_noskb for all other frames. I did something > like that on my work-in-progress mt7603 code. OK, I thought minstrels send some probe frames with high rates to check if they go through and thus relies on exact TX status for these? (IEEE80211_TX_CTL_RATE_CTRL_PROBE) Thanks, Johannes -- 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