On Wed, Mar 02, 2016 at 09:32:10AM +0200, Tuomas Räsänen wrote: > On Fri, Aug 14, 2015 at 02:32:29PM +0200, Jakub Kiciński wrote: > > CC: Linus W who was hacking on mt7630e recently. > > > > There is a fourth option: merge mt76 and mt7601u and add support for > > mt76x2u along the way ;) > > Btw, how difficult it would be to add master mode support to mt7601u? > > From 1 to 5, where 1 corresponds to "I know what I do, just give me > couple of days, no interruptions" and 5 corresponds to the work you > had to make to get mt7601u to its current shape? I can't answer that question, but I've spent time studying the various drivers in preparation for adding support for mt7610u, my conclusion is the hardware is similar to mt76x2e (same MAC, same RF) so for me that's the way to go. The big drawback of the USB devices is the lack of interrupts, especially no TBTT and PRE_TBTT, so it's not clear how to support AP mode properly. 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. 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? The mt7610u vendor driver doesn't use the TX_STAT_FIFO at all (it has code to read it but it is bypassed for mt7610u), its rate control relies on the statistic registers only. 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
