[OpenWrt-Devel] upstreaming (most) rt2x00 patches

[Martin Blumenstingl]

On Sat, Jan 14, 2017 at 3:44 AM, Daniel Golle <daniel at makrotopia.org> wrote:
> 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).
then I just misunderstood you, problem solved!

>> 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 ?
seems so, but I don't have a N900 and I've only been following the
discussion loosely

>> 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.
I actually used a device with RT3062F a bit more than a year ago,
because the main device I tried to use had crashing ath10k firmware
(due to some platforms not liking DMA bursts: [0]) and really poor
ath9k performance (due to [1]).
the device with RT3062F "just worked".

(so much for the off-topic stuff...)


[0] https://patchwork.kernel.org/patch/7173811/
[1] https://www.spinics.net/lists/linux-wireless/msg138953.html