[OpenWrt-Devel] upstreaming (most) rt2x00 patches

[Daniel Golle]

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 <pozega.tomislav at gmail.com> 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 <daniel at makrotopia.org> 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
> >> openwrt-devel at lists.openwrt.org
> >> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> >>
> >
> >
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel