- 26 Aug, 2015 6 commits
-
-
Kalle Valo authored
Major changes in ath10k: * add spectral scan support for qca99x0 * add qca6164 support
-
Raja Mani authored
Below compilation warnings are observed in gcc version 4.8.2. Even though it's not seen in bit older gcc versions (for ex, 4.7.3), It's good to fix it by changing format specifier from %d to %zd in wmi pull phyerr functions. wmi.c: In function 'ath10k_wmi_op_pull_phyerr_ev': wmi.c:3567:8: warning: format '%d' expects argument of type 'int', but argument 4 has type 'long unsigned int' [-Wformat=] left_len, sizeof(*phyerr)); ^ wmi.c: In function 'ath10k_wmi_10_4_op_pull_phyerr_ev': wmi.c:3612:8: warning: format '%d' expects argument of type 'int', but argument 4 has type 'long unsigned int' [-Wformat=] left_len, sizeof(*phyerr)); ^ Fixes: 991adf71 ("ath10k: refactor phyerr event handlers") Fixes: 2b0a2e0d ("ath10k: handle 10.4 firmware phyerr event") Signed-off-by:Raja Mani <rmani@qti.qualcomm.com> Signed-off-by:
Kalle Valo <kvalo@qca.qualcomm.com>
-
Michal Kazior authored
This adds additional 0x0041 PCI Device ID definition to ath10k for QCA6164 which is a 1 spatial stream sibling of the QCA6174 (which is 2 spatial stream chip). The QCA6164 needs a dedicated board.bin file which is different than the one used for QCA6174. If the board.bin is wrong the device will crash early while trying to boot firmware. The register dump will look like this: ath10k_pci 0000:02:00.0: firmware register dump: ath10k_pci 0000:02:00.0: [00]: 0x05010000 0x000015B3 0x000A012D 0x00955B31 ... Note the value 0x000A012D. Special credit goes to Alan Liu <alanliu@qca.qualcomm.com> for providing support help which enabled me to come up with this patch. Signed-off-by:
Michal Kazior <michal.kazior@tieto.com> Signed-off-by:
-
Raja Mani authored
To enable/configure spectral scan parameters in 10.4 firmware, existing wmi spectral related functions can be reused. Link those functions in 10.4 wmi ops table. In addition, adjust bin size (only when size is 68 bytes) before reporting bin samples to user space. The background for this adjustment is that qca99x0 reports bin size as 68 bytes (64 bytes + 4 bytes) in report mode 2. First 64 bytes carries in-band tones (-32 to +31) and last 4 byte carries band edge detection data (+32) mainly used in radar detection purpose. Additional last 4 bytes are stripped to make bin size valid one. This bin size adjustment will happen only for qca99x0, all other chipsets will report proper bin sizes (64/128) without extra 4 bytes being added at the end. The changes are validated in qca99x0 using 10.4 firmware. Signed-off-by:
-
Michal Kazior authored
The function returns 1 when DMA mapping fails. The driver would return bogus values and could possibly confuse itself if DMA failed. Fixes: 767d34fc ("ath10k: remove DMA mapping wrappers") Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Michal Kazior authored
Kernel would complain about leaving a held lock after going back to userspace and would subsequently deadlock. Fixes: e04cafbc ("ath10k: fix peer limit enforcement") Reported-by:
-
- 25 Aug, 2015 12 commits
-
-
Christian Engelmayer authored
Commit 5d5cd85f ("rsi: Fix failure to load firmware after memory leak fix and fix the leak") also added a check on the allocation of DMA-accessible memory that may directly return. In that case the already allocated firmware data is leaked. Make sure the data is always freed correctly. Detected by Coverity CID 1316519. Fixes: 5d5cd85f ("rsi: Fix failure to load firmware after memory leak fix and fix the leak") Signed-off-by:
Christian Engelmayer <cengelma@gmx.at> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org>
-
Hante Meuleman authored
Host platforms such as routers supported by OpenWRT can support NVRAM reading directly from internal NVRAM store. With this patch the nvram load routines will fall back to this method when there is no nvram file and support is available in the kernel. Reviewed-by:
Arend Van Spriel <arend@broadcom.com> Reviewed-by:
Franky (Zhenhui) Lin <frankyl@broadcom.com> Reviewed-by:
Pieter-Paul Giesberts <pieterpg@broadcom.com> Reviewed-by:
Daniel (Deognyoun) Kim <dekim@broadcom.com> Signed-off-by:
Hante Meuleman <meuleman@broadcom.com> Signed-off-by:
-
Arend van Spriel authored
The event mask length is determined by the highest event number that is specified in the driver. When this length is shorter than firmware expects setting event mask will fail and device becomes pretty useless. This issue was reported with bcm4339 firmware that was recently released. Reported-by:
Pontus Fuchs <pontusf@broadcom.com> Reviewed-by:
-
Franky Lin authored
brcmf_flowring_block blocks the last active flowring under the same interface instead of the one provided by caller. This could lead to a dead lock of netif stop if there are more than one flowring under the interface and the traffic is high enough so brcmf_flowring_enqueue can not unblock the ring right away. Reviewed-by:
-
Arend van Spriel authored
Use cfg80211_check_combinations() so we can bail out early when an interface add or change results in an invalid combination. Reviewed-by:
-
Franky Lin authored
Expose ring buffer read/write pointers and other useful statistics through debugfs. Reviewed-by:
-
Arend van Spriel authored
The interface combination provided by brcmfmac did not truly reflect the combinations supported by driver and/or firmware. Reviewed-by:
-
Rafał Miłecki authored
Broadcom is working on better reflection of interface combinations. With upcoming patches we may have 1st combination supporting less interfaces than others. To don't run out of addresses check all combinations to find the one with the greatest max_interfaces value. Signed-off-by:
Rafał Miłecki <zajec5@gmail.com> Signed-off-by:
-
Adrien Schildknecht authored
The v2 of NetGear WNA1000M uses a different idProduct: USB ID 0846:9043 Signed-off-by:
Adrien Schildknecht <adrien+dev@schischi.me> Cc: Stable <stable@vger.kernel.org> Acked-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
-
Wu Fengguang authored
drivers/net/wireless/rtlwifi/rtl8192ee/phy.c:856:2-3: Unneeded semicolon drivers/net/wireless/rtlwifi/rtl8192ee/phy.c:492:3-4: Unneeded semicolon drivers/net/wireless/rtlwifi/rtl8192ee/phy.c:452:3-4: Unneeded semicolon Remove unneeded semicolon. Generated by: scripts/coccinelle/misc/semicolon.cocci CC: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
Fengguang Wu <fengguang.wu@intel.com> Signed-off-by:
-
Oleksij Rempel authored
current code will handle -ETIMEDOUT as success which is probalbly wrong. According to this comment I assume it is safe to handle -ETIMEDOUT as false: drivers/net/wireless/ath/ath9k/calib.c 290 /* 291 * We timed out waiting for the noisefloor to load, probably due to an 292 * in-progress rx. Simply return here and allow the load plenty of time 293 * to complete before the next calibration interval. We need to avoid 294 * trying to load -50 (which happens below) while the previous load is 295 * still in progress as this can cause rx deafness. Instead by returning 296 * here, the baseband nf cal will just be capped by our present 297 * noisefloor until the next calibration timer. 298 */ Since no other error wariants are present, this patch is checking only for (ret <= 0). Reported-by:
Oleksij Rempel <linux@rempel-privat.de> Signed-off-by:
-
Kalle Valo authored
Merge tag 'iwlwifi-next-for-kalle-2015-08-23' of https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next * new Tx power firmware API * bump max firmware API to 17 * fix bug in debug prints * static checker fix * fix unused defines * fix command list on newest firmware
-
- 24 Aug, 2015 6 commits
-
-
Loganaden Velvindron authored
This BQL patch is based on work done by Tino Reichardt. Tested on 0000:05:00.0: 3Com PCI 3c905C Tornado at ffffc90000e6e000 by running Flent several times. Signed-off-by:
Loganaden Velvindron <logan@elandsys.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Tom Herbert says: ==================== ila: Precompute checksums This patch set: - Adds argument ot LWT build_state that holds a pointer to the fib configuration being applied to the new route - Adds support in ILA to precompute checksum difference for performance optimization v2: - Move return argument in build_state to end of arguments v3: - Update the signature for ip6_tun_build_state() ==================== Signed-off-by: -
Tom Herbert authored
In the ILA build state for LWT compute the checksum difference to apply to transport checksums that include the IPv6 pseudo header. The difference is between the route destination (from fib6_config) and the locator to write. Signed-off-by:
Tom Herbert <tom@herbertland.com> Signed-off-by:
-
Tom Herbert authored
Add cfg and family arguments to lwt build state functions. cfg is a void pointer and will either be a pointer to a fib_config or fib6_config structure. The family parameter indicates which one (either AF_INET or AF_INET6). LWT encpasulation implementation may use the fib configuration to build the LWT state. Signed-off-by:
-
Shaohui Xie authored
By implementing config_intr & ack_interrupt, now the phy can support link connect/disconnect interrupt. Signed-off-by:
Shaohui Xie <Shaohui.Xie@freescale.com> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/sameo/nfc-nextDavid S. Miller authored
Samuel Ortiz says: ==================== NFC 4.3 pull request This is the NFC pull request for 4.3. With this one we have: - A new driver for Samsung's S3FWRN5 NFC chipset. In order to properly support this driver, a few NCI core routines needed to be exported. Future drivers like Intel's Fields Peak will benefit from this. - SPI support as a physical transport for STM st21nfcb. - An additional netlink API for sending replies back to userspace from vendor commands. - 2 small fixes for TI's trf7970a - A few st-nci fixes. ==================== Signed-off-by:
-
- 23 Aug, 2015 16 commits
-
-
Jiri Benc authored
__recnt and related fields need to be in its own cacheline for performance reasons. Commit 61adedf3 ("route: move lwtunnel state to dst_entry") broke that on 32bit archs, causing BUILD_BUG_ON in dst_hold to be triggered. This patch fixes the breakage by moving the lwtunnel state to the end of dst_entry on 32bit archs. Unfortunately, this makes it share the cacheline with __refcnt and may affect performance, thus further patches may be needed. Reported-by:
Jiri Benc <jbenc@redhat.com> Signed-off-by:
-
David S. Miller authored
Merge tag 'linux-can-next-for-4.3-20150820' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next Marc Kleine-Budde says: ==================== this is a pull request of a two patches for net-next. The first patch is by Nik Nyby and fixes a typo in a function name. The second patch by Lucas Stach demotes register output to debug level. ==================== Signed-off-by:
-
David S. Miller authored
Jon Maloy says: ==================== tipc: fix link failover/synch problems We fix three problems with the new link failover/synch implementation, which was introduced earlier in this release cycle. They are all related to situations where there is a very short interval between the disabling and enabling of interfaces. ==================== Signed-off-by: -
Jon Paul Maloy authored
Recent changes to the link synchronization means that we can now just drop packets arriving on the synchronizing link before the synch point is reached. This has lead to significant simplifications to the implementation, but also turns out to have a flip side that we need to consider. Under unlucky circumstances, the two endpoints may end up repeatedly dropping each other's packets, while immediately asking for retransmission of the same packets, just to drop them once more. This pattern will eventually be broken when the synch point is reached on the other link, but before that, the endpoints may have arrived at the retransmission limit (stale counter) that indicates that the link should be broken. We see this happen at rare occasions. The fix for this is to not ask for retransmissions when a link is in state LINK_SYNCHING. The fact that the link has reached this state means that it has already received the first SYNCH packet, and that it knows the synch point. Hence, it doesn't need any more packets until the other link has reached the synch point, whereafter it can go ahead and ask for the missing packets. However, because of the reduced traffic on the synching link that follows this change, it may now take longer to discover that the synch point has been reached. We compensate for this by letting all packets, on any of the links, trig a check for synchronization termination. This is possible because the packets themselves don't contain any information that is needed for discovering this condition. Reviewed-by:
Ying Xue <ying.xue@windriver.com> Signed-off-by:
Jon Maloy <jon.maloy@ericsson.com> Signed-off-by:
-
Jon Paul Maloy authored
When we introduced the new link failover/synch mechanism in commit 6e498158 ("tipc: move link synch and failover to link aggregation level"), we missed the case when the non-tunnel link goes down during the link synchronization period. In this case the tunnel link will remain in state LINK_SYNCHING, something leading to unpredictable behavior when the failover procedure is initiated. In this commit, we ensure that the node and remaining link goes back to regular communication state (SELF_UP_PEER_UP/LINK_ESTABLISHED) when one of the parallel links goes down. We also ensure that we don't re-enter synch mode if subsequent SYNCH packets arrive on the remaining link. Reviewed-by:
-
Jon Paul Maloy authored
When a link goes down, and there is still a working link towards its destination node, a failover is initiated, and the failed link is not allowed to re-establish until that procedure is finished. To ensure this, the concerned link endpoints are set to state LINK_FAILINGOVER, and the node endpoints to NODE_FAILINGOVER during the failover period. However, if the link reset is due to a disabled bearer, the corres- ponding link endpoint is deleted, and only the node endpoint knows about the ongoing failover. Now, if the disabled bearer is re-enabled during the failover period, the discovery mechanism may create a new link endpoint that is ready to be established, despite that this is not permitted. This situation may cause both the ongoing failover and any subsequent link synchronization to fail. In this commit, we ensure that a newly created link goes directly to state LINK_FAILINGOVER if the corresponding node state is NODE_FAILINGOVER. This eliminates the problem described above. Furthermore, we tighten the criteria for which packets are allowed to end a failover state in the function tipc_node_check_state(). By checking that the receiving link is up and running, instead of just checking that it is not in failover mode, we eliminate the risk that protocol packets from the re-created link may cause the failover to be prematurely terminated. Reviewed-by:
-
David S. Miller authored
Noam Camus says: ==================== *** nps_enet fixups *** Change v2 TX done is handled back with NAPI poll. Change v1 This patch set is a bunch of fixes to make nps_enet work correctly with all platforms, i.e. real device, emulation system, and simulation system. The main trigger for this patch set was that in our emulation system the TX end interrupt is "edge-sensitive" and therefore we cannot use the cause register since it is not sticky. Also: TX is handled during HW interrupt context and not NAPI job. race with TX done was fixed. added acknowledge for TX when device is "level sensitive". enable drop of control frames which is not needed for regular usage. So most of this patch set is about TX handling, which is now more complete. ==================== Signed-off-by: -
Noam Camus authored
We define buf_int_enable in the minimal namespace it is used. Signed-off-by:
Noam Camus <noamc@ezchip.com> Signed-off-by:
-
Noam Camus authored
This is needed for when TX done interrupt is in "level mode". For example it is true for some simulators of this device. Signed-off-by:
-
Noam Camus authored
We set controller to drop control frames and not trying to pass them on. This is only needed for debug reasons. Signed-off-by:
-
Noam Camus authored
We need to set tx_skb pointer before send frame. If we receive interrupt before we set pointer we will try to free SKB with wrong pointer. Now we are sure that SKB pointer will never be NULL during handling TX done and check is removed. Signed-off-by:
-
Noam Camus authored
When interrupt is received we read directly from control register for RX/TX instead of reading cause register since this register fails to indicate TX done when TX interrupt is "edge mode". Signed-off-by:
-
David S. Miller authored
Tom Herbert says: ==================== gro: Fixes for tunnels and GRO This patch set addresses some issue related to tunneling and GRO: - Fix remote checksum offload to properly deal with frag0 in GRO. - Add support for GRO at VXLAN tunnel (call gro_cells) Testing: Ran one netperf TCP_STREAM to highlight impact of different configurations: GUE Zero UDP checksum 4628.42 MBps UDP checksums enabled 6800.51 MBps UDP checksums and remote checksum offload 7663.82 MBps UDP checksums and remote checksum offload using no-partial 7287.25 MBps VXLAN Zero UDP checksum 4112.02 UDP checksums enabled 6785.80 MBps UDP checksums and remote checksum offload 7075.56 MBps v2: - Drop "gro: Pull headers into skb head for 1st skb in gro list" from patch set - In vxlan_remcsum and gue_remcsum return immediately if remcsum processing was already done - Add gro callbacks for sit offload - Use WARN_ON_ONCE if we get a GUE protocol that does not have GRO offload support v3: - Don't restore gro callbacks for sit offload ==================== Signed-off-by: -
Tom Herbert authored
Do WARN_ON_ONCE instead of WARN_ON in gue_gro_receive when the offload callcaks are bad (either don't exist or gro_receive is not specified). Signed-off-by:
-
Tom Herbert authored
Add calls to gro_cells infrastructure to do GRO when receiving on a tunnel. Testing: Ran 200 netperf TCP_STREAM instance - With fix (GRO enabled on VXLAN interface) Verify GRO is happening. 9084 MBps tput 3.44% CPU utilization - Without fix (GRO disabled on VXLAN interface) Verified no GRO is happening. 9084 MBps tput 5.54% CPU utilization Signed-off-by: -
Tom Herbert authored
The remote checksum offload GRO did not consider the case that frag0 might be in use. This patch fixes that by accessing headers using the skb_gro functions and not saving offsets relative to skb->head. Signed-off-by:
-
