[LEDE-DEV] [OpenWrt-Devel] MT7620A WiFi issue - with a twist!

[Daniel Golle]

Hi Weedy,

On Fri, Feb 03, 2017 at 07:49:22PM -0500, Weedy wrote:
> On 1 February 2017 at 15:29, Jamie Stuart <jamie at onebillion.org> wrote:
> > Hello LEDE / OpenWRT devs,
> >
> > I am requesting your help. First a little background…
> ...
> > This a known issue with the chipset and seems to have been round for years.
> > We are currently building on LEDE trunk and still the issue persists.
> >
> > We are not driver developers, so my question is whether anyone with
> > knowledge can help and provide a proper fix for this issue?
> 
> 
> You will probably have the most luck posting a bounty on the linux
> wifi mailing list.

As a response to the many issues and obvious code quality problems in
the patch adding support for MT7620 to rt2x00 I started a kickstarter
project to fund an afternoon or two (depending on the amount people
throw into my hat) of focussing on rt2x00 running on MT7620:

https://www.kickstarter.com/projects/1327597961/better-support-for-mt7620a-n-in-openwrt-lede


> 
> Your root problem is picking a platform that basically uses a client
> mode tested driver in AP mode and then hanging a million clients off
> of it. I'm honestly surprised it didn't fall over sooner.

Well, rt2x00 is used for both AP and Client mode, and afaik there
wasn't a lot of testing for either mode of operation. And AP mode has
recently seen quite a bunch of improvements.
Having seperate drivers for AP and STA is a common strategy of chip
makers to devide-and-conquer QA and also add product differentiation,
ie. sell the same hardware for more if it is used for specific tasks.
Thus Ralink used to give away the station-mode driver for free and used
to charge people for the AP-mode driver (they do share a common
codebase). The bigger issue here is that Ralink's WiFi chip design is
flawed when using the chips in multi-STA modes (AP, Adhoc, Mesh)
because instead of having a way to set parameters for each associated
station it only allows it to be set globally, see [1] for an example of
how rt2x00 thus needs to limit the hardware to use the parameters of
the weakest associated station (the vendor driver does the same).

> 
> May I suggest when it comes time to refresh the hardware you guys pick
> something with NGFF or mini-pcie slots for ALL radios.

+1
Though I personally don't believe it's ever going to get as chaotic
and complex as for the final generation of Ralink's WiFi chips (ie.
which later became MT76x0). Ralink/Mediatek's newer chips are much
cleaner and don't share the same issues.


Cheers


Daniel

[1] https://git.kernel.org/cgit/linux/kernel/git/kvalo/wireless-drivers-next.git/commit/drivers/net/wireless/ralink/rt2x00/rt2800lib.c?id=8f03a7c6e7f959edd22e35158fbb9a4087962fae