- 09 Sep, 2014 30 commits
-
-
Sujith Manoharan authored
Scanning is curently broken when two channel contexts are active. For example in a P2P-GO/STA setup, the offchannel timer allows HZ / 10 to elapse before initiating a switch to the next scan channel from the current operating channel, which in this case would be the P2P-GO context. But, the channel context timer might decide to switch to the STA context when an SWBA comes early and a beacon is sent out. Since pending offchannel requests are processed in EVENT_BEACON_PREPARE, this causes inconsistent scanning. Fix this by making sure that a context switch happens before processing the pending offchannel request. This also makes sure that active channel contexts will always have higher priority than offchannel operations and the scan sequence looks like this: p2p-go, sta, p2p-go, offchannel, p2p-go, sta, p2p-go, offchannel,..... The oper-channel is p2p-go, so the STA context has to switch to p2p-go again before switching offchannel. Signed-off-by:
Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Sujith Manoharan authored
When multiple channel contexts are active, an offchannel request will not be handled immediately, but will be queued to be handled later. But, currently, the channel definition is not copied to the local offchannel state. This breaks operation like scanning when MCC is active. Fix this by storing the offchannel parameters properly. Signed-off-by:
-
Sujith Manoharan authored
Reduces code duplication. Signed-off-by:
-
Sujith Manoharan authored
Currently, the interface count is maintained globally, but this causes problems in RX filter calculation. Make the interface count a per-channel-context variable to fix this. Signed-off-by:
-
Sujith Manoharan authored
Maintain the RX filter on a per-channel-context basis and not globally. Not doing so was resulting in incorrect filter calculation. Signed-off-by:
-
Sujith Manoharan authored
ATH9K_RX_FILTER_COMP_BAR is used to receive BAR completion frames and is set if the current channel is HT. When channel contexts are enabled, instead of using the mac80211 helpers, check if the current channel definition is HT. Signed-off-by:
-
Sujith Manoharan authored
Since ath_startrecv() doesn't return an error value, cleanup the callsites. Signed-off-by:
-
Sujith Manoharan authored
If multiple channel contexts are active, then the opmode can be different in each context. Since the RX filter is calculated in ath_startrecv() before switching to the new opmode, the wrong filters are chosen. Fix this by calling ath9k_calculate_summary_state() before the RX module is started. Signed-off-by:
-
Sujith Manoharan authored
Since CTWindow can be used for improving discoverability, fill this field in the NoA Attribute properly. Signed-off-by:
-
Sujith Manoharan authored
Currently, different units are used for handling sc->offchannel.duration. In scan mode, it contains jiffies and in RoC mode, milliseconds is used. This causes confusion since in ath_chanctx_switch(), TU_TO_USEC is used to determine the offchannel duration, resulting in incorrect values. Fix this by using jiffies in both modes. Signed-off-by:
-
Sujith Manoharan authored
The start time field in the NoA attribute needs to be updated based on the TSF timer when an absence notification is sent by the P2P GO. When two channel contexts are active, continuous, cyclic NoA is announced by setting the count value to 255, but the start time is updated only once, for one beacon and the same value is sent in all subsequent beacons, even though the timestamp keeps moving. Fix this by removing the check for 'periodic_noa_duration' and assign the interface's start_time/duration values directly when there is more than one active context. Signed-off-by:
-
Sujith Manoharan authored
If a station interface is already assigned to a context and is active and a second interface of type AP is added, then beaconing on the new interface has to be begin only after the BSS_CHANGED_BEACON_ENABLED flag is sent by mac80211 to the driver. But, since we issue ATH_CHANCTX_EVENT_ENABLE_MULTICHANNEL as soon as a new channel context is added, a switch occurs almost immediately before BSS_CHANGED_BEACON_ENABLED is received. When a HW reset is done for the new context, beacons are enabled for the interface since "enable_beacon" in the BSS config maintained in mac80211 is true - but the driver hasn't been notified yet. This causes a panic, since the beacon interval is zero for this interface and ath9k_cmn_beacon_config_ap() doesn't have a safety check. Fix this panic by checking if the beacon params has been cached for this context and use the "enable_beacon" flag maintained locally in the driver. Also, recalculate the summary data after the beacon params have been cached when BSS_CHANGED_BEACON_ENABLED is received. Signed-off-by:
-
Sujith Manoharan authored
If the current opmode is managed, the ATH_OP_BEACONS flag needs to be set only when there is a primary station interface and it is associated/active. Signed-off-by:
-
Sujith Manoharan authored
In channel context mode, when a new context is added, mac80211 issues a bss_info_changed() notfication when preparing the connection for the new interface/context. But, this is done prior to the mgd_prepare_tx() call which is where we switch to the new context. Since the current context will be different when the earlier bss_info_changed() is handled, the beacon information for the VIF is not updated, but discarded since the rules for the current context disallows it. In the subsequent association process for the new context/vif, this becomes a problem because the beacon parameters are invalid. This causes problems with the TSF timer, causing large jumps. To fix this, check if the beacon info is being updated for a different context and if so, allow it without any checks since we limit the max. interfaces to two anyway. Signed-off-by:
-
Rafał Miłecki authored
On Northstar (ARM arch) we will use MTD subsystem to access NVRAM and SPROM. To get access to flash device we need to register these cores first. Signed-off-by:
Rafał Miłecki <zajec5@gmail.com> Acked-by:
Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by:
-
Rafał Miłecki authored
This cleans code a bit and will us to register cores in other places as well. The only difference with this patch is using "core_index" for setting device name. Signed-off-by:
-
Larry Finger authored
This patch makes halbtcoutsrc.{c,h} work with the new pieces of the driver. Also included are some modifications to various header files. Signed-off-by:Larry Finger <Larry.Finger@lwfinger.net> Cc: troy_tan@realsil.com.cn Signed-off-by:
-
Larry Finger authored
This code comes from the V062414 version of the drivers from Realtek. Signed-off-by:
-
Larry Finger authored
This patch adds the code needed for the new rtl8821ae driver. Signed-off-by:
-
Larry Finger authored
This patch adds the routines found in the V062814 Realtek version. Signed-off-by:
-
Larry Finger authored
This patch adds the routines needed to support BT coexistence with the new rtl8192ee driver. Signed-off-by:
-
Larry Finger authored
Signed-off-by:
-
Larry Finger authored
This patch is the first of a set to bring this driver up to the latest Realtek code. Signed-off-by:
-
Rafał Miłecki authored
This is required to split SoC bus init into two phases. The later one (which includes scanning) should be called when kalloc is available. Cc: Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
-
Rafał Miłecki authored
This change is important for SoC host. In future we will want to know chip ID (needed for early MIPS boot) before doing cores scanning. Signed-off-by:
-
Jukka Rissanen authored
Packets that are supposed to be delivered via the peer device need to be checked and sent to correct device. This requires that user has set the routes properly so that the 6lowpan module can then figure out the destination gateway and the correct Bluetooth device. Signed-off-by:
Jukka Rissanen <jukka.rissanen@linux.intel.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Cc: stable@vger.kernel.org # 3.17.x
-
Jukka Rissanen authored
The peer IPv6 address contained wrong U/L bit in the EUI-64 part. Signed-off-by:
-
Jukka Rissanen authored
Use the default connection timeout value defined in l2cap.h because the current timeout was too short and most of the time the connection attempts timed out. Signed-off-by:
-
Champion Chen authored
Suspend could fail for some platforms because btusb_suspend==> btusb_stop_traffic ==> usb_kill_anchored_urbs. When btusb_bulk_complete returns before system suspend and resubmits an URB, the system cannot enter suspend state. Signed-off-by:
Champion Chen <champion_chen@realsil.com.cn> Signed-off-by:
-
Johan Hedberg authored
Whether through HCI with BR/EDR or SMP with LE when authentication fails we should also notify any pending Pair Device mgmt command. This patch updates the mgmt_auth_failed function to take the actual hci_conn object and makes sure that any pending pairing command is notified and cleaned up appropriately. Signed-off-by:
Johan Hedberg <johan.hedberg@intel.com> Signed-off-by:
-
- 08 Sep, 2014 10 commits
-
-
Johan Hedberg authored
This patch fixes the following type of static analyzer warning (and probably a real bug as well as the NULL check should be there for a reason): net/bluetooth/smp.c:1182 smp_conn_security() warn: variable dereferenced before check 'conn' (see line 1174) Signed-off-by:
-
Behan Webster authored
Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99 compliant equivalent. This patch allocates the appropriate amount of memory using an char array. The new code can be compiled with both gcc and clang. struct shash_desc contains a flexible array member member ctx declared with CRYPTO_MINALIGN_ATTR, so sizeof(struct shash_desc) aligns the beginning of the array declared after struct shash_desc with long long. No trailing padding is required because it is not a struct type that can be used in an array. The CRYPTO_MINALIGN_ATTR is required so that desc is aligned with long long as would be the case for a struct containing a member with CRYPTO_MINALIGN_ATTR. Signed-off-by:
Behan Webster <behanw@converseincode.com> Signed-off-by:
Mark Charlebois <charlebm@gmail.com> Signed-off-by:
Jan-Simon Möller <dl9pf@gmx.de> Signed-off-by:
-
Johan Hedberg authored
SMP defines quite clearly when certain PDUs are to be expected/allowed and when not, but doesn't have any explicit request/response definition. So far the code has relied on each PDU handler to behave correctly if receiving PDUs at an unexpected moment, however this requires many different checks and is prone to errors. This patch introduces a generic way to keep track of allowed PDUs and thereby reduces the responsibility & load on individual command handlers. The tracking is implemented using a simple bit-mask where each opcode maps to its own bit. If the bit is set the corresponding PDU is allow and if the bit is not set the PDU is not allowed. As a simple example, when we send the Pairing Request we'd set the bit for Pairing Response, and when we receive the Pairing Response we'd clear the bit for Pairing Response. Since the disallowed PDU rejection is now done in a single central place we need to be a bit careful of which action makes most sense to all cases. Previously some, such as Security Request, have been simply ignored whereas others have caused an explicit disconnect. The only PDU rejection action that keeps good interoperability and can be used for all the applicable use cases is to drop the data. This may raise some concerns of us now being more lenient for misbehaving (and potentially malicious) devices, but the policy of simply dropping data has been a successful one for many years e.g. in L2CAP (where this is the *only* policy for such cases - we never request disconnection in l2cap_core.c because of bad data). Furthermore, we cannot prevent connected devices from creating the SMP context (through a Security or Pairing Request), and once the context exists looking up the corresponding bit for the received opcode and deciding to reject it is essentially an equally lightweight operation as the kind of rejection that l2cap_core.c already successfully does. Signed-off-by:
-
Johan Hedberg authored
When we're in the process of receiving keys in phase 3 of SMP we keep track of which keys are still expected in the smp->remote_key_dist variable. If we still have some key bits set we need to continue waiting for more PDUs and not needlessly call smp_distribute_keys(). This patch fixes two such cases in the smp_cmd_master_ident() and smp_cmd_ident_addr_info() handler functions. Signed-off-by:
-
Johan Hedberg authored
This patch adds a define for the allowed bits of the key distribution mask so we don't have to have magic 0x07 constants throughout the code. Signed-off-by:
-
Johan Hedberg authored
Before the move the l2cap_chan the SMP context (smp_chan) didn't have any kind of proper locking. The best there existed was the HCI_CONN_LE_SMP_PEND flag which was used to enable mutual exclusion for potential multiple creators of the SMP context. Now that SMP has been converted to use the l2cap_chan infrastructure and since the SMP context is directly mapped to a corresponding l2cap_chan we get the SMP context locking essentially for free through the l2cap_chan lock. For all callbacks that l2cap_core.c makes for each channel implementation (smp.c in the case of SMP) the l2cap_chan lock is held through l2cap_chan_lock(chan). Since the calls from l2cap_core.c to smp.c are covered the only missing piece to have the locking implemented properly is to ensure that the lock is held for any other call path that may access the SMP context. This means user responses through mgmt.c, requests to elevate the security of a connection through hci_conn.c, as well as any deferred work through workqueues. This patch adds the necessary locking to all these other code paths that try to access the SMP context. Since mutual exclusion for the l2cap_chan access is now covered from all directions the patch also removes unnecessary HCI_CONN_LE_SMP_PEND flag (once we've acquired the chan lock we can simply check whether chan->smp is set to know if there's an SMP context). Signed-off-by:
-
Johan Hedberg authored
Now that the identity address update happens through its own deferred work there's no need to have smp_distribute_keys anymore behind a second deferred work. This patch removes this extra construction and makes the code do direct calls to smp_distribute_keys() again. Signed-off-by:
-
Johan Hedberg authored
The identity address update of all channels for an l2cap_conn needs to take the lock for each channel, i.e. it's safest to do this by a separate workqueue callback. Previously this was partially solved by moving the entire SMP key distribution behind a workqueue. However, if we want SMP context locking to be correct and safe we should always use the l2cap_chan lock when accessing it, meaning even smp_distribute_keys needs to take that lock which would once again create a dead lock when updating the identity address. The simplest way to solve this is to have l2cap_conn manage the deferred work which is what this patch does. A subsequent patch will remove the now unnecessary SMP key distribution work struct. Signed-off-by:
-
Johan Hedberg authored
When smp_resume_cb is called if we're not encrypted (i.e. the callback wasn't called because the connection became encrypted) we shouldn't take any action at all. This patch moves also the security_timer cancellation behind this condition. Signed-off-by:
-
Johan Hedberg authored
The SMP security timer used to be able to modify the SMP context state but now days it simply calls hci_disconnect(). It is therefore unnecessary to have extra sanity checks for the SMP context after canceling the timer. Signed-off-by:
-
