Hi
I'm very interested in adding support (especially AP mode) for MT76x2U
USB-dongles to Linux kernel. I'm aware of the work you both have done, Felix's
work on MT76x2 PCI-devices and Jakub's work to add support for MT7601U. So I
guess no one knows this exact problem domain better than you (perhaps excluding
MediaTek's subcontractors who wrote the original vendor driver), that is why I'm
writing specifically to you.
I have ASUS USB-N53_B1 adapter (0b05:180b) as a test device:
https://wikidevi.com/wiki/ASUS_USB-N53_B1
As far as I know, no one has been / is working on MT76x2U USB-dongles, please
correct me if I'm wrong.
I have a strong system programming background, some knowledge on 802.11 in
general, but no actual experience in Linux kernel programming. So I'm pretty
confident that I'll have many questions to throw at you before I have managed to
make anything functional.
So, to get started, I was wondering what would be the best way forward. I can
think of two reasonable approaches:
#1 Base the new driver on Felix's mt76 and modify it to work on USB-bus
instead of PCI.
#2 Base the new driver on Jakub's mt7601u and modify it to handle mt76x2u
devices by using Felix's mt76 and the vendor driver as a reference.
Of course there's the third option to write it from scratch based solely on the
vendor driver, but because you have already done such a great job in
interpreting the outdated and quite ugly (subjective view?) vendor driver code,
that would be foolish.
At first I had a hunch that #1 would be the easiest way forward, but now that I
skimmed through the code, I'm beginning to think that approach #2 has the least
resistance. However, I'm not necessarily looking for the easiest way but *the
best/right* way. So any ideas, opinions and thoughts are more than welcome.
--
Tuomas
CC: Linus W who was hacking on mt7630e recently.
On Fri, 14 Aug 2015 11:15:26 +0300, Tuomas Räsänen wrote:
> Hi
>
> I'm very interested in adding support (especially AP mode) for MT76x2U
> USB-dongles to Linux kernel. I'm aware of the work you both have done, Felix's
> work on MT76x2 PCI-devices and Jakub's work to add support for MT7601U. So I
> guess no one knows this exact problem domain better than you (perhaps excluding
> MediaTek's subcontractors who wrote the original vendor driver), that is why I'm
> writing specifically to you.
>
> I have ASUS USB-N53_B1 adapter (0b05:180b) as a test device:
> https://wikidevi.com/wiki/ASUS_USB-N53_B1
>
> As far as I know, no one has been / is working on MT76x2U USB-dongles, please
> correct me if I'm wrong.
>
> I have a strong system programming background, some knowledge on 802.11 in
> general, but no actual experience in Linux kernel programming. So I'm pretty
> confident that I'll have many questions to throw at you before I have managed to
> make anything functional.
>
> So, to get started, I was wondering what would be the best way forward. I can
> think of two reasonable approaches:
>
> #1 Base the new driver on Felix's mt76 and modify it to work on USB-bus
> instead of PCI.
>
> #2 Base the new driver on Jakub's mt7601u and modify it to handle mt76x2u
> devices by using Felix's mt76 and the vendor driver as a reference.
>
> Of course there's the third option to write it from scratch based solely on the
> vendor driver, but because you have already done such a great job in
> interpreting the outdated and quite ugly (subjective view?) vendor driver code,
> that would be foolish.
There is a fourth option: merge mt76 and mt7601u and add support for
mt76x2u along the way ;)
> At first I had a hunch that #1 would be the easiest way forward, but now that I
> skimmed through the code, I'm beginning to think that approach #2 has the least
> resistance. However, I'm not necessarily looking for the easiest way but *the
> best/right* way. So any ideas, opinions and thoughts are more than welcome.
Hardware wise your chipsets will be closer to the ones Felix is
supporting and mt76 has AP support as well (which mt7601u is lacking).
But mt76 is not upstream and I don't think USB is a priority there...
On my side, I won't be able to help you or do mentoring for next few
months for contractual reasons :(
Hi,
On Wed, Dec 16, 2015 at 07:53:04PM +0100, Felix Fietkau wrote:
> Once I'm done with mt7603 bringup (monitor mode rx already works), I
> plan on submitting mt76 upstream, and then we can see about adding
> support for 76x2u, or even merging the hardware support for mt7601u.
>
> You can check out my work in the mt7603 branch here:
> https://github.com/openwrt/mt76/tree/mt7603
let me chime in to say that I'm interested to work on
support for mt7610u (TP-LINK Archer T2U/T2UH).
https://wikidevi.com/wiki/TP-LINK_Archer_T2U
I'm facing the same question as Tuomas about using
mt76 or mt7601u as the base?
Johannes
Hi Felix and Jakub,
On Wed, Dec 16, 2015 at 10:24:25PM +0100, Johannes Stezenbach wrote:
> On Wed, Dec 16, 2015 at 07:53:04PM +0100, Felix Fietkau wrote:
> > Once I'm done with mt7603 bringup (monitor mode rx already works), I
> > plan on submitting mt76 upstream, and then we can see about adding
> > support for 76x2u, or even merging the hardware support for mt7601u.
> >
> > You can check out my work in the mt7603 branch here:
> > https://github.com/openwrt/mt76/tree/mt7603
>
> let me chime in to say that I'm interested to work on
> support for mt7610u (TP-LINK Archer T2U/T2UH).
> https://wikidevi.com/wiki/TP-LINK_Archer_T2U
>
> I'm facing the same question as Tuomas about using
> mt76 or mt7601u as the base?
It's not like I didn't get from your earlier mail that
you'd rather have us wait for mt76 to be upstream, but
I guess that'll take half a year at least, right?
Probably it would take me months to get something working
anyway as I have a lot to learn and I'm doing it in my
spare time. I have no problem to rewrite the code multiple
times as needed when upstream changes.
But I'd love to get your recommendation how to get started soon,
and especially if you know if the mt7610u chipset is
closer to mt7601u or mt76x[23][eu]?
Thanks,
Johannes
On 2015-08-14 14:32, Jakub Kiciński wrote:
> CC: Linus W who was hacking on mt7630e recently.
>
> On Fri, 14 Aug 2015 11:15:26 +0300, Tuomas Räsänen wrote:
>> Hi
>>
>> I'm very interested in adding support (especially AP mode) for MT76x2U
>> USB-dongles to Linux kernel. I'm aware of the work you both have done, Felix's
>> work on MT76x2 PCI-devices and Jakub's work to add support for MT7601U. So I
>> guess no one knows this exact problem domain better than you (perhaps excluding
>> MediaTek's subcontractors who wrote the original vendor driver), that is why I'm
>> writing specifically to you.
>>
>> I have ASUS USB-N53_B1 adapter (0b05:180b) as a test device:
>> https://wikidevi.com/wiki/ASUS_USB-N53_B1
>>
>> As far as I know, no one has been / is working on MT76x2U USB-dongles, please
>> correct me if I'm wrong.
>>
>> I have a strong system programming background, some knowledge on 802.11 in
>> general, but no actual experience in Linux kernel programming. So I'm pretty
>> confident that I'll have many questions to throw at you before I have managed to
>> make anything functional.
>>
>> So, to get started, I was wondering what would be the best way forward. I can
>> think of two reasonable approaches:
>>
>> #1 Base the new driver on Felix's mt76 and modify it to work on USB-bus
>> instead of PCI.
>>
>> #2 Base the new driver on Jakub's mt7601u and modify it to handle mt76x2u
>> devices by using Felix's mt76 and the vendor driver as a reference.
>>
>> Of course there's the third option to write it from scratch based solely on the
>> vendor driver, but because you have already done such a great job in
>> interpreting the outdated and quite ugly (subjective view?) vendor driver code,
>> that would be foolish.
>
> There is a fourth option: merge mt76 and mt7601u and add support for
> mt76x2u along the way ;)
>
>> At first I had a hunch that #1 would be the easiest way forward, but now that I
>> skimmed through the code, I'm beginning to think that approach #2 has the least
>> resistance. However, I'm not necessarily looking for the easiest way but *the
>> best/right* way. So any ideas, opinions and thoughts are more than welcome.
>
> Hardware wise your chipsets will be closer to the ones Felix is
> supporting and mt76 has AP support as well (which mt7601u is lacking).
> But mt76 is not upstream and I don't think USB is a priority there...
>
> On my side, I won't be able to help you or do mentoring for next few
> months for contractual reasons :(
Hey guys,
I just wanted to let you know that I'm making good progress with mt76
support for mt7603e chips.
I think I finally have a good code structure in place to deal with with
very different chipsets.
While mt7603 has an entirely different register layout, MCU packet
format and MAC interface, I was able to share a lot of code between 76x2
and 7603 with very little indirection.
Once I'm done with mt7603 bringup (monitor mode rx already works), I
plan on submitting mt76 upstream, and then we can see about adding
support for 76x2u, or even merging the hardware support for mt7601u.
You can check out my work in the mt7603 branch here:
https://github.com/openwrt/mt76/tree/mt7603
- Felix
On Fri, Aug 14, 2015 at 2:32 PM, Jakub Kiciński <[email protected]> wrote:
> CC: Linus W who was hacking on mt7630e recently.
FWIW I have pushed my git tree here:
https://github.com/linusw/linux-mt7630e
The driver codedrop from Mediatek turned out to be based on
kernel v3.10 so there the patches applied cleanly. I then rebased
that to v3.11 all the way up to v4.3.
Branches are named:
mt7630e-<kernelversion>
That branch does allow me to see access points so it's not
totally worthless, but it doesn't associate or connect so
there is logic missing, and that's where my knowledge of
wireless fell short. It wasn't about git rebasing and simple
C code anymore ... I actually had to know what I was
doing, haha :)
Since then I have not had time to go back and look at it
again.
Yours,
Linus Walleij
On 2016-03-08 13:49, Johannes Stezenbach wrote:
> On Mon, Mar 07, 2016 at 10:22:38PM +0100, Felix Fietkau wrote:
>> On 2016-03-07 13:41, Johannes Stezenbach wrote:
>> > http://www.mediatek.com/en/downloads1/downloads/mt7612u/
>> I checked, they simply use a software timer for it and stuff buffered
>> multicast packets into the BE queue. I don't think the hardware offers
>> any better way of doing this...
>
> I had to refresh my memory on this driver. The thing that tripped
> me when I first read through it was that is using a jiffies based
> timer and additionally sets it to fire 10ms after the calculated
> beacon time. So it's always too late, isn't it?
>
> But of course it is irrelevant for us since we can use a hrtimer.
> However, if other frames are queued in the hw they are still sent
> before the buffered frames. Since the hw has a dedicated queue
> for HCCA I wonder if it could be used here?
> (My knowledged of the standard is also rusty, ISTR the buffered
> traffic must be sent before other traffic before the stations
> go back to sleep.)
On mt76x2e, I simply use the management queue for buffered frames, since
it has a very high priority, and management frames are typically
delivered via the voice WMM queue anyway.
I think the MAC is probably similar enough that the same approach is
possible on mt76x2u as well.
- Felix
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
On Tue, Mar 08, 2016 at 01:58:03PM +0100, Felix Fietkau wrote:
> On 2016-03-08 13:49, Johannes Stezenbach wrote:
> > On Mon, Mar 07, 2016 at 10:22:38PM +0100, Felix Fietkau wrote:
> >> On 2016-03-07 13:41, Johannes Stezenbach wrote:
> >> > http://www.mediatek.com/en/downloads1/downloads/mt7612u/
> >> I checked, they simply use a software timer for it and stuff buffered
> >> multicast packets into the BE queue. I don't think the hardware offers
> >> any better way of doing this...
> >
> > I had to refresh my memory on this driver. The thing that tripped
> > me when I first read through it was that is using a jiffies based
> > timer and additionally sets it to fire 10ms after the calculated
> > beacon time. So it's always too late, isn't it?
> >
> > But of course it is irrelevant for us since we can use a hrtimer.
> > However, if other frames are queued in the hw they are still sent
> > before the buffered frames. Since the hw has a dedicated queue
> > for HCCA I wonder if it could be used here?
> > (My knowledged of the standard is also rusty, ISTR the buffered
> > traffic must be sent before other traffic before the stations
> > go back to sleep.)
> On mt76x2e, I simply use the management queue for buffered frames, since
> it has a very high priority, and management frames are typically
> delivered via the voice WMM queue anyway.
> I think the MAC is probably similar enough that the same approach is
> possible on mt76x2u as well.
The mt7610u has 2 IN and 6 OUT endpoints, where 1 IN and 1 out
are for MCU commands and the 5 remaining OUT EPs are
for EDCA VO/VI/BE/BK and HCCA.
I found the vendor driver uses:
#define MGMTPIPEIDX 0 /* EP6 is highest priority */
where the comment is confusing since
#define EDCA_AC0_PIPE 0 /* Bulk EP1 OUT */
#define EDCA_AC1_PIPE 1 /* Bulk EP2 OUT */
#define EDCA_AC2_PIPE 2 /* Bulk EP3 OUT */
#define EDCA_AC3_PIPE 3 /* Bulk EP4 OUT */
#define HCCA_PIPE 4 /* Bulk EP5 OUT */
Johannes
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
On 2016-03-07 13:41, Johannes Stezenbach wrote:
> 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)
The driver does need to provide the exact rates that were tried, but
minstrel does not care about the skb itself. mt76 infers the probed rate
from the status last tx rate + the number of retries (based on the
hardcoded hardware rate fallback table).
- Felix
On Mon, Mar 07, 2016 at 10:22:38PM +0100, Felix Fietkau wrote:
> On 2016-03-07 13:41, Johannes Stezenbach wrote:
> > http://www.mediatek.com/en/downloads1/downloads/mt7612u/
> I checked, they simply use a software timer for it and stuff buffered
> multicast packets into the BE queue. I don't think the hardware offers
> any better way of doing this...
I had to refresh my memory on this driver. The thing that tripped
me when I first read through it was that is using a jiffies based
timer and additionally sets it to fire 10ms after the calculated
beacon time. So it's always too late, isn't it?
But of course it is irrelevant for us since we can use a hrtimer.
However, if other frames are queued in the hw they are still sent
before the buffered frames. Since the hw has a dedicated queue
for HCCA I wonder if it could be used here?
(My knowledged of the standard is also rusty, ISTR the buffered
traffic must be sent before other traffic before the stations
go back to sleep.)
Johannes
On 2016-03-07 12:14, Johannes Stezenbach wrote:
> 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.
Where can I find the most recent version of that vendor driver?
I can take a quick look at it.
> 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.
- Felix
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?
--
Tuomas
On 2016-03-07 13:41, Johannes Stezenbach wrote:
> 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/
I checked, they simply use a software timer for it and stuff buffered
multicast packets into the BE queue. I don't think the hardware offers
any better way of doing this...
- Felix