summaryrefslogtreecommitdiffstats
path: root/net
Commit message (Collapse)AuthorAgeFilesLines
* Merge tag 'mac80211-next-for-john-2014-08-29' of ↵John W. Linville2014-09-0421-170/+179
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next Johannes Berg <johannes@sipsolutions.net> says: "Not that much content this time. Some RCU cleanups, crypto performance improvements, and various patches all over, rather than listing them one might as well look into the git log instead." Signed-off-by: John W. Linville <linville@tuxdriver.com> Conflicts: drivers/net/wireless/ath/wil6210/wmi.c
| * net: rfkill: gpio: Add more Broadcom bluetooth ACPI IDsMika Westerberg2014-08-291-0/+1
| | | | | | | | | | | | | | This adds one more ACPI ID of a Broadcom bluetooth chip. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * mac80211: fix chantype recalc warningMichal Kazior2014-08-291-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a device driver is unloaded local->interfaces list is cleared. If there was more than 1 interface running and connected (bound to a chanctx) then chantype recalc was called and it ended up with compat being NULL causing a call trace warning. Warn if compat becomes NULL as a result of incompatible bss_conf.chandef of interfaces bound to a given channel context only. The call trace looked like this: WARNING: CPU: 2 PID: 2594 at /devel/src/linux/net/mac80211/chan.c:557 ieee80211_recalc_chanctx_chantype+0x2cd/0x2e0() Modules linked in: ath10k_pci(-) ath10k_core ath CPU: 2 PID: 2594 Comm: rmmod Tainted: G W 3.16.0-rc1+ #150 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 0000000000000009 ffff88001ea279c0 ffffffff818dfa93 0000000000000000 ffff88001ea279f8 ffffffff810514a8 ffff88001ce09cd0 ffff88001e03cc58 0000000000000000 ffff88001ce08840 ffff88001ce09cd0 ffff88001ea27a08 Call Trace: [<ffffffff818dfa93>] dump_stack+0x4d/0x66 [<ffffffff810514a8>] warn_slowpath_common+0x78/0xa0 [<ffffffff81051585>] warn_slowpath_null+0x15/0x20 [<ffffffff818a407d>] ieee80211_recalc_chanctx_chantype+0x2cd/0x2e0 [<ffffffff818a3dda>] ? ieee80211_recalc_chanctx_chantype+0x2a/0x2e0 [<ffffffff818a4919>] ieee80211_assign_vif_chanctx+0x1a9/0x770 [<ffffffff818a6220>] __ieee80211_vif_release_channel+0x70/0x130 [<ffffffff818a6dd3>] ieee80211_vif_release_channel+0x43/0xb0 [<ffffffff81885f4e>] ieee80211_stop_ap+0x21e/0x5a0 [<ffffffff8184b9b5>] __cfg80211_stop_ap+0x85/0x520 [<ffffffff8181c188>] __cfg80211_leave+0x68/0x120 [<ffffffff8181c268>] cfg80211_leave+0x28/0x40 [<ffffffff8181c5f3>] cfg80211_netdev_notifier_call+0x373/0x6b0 [<ffffffff8107f965>] notifier_call_chain+0x55/0x110 [<ffffffff8107fa41>] raw_notifier_call_chain+0x11/0x20 [<ffffffff816a8dc0>] call_netdevice_notifiers_info+0x30/0x60 [<ffffffff816a8eb9>] __dev_close_many+0x59/0xf0 [<ffffffff816a9021>] dev_close_many+0x81/0x120 [<ffffffff816aa1c5>] rollback_registered_many+0x115/0x2a0 [<ffffffff816aa3a6>] unregister_netdevice_many+0x16/0xa0 [<ffffffff8187d841>] ieee80211_remove_interfaces+0x121/0x1b0 [<ffffffff8185e0e6>] ieee80211_unregister_hw+0x56/0x110 [<ffffffffa0011ac4>] ath10k_mac_unregister+0x14/0x60 [ath10k_core] [<ffffffffa0014fe7>] ath10k_core_unregister+0x27/0x40 [ath10k_core] [<ffffffffa003b1f4>] ath10k_pci_remove+0x44/0xa0 [ath10k_pci] [<ffffffff81373138>] pci_device_remove+0x28/0x60 [<ffffffff814cb534>] __device_release_driver+0x64/0xd0 [<ffffffff814cbcc8>] driver_detach+0xb8/0xc0 [<ffffffff814cb23a>] bus_remove_driver+0x4a/0xb0 [<ffffffff814cc697>] driver_unregister+0x27/0x50 Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * mac80211: Replace rcu_dereference() with rcu_access_pointer()Andreea-Cristina Bernat2014-08-271-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The "rcu_dereference()" calls are used directly in conditions. Since their return values are never dereferenced it is recommended to use "rcu_access_pointer()" instead of "rcu_dereference()". Therefore, this patch makes the replacements. The following Coccinelle semantic patch was used: @@ @@ ( if( (<+... - rcu_dereference + rcu_access_pointer (...) ...+>)) {...} | while( (<+... - rcu_dereference + rcu_access_pointer (...) ...+>)) {...} ) Signed-off-by: Andreea-Cristina Bernat <bernat.ada@gmail.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * mac80211: scan: Replace rcu_assign_pointer() with RCU_INIT_POINTER()Andreea-Cristina Bernat2014-08-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The use of "rcu_assign_pointer()" is NULLing out the pointer. According to RCU_INIT_POINTER()'s block comment: "1. This use of RCU_INIT_POINTER() is NULLing out the pointer" it is better to use it instead of rcu_assign_pointer() because it has a smaller overhead. The following Coccinelle semantic patch was used: @@ @@ - rcu_assign_pointer + RCU_INIT_POINTER (..., NULL) Signed-off-by: Andreea-Cristina Bernat <bernat.ada@gmail.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * cfg80211: allow passing frame type to cfg80211_inform_bss()Johannes Berg2014-08-261-2/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | When using the cfg80211_inform_bss[_width]() functions drivers cannot currently indicate whether the data was received in a beacon or probe response. Fix that by passing a new enum that indicates such (or unknown). For good measure, use it in ath6kl. Acked-by: Kalle Valo <kvalo@qca.qualcomm.com> [ath6kl] Acked-by: Arend van Spriel <arend@broadcom.com> [brcmfmac] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * cfg80211: clarify BSS probe response vs. beacon dataJohannes Berg2014-08-262-6/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are a few possible cases of where BSS data came from: 1) only a beacon has been received 2) only a probe response has been received 3) the driver didn't report what it received (this happens when using cfg80211_inform_bss[_width]()) 4) both probe response and beacon data has been received Unfortunately, in the userspace API, a few things weren't there: a) there was no way to differentiate cases 1) and 4) above without comparing the data of the IEs b) the TSF was always from the last frame, instead of being exposed for beacon/probe response separately like IEs Fix this by i) exporting a new flag attribute that indicates whether or not probe response data has been received - this addresses (a) ii) exporting a BEACON_TSF attribute that holds the beacon's TSF if a beacon has been received iii) not exporting the beacon attributes in case (3) above as that would just lead userspace into thinking the data actually came from a beacon when that isn't clear To implement this, track inside the IEs struct whether or not it (definitely) came from a beacon. Reported-by: William Seto Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * cfg80211: re-enable CSA for drivers that support itMichal Kazior2014-08-261-6/+0
| | | | | | | | | | | | | | | | | | | | | | This reverts commit dda444d52496aa8ddc501561bca580f1374a96a9. Channel switching code has been reworked and improved significantly since the time original locking issues were found. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * mac80211: don't resize skbs needlesslyIdo Yariv2014-08-261-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Header-less cloned skbs with sufficient headroom need not be cloned unless the tailroom is going to be modified. Fix ieee80211_skb_resize so it would only resize cloned skbs if either the header isn't released or the tailroom is going to be modified. Some drivers might have assumed that skbs are never cloned, so add a HW flag that explicitly permits cloned TX skbs. Drivers which do not modify TX skbs should set this flag to avoid copying skbs. Signed-off-by: Ido Yariv <idox.yariv@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * mac80211: Fix accounting of the tailroom-needed counterIdo Yariv2014-08-261-9/+3
| | | | | | | | | | | | | | | | | | | | When hw acceleration is enabled, the GENERATE_IV or PUT_IV_SPACE flags will only require headroom space. Consequently, the tailroom-needed counter can safely be decremented. Signed-off-by: Ido Yariv <idox.yariv@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * cfg80211: remove @gfp parameter from cfg80211_rx_mgmt()Vladimir Kondratiev2014-08-262-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | In the cfg80211_rx_mgmt(), parameter @gfp was used for the memory allocation. But, memory get allocated under spin_lock_bh(), this implies atomic context. So, one can't use GFP_KERNEL, only variants with no __GFP_WAIT. Actually, in all occurrences GFP_ATOMIC is used (wil6210 use GFP_KERNEL by mistake), and it should be this way or warning triggered in the memory allocation code. Remove @gfp parameter as no actual choice exist, and use hard coded GFP_ATOMIC for memory allocation. Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * mac80211: make ieee80211_vif_use_reserved_switch staticJohannes Berg2014-08-262-95/+93
| | | | | | | | | | | | | | Reorder some code to make ieee80211_vif_use_reserved_switch() static, no other changes. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * mac80211: mesh_plink: use get_unaligned_le16 instead of memcpyBob Copeland2014-08-261-7/+3
| | | | | | | | | | | | | | Use get_unaligned_le16 to access llid/plid. Signed-off-by: Bob Copeland <me@bobcopeland.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * mac80211: disable 40MHz support in case of 20MHz APEliad Peller2014-08-151-8/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | If the AP only advertises support for 20MHz (in the ht operation ie), disable 40MHz and VHT. This can improve interoperability with APs that don't like stations exceeding their own advertised capabilities. Signed-off-by: Eliad Peller <eliadx.peller@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * mac80211: don't duplicate station QoS capability dataJohannes Berg2014-08-1510-28/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | We currently track the QoS capability twice: for all peer stations in the WLAN_STA_WME flag, and for any clients associated to an AP interface separately for drivers in the sta->sta.wme field. Remove the WLAN_STA_WME flag and track the capability only in the driver-visible field, getting rid of the limitation that the field is only valid in AP mode. Reviewed-by: Arik Nemtsov <arik@wizery.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | wireless: core: Reorder wiphy_register() notifications relevantlyTomasz Bursztyka2014-08-251-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | Currently it can send regulatory domain change notification before any NEW_WIPHY notification. Moreover, if rfill_register() fails, calling wiphy_unregister() will send a DEL_WIPHY though no NEW_WIPHY had been sent previously. Thus reordering so it properly notifies NEW_WIPHY before any other. Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | Merge branch 'for-upstream' of ↵John W. Linville2014-08-2512-548/+766
|\ \ | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next
| * | Bluetooth: Fix ERTM L2CAP resend packetLukasz Rymanowski2014-08-141-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I-Frame which is going to be resend already has FCS field added and set (if it was required). Adding additional FCS field calculated from data + old FCS in resend function is incorrect. This patch fix that. Issue has been found during PTS testing. Signed-off-by: Lukasz Rymanowski <lukasz.rymanowski@tieto.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| * | Bluetooth: Improve data packing in SAR modeLukasz Rymanowski2014-08-141-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is no need to decrease pdu size with L2CAP SDU lenght in Start L2CAP SDU frame. Start packtet is just 2 bytes longer as specified and we can keep payload as long as possible. When testing SAR L2CAP against PTS, L2CAP channel is usually configured in that way, that SDU = MPS * 3. PTS expets then 3 I-Frames from IUT: Start, Continuation and End frame. Without this fix, we sent 4 I-Frames. We could pass a test by using -b option in l2test and send just two bytes less than SDU length. With this patch no need to use -b option. Signed-off-by: Lukasz Rymanowski <lukasz.rymanowski@tieto.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| * | mac802154: common tx error pathVarka Bhadram2014-08-141-7/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | This patch introduce the common error path on failure of Tx by inserting the label 'err_tx'. Signed-off-by: Varka Bhadram <varkab@cdac.in> Signed-off-by: Alexander Aring <alex.aring@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| * | ieee802154: 6lowpan: remove unused functionAlexander Aring2014-08-141-8/+0
| | | | | | | | | | | | | | | Signed-off-by: Alexander Aring <alex.aring@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| * | mac802154: common error pathVarka Bhadram2014-08-141-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | By introducing label fail, making the common error path for mac802154_llsec_decrypt() and packet type default case. Signed-off-by: Varka Bhadram <varkab@cdac.in> Signed-off-by: Alexander Aring <alex.aring@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| * | mac802154: cleanup in rx pathVarka Bhadram2014-08-141-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | This patch replace the sizeof(struct rx_work) with sizeof(*work) and directly passing the skb in mac802154_subif_rx() Signed-off-by: Varka Bhadram <varkab@cdac.in> Signed-off-by: Alexander Aring <alex.aring@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| * | Bluetooth: Make smp_chan_destroy() private to smp.cJohan Hedberg2014-08-142-52/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | There are no external users of smp_chan_destroy() so make it private to smp.c. The patch also moves the function higher up in the c-file in order to avoid forward declarations. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| * | Bluetooth: Always call smp_distribute_keys() from a workqueueJohan Hedberg2014-08-141-16/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The smp_distribute_keys() function calls smp_notify_keys() which in turn calls l2cap_conn_update_id_addr(). The l2cap_conn_update_id_addr() function will iterate through all L2CAP channels for the respective connection: lock the channel, update the address information and unlock the channel. Since SMP is now using l2cap_chan callbacks each callback is called with the channel lock held. Therefore, calling l2cap_conn_update_id_addr() would cause a deadlock calling l2cap_chan_lock() on the SMP channel. This patch moves calling smp_distribute_keys() through a workqueue so that it is never called from an L2CAP channel callback. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| * | Bluetooth: Move canceling security_timer into smp_chan_destroy()Johan Hedberg2014-08-141-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | All places needing to cancel the security timer also call smp_chan_destroy() in the same go. To eliminate the need to do these two calls in multiple places simply move the timer cancellation into smp_chan_destroy(). Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| * | Bluetooth: Remove unused l2cap_conn->security_timerJohan Hedberg2014-08-141-17/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now that there are no-longer any users for l2cap_conn->security_timer we can go ahead and simply remove it. The patch makes initialization of the conn->info_timer unconditional since it's better not to leave any l2cap_conn data structures uninitialized no matter what the underlying transport. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| * | Bluetooth: Add SMP-internal timeout callbackJohan Hedberg2014-08-141-9/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds an SMP-internal timeout callback to remove the depenency on (the soon to be removed) l2cap_conn->security_timer. The behavior is the same as with l2cap_conn->security_timer except that the new l2cap_conn_shutdown() public function is used instead of the L2CAP core internal l2cap_conn_del(). Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| * | Bluetooth: Fix double free of SMP data skbJohan Hedberg2014-08-141-7/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the case that the SMP recv callback returns error the calling code in l2cap_core.c expects that it still owns the skb and will try to free it. The SMP code should therefore not try to free the skb if it return an error. This patch fixes such behavior in the SMP command handler function. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| * | Bluetooth: Call l2cap_conn_shutdown() when SMP recv callback failsJohan Hedberg2014-08-141-1/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To restore pre-l2cap_chan functionality we should be trying to disconnect the connection when receviving garbage SMP data (i.e. when the SMP command handler fails). This patch renames the command handler back to smp_sig_channel() and adds a smp_recv_cb() wrapper function for calling it. If smp_sig_channel() fails the code calls l2cap_conn_shutdown(). Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| * | Bluetooth: Add public l2cap_conn_shutdown() API to request disconnectionJohan Hedberg2014-08-141-0/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since we no-longer do special handling of SMP within l2cap_core.c we don't have any code for calling l2cap_conn_del() when smp.c doesn't like the data it gets. At the same time we cannot simply export l2cap_conn_del() since it will try to lock the channels it calls into whereas we already hold the lock in the smp.c l2cap_chan callbacks (i.e. it'd lead to a deadlock). This patch adds a new l2cap_conn_shutdown() API which is very similar to l2cap_conn_del() except that it defers the call to l2cap_conn_del() through a workqueue, thereby making it safe to use it from an L2CAP channel callback. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| * | Bluetooth: Use L2CAP resume callback to call smp_distribute_keysJohan Hedberg2014-08-143-191/+196
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There's no need to export the smp_distribute_keys() function since the resume callback is called in the same scenario. This patch makes the smp_notify_keys function private (at the same time moving it higher up in smp.c to avoid forward declarations) and adds a resume callback for SMP to call it from there instead. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| * | Bluetooth: Convert SMP to use l2cap_chan infrastructureJohan Hedberg2014-08-143-67/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now that we have all the necessary pieces in place we can fully convert SMP to use the L2CAP channel infrastructure. This patch adds the necessary callbacks and removes the now unneeded conn->smp_chan pointer. One notable behavioral change in this patch comes from the following code snippet: - case L2CAP_CID_SMP: - if (smp_sig_channel(conn, skb)) - l2cap_conn_del(conn->hcon, EACCES); This piece of code was essentially forcing a disconnection if garbage SMP data was received. The l2cap_conn_del() function is private to l2cap_conn.c so we don't have access to it anymore when using the L2CAP channel callbacks. Therefore, the behavior of the new code is simply to return errors in the recv() callback (which is simply the old smp_sig_channel()), but no disconnection will occur. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| * | Bluetooth: Make AES crypto context private to SMPJohan Hedberg2014-08-143-27/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now that we have per-adapter SMP data thanks to the root SMP L2CAP channel we can take advantage of it and attach the AES crypto context (only used for SMP) to it. This means that the smp_irk_matches() and smp_generate_rpa() function can be converted to internally handle the AES context. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| * | Bluetooth: Add SMP L2CAP channel skeletonJohan Hedberg2014-08-141-1/+130
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch creates the initial SMP L2CAP channels and a skeleton for their callbacks. There is one per-adapter channel created upon adapter registration, and then one channel per-connection created through the new_connection callback. The channels are registered with the reserved CID 0x1f for now in order to not conflict with existing SMP functionality. Once everything is in place the value can be changed to what it should be, i.e. L2CAP_CID_SMP. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| * | Bluetooth: Move SMP (de)initialization to smp.cJohan Hedberg2014-08-143-30/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | As preparation for moving SMP to use l2cap_chan infrastructure we need to move the (de)initialization functions to smp.c (where they'll eventually need access to the local L2CAP channel callbacks). Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| * | Bluetooth: Move SMP initialization after HCI initJohan Hedberg2014-08-141-7/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | First of all, it's wasteful to initialize SMP if it's never going to be used (e.g. on non-LE controllers). Second of all, when we move to use l2cap_chan we need to know the real local address, meaning we must have completed at least part of the HCI init. This patch moves the SMP initialization to after the HCI init procedure and makes it depend on whether the controller actually supports LE. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| * | Bluetooth: Refactor SMP (de)initialization into separate functionsJohan Hedberg2014-08-141-12/+34
| | | | | | | | | | | | | | | | | | | | | | | | As preparation for converting SMP to use the l2cap_chan infrastructure refactor the (de)initialization into separate functions. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| * | Bluetooth: Fix IRK lookup when tfm_aes is not availableJohan Hedberg2014-08-141-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the AES crypto has not been initialized properly we should cleanly return from the hci_find_irk_by_rpa() function. Right now this will not happen in practice, but once (in subsequent patches) SMP init is moved to after the HCI init procedure it is possible that the pointer is NULL. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| * | Bluetooth: Fix hci_update_random_address() error return for no cryptoJohan Hedberg2014-08-141-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | If the AES crypto context is not available we cannot generate new RPAs. We should therefore cleanly return an error from the function responsible for updating the random address. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| * | Bluetooth: Fix using HCI_CONN_LE_SMP_PEND to check for SMP contextJohan Hedberg2014-08-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The code is consistently using the HCI_CONN_LE_SMP_PEND flag check for the existence of the SMP context, with the exception of this one place in smp_sig_channel(). This patch converts the place to use the flag just like all other instances. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| * | Bluetooth: Call l2cap_le_conn_ready after notifying channelsJohan Hedberg2014-08-141-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For most cases it makes no difference whether l2cap_le_conn_ready() is called before or after calling the channel ready() callbacks, however for upcoming SMP code we need this as the ready() callback initializes certain structures that a call to smp_conn_security() from l2cap_le_conn_ready() depends on. Therefore, move the call to l2cap_le_conn_ready() after iterating through and notifying channels. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| * | Bluetooth: Call L2CAP teardown callback before clearing chan->connJohan Hedberg2014-08-141-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | L2CAP channel implementations may want to still access the chan->conn pointer. This will particularly be the case for SMP that will want to clear a reference to the SMP channel in the l2cap_conn structure. The only user of the teardown callback so far is l2cap_sock.c and for the code there it makes no difference whether the callback is called before or after clearing the chan->conn pointer. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| * | Bluetooth: Move parts of fixed channel initialization to l2cap_add_scidJohan Hedberg2014-08-142-9/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The l2cap_add_scid function is used for registering a fixed L2CAP channel. Instead of having separate initialization of the channel type and outgoing MTU in l2cap_sock.c it's more intuitive to do these things in the l2cap_add_scid function itself (and thereby make the functionality available to other users besides l2cap_sock.c). Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| * | Bluetooth: Remove special ATT data channel handlingJohan Hedberg2014-08-141-79/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now that we've got the fixed channel infrastructure cleaned up in a generic way there's no longer a need to have a dedicated function for handling data on the ATT channel. Instead the generic l2cap_data_channel() handler will be able to do the exact same thing. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| * | Bluetooth: Improve fixed channel lookup based on link typeJohan Hedberg2014-08-141-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When notifying global fixed channels of new connections it doesn't make sense to consider channels meant for a different link type than the one available. This patch adds an extra parameter to the l2cap_global_fixed_chan() lookup function and ensures that only channels matching the current hci_conn type are looked up. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| * | Bluetooth: Move L2CAP fixed channel creation into l2cap_conn_cfmJohan Hedberg2014-08-141-44/+80
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In order to remove special handling of fixed L2CAP channels we need to start creating them in a single place instead of having per-channel exceptions. The most natural place is the l2cap_conn_cfm() function which is called whenever there is a new baseband link. The only really special case so far has been the ATT socket, so in order not to break the code in between this patch removes the ATT special handling at the same time as it adds the generic fixed channel handling from l2cap_le_conn_ready() into the hci_conn_cfm() function. As a related change the channel locking in l2cap_conn_ready() becomes simpler and we can thereby move the smp_conn_security() call into the l2cap_le_conn_ready() function. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| * | Bluetooth: Refactor l2cap_connect_cfmJohan Hedberg2014-08-141-5/+8
| | | | | | | | | | | | | | | | | | | | | | | | This patch is a simple refactoring of l2cap_connect_cfm to allow easier extension of the function. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| * | Bluetooth: Remove special handling of ATT in l2cap_security_cfm()Johan Hedberg2014-08-141-9/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With the update to sk->resume() and __l2cap_no_conn_pending() we no-longer need to have special handling of ATT channels in the l2cap_security_cfm() function. The chan->sec_level update when encryption has been enabled is safe to do for any kind of channel, and the loop takes later care of calling chan->ready() or chan->resume() if necessary. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| * | Bluetooth: Resume BT_CONNECTED state after LE security elevationJohan Hedberg2014-08-141-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The LE ATT socket uses a special trick where it temporarily sets BT_CONFIG state for the duration of a security level elevation. In order to not require special hacks for going back to BT_CONNECTED state in the l2cap_core.c code the most reasonable place to resume the state is the resume callback. This patch adds a new flag to track the pending security level change and ensures that the state is set back to BT_CONNECTED in the resume callback in case the flag is set. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
OpenPOWER on IntegriCloud