summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2014-02-14Bluetooth: Cleanup RFCOMM device registration error handlingPeter Hurley
If RFCOMM tty device registration fails, cleanup by releasing the tty_port reference to trigger rfcomm_dev destruction (rather than open-coding it). The dlc reference release is moved into rfcomm_dev_add(), which ensures cleanup in both error paths -- ie., if __rfcomm_dev_add() fails or if tty_port_register_device() fails. Fixes releasing the module reference if device registration fails. Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Tested-By: Alexander Holler <holler@ahsoftware.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-02-14Bluetooth: Refactor rfcomm_dev_add()Peter Hurley
Move rfcomm_dev allocation and initialization into new function, __rfcomm_dev_add(), to simplify resource release in error handling. Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Tested-By: Alexander Holler <holler@ahsoftware.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-02-14Bluetooth: Serialize RFCOMMCREATEDEV and RFCOMMRELEASEDEV ioctlsPeter Hurley
At least two different race conditions exist with multiple concurrent RFCOMMCREATEDEV and RFCOMMRELEASEDEV ioctls: * Multiple concurrent RFCOMMCREATEDEVs with RFCOMM_REUSE_DLC can mistakenly share the same DLC. * RFCOMMRELEASEDEV can destruct the rfcomm_dev still being constructed by RFCOMMCREATEDEV. Introduce rfcomm_ioctl_mutex to serialize these add/remove operations. Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Tested-By: Alexander Holler <holler@ahsoftware.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-02-14Bluetooth: Rename __rfcomm_dev_get() to __rfcomm_dev_lookup()Peter Hurley
Functions which search lists for matching id's are more commonly named *_lookup, which is the convention in the bluetooth core as well. Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Tested-By: Alexander Holler <holler@ahsoftware.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-02-14Bluetooth: Fix RFCOMM parent device for reused dlcPeter Hurley
The RFCOMM tty device is parented to the acl link device when the dlc state_change(BT_CONNECTED) notification is received. However, if the dlc from the RFCOMM socket is being reused (RFCOMM_REUSE_DLC is set), then the dlc may already be connected, and no notification will occur. Instead, always parent the RFCOMM tty device to the acl link device at registration time. If the acl link device is not available (eg, because the dlc is not connected) then the tty will remain unparented until the BT_CONNECTED notification is received. Fixes regression with ModemManager when the rfcomm device is created with the flag RFCOMM_REUSE_DLC. Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Tested-By: Alexander Holler <holler@ahsoftware.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-02-14Bluetooth: Fix unsafe RFCOMM device parentingPeter Hurley
Accessing the results of hci_conn_hash_lookup_ba() is unsafe without holding the hci_dev_lock() during the lookup. For example: CPU 0 | CPU 1 hci_conn_hash_lookup_ba | hci_conn_del rcu_read_lock | hci_conn_hash_del list_for_each_entry_rcu | list_del_rcu if (.....) | synchronize_rcu rcu_read_unlock | | hci_conn_del_sysfs | hci_dev_put | hci_conn_put | put_device (last reference) | bt_link_release | kfree(conn) return p << just freed | Even if a hci_conn reference were taken (via hci_conn_get), would not guarantee the lifetime of the sysfs device, but only safe access to the in-memory structure. Ensure the hci_conn device stays valid while the rfcomm device is reparented; rename rfcomm_get_device() to rfcomm_reparent_device() and perform the reparenting within the function while holding the hci_dev_lock. Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Tested-By: Alexander Holler <holler@ahsoftware.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-02-14Bluetooth: Directly close dlc for not yet started RFCOMM sessionPeter Hurley
If the RFCOMM session has not yet been started (ie., session is still in BT_BOUND state) when a dlc is closed, directly close and unlink the dlc rather than sending a DISC frame that is never sent. This allows the dlci to be immediately reused rather than waiting for a 20 second timeout. Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Tested-By: Alexander Holler <holler@ahsoftware.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-02-14Bluetooth: Refactor dlc disconnect logic in rfcomm_dlc_close()Peter Hurley
Prepare for directly closing dlc if the RFCOMM session has not yet been started; refactor the dlc disconnect logic into a separate local function, __rfcomm_dlc_disconn(). Retains functional equivalence. Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Tested-By: Alexander Holler <holler@ahsoftware.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-02-14Bluetooth: Refactor deferred setup test in rfcomm_dlc_close()Peter Hurley
Prepare for directly closing dlc if the RFCOMM session has not yet been started; refactor the deferred setup test for only those dlc states to which the test applies. Retains functional equivalence. Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Tested-By: Alexander Holler <holler@ahsoftware.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-02-14Bluetooth: Simplify RFCOMM session state evalPeter Hurley
Merge conditional test for BT_LISTEN session state into following switch statement (which is functionally equivalent). Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Tested-By: Alexander Holler <holler@ahsoftware.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-02-14Bluetooth: Verify dlci not in use before rfcomm_dev createPeter Hurley
Only one session/channel combination may be in use at any one time. However, the failure does not occur until the tty is opened (in rfcomm_dlc_open()). Because these settings are actually bound at rfcomm device creation (via RFCOMMCREATEDEV ioctl), validate and fail before creating the rfcomm tty device. Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Tested-By: Alexander Holler <holler@ahsoftware.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-02-14Bluetooth: Fix RFCOMM tty teardown racePeter Hurley
RFCOMM tty device teardown can race with new tty device registration for the same device id: CPU 0 | CPU 1 rfcomm_dev_add | rfcomm_dev_destruct | spin_lock | list_del <== dev_id no longer used | spin_unlock spin_lock | . [search rfcomm_dev_list] | . [dev_id not in use] | . [initialize new rfcomm_dev] | . spin_unlock | . | . tty_port_register_device | tty_unregister_device Don't remove rfcomm_dev from the device list until after tty device unregistration has completed. Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Tested-By: Alexander Holler <holler@ahsoftware.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-02-14Bluetooth: Fix unreleased rfcomm_dev referencePeter Hurley
When RFCOMM_RELEASE_ONHUP is set, the rfcomm tty driver 'takes over' the initial rfcomm_dev reference created by the RFCOMMCREATEDEV ioctl. The assumption is that the rfcomm tty driver will release the rfcomm_dev reference when the tty is freed (in rfcomm_tty_cleanup()). However, if the tty is never opened, the 'take over' never occurs, so when RFCOMMRELEASEDEV ioctl is called, the reference is not released. Track the state of the reference 'take over' so that the release is guaranteed by either the RFCOMMRELEASEDEV ioctl or the rfcomm tty driver. Note that the synchronous hangup in rfcomm_release_dev() ensures that rfcomm_tty_install() cannot race with the RFCOMMRELEASEDEV ioctl. Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Tested-By: Alexander Holler <holler@ahsoftware.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-02-14Bluetooth: Release rfcomm_dev only oncePeter Hurley
No logic prevents an rfcomm_dev from being released multiple times. For example, if the rfcomm_dev ref count is large due to pending tx, then multiple RFCOMMRELEASEDEV ioctls may mistakenly release the rfcomm_dev too many times. Note that concurrent ioctls are not required to create this condition. Introduce RFCOMM_DEV_RELEASED status bit which guarantees the rfcomm_dev can only be released once. NB: Since the flags are exported to userspace, introduce the status field to track state for which userspace should not be aware. Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Tested-By: Alexander Holler <holler@ahsoftware.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-02-14Bluetooth: Exclude released devices from RFCOMMGETDEVLIST ioctlPeter Hurley
When enumerating RFCOMM devices in the rfcomm_dev_list, holding the rfcomm_dev_lock only guarantees the existence of the enumerated rfcomm_dev in memory, and not safe access to its state. Testing the device state (such as RFCOMM_TTY_RELEASED) does not guarantee the device will remain in that state for the subsequent access to the rfcomm_dev's fields, nor guarantee that teardown has not commenced. Obtain an rfcomm_dev reference for the duration of rfcomm_dev access. Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Tested-By: Alexander Holler <holler@ahsoftware.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-02-14Bluetooth: Fix racy acquire of rfcomm_dev referencePeter Hurley
rfcomm_dev_get() can return a rfcomm_dev reference for a device for which destruction may be commencing. This can happen on tty destruction, which calls rfcomm_tty_cleanup(), the last port reference may have been released but RFCOMM_TTY_RELEASED was not set. The following race is also possible: CPU 0 | CPU 1 | rfcomm_release_dev rfcomm_dev_get | . spin_lock | . dev = __rfcomm_dev_get | . if dev | . if test_bit(TTY_RELEASED) | . | !test_and_set_bit(TTY_RELEASED) | tty_port_put <<<< last reference else | tty_port_get | The reference acquire is bogus because destruction will commence with the release of the last reference. Ignore the external state change of TTY_RELEASED and instead rely on the reference acquire itself to determine if the reference is valid. Cc: Jiri Slaby <jslaby@suse.cz> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Tested-By: Alexander Holler <holler@ahsoftware.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-02-14tty: Fix ref counting for port krefsPeter Hurley
The tty core supports two models for handling tty_port lifetimes; the tty_port can use the kref supplied by tty_port (which will automatically destruct the tty_port when the ref count drops to zero) or it can destruct the tty_port manually. For tty drivers that choose to use the port kref to manage the tty_port lifetime, it is not possible to safely acquire a port reference conditionally. If the last reference is released after evaluating the condition but before acquiring the reference, a bogus reference will be held while the tty_port destruction commences. Rather, only acquire a port reference if the ref count is non-zero and allow the caller to distinguish if a reference has successfully been acquired. Cc: Jiri Slaby <jslaby@suse.cz> Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Tested-By: Alexander Holler <holler@ahsoftware.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-02-14Revert "Bluetooth: Move rfcomm_get_device() before rfcomm_dev_activate()"Peter Hurley
This reverts commit e228b63390536f5b737056059a9a04ea016b1abf. This is the third of a 3-patch revert, together with Revert "Bluetooth: Remove rfcomm_carrier_raised()" and Revert "Bluetooth: Always wait for a connection on RFCOMM open()". Commit 4a2fb3ecc7467c775b154813861f25a0ddc11aa0, "Bluetooth: Always wait for a connection on RFCOMM open()" open-codes blocking on tty open(), rather than using the default behavior implemented by the tty port. The reasons for reverting that patch are detailed in that changelog; this patch restores required functionality for that revert. Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Tested-By: Alexander Holler <holler@ahsoftware.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-02-14Revert "Bluetooth: Always wait for a connection on RFCOMM open()"Peter Hurley
This reverts commit 4a2fb3ecc7467c775b154813861f25a0ddc11aa0. This is the second of a 3-patch revert, together with Revert "Bluetooth: Remove rfcomm_carrier_raised()" and Revert "Bluetooth: Move rfcomm_get_device() before rfcomm_dev_activate()". Before commit cad348a17e170451ea8688b532a6ca3e98c63b60, Bluetooth: Implement .activate, .shutdown and .carrier_raised methods, tty_port_block_til_ready() was open-coded in rfcomm_tty_install() as part of the RFCOMM tty open(). Unfortunately, it did not implement non-blocking open nor CLOCAL open, but rather always blocked for carrier. This is not the expected or typical behavior for ttys, and prevents several common terminal programming idioms from working (eg., opening in non-blocking mode to initialize desired termios settings then re-opening for connection). Commit cad348a17e170451ea8688b532a6ca3e98c63b60, Bluetooth: Implement .activate, .shutdown and .carrier_raised methods, added the necessary tty_port methods to use the default tty_port_open(). However, this triggered two important user-space regressions. The first regression involves the complicated mechanism for reparenting the rfcomm tty device to the ACL link device which represents an open link to a specific bluetooth host. This regression causes ModemManager to conclude the rfcomm tty device does not front a modem so it makes no attempt to initialize an attached modem. This regression is caused by the lack of a device_move() if the dlc is already open (and not specifically related to the open-coded block_til_ready()). A more appropriate solution is submitted in "Bluetooth: Fix unsafe RFCOMM device parenting" and "Bluetooth: Fix RFCOMM parent device for reused dlc" The second regression involves "rfcomm bind" and wvdial (a ppp dialer). rfcomm bind creates a device node for a /dev/rfcomm<n>. wvdial opens that device in non-blocking mode (because it expects the connection to have already been established). In addition, subsequent writes to the rfcomm tty device fail (because the link is not yet connected; rfcomm connection begins with the actual tty open()). However, restoring the original behavior (in the patch which this reverts) was undesirable. Firstly, the original reporter notes that a trivial userspace "workaround" already exists: rfcomm connect, which creates the device node and establishes the expected connection. Secondly, the failed writes occur because the rfcomm tty driver does not buffer writes to an unconnected device; this contrasts with the dozen of other tty drivers (in fact, all of them) that do just that. The submitted patch "Bluetooth: Don't fail RFCOMM tty writes" corrects this. Thirdly, it was a long-standing bug to block on non-blocking open, which is re-fixed by revert. Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Tested-By: Alexander Holler <holler@ahsoftware.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-02-14Revert "Bluetooth: Remove rfcomm_carrier_raised()"Peter Hurley
This reverts commit f86772af6a0f643d3e13eb3f4f9213ae0c333ee4. This is the first of a 3-patch revert, together with Revert "Bluetooth: Always wait for a connection on RFCOMM open()" and Revert "Bluetooth: Move rfcomm_get_device() before rfcomm_dev_activate()". Commit 4a2fb3ecc7467c775b154813861f25a0ddc11aa0, "Bluetooth: Always wait for a connection on RFCOMM open()" open-codes blocking on tty open(), rather than using the default behavior implemented by the tty port. The reasons for reverting that patch are detailed in that changelog; this patch restores required functionality for that revert. Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Tested-By: Alexander Holler <holler@ahsoftware.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-02-14Bluetooth: Enable LE L2CAP CoC support by defaultJohan Hedberg
Now that the LE L2CAP Connection Oriented Channel support has undergone a decent amount of testing we can make it officially supported. This patch removes the enable_lecoc module parameter which was previously needed to enable support for LE L2CAP CoC. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-02-14ath10k: release conf_mutex if vdev_start() failsKalle Valo
I modified Michal's commit c930f744bdb0 ("ath10k: implement channel switching") to return when vdev_start() fails, but forgot to release conf_mutex. Found by coccinelle: >> drivers/net/wireless/ath/ath10k/mac.c:2745:5-11: preceding lock on line 2663 Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2014-02-14ath: remove camel case from struct reg_dmn_pair_mappingKalle Valo
Fixes a checkpatch warning in ath10k: drivers/net/wireless/ath/ath10k/mac.c:1636: WARNING: Avoid CamelCase: <regpair->regDmnEnum> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2014-02-14ath10k: fix alignment in ath10k_dbg()Kalle Valo
Fix a checkpatch warning: drivers/net/wireless/ath/ath10k/debug.h:95: CHECK: Alignment should match open parenthesis Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2014-02-13Staging: rtl8812ae: remove modules field of rate_control_opsStephen Rothwell
This has been removed in further work. Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-02-13wcn36xx: Update dtim period before starting BSSPontus Fuchs
The dtim period sent to FW was 0 because the dtim period was never set. This caused an incorrect dtim count to be sent in beacons. Signed-off-by: Pontus Fuchs <pontus.fuchs@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-02-13wcn36xx: Track dpu signature per staPontus Fuchs
This fixes problems seen with multiple softap clients and reconnecting softap clients. Signed-off-by: Pontus Fuchs <pontus.fuchs@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-02-13wcn36xx: Rename wcn36xx_vif.ucast_dpu_signature to self_ucast_dpu_signPontus Fuchs
This is more line with the names of the other members Signed-off-by: Pontus Fuchs <pontus.fuchs@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-02-13wcn36xx: Add support for 3680Pontus Fuchs
3680 has a few registers on other addresses. Signed-off-by: Pontus Fuchs <pontus.fuchs@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-02-13wcn36xx: Print FW capabilitiesPontus Fuchs
After fw caps exchange, print the FW's capabilities. Signed-off-by: Pontus Fuchs <pontus.fuchs@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-02-13wcn36xx: Cache nv to avoid request_firmware on resume pathPontus Fuchs
If wowlan if off mac80211 will stop / start the driver on suspend / resume. This causes problems on resume since request_firmware is called from start. Fix this by caching the nv. Signed-off-by: Pontus Fuchs <pontus.fuchs@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-02-13wcn36xx: Wait longer for SMD commands to completePontus Fuchs
On some wcnss firmwares the start command can take up to 300ms to complete. Currently there is a 200ms timeout for SMD command to complete which causes the start to fail. Increase the timeout to 500ms. Also improve debug information regarding SMD command completion time. Signed-off-by: Pontus Fuchs <pontus.fuchs@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-02-13wcn36xx: Improve feature caps exchangePontus Fuchs
* Response format is not in the canonical format. wcn36xx_smd_rsp_status_check cannot be used. * Save the FW caps in wcn36xx struct for later use. Signed-off-by: Pontus Fuchs <pontus.fuchs@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-02-13wcn36xx: Fix copy paste error hal_exit_bmps -> hal_keep_alivePontus Fuchs
Signed-off-by: Pontus Fuchs <pontus.fuchs@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-02-13wlcore: add support for STA CSA with chan contextsArik Nemtsov
TI wl12xx/wl18xx cards support channel switch via a driver specific switch_channel op while operating with channel contexts. Signed-off-by: Arik Nemtsov <arik@wizery.com> Signed-off-by: Eliad Peller <eliad@wizery.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-02-13wlcore: enable beacon filtering only after receiving a beaconEliad Peller
Enabling beacon filtering before receving a beacon might result in not having a beacon at all for the current connected AP, which prevents the station from entering power-save. Replace the current approach (of starting beacon filtering on init) and configure beacon filering only after bss_conf->dtimper is set (which means mac80211 already parsed a beacon). Signed-off-by: Eliad Peller <eliad@wizery.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-02-13wlcore: increase timeout to 5000 msecsYaniv Machani
dfs configuration command might take longer than the current timeout. increase it to 5 seconds. Signed-off-by: Yaniv Machani <yanivma@ti.com> Signed-off-by: Eliad Peller <eliad@wizery.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-02-13wlcore: decrease warning verbosity during recoveryArik Nemtsov
Silently ignore repetitive scheduling of recovery work and commands being passed to the bus when the HW is not available. This can happen many times during recovery and slow it down. It also spams the kernel logs. Signed-off-by: Arik Nemtsov <arik@wizery.com> Signed-off-by: Eliad Peller <eliad@wizery.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-02-13wlcore: consider multiple APs when checking active_link_countEliad Peller
Each AP has its own global and broadcast links, so when checking for active sta count (according to the active_link_count) we must take them all into account. Signed-off-by: Eliad Peller <eliad@wizery.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-02-13wlcore: don't handle unsetting of default wep keyEliad Peller
mac80211 unsets the default wep key on disassoc. The fw doesn't support this notification, so simply ignore it. The actual flow actually triggers fw recovery in some cases, as mac80211 unsets the default key only after disassoc, when wlvif->sta.hlid, resulting in invalid hlid being passed to the fw. Signed-off-by: Eliad Peller <eliad@wizery.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-02-13wlcore: wl18xx: allow CCK rates for AP modeArik Nemtsov
12xx chips allow only OFDM rates in AP mode for BT-Coex purposes. This is no longer required in 18xx chips, starting with FW 8.6.0.0.8. Update the min allowed FW version in 18xx to support this functionality. Signed-off-by: Arik Nemtsov <arik@wizery.com> Signed-off-by: Eliad Peller <eliad@wizery.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-02-13wlcore: don't stop sched_scan on interface removalBarak Bercovitz
Stopping sched scan on interface removal (during recovery) is no longer needed, as sched scanning is automatically restarted by mac80211. Signed-off-by: Barak Bercovitz <barak@wizery.com> Signed-off-by: Eliad Peller <eliad@wizery.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-02-13wlcore: send EAPOL frames with voice priorityIgal Chernobelsky
Send EAPOL frames with voice priority by setting (the new) TX_HW_ATTR_EAPOL_FRAME bit in tx attribute. Sending EAPOL with voice priority fixes re-key timeout issues during heavy traffic. Signed-off-by: Igal Chernobelsky <igalc@ti.com> Signed-off-by: Eliad Peller <eliad@wizery.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-02-13wl18xx: move to new firmware (wl18xx-fw-3.bin)Eliad Peller
Bump the min wl18xx fw version to 8.8.0.0.13 This fw is not backward compatible with older firmware (due to api changes), so use bump the firmware name as well. Some modifications were done to the driver-fw api in order to support multiple APs. Additionally, some of the consts (such as max stations, max links and max RX BA sessions) were changed. Signed-off-by: Arik Nemtsov <arik@wizery.com> Signed-off-by: Eliad Peller <eliad@wizery.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-02-13wlcore/wl12xx/wl18xx: configure iface_combinations per-hwEliad Peller
Each hw supports a different iface combinations. Define the supported combinations in each driver, and save it in wl->iface_combinations. Since each driver defines its own combinations now, it can also define its max supported channels, so we no longer need to save and set it explicitly in wlcore. Update wl18xx interface combinations to allow multiple APs. Signed-off-by: Eliad Peller <eliad@wizery.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-02-13wlcore/wl12xx/wl18xx: configure max_stations per-hwEliad Peller
Each hw supports a different max stations (connected to the same ap). add a new wl->max_ap_stations and use it instead of the current common AP_MAX_STATIONS. Signed-off-by: Eliad Peller <eliad@wizery.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-02-13wlcore/wl12xx/wl18xx: configure num_links per-hwEliad Peller
Upcoming fw versions will have different max links support (according to the hw). Get ready for it by configuring wl->num_links per-hw, instead of using the const WL12XX_MAX_LINKS. However, continue using WLCORE_MAX_LINKS in order to simplify structs declarations (we use it in multiple bitmaps, and converting them to dynamic arrays is just cumbersome). Signed-off-by: Eliad Peller <eliad@wizery.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-02-13wlcore/wl12xx/wl18xx: simplify fw_status handlingEliad Peller
Instead of splitting the fw_status into 2 and using some complex calculations, read the fw status and let each low-level driver (wl12xx/wl18xx) convert it into a common struct. This is required for the upcoming fw api changes, which break the current logic anyway. Signed-off-by: Eliad Peller <eliad@wizery.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-02-13wlcore: AP: don't start mac80211 PS on non-peer HLIDsArik Nemtsov
It seems the wl18xx FW sometimes sends spurious changes on the PSM state of the broadcast HLID. This causes us to search for a station on a non-peer link and fail, causing warnings in our log. Prevent the driver from considering PSM changes for any non-peer HLIDs. Signed-off-by: Arik Nemtsov <arik@wizery.com> Signed-off-by: Eliad Peller <eliad@wizery.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-02-13wlcore: block read/writes to FW during ELPBarak Bercovitz
When the chip is in ELP mode read/write to FW is invalid and may cause the lower layers to get stuck. The reads/writes concerning ELP wakeup are the exception here and are checked for. In addition to blocking the IO, produce a warning. Signed-off-by: Barak Bercovitz <barak@wizery.com> Signed-off-by: Eliad Peller <eliad@wizery.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>