[OpenWrt-Devel] upstreaming (most) rt2x00 patches

[Martin Blumenstingl]

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)

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

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 :))!


Regards,
Martin


[0] https://marc.info/?l=linux-wireless&m=148259864900818&w=2
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel