summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2014-10-08net: rfkill: kernel-doc warning fixesFabian Frederick
s/state/blocked Signed-off-by: Fabian Frederick <fabf@skynet.be> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-10-07ath9k_htc: avoid kernel panic in ath9k_hw_resetMarek Puzyniak
hw pointer of ath_hw is not assigned to proper value in function ath9k_hw_reset what finally causes kernel panic. This can be solved by proper initialization of ath_hw in ath9k_init_priv. Signed-off-by: Marek Puzyniak <marek.puzyniak@tieto.com> Acked-by: Oleksij Rempel <linux@rempel-privat.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-10-07ath9k: Fix crash in MCC modeSujith Manoharan
When a channel context is removed, the hw_queue_base is set to -1, this will result in a panic because ath9k_chanctx_stop_queues() can be called on an interface that is not assigned to any context yet - for example, when trying to scan. Fix this issue by setting the hw_queue_base to zero when a channel context is removed. Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-10-07ath: Fix smatch warningSujith Manoharan
drivers/net/wireless/ath/main.c:88 ath_printk() error: we previously assumed 'common->hw' could be null (see line 82) Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-10-07rtl818x_pci: fix response rate may be incorrect.Andrea Merello
Currently the allowed "respose rate" set (rates for HW generated frames like ACKs) is the same as the basic rate set. The HW will use the higher allowed response rate that is lower than the rate of the received frame. This is more or less what IEEE80211 mandates, but I missed the fact that IEEE80211 also says that whenever it happens that for a modulation class there is no any rate in the basic rates set, then the response rate set shall include also all the mandatory rates for that modulation class. This patch adds mandatory OFDM rates to the allowed response rate set if no OFDM rate is included in the basic rate set. Depending by the AP, I faced cases in which this patch seems to cause a noticeable perfomance improvement. - With my usual test AP there is no particular perfomance difference. - With a prism54/hostapd AP this patch causes RX thoughput increase from about 5Mbps to about 20Mbps. Hopefully this patch may help people that faced performance regression wrt the old staging driver. Signed-off-by: Andrea Merello <andrea.merello@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-10-07Merge branch 'master' of ↵John W. Linville
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless
2014-10-02rtlwifi: Fix static checker warnings for various driversLarry Finger
Indenting errors yielded the following static checker warnings: drivers/net/wireless/rtlwifi/rtl8192ee/hw.c:533 rtl92ee_set_hw_reg() warn: add curly braces? (if) drivers/net/wireless/rtlwifi/rtl8192ee/hw.c:539 rtl92ee_set_hw_reg() warn: add curly braces? (if) An unreleased version of the static checker also reported: drivers/net/wireless/rtlwifi/rtl8723be/trx.c:550 rtl8723be_rx_query_desc() warn: 'hdr' can't be NULL. drivers/net/wireless/rtlwifi/rtl8188ee/trx.c:621 rtl88ee_rx_query_desc() warn: 'hdr' can't be NULL. drivers/net/wireless/rtlwifi/rtl8192ee/trx.c:567 rtl92ee_rx_query_desc() warn: 'hdr' can't be NULL. drivers/net/wireless/rtlwifi/rtl8821ae/trx.c:758 rtl8821ae_rx_query_desc() warn: 'hdr' can't be NULL. drivers/net/wireless/rtlwifi/rtl8723ae/trx.c:494 rtl8723e_rx_query_desc() warn: 'hdr' can't be NULL. drivers/net/wireless/rtlwifi/rtl8192se/trx.c:315 rtl92se_rx_query_desc() warn: 'hdr' can't be NULL. drivers/net/wireless/rtlwifi/rtl8192ce/trx.c:392 rtl92ce_rx_query_desc() warn: 'hdr' can't be NULL. All of these are fixed. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Cc: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-10-02rtlwifi: Fix Kconfig for RTL8192EELarry Finger
The driver needs btcoexist, but Kconfig fails to select it. This omission could cause build errors for some configurations. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-10-02ath9k: Fix flushing in MCC modeSujith Manoharan
When we are attempting to switch to a new channel context, the TX queues are flushed, but the mac80211 queues are not stopped and traffic can still come down to the driver. This patch fixes it by stopping the queues assigned to the current context/vif before trying to flush. Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-10-02ath9k: Fix queue handling for channel contextsSujith Manoharan
When a full chip reset is done, all the queues across all VIFs are stopped, but if MCC is enabled, only the queues of the current context is awakened, when we complete the reset. This results in unfairness for the inactive context. Since frames are queued internally in the driver if there is a context mismatch, we can awaken all the queues when coming out of a reset. The VIF-specific queues are still used in flow control, to ensure fairness when traffic is high. Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-10-02ath9k: Add ath9k_chanctx_stop_queues()Sujith Manoharan
This can be used when the queues of a context needs to be stopped. Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-10-02ath9k: Pass context to ath9k_chanctx_wake_queues()Sujith Manoharan
Change the ath9k_chanctx_wake_queues() API so that we can pass the channel context that needs its queues to be stopped. Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-10-02ath9k: Fix queue handling in flush()Sujith Manoharan
When draining of the TX queues fails, a full HW reset is done. ath_reset() makes sure that the queues in mac80211 are restarted, so there is no need to wake them up again. Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-10-02ath9k: Remove duplicate codeSujith Manoharan
ath9k_has_tx_pending() can be used to check if there are pending frames instead of having duplicate code. Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-10-02ath9k: Fix pending frame checkSujith Manoharan
Checking for the queue depth outside of the TX queue lock is incorrect and in this case, is not required since it is done inside ath9k_has_pending_frames(). Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-10-02ath9k: Check pending frames properlySujith Manoharan
There is no need to check if the current channel context has active ACs queued up if the TX queue is not empty. Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-10-02ath9k: Print RoC expirationSujith Manoharan
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-10-02mwifiex: add support for SD8887 chipsetAvinash Patil
This patch adds SD8887 support to mwifiex. SD8887 is Marvell's 1x1 11ac solution. The corresponding firmware image file is located at: "mrvl/sd8887_uapsta.bin" Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: Cathy Luo <cluo@marvell.com> Signed-off-by: Frank Huang <frankh@marvell.com> Signed-off-by: Nishant Sarmukadam <nishants@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-10-02mwifiex: few more register offset entries for sdio card structureAvinash Patil
This patch adds some more defitions to card specific register structure and removes static defines for these registers. Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: Cathy Luo <cluo@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-10-02wil6210: atomic I/O for the card memoryVladimir Kondratiev
Introduce netdev IOCTLs, to be used by the debug tools. Allows to read/write single dword value or memory block, aligned to dword Different address modes supported: - BAR offset - Firmware "linker" address - target's AHB bus Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-10-02wil6210: manual FW error recovery modeVladimir Kondratiev
Introduce manual FW recovery mode. It is activated if module parameter @no_fw_recovery set to true. May be changed at runtime. Recovery information provided by new "recovery" debugfs file. It prints: mode = [auto|manual] state = [idle|pending|running] In manual mode, after FW error, recovery won't start automatically. Instead, after notification to user space, recovery waits in "pending" state, as indicated by the "recovery" debugfs file. User space tools may perform data collection and allow to continue recovery by writing "run" to the "recovery" debugfs file. Alternatively, recovery pending may be canceled by stopping network interface i.e. 'ifconfig wlan0 down' Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-10-02ath: Add support for tracingSujith Manoharan
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-10-02Merge branch 'for-upstream' of ↵John W. Linville
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next
2014-10-02Bluetooth: 6lowpan: Check transmit errors for multicast packetsJukka Rissanen
We did not return error if multicast packet transmit failed. This might not be desired so return error also in this case. If there are multiple 6lowpan devices where the multicast packet is sent, then return error even if sending to only one of them fails. Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2014-10-02Bluetooth: 6lowpan: Return EAGAIN error also for multicast packetsJukka Rissanen
Make sure that we are able to return EAGAIN from l2cap_chan_send() even for multicast packets. The error code was ignored unncessarily. Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2014-10-02Bluetooth: 6lowpan: Avoid memory leak if memory allocation failsJukka Rissanen
If skb_unshare() returns NULL, then we leak the original skb. Solution is to use temp variable to hold the new skb. Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2014-10-02Bluetooth: 6lowpan: Memory leak as the skb is not freedJukka Rissanen
The earlier multicast commit 36b3dd250dde ("Bluetooth: 6lowpan: Ensure header compression does not corrupt IPv6 header") lost one skb free which then caused memory leak. Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2014-10-02Bluetooth: Fix lockdep warning with l2cap_chan_connectJohan Hedberg
The L2CAP connection's channel list lock (conn->chan_lock) must never be taken while already holding a channel lock (chan->lock) in order to avoid lock-inversion and lockdep warnings. So far the l2cap_chan_connect function has acquired the chan->lock early in the function and then later called l2cap_chan_add(conn, chan) which will try to take the conn->chan_lock. This violates the correct order of taking the locks and may lead to the following type of lockdep warnings: -> #1 (&conn->chan_lock){+.+...}: [<c109324d>] lock_acquire+0x9d/0x140 [<c188459c>] mutex_lock_nested+0x6c/0x420 [<d0aab48e>] l2cap_chan_add+0x1e/0x40 [bluetooth] [<d0aac618>] l2cap_chan_connect+0x348/0x8f0 [bluetooth] [<d0cc9a91>] lowpan_control_write+0x221/0x2d0 [bluetooth_6lowpan] -> #0 (&chan->lock){+.+.+.}: [<c10928d8>] __lock_acquire+0x1a18/0x1d20 [<c109324d>] lock_acquire+0x9d/0x140 [<c188459c>] mutex_lock_nested+0x6c/0x420 [<d0ab05fd>] l2cap_connect_cfm+0x1dd/0x3f0 [bluetooth] [<d0a909c4>] hci_le_meta_evt+0x11a4/0x1260 [bluetooth] [<d0a910eb>] hci_event_packet+0x3ab/0x3120 [bluetooth] [<d0a7cb08>] hci_rx_work+0x208/0x4a0 [bluetooth] CPU0 CPU1 ---- ---- lock(&conn->chan_lock); lock(&chan->lock); lock(&conn->chan_lock); lock(&chan->lock); Before calling l2cap_chan_add() the channel is not part of the conn->chan_l list, and can therefore only be accessed by the L2CAP user (such as l2cap_sock.c). We can therefore assume that it is the responsibility of the user to handle mutual exclusion until this point (which we can see is already true in l2cap_sock.c by it in many places touching chan members without holding chan->lock). Since the hci_conn and by exctension l2cap_conn creation in the l2cap_chan_connect() function depend on chan details we cannot simply add a mutex_lock(&conn->chan_lock) in the beginning of the function (since the conn object doesn't yet exist there). What we can do however is move the chan->lock taking later into the function where we already have the conn object and can that way take conn->chan_lock first. This patch implements the above strategy and does some other necessary changes such as using __l2cap_chan_add() which assumes conn->chan_lock is held, as well as adding a second needed label so the unlocking happens as it should. Reported-by: Jukka Rissanen <jukka.rissanen@linux.intel.com> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Tested-by: Jukka Rissanen <jukka.rissanen@linux.intel.com> Acked-by: Jukka Rissanen <jukka.rissanen@linux.intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-09-30rtlwifi: Fix randconfig build error with next-20140930Larry Finger
Configuration randconfig-1412075201 gets an error because driver rtl8821ae depends on driver btcoexist, but Kconfig does not select it. Reported-by: Jim Davis <jim.epost@gmail.com> Cc: Jim Davis <jim.epost@gmail.com> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-30mwifiex: add client mac address while configuring keys on GO.Maithili Hinge
When mwifiex device becomes GO, unicast traffic between client1 and GO stops when client2 connects to GO. Reason behind this was PTK getting overwritten by key_material command for client2 as it did not have client mac address. So, client1 can no more decode GO's ping packets though it responds to its broadcast packets. This patch adds case to check for BSS_ROLE instead of bss_type to set client mac address while configuring keys when device becomes GO. Signed-off-by: Maithili Hinge <maithili@marvell.com> Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: Cathy Luo <cluo@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-30ath9k: fix getting tx duration for dynackFelix Fietkau
On AR9003, tx control and tx status are in separate descriptor rings. Tx duration is extracted from the tx control descriptor data, which ar9003_hw_proc_txdesc cannot access. Fix getting the duration by adding a separate callback for it. Acked-by: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com> Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-30ath9k: Check early for HW resetSujith Manoharan
chan_lock is not required for checking if we are in the middle of a HW reset, so do it early. This also removes the small window where the lock is dropped and reacquired. Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-30brcmfmac: Add wowl support for PCIE devices.Hante Meuleman
Add basic wowl (magic packet and disconnect) support. This patch adds this support only for PCIE bus devices. This feature requires FW which has support for wowl built in. 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 <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-30brcmfmac: Fix crash on cleanup.Hante Meuleman
When driver gets unloaded due to error situation there is a chance a packet gets received while fws has already been cleaned up. This will result in kernel crash. This patch adds a check to avoid this crash. Reviewed-by: Arend Van Spriel <arend@broadcom.com> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Signed-off-by: Hante Meuleman <meuleman@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-30brcmfmac: assure P2P discovery is disabled when setting P2P_DEVICE mac addressArend van Spriel
In order to provision the P2P_DEVICE mac address using p2p_da_override iovar the discovery interface must be disabled. On some targets setting the mac address failed so disable the discovery interface to be certain. Reviewed-by: Hante Meuleman <meuleman@broadcom.com> Reviewed-by: Franky (Zhenhui) Lin <frankyl@broadcom.com> Reviewed-by: Daniel (Deognyoun) Kim <dekim@broadcom.com> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-30brcmfmac: Avoid usage of GFP_ATOMIC.Hante Meuleman
Msgbuf is using GFP_ATOMIC where GFP_KERNEL is also sufficient. On some platforms the coherent DMA memory is very limited when using GFP_ATOMIC. This patch changes usage of GFP_ATOMIC to GFP_KERNEL and uses worker to make this possible for creation of flowring. 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 <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-30brcmfmac: Fix sign issue with IOCTL return code in msgbuf.Hante Meuleman
Need a cast to assure correct value is propagated. 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 <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-30brcmfmac: On scan timeout do send received results.Hante Meuleman
Increase driver scan timeout from 8 to 10 seconds and report results to cfg80211. Without this patch the already received results were dropped on driver timeout. 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 <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-30ath9k_hw: fix PLL clock initialization for newer SoCFelix Fietkau
On AR934x and newer SoC devices, the layout of the AR_RTC_PLL_CONTROL register changed. This currently breaks at least 5/10 MHz operation. AR933x uses the old layout. It might also have been causing other stability issues because of the different location of the PLL_BYPASS bit which needs to be set during PLL clock initialization. This patch also removes more instances of hardcoded register values in favor of properly computed ones with the PLL_BYPASS bit added. Reported-by: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com> Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-30ath9k_hw: reduce ANI spur immunity setting on HT40 extension channelFelix Fietkau
The cycpwr_thr1 value needs to be lower on the extension channel than on the control channel, similar to how the register settings are programmed in the initvals. Also drop the unnecessary check for HT40 - this register can always be written. This patch has been reported to improve HT40 stability and throughput in some environments. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-30Revert "ath9k_hw: reduce ANI firstep range for older chips"Felix Fietkau
This reverts commit 09efc56345be4146ab9fc87a55c837ed5d6ea1ab I've received reports that this change is decreasing throughput in some rare conditions on an AR9280 based device Cc: stable@vger.kernel.org Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-30mwifiex: remove unnecessary rx_q lockAvinash Patil
SKB lists have their own lock. So this lock is not needed. Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-30mwifiex: do not decrement rx_pending count twiceAvinash Patil
This patch fixes an issue with rx processing function where we were decrementing rx_pending count twice. Patch also queues correct main_work item when rx_pending count reaches low watermark. Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: Cathy Luo <cluo@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-30mwifiex: fix soft lockup during iperf UDP RXAvinash Patil
A soft lockup was observed on ARM multicore platform while UDP RX iperf was running on station. Reason for this is delay_main_task was not taken into consideration while jumping to process_start. Now if delay_main_task is true, we would exit mwifiex_main_process instead of going to process_start again. This ensure other process is scheduled on this CPU and soft lockup is avoided. Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kevin Gan <ganhy@marvell.com> Signed-off-by: Marc Yang <yangyang@marvell.com> Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: Cathy Luo <cluo@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-30MAINTAINERS: change rt2x00 maintainerStanislaw Gruszka
After short chat with Ivo, we decided that I'll take maintenance of rt2x00 driver. Thanks for Ivo's great work in the past! Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Acked-by: Ivo Van Doorn <ivdoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-30ath9k_hw: disable hardware ad-hoc flag on ar934x rev 3Felix Fietkau
On AR934x rev 3, settin the ad-hoc flag completely messes up hardware state - beacons get stuck, almost no packets make it out, hardware is constantly reset. When leaving out that flag and setting up the hw like in AP mode, TSF timers won't be automatically synced, but at least the rest works. AR934x rev 2 and older are not affected by this bug Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-30ath9k: use ah->get_mac_revision for all SoC devices if availableFelix Fietkau
It is needed for AR934x as well Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-30ath5k: add missing include for debug codeFelix Fietkau
Needed for calling vmalloc()/vfree() Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-30rtlwifi: rtl8188ee: rtl8723ae: rtl8821ae: Initialize some variablesLarry Finger
In a number of places, kmalloc or valloc were used to acquire memory. To ensure that these locations are correctly initialized, the calls were changed to kzalloc and vzalloc. The change fixes a problem that was causing HT operations to be cancelled. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-30rtlwifi: rtl8188ee: rtl8192com: rtl8192cu: rtl8192ee: rtl8723ae: rtl87323be: ↵Larry Finger
rtl8821ae: Use common cmd_send_packet A locking problem was found in routine _rtl92ee_cmd_send_packet() that led to system freezes. Upon inspection, several drivers had the same problem; however, the routines all used the same code. The common code has been moved into rtlwifi. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
generated by cgit v1.2.3 (git 2.39.1) at 2025-07-29 06:19:33 +0000