The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped automatically by the mailing list software.
--- Begin Message ---On Sat, Jan 14, 2017 at 3:44 AM, Daniel Golle <dan...@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 <dan...@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
--- End Message ---
_______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev