[OpenWrt-Devel] upstreaming (most) rt2x00 patches

[Daniel Golle]

Hi Martin,

On Sat, Jan 14, 2017 at 01:28:06AM +0100, Martin Blumenstingl wrote:
> On Thu, Jan 12, 2017 at 3:35 PM, 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.
> are you sure about removing the firmware-loading mechanism? I recently
> *added* this to ath9k upstream due to the following problems we had
> with "ath9k calibration data":
> 1. calibration data is stored inside a UBI volume on some ar71xx and
> lantiq devices
> 2. calibration data is stored on an unaligned offset inside the NOR
> flash of some lantiq (Fritz Box) devices
> 3. some calibration data is simply broken (vendors did a swab16(),
> messing up the position of some fields so we need another swab16() to
> get valid calibration data)

I'm fully aware of that and fully agree with you.
However, the current state of rt2x00 eeprom loading hacks wasn't in
shape for being sent upstream imho, ie. obvious things like missing
additions to Documentation/devicetree/bindings/ and remaining
platform_data legacy make it unlikely to have those patches merged
at this stage.
Apart from that, Mathias Kresin has recently been improving EEPROM
loading on rt2x00 and once all the rest is in shape upstream he should
just submit that on top once completed and cleaned up (ie. patches
adding EEPROM file reading in various ways if requested via device-tree
should be folded up, legacy platform_data stuff should be omitted).

> 
> there's also a similar discussion going on for wl1251 because there
> seem to be devices where the calibration data is obfuscated, etc.
> see [0] for more information on the wl1251 topic

Interesting. Does that mean that the N900 hardware is now fully
supported by kernel.org/torvalds/linux.git ?

> 
> apart from that: thank you for taking the time to upstream this
> (building a pile of patches which *could* be upstreamed and
> maintaining them for a very long time doesn't make us better than all
> the vendors with their custom stacks, so big thanks :))!

I recently started seeing new hope in rt2x00 as things were already
working quite nicely with our current patchset (apart from MT7620
which imho still needs quite some more work. If noone else comes first
I might do that at some point).

Now the driver has also received a lot of improvements related to
aggregation upstream, so it might finally get somewhere near to the
performance seen with ath9k. Adding proper upstream support for the
WiSoC chips seems crucial, given the popularity of chips like the
Rt5350, also to open the doors to other vanilla Linux based
distributions on those platforms.


Cheers


Daniel
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel