summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2016-03-06ath10k: fix firmware assert in monitor modeRajkumar Manoharan
commit 166de3f1895d ("ath10k: remove supported chain mask") had revealed an issue on monitor mode. Configuring NSS upon monitor interface creation is causing target assert in all qca9888x and qca6174 firmware. Firmware assert issue can be reproduced by below sequence even after reverting commit 166de3f1895d ("ath10k: remove supported chain mask"). ip link set wlan0 down iw wlan0 set type monitor iw phy0 set antenna 7 ip link set wlan0 up This issue is originally reported on qca9888 with 10.1 firmware. Fixes: 5572a95b4b ("ath10k: apply chainmask settings to vdev on creation") Cc: stable@vger.kernel.org Reported-by: Janusz Dziedzic <janusz.dziedzic@tieto.com> Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-03-06ath10k: change htt tx desc/qcache peer limit configMichal Kazior
The number of HTT Tx descriptors and qcache peer limit aren't hw-specific. In fact they are firmware specific and should not be placed in hw_params. The QCA4019 limits were submitted with the peer flow control firmware only and to my understanding there's no non-peer-flow-ctrl QCA4019 firmware. However QCA99X0 is planned to run firmware supporting the feature as well. Therefore this patch enables QCA99X0 to use 2500 tx descriptors whenever possible instead of just 1424. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-03-06ath10k: fix HTT Tx CE ring sizeMichal Kazior
QCA4019 can queue up to 2500 frames at a time. This means it requires roughly 5000 entires on the ring to work properly. Otherwise random tx failure may occur. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-03-06ath10k: implement push-pull txMichal Kazior
The current/old tx path design was that host, at its own leisure, pushed tx frames to the device. For HTT there was ~1000-1400 msdu queue depth. After reaching that limit the driver would request mac80211 to stop queues. There was little control over what packets got in there as far as DA/RA was considered so it was rather easy to starve per-station traffic flows. With MU-MIMO this became a significant problem because the queue depth was insufficient to buffer frames from multiple clients (which could have different signal quality and capabilities) in an efficient fashion. Hence the new tx path in 10.4 was introduced: a pull-push mode. Firmware and host can share tx queue state via DMA. The state is logically a 2 dimensional array addressed via peer_id+tid pair. Each entry is a counter (either number of bytes or packets. Host keeps it updated and firmware uses it for scheduling Tx pull requests to host. This allows MU-MIMO to become a lot more effective with 10+ clients. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-03-06ath10k: keep track of queue depth per txqMichal Kazior
This will be necessary for later. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-03-06ath10k: store txq in skb_cbMichal Kazior
This will be necessary for later. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-03-06ath10k: implement updating shared htt txq stateMichal Kazior
Firmware 10.4.3 onwards can support a pull-push Tx model where it shares a Tx queue state with the host. The host updates the DMA region it pointed to during HTT setup whenever number of software queued from (on host) changes. Based on this information firmware issues fetch requests to the host telling the host how many frames from a list of given stations/tids should be submitted to the firmware. The code won't be called because not all appropriate HTT events are processed yet. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-03-06ath10k: implement wake_tx_queueMichal Kazior
This implements very basic support for software queueing. It also contains some knobs that will be patched later. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-03-06ath10k: add new htt message generation/parsing logicMichal Kazior
This merely adds some parsing, generation and sanity checks with placeholders for real code/functionality to be added later. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-03-06ath10k: add fast peer_map lookupMichal Kazior
The pull-push functionality of 10.4 will be based on peer_id and tid. These will need to be mapped, eventually, to ieee80211_txq to be used with ieee80211_tx_dequeue(). Iterating over existing stations every time peer_id needs to be mapped to a station would be inefficient wrt CPU time. The new firmware, which will be the only user of the code flow-wise, will guarantee to use low peer_ids first so despite peer_map's apparent huge size d-cache thrashing should not be a problem. Older firmware hot paths will effectively not use peer_map. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-03-06ath10k: maintain peer_id for each sta and vifMichal Kazior
The 10.4.3 firmware with congestion control guarantees that each peer has only a single peer_id mapping. The 1:1 mapping isn't the case for older firmwares (e.g. 10.4.1, 10.2, 10.1) but it should not matter. This 1:1 mapping is going to be only used by future code which inherently (flow-wise) is for 10.4.3. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-03-06ath10k: refactor tx pending managementMichal Kazior
Tx pending counter logic assumed that the sk_buff is already known and hence was performed in HTT functions themselves. However, for the sake of future wake_tx_queue() usage the driver must be able to tell whether it can submit more frames to firmware before it dequeues frame from ieee80211_txq (and thus long before HTT Tx functions are called) because once a frame is dequeued it cannot be requeud back to mac80211. This prepares the driver for future changes. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-03-06ath10k: unify txpath decisionMichal Kazior
Some future changes will need to determine final tx method early on. Prepare the code. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-03-06ath10k: refactor tx codeMichal Kazior
This prepares the code for future reuse with ieee80211_txq and wake_tx_queue() in mind. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-03-06Merge 'net-next/master'Kalle Valo
Needed by the upcoming merge of iwlwifi-next-for-kalle-2016-03-02 tag.
2016-03-06Merge ath-next from ath.gitKalle Valo
ath.git patches for 4.6. Major changes: ath10k * dt: add bindings for ipq4019 wifi block * start adding support for qca4019 chip ath9k * add device ID for Toshiba WLM-20U2/GN-1080 * allow more than one interface on DFS channels
2016-03-04Merge branch 'reset_mac_header'David S. Miller
Zhang Shengju says: ==================== use reset to set header pointers This patch series replace set function with reset when offset is zero. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-04wireless: use reset to set mac headerZhang Shengju
Since offset is zero, it's not necessary to use set function. Reset function is straightforward, and will remove the unnecessary add operation in set function. Signed-off-by: Zhang Shengju <zhangshengju@cmss.chinamobile.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-04mac80211: use reset to set header pointerZhang Shengju
Since offset is zero, it's not necessary to use set function. Reset function is straightforward, and will remove the unnecessary add operation in set function. Signed-off-by: Zhang Shengju <zhangshengju@cmss.chinamobile.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-04mac80211_hwsim: use reset to set mac headerZhang Shengju
Since offset is zero, it's not necessary to use set function. Reset function is straightforward, and will remove the unnecessary add operation in set function. Signed-off-by: Zhang Shengju <zhangshengju@cmss.chinamobile.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-04vxlan: use reset to set header pointersZhang Shengju
Since offset is zero, it's not necessary to use set function. Reset function is straightforward, and will remove the unnecessary add operation in set function. Signed-off-by: Zhang Shengju <zhangshengju@cmss.chinamobile.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-04Merge tag 'rxrpc-rewrite-20160304' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs David Howells says: ==================== RxRPC: Rewrite part 1 Here's the first set of patches from my RxRPC rewrite, aimed at net-next. These do some clean ups and bug fixes. Most of the changes are small, but there are a couple of bigger changes: (*) Convert call flag numbers and event numbers into enums. Then rename the event numbers to all have _EV_ in their name to stop confusion. Fix one instance of an event bit being used instead of a flag bit. (*) A copy of the Rx protocol header is kept in the sk_buff private data. Keep this in host byte order rather than network byte order as it makes more sense. A number of other fields then get converted into host byte order too. Conversion between host and network byte order is then done at the packet reception/generation stage. This is based on net-next/master ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-04Merge branch 'DIV_ROUND_UP-uapi'David S. Miller
Nicolas Dichtel says: ==================== uapi: consolidate DIV_ROUND_UP definition The inital goal was to consolidate ethtool.h uapi header. But I took the opportunity to remove all duplicate definitions of DIV_ROUND_UP. v3: add patch #2 and #3 v2: split the patch define DIV_ROUND_UP in uapi ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-04ethtool.h: define INT_MAX for userlandNicolas Dichtel
INT_MAX needs limits.h in userland. When ethtool.h is included by a userland app, we got the following error: .../usr/include/linux/ethtool.h: In function 'ethtool_validate_speed': .../usr/include/linux/ethtool.h:1471:18: error: 'INT_MAX' undeclared (first use in this function) return speed <= INT_MAX || speed == SPEED_UNKNOWN ^ Fixes: e02564ee334a ("ethtool: make validate_speed accept all speeds between 0 and INT_MAX") CC: Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Acked-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-04drm/vmwgfx: remove userland definition of DIV_ROUND_UPNicolas Dichtel
Let's use __KERNEL_DIV_ROUND_UP, which is defined in uapi/linux/kernel.h. Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-04cxgb4i: don't redefine DIV_ROUND_UPNicolas Dichtel
let's use the common definition to avoid the following warning during the compilation: drivers/scsi/cxgbi/cxgb4i/cxgb4i.c:161:0: warning: "DIV_ROUND_UP" redefined #define DIV_ROUND_UP(n, d) (((n) + (d) - 1) / (d)) ^ In file included from include/linux/list.h:8:0, from include/linux/module.h:9, from drivers/scsi/cxgbi/cxgb4i/cxgb4i.c:16: include/linux/kernel.h:67:0: note: this is the location of the previous definition #define DIV_ROUND_UP __KERNEL_DIV_ROUND_UP ^ Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-04uapi: define DIV_ROUND_UP for userlandNicolas Dichtel
DIV_ROUND_UP is defined in linux/kernel.h only for the kernel. When ethtool.h is included by a userland app, we got the following error: include/linux/ethtool.h:1218:8: error: variably modified 'queue_mask' at file scope __u32 queue_mask[DIV_ROUND_UP(MAX_NUM_QUEUE, 32)]; ^ Let's add a common definition in uapi and use it everywhere. Fixes: ac2c7ad0e5d6 ("net/ethtool: introduce a new ioctl for per queue setting") CC: Kan Liang <kan.liang@intel.com> Suggested-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-04nfp: remove Rolf Neugebauer as co-maintainerSimon Horman
Rolf is no longer in his previous role at Netronome and as far as I know no longer working on the NFP driver. Thus it does not seem appropriate for him to be a co-maintainer anymore. Reviewed-by: Dinan Gunawardena <dinan.gunawardena@netronome.com> Signed-off-by: Simon Horman <simon.horman@netronome.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-04rxrpc: Don't try to map ICMP to error as the lower layer already did thatDavid Howells
In the ICMP message processing code, don't try to map ICMP codes to UNIX error codes as the caller (IPv4/IPv6) already did that for us (ee_errno). Signed-off-by: David Howells <dhowells@redhat.com>
2016-03-04rxrpc: Clear the unused part of a sockaddr_rxrpc for memcmp() useDavid Howells
Clear the unused part of a sockaddr_rxrpc structs so that memcmp() can be used to compare them. Signed-off-by: David Howells <dhowells@redhat.com>
2016-03-04rxrpc: rxkad: Casts are needed when comparing be32 valuesDavid Howells
Forced casts are needed to avoid sparse warning when directly comparing be32 values. Signed-off-by: David Howells <dhowells@redhat.com>
2016-03-04rxrpc: rxkad: The version number in the response should be net byte orderDavid Howells
The version number rxkad places in the response should be network byte order. Whilst we're at it, rearrange the code to be more readable. Signed-off-by: David Howells <dhowells@redhat.com>
2016-03-04rxrpc: Use ACCESS_ONCE() when accessing circular buffer pointersDavid Howells
Use ACCESS_ONCE() when accessing the other-end pointer into a circular buffer as it's possible the other-end pointer might change whilst we're doing this, and if we access it twice, we might get some weird things happening. Signed-off-by: David Howells <dhowells@redhat.com>
2016-03-04rxrpc: Adjust some whitespace and commentsDavid Howells
Remove some excess whitespace, insert some missing spaces and adjust a couple of comments. Signed-off-by: David Howells <dhowells@redhat.com>
2016-03-04rxrpc: Be more selective about the types of received packets we acceptDavid Howells
Currently, received RxRPC packets outside the range 1-13 are rejected. There are, however, holes in the range that should also be rejected - plus at least one type we don't yet support - so reject these also. Signed-off-by: David Howells <dhowells@redhat.com>
2016-03-04rxrpc: Fix defined range for /proc/sys/net/rxrpc/rx_mtuDavid Howells
The upper bound of the defined range for rx_mtu is being set in the same member as the lower bound (extra1) rather than the correct place (extra2). I'm not entirely sure why this compiles. Signed-off-by: David Howells <dhowells@redhat.com>
2016-03-04rxrpc: The protocol family should be set to PF_RXRPC not PF_UNIXDavid Howells
Fix the protocol family set in the proto_ops for rxrpc to be PF_RXRPC not PF_UNIX. Signed-off-by: David Howells <dhowells@redhat.com>
2016-03-04rxrpc: Keep the skb private record of the Rx header in host byte orderDavid Howells
Currently, a copy of the Rx packet header is copied into the the sk_buff private data so that we can advance the pointer into the buffer, potentially discarding the original. At the moment, this copy is held in network byte order, but this means we're doing a lot of unnecessary translations. The reasons it was done this way are that we need the values in network byte order occasionally and we can use the copy, slightly modified, as part of an iov array when sending an ack or an abort packet. However, it seems more reasonable on review that it would be better kept in host byte order and that we make up a new header when we want to send another packet. To this end, rename the original header struct to rxrpc_wire_header (with BE fields) and institute a variant called rxrpc_host_header that has host order fields. Change the struct in the sk_buff private data into an rxrpc_host_header and translate the values when filling it in. This further allows us to keep values kept in various structures in host byte order rather than network byte order and allows removal of some fields that are byteswapped duplicates. Signed-off-by: David Howells <dhowells@redhat.com>
2016-03-04rxrpc: Rename call events to begin RXRPC_CALL_EV_David Howells
Rename call event names to begin RXRPC_CALL_EV_ to distinguish them from the flags. Signed-off-by: David Howells <dhowells@redhat.com>
2016-03-04rxrpc: Convert call flag and event numbers into enumsDavid Howells
Convert call flag and event numbers into enums and move their definitions outside of the struct. Also move the call state enum outside of the struct and add an extra element to count the number of states. Signed-off-by: David Howells <dhowells@redhat.com>
2016-03-04rxrpc: Fix a case where a call event bit is being used as a flag bitDavid Howells
Fix a case where RXRPC_CALL_RELEASE (an event) is being used to specify a flag bit. RXRPC_CALL_RELEASED should be used instead. Signed-off-by: David Howells <dhowells@redhat.com>
2016-03-03net: sched: use pfifo_fast for non real queuesEric Dumazet
Some devices declare a high number of TX queues, then set a much lower real_num_tx_queues This cause setups using fq_codel, sfq or fq as the default qdisc to consume more memory than really needed. Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-03net: ipv6: Fix refcnt on host routesDavid Ahern
Andrew and Ying Huang's test robot both reported usage count problems that trace back to the 'keep address on ifdown' patch. >From Andrew: We execute CRIU test on linux-next. On the current linux-next kernel they hangs on creating a network namespace. The kernel log contains many massages like this: [ 1036.122108] unregister_netdevice: waiting for lo to become free. Usage count = 2 [ 1046.165156] unregister_netdevice: waiting for lo to become free. Usage count = 2 [ 1056.210287] unregister_netdevice: waiting for lo to become free. Usage count = 2 I tried to revert this patch and the bug disappeared. Here is a set of commands to reproduce this bug: [root@linux-next-test linux-next]# uname -a Linux linux-next-test 4.5.0-rc6-next-20160301+ #3 SMP Wed Mar 2 17:32:18 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux [root@linux-next-test ~]# unshare -n [root@linux-next-test ~]# ip link set up dev lo [root@linux-next-test ~]# ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever [root@linux-next-test ~]# logout [root@linux-next-test ~]# unshare -n ----- The problem is a change made to RTM_DELADDR case in __ipv6_ifa_notify that was added in an early version of the offending patch and is no longer needed. Fixes: f1705ec197e7 ("net: ipv6: Make address flushing on ifdown optional") Cc: Andrey Wagin <avagin@gmail.com> Cc: Ying Huang <ying.huang@linux.intel.com> Signed-off-by: David Ahern <dsa@cumulusnetworks.com> Tested-by: Jeremiah Mahler <jmmahler@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-03net: ezchip: adapt driver to little endian architectureLada Trimasova
Since ezchip network driver is written with big endian EZChip platform it is necessary to add support for little endian architecture. The first issue is that the order of the bits in a bit field is implementation specific. So all the bit fields are removed. Named constants are used to access necessary fields. And the second one is that network byte order is big endian. For example, data on ethernet is transmitted with most-significant octet (byte) first. So in case of little endian architecture it is important to swap data byte order when we read it from register. In case of unaligned access we can use "get_unaligned_be32" and in other case we can use function "ioread32_rep" which reads all data from register and works either with little endian or big endian architecture. And then when we are going to write data to register we need to restore byte order using the function "put_unaligned_be32" in case of unaligned access and in other case "iowrite32_rep". The last little fix is a space between type and pointer to observe coding style. Signed-off-by: Lada Trimasova <ltrimas@synopsys.com> Cc: Alexey Brodkin <abrodkin@synopsys.com> Cc: Noam Camus <noamc@ezchip.com> Cc: Tal Zilcer <talz@ezchip.com> Cc: Arnd Bergmann <arnd@arndb.de> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-03sh_eth, ravb: Use ARCH_RENESASSimon Horman
Make use of ARCH_RENESAS in place of ARCH_SHMOBILE. This is part of an ongoing process to migrate from ARCH_SHMOBILE to ARCH_RENESAS the motivation for which being that RENESAS seems to be a more appropriate name than SHMOBILE for the majority of Renesas ARM based SoCs. Signed-off-by: Simon Horman <horms+renesas@verge.net.au> Acked-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-03net: mellanox: add DEVLINK dependenciesArnd Bergmann
The new NET_DEVLINK infrastructure can be a loadable module, but the drivers using it might be built-in, which causes link errors like: drivers/net/built-in.o: In function `mlx4_load_one': :(.text+0x2fbfda): undefined reference to `devlink_port_register' :(.text+0x2fc084): undefined reference to `devlink_port_unregister' drivers/net/built-in.o: In function `mlxsw_sx_port_remove': :(.text+0x33a03a): undefined reference to `devlink_port_type_clear' :(.text+0x33a04e): undefined reference to `devlink_port_unregister' There are multiple ways to avoid this: a) add 'depends on NET_DEVLINK || !NET_DEVLINK' dependencies for each user b) use 'select NET_DEVLINK' from each driver that uses it and hide the symbol in Kconfig. c) make NET_DEVLINK a 'bool' option so we don't have to list it as a dependency, and rely on the APIs to be stubbed out when it is disabled d) use IS_REACHABLE() rather than IS_ENABLED() to check for NET_DEVLINK in include/net/devlink.h This implements a variation of approach a) by adding an intermediate symbol that drivers can depend on, and changes the three drivers using it. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: 09d4d087cd48 ("mlx4: Implement devlink interface") Fixes: c4745500e988 ("mlxsw: Implement devlink interface") Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-03Merge branch 'for-upstream' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next Johan Hedberg says: ==================== pull request: bluetooth-next 2016-03-01 Here's our main set of Bluetooth & 802.15.4 patches for the 4.6 kernel. - New Bluetooth HCI driver for Intel/AG6xx controllers - New Broadcom ACPI IDs - LED trigger support for indicating Bluetooth powered state - Various fixes in mac802154, 6lowpan and related drivers - New USB IDs for AR3012 Bluetooth controllers Please let me know if there are any issues pulling. Thanks. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-03net: relax setup_tc ndo op handle restrictionJohn Fastabend
I added this check in setup_tc to multiple drivers, if (handle != TC_H_ROOT || tc->type != TC_SETUP_MQPRIO) Unfortunately restricting to TC_H_ROOT like this breaks the old instantiation of mqprio to setup a hardware qdisc. This patch relaxes the test to only check the type to make it equivalent to the check before I broke it. With this the old instantiation continues to work. A good smoke test is to setup mqprio with, # tc qdisc add dev eth4 root mqprio num_tc 8 \ map 0 1 2 3 4 5 6 7 \ queues 0@0 1@1 2@2 3@3 4@4 5@5 6@6 7@7 Fixes: e4c6734eaab9 ("net: rework ndo tc op to consume additional qdisc handle paramete") Reported-by: Singh Krishneil <krishneil.k.singh@intel.com> Reported-by: Jake Keller <jacob.e.keller@intel.com> CC: Murali Karicheri <m-karicheri2@ti.com> CC: Shradha Shah <sshah@solarflare.com> CC: Or Gerlitz <ogerlitz@mellanox.com> CC: Ariel Elior <ariel.elior@qlogic.com> CC: Jeff Kirsher <jeffrey.t.kirsher@intel.com> CC: Bruce Allan <bruce.w.allan@intel.com> CC: Jesse Brandeburg <jesse.brandeburg@intel.com> CC: Don Skidmore <donald.c.skidmore@intel.com> Signed-off-by: John Fastabend <john.r.fastabend@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-03ath9k: clear bb filter calibration power thresholdMiaoqing Pan
JP WiFi certification for bandwidth of channel 14 failed, the OBW is lower than the requirement. Clear the bb filter calibration power threshold to increase OBW(+2). The fix only for qca9531 chip now. Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-03-03ath9k: reduce stack usage in ar9003_aic_cal_post_processArnd Bergmann
In some configurations, this function uses more than the warning limit of 1024 bytes: drivers/net/wireless/ath/ath9k/ar9003_aic.c: In function 'ar9003_aic_cal_post_process': drivers/net/wireless/ath/ath9k/ar9003_aic.c:434:1: error: the frame size of 1040 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] It turns out that there are two large arrays on the stack here, but almost all the data in them is never used outside of the loop in which it gets written, so we can replace the array with a single instance. The .valid flag is used later, so I'm replacing the array of structures with an array of bools. An obvious follow-up optimization would be to replace it with a bitmask and set_bit()/find_first_bit()/ find_last_bit()/... operations. However, I have not tested this patch, so I sticked to the simpler transformation that does the job of reducing the stack usage to a harmless level. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>