Re: About adding support for MT76x2U to Linux kernel

[Johannes Stezenbach <js@sig21.net>]

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