Hi Tom, Thank you for reporting that issue. I reckon that support for the MT7620 family should thus be considered experimental and is not yet fit for being merged upstream. I thus removed it from them rt2x00 patch-queue tree on github.
Cheers Daniel On Fri, Jan 13, 2017 at 12:16:01AM +0100, Tom Psyborg wrote: > more info: > > https://forum.openwrt.org/viewtopic.php?id=69042 > > https://forum.lede-project.org/t/mt7620a-rx-path-issue/671 > > On 13 January 2017 at 00:14, Tom Psyborg <[email protected]> wrote: > > > Hi > > > > Any news on MT7620A LNA support? I still don't know if all devices are > > affected, but few of them are confirmed to have weak reception, possibly > > eLNA layout devices? > > > > On 12 January 2017 at 15:35, Daniel Golle <[email protected]> wrote: > > > >> Hi! > >> > >> The amount of patches on top of rt2x00 has grown into a huge pile > >> during the past couple of years. To get things into a shape that allow > >> discussing and merging them upstream, I created a tree on github based > >> on wireless-drivers-next.git: > >> > >> https://github.com/dangowrt/linux/commits/rt2x00-from-openwrt > >> > >> I had to fix up some of Gabor's patches to still apply on the updated > >> code base, but apart from those small fixes, things still apply cleanly > >> on that tree. > >> Imho the patch adding support for MT7620 still needs some more cleaning > >> (I fixed some white-space and indention issues already), and both > >> MT7620 and RT5350 still use mdelay and udelay which should be replaced > >> in the same way done for other codepaths upstream. It'd also be great > >> not to mess up RFxxxx and RTxxxx, ie. correctly set the RFxxxx value > >> for RT5350 and MT7620 according to the actual RF IP used on those > >> chips. Just for clarification, RT6352 was later renamed to MT7620 > >> > >> I for now didn't add any of the EEPROM-related patches, I a suppose > >> that only read_eeprom_from_mtd() should go upstream and all file and > >> firmware-loading mechanics can be considered legacy. > >> I also didn't add any of the device-tree specific stuff, as that will > >> need to be documented (Documentation/devicetree/ofbindings/). > >> > >> However, all the rest should be fine. Maybe the commit messages could > >> be nicer... > >> > >> The goal is to have a nice and clean tree which we can asked to be > >> merged into wireless-drivers-next.git instead of submitting the patches > >> one-by-one via the mailing list. > >> > >> Thus I'm asking for your help: Please review the patches, and also > >> let me know if you had any plans for upstreaming them yourself. > >> > >> > >> Cheers > >> > >> > >> Daniel > >> _______________________________________________ > >> openwrt-devel mailing list > >> [email protected] > >> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > >> > > > > _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
