Archer C7 V2.0 units from December 2015 onwards ( serials starting 215C
) have changed flash chips to the gd25q128 chip, this is supported in
trunk but not presently in 15.05. I would like stable support for this
version so I've back ported the required fix from trunk and removed a
conflicting patch from bcm53xx I've tested the patch it and I'm able to
install a build of 15.05.1 on a new Archer C7 device with this patch.
Signed-off-by: John Marrett <johnf@zioncluster.ca>
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
git-svn-id: svn://svn.openwrt.org/openwrt/branches/chaos_calmer@49220 3c298f89-4303-0410-b956-a3cf2f4a3e73
compat-wireless/backports now contains a bcm47xx_nvram.h file to
backport some of the functions in it which are used by the bcmfmac
driver. This file just checks for the kernel versions and provide an
empty implementations on older kernel versions. This is OK on most
systems, but on bcm47xx / bcm53xx systems we want to call the real
functions here. This commit removes the file from backports in our
build process like we do it with the bcma and ssb header files. Instead
we add a recent version into our kernel so all code uses only one
header file. On bcm47xx / bcm53xx the real implementations of this code
will be used.
Reported-by: Hante Meuleman <meuleman@broadcom.com>
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
[Backport of r47467. The recent mac80211 backport was missing this patch,
breaking the build of the brcmfmac module]
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
git-svn-id: svn://svn.openwrt.org/openwrt/branches/chaos_calmer@48831 3c298f89-4303-0410-b956-a3cf2f4a3e73
This simply replaces init fix with a final version and puts it in a
generic dir. This will allow backporting some trivial changes from 4.6.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
git-svn-id: svn://svn.openwrt.org/openwrt/branches/chaos_calmer@48788 3c298f89-4303-0410-b956-a3cf2f4a3e73
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Backport of r48409
git-svn-id: svn://svn.openwrt.org/openwrt/branches/chaos_calmer@48411 3c298f89-4303-0410-b956-a3cf2f4a3e73
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Backport of r48371
git-svn-id: svn://svn.openwrt.org/openwrt/branches/chaos_calmer@48392 3c298f89-4303-0410-b956-a3cf2f4a3e73
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Backport of r48372
git-svn-id: svn://svn.openwrt.org/openwrt/branches/chaos_calmer@48373 3c298f89-4303-0410-b956-a3cf2f4a3e73
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Backport of r47284
git-svn-id: svn://svn.openwrt.org/openwrt/branches/chaos_calmer@48165 3c298f89-4303-0410-b956-a3cf2f4a3e73
It was never tested, most likely not working (because of le32_to_cpu)
and not upstreamed.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Backport of r48060
git-svn-id: svn://svn.openwrt.org/openwrt/branches/chaos_calmer@48139 3c298f89-4303-0410-b956-a3cf2f4a3e73
This fixes regression introduced in my recent ledtrig-netdev commit.
Events triggered by different interfaces were stopping timer so it
wasn't working for tx/rx mode.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Backport of r48072
git-svn-id: svn://svn.openwrt.org/openwrt/branches/chaos_calmer@48074 3c298f89-4303-0410-b956-a3cf2f4a3e73
The ppp0 interface is renamed after the connection is established. Due
to a missing NETDEV_REGISTER event, the ledtrig-netdev isn't aware of
the renamed interface and literally ignores the device
(no tx/rx indication, led isn't switched off with 'ifdown wan').
Signed-off-by: Mathias Kresin <openwrt@kresin.me>
Backport of r48048
git-svn-id: svn://svn.openwrt.org/openwrt/branches/chaos_calmer@48073 3c298f89-4303-0410-b956-a3cf2f4a3e73
Previously switching to non-existing device (interface) could result in
leaving LED on.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Backport of r47990
git-svn-id: svn://svn.openwrt.org/openwrt/branches/chaos_calmer@47992 3c298f89-4303-0410-b956-a3cf2f4a3e73
We may just delete timer on every trigger update and then start it again
if needed. This will let us avoid both: races and locking in frequently
called timer callback.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Backport of r47987
git-svn-id: svn://svn.openwrt.org/openwrt/branches/chaos_calmer@47991 3c298f89-4303-0410-b956-a3cf2f4a3e73
Read/write lock was adding useless complexity, there wasn't any real
gain in case of this driver.
Also switch to _bh variants to avoid deadlocks.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Backport of r47986
git-svn-id: svn://svn.openwrt.org/openwrt/branches/chaos_calmer@47989 3c298f89-4303-0410-b956-a3cf2f4a3e73
All supported kernels require patching ledtrig-netdev in the same way,
so it's safe to just move these changes to the base version of this
driver. We needed these patches for some old kernels 2.6.36 and 3.11.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Backport of r47962
git-svn-id: svn://svn.openwrt.org/openwrt/branches/chaos_calmer@47988 3c298f89-4303-0410-b956-a3cf2f4a3e73
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Backport of r47966
git-svn-id: svn://svn.openwrt.org/openwrt/branches/chaos_calmer@47967 3c298f89-4303-0410-b956-a3cf2f4a3e73
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Backport of r47963
git-svn-id: svn://svn.openwrt.org/openwrt/branches/chaos_calmer@47964 3c298f89-4303-0410-b956-a3cf2f4a3e73
This replaces old bcm53xx patch for scanning whole flash and makes
bcm47xxpart compatible with NAND.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Backport of r47800
git-svn-id: svn://svn.openwrt.org/openwrt/branches/chaos_calmer@47803 3c298f89-4303-0410-b956-a3cf2f4a3e73
This contains only the fixes from the 4.3-rc4 kernel.
Additional improvements are going into 4.4 which will fix and enable
hardware checksum/TSO offload, but backporting those to older kernels
is non-trivial.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
git-svn-id: svn://svn.openwrt.org/openwrt/branches/chaos_calmer@47195 3c298f89-4303-0410-b956-a3cf2f4a3e73
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Backport of r47045
git-svn-id: svn://svn.openwrt.org/openwrt/branches/chaos_calmer@47046 3c298f89-4303-0410-b956-a3cf2f4a3e73
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Backport of r47026
git-svn-id: svn://svn.openwrt.org/openwrt/branches/chaos_calmer@47027 3c298f89-4303-0410-b956-a3cf2f4a3e73
The mips reloc patch introduced new allocations which were done before
add_unformed_module but never freed them in case of an error. A new hook in
Linux 3.19 called module_arch_freeing_init can be used for freeing memory
which were allocated during this init phase.
The problem can be seen when trying to load a module (via busybox insmod)
when it was already loaded.
free -m
for i in `seq 1 100`; do
/sbin/insmod /lib/modules/*/ath9k.ko >& /dev/null
done
free -m
This simple loop would leak ~3.2 MB.
Signed-off-by: Sven Eckelmann <sven@open-mesh.com>
Backport of r46247
git-svn-id: svn://svn.openwrt.org/openwrt/branches/chaos_calmer@47004 3c298f89-4303-0410-b956-a3cf2f4a3e73
Currently, multicast packets from an STA are sent to any according
multicast listener directly through the bridge multicast-to-unicast
feature. Unfortunately, so far this includes the originating STA, too,
resulting in multicast packets being echo'ed back to the originating STA
if it itself is a multicast listener for that group.
This behaviour breaks IPv6 duplicate address detection: An IPv6 Neighbor
Solicitation for IPv6 Duplicate Address Detection is being echo'ed back,
resulting in the host falsely detecting an address collision, which
makes the node unable to claim an IPv6 address and use IPv6 in general.
Mac80211 unfortunately only prevents the echoes for us for multicast
frames. For the multicast frames cast to a unicast destination we'll
need to take care of excluding the originator ourselves.
Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
Backport of r46765
git-svn-id: svn://svn.openwrt.org/openwrt/branches/chaos_calmer@47003 3c298f89-4303-0410-b956-a3cf2f4a3e73
commit r30917 ("kernel: bypass all netfilter hooks if the sysctls for that
functionality have been disabled - eliminates the overhead of enabling
CONFIG_BRIDGE_NETFILTER in the kernel config") introduced an optimization
which should reduce/eliminate the overhead for traffic send over bridges on
kernels compiled with CONFIG_BRIDGE_NETFILTER=y. But this optimization
breaks the nf_call_iptables per bridge setting which is more fine grained
than the global sysctl net.bridge.bridge-nf-call-iptables setting.
A test reflecting a real world setup was created to identify if this really
eliminates the overhead and if per-bridge nf_call_iptables could be used in
some setups to increase the throughput. A Qualcomm Atheros QCA9558 based
system with one ethernet and an ath9k wifi 3x3 in HT40 mode was used.
Cables from the AP to the wifi station were used to reduce interference
problems during the tests.
The wlan interface was put in one bridge interface called br-wlan. This
bridge usually contains some more wlan interfaces. The eth0 was put in a
second bridge called br-lan. This usually contains some other privileged
wlan or mesh interfaces. Routing was added between br-lan and br-wlan.
Three kernels were tested:
* (default) OpenWrt kernel for this device
* (brfilter-global) OpenWrt kernel with CONFIG_BRIDGE_NETFILTER=y
* (brfilter-local) OpenWrt kernel with CONFIG_BRIDGE_NETFILTER=y and
without 644-bridge_optimize_netfilter_hooks.patch
The changes to the the netfilter settings of the bridge were done via:
* (brfilter-global) /sbin/sysctl -w net.bridge.bridge-nf-call-iptables=1
* (brfilter-lobal) echo 1 > /sys/class/net/br-lan/bridge/nf_call_iptables
and/or echo 1 > /sys/class/net/br-wan/bridge/nf_call_iptables
A station connected to the wlan0 (AP) interface was used to send traffic to
a PC connected via ethernet. iperf with 3 concurrent transmissions was used
to generate the traffic.
| kernel | br-nf-* global | nf-call* iface | download | upload |
|-----------------|----------------|----------------|----------|----------|
| default | 0 | - | 209 | 268 |
| brfilter-global | 0 | - | 185 | 243 |
| brfilter-local | 0 | - | 187 | 243 |
| brfilter-local | 0 | br-lan | 157 | 226 |
| brfilter-local | 0 | br-lan br-wlan | 139 | 161 |
| brfilter-global | 1 | - | 136 | 162 |
Download/upload results in Mibit/s
It can be seen that the patch doesn't eliminate the overhead. It can also
be seen that the throughput of brfilter-global and brfilter-local with
disabled filtering is the roughly the same. Also the throughput for
brfilter-global and brfilter-local for enabled filtering on all bridges is
roughly the same.
But also the brfilter-local throughput is higher when only br-lan requires
the filtering. This setting would not be possible with
644-bridge_optimize_netfilter_hooks.patch applied and thus can only be
compared with brfilter-global and filtering enabled for all interfaces.
Signed-off-by: Sven Eckelmann <sven@open-mesh.com>
Backport of r46835
git-svn-id: svn://svn.openwrt.org/openwrt/branches/chaos_calmer@47002 3c298f89-4303-0410-b956-a3cf2f4a3e73
A call to pskb_may_pull() might reallocate skb->data. Therefore we
should only assign the src-pointer after any potential reallocations.
Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Backport of r46721
git-svn-id: svn://svn.openwrt.org/openwrt/branches/chaos_calmer@47001 3c298f89-4303-0410-b956-a3cf2f4a3e73
This reverts commit a080e8e1943156168913d0353a2e99d1151102aa.
It did not fix the problem but just hid some symptom. The real issue was
that IGMP/MLD report suppression was not considered for the
multicast-to-unicast feature. A recent netifd which isolates IGMP/MLD
reports between STAs by utilizing AP-isolation and bridge-hairpinning
should have fixed this.
It is perfectly fine to apply multicast-to-unicast to IPv6 Neighbor
Solicitations, too (once that feature is configured correctly).
Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Backport of r46720
git-svn-id: svn://svn.openwrt.org/openwrt/branches/chaos_calmer@47000 3c298f89-4303-0410-b956-a3cf2f4a3e73
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Backport of r46993
git-svn-id: svn://svn.openwrt.org/openwrt/branches/chaos_calmer@46995 3c298f89-4303-0410-b956-a3cf2f4a3e73
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Backport of r46992
git-svn-id: svn://svn.openwrt.org/openwrt/branches/chaos_calmer@46994 3c298f89-4303-0410-b956-a3cf2f4a3e73
It was accidentally added in r46094.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
git-svn-id: svn://svn.openwrt.org/openwrt/branches/chaos_calmer@46849 3c298f89-4303-0410-b956-a3cf2f4a3e73
It was corrupted in r38528. The most obvious symptom is repeated messages like this:
Tue Sep 8 08:25:18 2015 kern.warn kernel: [77141.972226] br-lan: received packet on wlan0 with own address as source address
Signed-off-by: Dmitry Ivanov <dima@ubnt.com>
Backport of r46821
git-svn-id: svn://svn.openwrt.org/openwrt/branches/chaos_calmer@46822 3c298f89-4303-0410-b956-a3cf2f4a3e73
Properly treat -ENOSYS as no PHY, else ehci-orion won't work without
generic phy support.
Backport of r46711.
Signed-off-by: Jonas Gorski <jogo@openwrt.org>
git-svn-id: svn://svn.openwrt.org/openwrt/branches/chaos_calmer@46712 3c298f89-4303-0410-b956-a3cf2f4a3e73
This should fix build of sunxi.
Backport of r46304
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
git-svn-id: svn://svn.openwrt.org/openwrt/branches/chaos_calmer@46310 3c298f89-4303-0410-b956-a3cf2f4a3e73
On two tested devices: Netgear R6250 (BCM53011 rev 2) and Luxul XWC-1000
(BCM53011 rev 3) it was possible to use port 7 and eth1 (instead of port
5 and eth0). It seems BCM53011 just like BCM53012 has 8 ports and
usually 3 of them are connected to the SoC.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Backport of r46104
git-svn-id: svn://svn.openwrt.org/openwrt/branches/chaos_calmer@46107 3c298f89-4303-0410-b956-a3cf2f4a3e73
