summaryrefslogtreecommitdiff
path: root/net/bluetooth
AgeCommit message (Collapse)Author
2011-07-27net: Audit drivers to identify those needing IFF_TX_SKB_SHARING clearedNeil Horman
After the last patch, We are left in a state in which only drivers calling ether_setup have IFF_TX_SKB_SHARING set (we assume that drivers touching real hardware call ether_setup for their net_devices and don't hold any state in their skbs. There are a handful of drivers that violate this assumption of course, and need to be fixed up. This patch identifies those drivers, and marks them as not being able to support the safe transmission of skbs by clearning the IFF_TX_SKB_SHARING flag in priv_flags Signed-off-by: Neil Horman <nhorman@tuxdriver.com> CC: Karsten Keil <isdn@linux-pingi.de> CC: "David S. Miller" <davem@davemloft.net> CC: Jay Vosburgh <fubar@us.ibm.com> CC: Andy Gospodarek <andy@greyhouse.net> CC: Patrick McHardy <kaber@trash.net> CC: Krzysztof Halasa <khc@pm.waw.pl> CC: "John W. Linville" <linville@tuxdriver.com> CC: Greg Kroah-Hartman <gregkh@suse.de> CC: Marcel Holtmann <marcel@holtmann.org> CC: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: David S. Miller <davem@davemloft.net>
2011-07-21Merge branch 'master' of ↵David S. Miller
master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6 Conflicts: net/bluetooth/l2cap_core.c
2011-07-16Bluetooth: Fix crash with incoming L2CAP connectionsIlia Kolomisnky
Another regression fix considering incomming l2cap connections with defer_setup enabled. In situations when incomming connection is extracted with l2cap_sock_accept, it's bt_sock info will have 'parent' member zerroed, but 'parent' may be used unconditionally in l2cap_conn_start() and l2cap_security_cfm() when defer_setup is enabled. Backtrace: [<bf02d5ac>] (l2cap_security_cfm+0x0/0x2ac [bluetooth]) from [<bf01f01c>] (hci_event_pac ket+0xc2c/0x4aa4 [bluetooth]) [<bf01e3f0>] (hci_event_packet+0x0/0x4aa4 [bluetooth]) from [<bf01a844>] (hci_rx_task+0x cc/0x27c [bluetooth]) [<bf01a778>] (hci_rx_task+0x0/0x27c [bluetooth]) from [<c008eee4>] (tasklet_action+0xa0/ 0x15c) [<c008ee44>] (tasklet_action+0x0/0x15c) from [<c008f38c>] (__do_softirq+0x98/0x130) r7:00000101 r6:00000018 r5:00000001 r4:efc46000 [<c008f2f4>] (__do_softirq+0x0/0x130) from [<c008f524>] (do_softirq+0x4c/0x58) [<c008f4d8>] (do_softirq+0x0/0x58) from [<c008f5e0>] (run_ksoftirqd+0xb0/0x1b4) r4:efc46000 r3:00000001 [<c008f530>] (run_ksoftirqd+0x0/0x1b4) from [<c009f2a8>] (kthread+0x84/0x8c) r7:00000000 r6:c008f530 r5:efc47fc4 r4:efc41f08 [<c009f224>] (kthread+0x0/0x8c) from [<c008cc84>] (do_exit+0x0/0x5f0) Signed-off-by: Ilia Kolomisnky <iliak@ti.com> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi> Signed-off-by: David S. Miller <davem@davemloft.net>
2011-07-16Bluetooth: Fix regression in L2CAP connection procedureGustavo F. Padovan
Caused by the following commit, partially revert it. commit 9fa7e4f76f3658ba1f44fbdb95c77e7df3f53f95 Author: Gustavo F. Padovan <padovan@profusion.mobi> Date: Thu Jun 30 16:11:30 2011 -0300 Bluetooth: Fix regression with incoming L2CAP connections PTS test A2DP/SRC/SRC_SET/TC_SRC_SET_BV_02_I revealed that ( probably after the df3c3931e commit ) the l2cap connection could not be established in case when the "Auth Complete" HCI event does not arive before the initiator send "Configuration request", in which case l2cap replies with "Command rejected" since the channel is still in BT_CONNECT2 state. Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi> Signed-off-by: David S. Miller <davem@davemloft.net>
2011-07-15Merge branch 'master' of ↵John W. Linville
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6 into for-davem Conflicts: net/bluetooth/l2cap_core.c
2011-07-14Merge branch 'master' of ↵David S. Miller
master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6 Conflicts: net/bluetooth/l2cap_core.c
2011-07-11Merge branch 'master' of ↵John W. Linville
master.kernel.org:/pub/scm/linux/kernel/git/padovan/bluetooth-next-2.6 Conflicts: net/bluetooth/l2cap_core.c
2011-07-11Merge branch 'master' of ↵John W. Linville
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6 Conflicts: drivers/net/wireless/ath/ath5k/sysfs.c net/bluetooth/l2cap_core.c net/mac80211/wpa.c
2011-07-11Bluetooth: Fixes l2cap "command reject" reply according to specIlia Kolomisnky
There can 3 reasons for the "command reject" reply produced by the stack. Each such reply should be accompanied by the relevand data ( as defined in spec. ). Currently there is one instance of "command reject" reply with reason "invalid cid" wich is fixed. Also, added clean-up definitions related to the "command reject" replies. Signed-off-by: Ilia Kolomisnky <iliak@ti.com> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-07-08Bluetooth: Add support for returning the encryption key sizeVinicius Costa Gomes
This will be useful when userspace wants to restrict some kinds of operations based on the length of the key size used to encrypt the link. Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-07-08Bluetooth: Add support for storing the key sizeVinicius Costa Gomes
In some cases it will be useful having the key size used for encrypting the link. For example, some profiles may restrict some operations depending on the key length. The key size is stored in the key that is passed to userspace using the pin_length field in the key structure. For now this field is only valid for LE controllers. 3.0+HS controllers define the Read Encryption Key Size command, this field is intended for storing the value returned by that command. Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-07-08Bluetooth: Add support for communicating keys with userspaceVinicius Costa Gomes
As the key format has changed to something that has a dynamic size, the way that keys are received and sent must be changed. The structure fields order is changed to make the parsing of the information received from the Management Interface easier. Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-07-08Bluetooth: Remove unused field in hci_connVinicius Costa Gomes
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-07-08Bluetooth: Use the stored LTK for restabilishing securityVinicius Costa Gomes
Now that it's possible that the exchanged key is present in the link key list, we may be able to estabilish security with an already existing key, without need to perform any SMP procedure. Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-07-08Bluetooth: Use the link key list to temporarily store the STKVinicius Costa Gomes
With this we can use only one place to store all keys, without need to use a field in the connection structure for this purpose. Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-07-08Bluetooth: Add support for storing the LTKVinicius Costa Gomes
Now when the LTK is received from the remote or generated it is stored, so it can later be used. Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-07-08Bluetooth: Fix SM pairing parameters negotiationVinicius Costa Gomes
Before implementing SM key distribution, the pairing features exchange must be better negotiated, taking into account some features of the host and connection requirements. If we are in the "not pairable" state, it makes no sense to exchange any key. This allows for simplification of the key negociation method. Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-07-08Bluetooth: Reject an encryption request when the key isn't foundVinicius Costa Gomes
Now that we have methods to finding keys by its parameters we can reject an encryption request if the key isn't found. Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-07-08Bluetooth: Add functions to manipulate the link key list for SMPVinicius Costa Gomes
As the LTK (the new type of key being handled now) has more data associated with it, we need to store this extra data and retrieve the keys based on that data. Methods for searching for a key and for adding a new LTK are introduced here. Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-07-08Bluetooth: Add support for SMP phase 3 (key distribution)Vinicius Costa Gomes
This adds support for generating and distributing all the keys specified in the third phase of SMP. This will make possible to re-establish secure connections, resolve private addresses and sign commands. For now, the values generated are random. Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-07-07Bluetooth: Remove L2CAP busy queueMat Martineau
The ERTM receive buffer is now handled in a way that does not require the busy queue and the associated polling code. Signed-off-by: Mat Martineau <mathewm@codeaurora.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-07-07Bluetooth: Use event-driven approach for handling ERTM receive bufferMat Martineau
This change moves most L2CAP ERTM receive buffer handling out of the L2CAP core and in to the socket code. It's up to the higher layer (the socket code, in this case) to tell the core when its buffer is full or has space available. The recv op should always accept incoming ERTM data or else the connection will go down. Within the socket layer, an skb that does not fit in the socket receive buffer will be temporarily stored. When the socket is read from, that skb will be placed in the receive buffer if possible. Once adequate buffer space becomes available, the L2CAP core is informed and the ERTM local busy state is cleared. Receive buffer management for non-ERTM modes is unchanged. Signed-off-by: Mat Martineau <mathewm@codeaurora.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-07-07Bluetooth: Move code for ERTM local busy state to separate functionsMat Martineau
The local busy state is entered and exited based on buffer status in the socket layer (or other upper layer). This change is in preparation for general buffer status reports from the socket layer, which will then be used to change the local busy status. Signed-off-by: Mat Martineau <mathewm@codeaurora.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-07-07Bluetooth: Fix potential deadlock in mgmtAndre Guedes
All threads running in process context should disable local bottom halve before locking hdev->lock. This patch fix the following message generated when Bluetooh module is loaded with enable_mgmt=y (CONFIG_PROVE_LOCKING enabled). [ 107.880781] ================================= [ 107.881631] [ INFO: inconsistent lock state ] [ 107.881631] 2.6.39+ #1 [ 107.881631] --------------------------------- [ 107.881631] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. [ 107.881631] rcuc0/7 [HC0[0]:SC1[3]:HE1:SE0] takes: [ 107.881631] (&(&hdev->lock)->rlock){+.?...}, at: [<ffffffffa0012c8d>] mgmt_set_local_name_complete+0x84/0x10b [bluetooth] [ 107.881631] {SOFTIRQ-ON-W} state was registered at: [ 107.881631] [<ffffffff8105188b>] __lock_acquire+0x347/0xd52 [ 107.881631] [<ffffffff810526ac>] lock_acquire+0x8a/0xa7 [ 107.881631] [<ffffffff812b3758>] _raw_spin_lock+0x2c/0x3b [ 107.881631] [<ffffffffa0011cc2>] mgmt_control+0xd4d/0x175b [bluetooth] [ 107.881631] [<ffffffffa0013275>] hci_sock_sendmsg+0x97/0x293 [bluetooth] [ 107.881631] [<ffffffff8121940c>] sock_aio_write+0x126/0x13a [ 107.881631] [<ffffffff810a35fa>] do_sync_write+0xba/0xfa [ 107.881631] [<ffffffff810a3beb>] vfs_write+0xaa/0xca [ 107.881631] [<ffffffff810a3d80>] sys_write+0x45/0x69 [ 107.881631] [<ffffffff812b4892>] system_call_fastpath+0x16/0x1b [ 107.881631] irq event stamp: 2100876 [ 107.881631] hardirqs last enabled at (2100876): [<ffffffff812b40d4>] restore_args+0x0/0x30 [ 107.881631] hardirqs last disabled at (2100875): [<ffffffff812b3f6a>] save_args+0x6a/0x70 [ 107.881631] softirqs last enabled at (2100862): [<ffffffff8106a805>] rcu_cpu_kthread+0x2b5/0x2e2 [ 107.881631] softirqs last disabled at (2100863): [<ffffffff812b56bc>] call_softirq+0x1c/0x26 [ 107.881631] [ 107.881631] other info that might help us debug this: [ 107.881631] Possible unsafe locking scenario: [ 107.881631] [ 107.881631] CPU0 [ 107.881631] ---- [ 107.881631] lock(&(&hdev->lock)->rlock); [ 107.881631] <Interrupt> [ 107.881631] lock(&(&hdev->lock)->rlock); [ 107.881631] [ 107.881631] *** DEADLOCK *** [ 107.881631] [ 107.881631] 1 lock held by rcuc0/7: [ 107.881631] #0: (hci_task_lock){++.-..}, at: [<ffffffffa0008353>] hci_rx_task+0x49/0x2f3 [bluetooth] [ 107.881631] [ 107.881631] stack backtrace: [ 107.881631] Pid: 7, comm: rcuc0 Not tainted 2.6.39+ #1 [ 107.881631] Call Trace: [ 107.881631] <IRQ> [<ffffffff812ae901>] print_usage_bug+0x1e7/0x1f8 [ 107.881631] [<ffffffff8100a796>] ? save_stack_trace+0x27/0x44 [ 107.881631] [<ffffffff8104fc3f>] ? print_irq_inversion_bug.part.26+0x19a/0x19a [ 107.881631] [<ffffffff810504bb>] mark_lock+0x106/0x258 [ 107.881631] [<ffffffff81051817>] __lock_acquire+0x2d3/0xd52 [ 107.881631] [<ffffffff8102be73>] ? vprintk+0x3ab/0x3d7 [ 107.881631] [<ffffffff810526ac>] lock_acquire+0x8a/0xa7 [ 107.881631] [<ffffffffa0012c8d>] ? mgmt_set_local_name_complete+0x84/0x10b [bluetooth] [ 107.881631] [<ffffffff81052615>] ? lock_release+0x16c/0x179 [ 107.881631] [<ffffffff812b3952>] _raw_spin_lock_bh+0x31/0x40 [ 107.881631] [<ffffffffa0012c8d>] ? mgmt_set_local_name_complete+0x84/0x10b [bluetooth] [ 107.881631] [<ffffffffa0012c8d>] mgmt_set_local_name_complete+0x84/0x10b [bluetooth] [ 107.881631] [<ffffffffa000d3fe>] hci_event_packet+0x122b/0x3e12 [bluetooth] [ 107.881631] [<ffffffff81050658>] ? mark_held_locks+0x4b/0x6d [ 107.881631] [<ffffffff812b3cff>] ? _raw_spin_unlock_irqrestore+0x40/0x4d [ 107.881631] [<ffffffff810507b9>] ? trace_hardirqs_on_caller+0x13f/0x172 [ 107.881631] [<ffffffff812b3d07>] ? _raw_spin_unlock_irqrestore+0x48/0x4d [ 107.881631] [<ffffffffa00083d2>] hci_rx_task+0xc8/0x2f3 [bluetooth] [ 107.881631] [<ffffffff8102f836>] ? __local_bh_enable+0x90/0xa4 [ 107.881631] [<ffffffff8102f5a9>] tasklet_action+0x87/0xe6 [ 107.881631] [<ffffffff8102fa11>] __do_softirq+0x9f/0x13f [ 107.881631] [<ffffffff812b56bc>] call_softirq+0x1c/0x26 [ 107.881631] <EOI> [<ffffffff810033b8>] ? do_softirq+0x46/0x9a [ 107.881631] [<ffffffff8106a805>] ? rcu_cpu_kthread+0x2b5/0x2e2 [ 107.881631] [<ffffffff8102f906>] _local_bh_enable_ip+0xac/0xc9 [ 107.881631] [<ffffffff8102f93b>] local_bh_enable+0xd/0xf [ 107.881631] [<ffffffff8106a805>] rcu_cpu_kthread+0x2b5/0x2e2 [ 107.881631] [<ffffffff81041586>] ? __init_waitqueue_head+0x46/0x46 [ 107.881631] [<ffffffff8106a550>] ? rcu_yield.constprop.42+0x98/0x98 [ 107.881631] [<ffffffff81040f0a>] kthread+0x7f/0x87 [ 107.881631] [<ffffffff812b55c4>] kernel_thread_helper+0x4/0x10 [ 107.881631] [<ffffffff812b40d4>] ? retint_restore_args+0x13/0x13 [ 107.881631] [<ffffffff81040e8b>] ? __init_kthread_worker+0x53/0x53 [ 107.881631] [<ffffffff812b55c0>] ? gs_change+0x13/0x13 Signed-off-by: Andre Guedes <andre.guedes@openbossa.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-07-07Bluetooth: Fix potential deadlock in hci_coreAndre Guedes
Since hdev->lock may be acquired by threads runnning in interrupt context, all threads running in process context should disable local bottom halve before locking hdev->lock. This can be done by using hci_dev_lock_bh macro. This way, we avoid potencial deadlocks like this one reported by CONFIG_PROVE_LOCKING=y. [ 304.788780] ================================= [ 304.789686] [ INFO: inconsistent lock state ] [ 304.789686] 2.6.39+ #1 [ 304.789686] --------------------------------- [ 304.789686] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. [ 304.789686] ksoftirqd/0/3 [HC0[0]:SC1[1]:HE1:SE0] takes: [ 304.789686] (&(&hdev->lock)->rlock){+.?...}, at: [<ffffffffa000bbfe>] hci_conn_check_pending+0x38/0x76 [bluetooth] [ 304.789686] {SOFTIRQ-ON-W} state was registered at: [ 304.789686] [<ffffffff8105188b>] __lock_acquire+0x347/0xd52 [ 304.789686] [<ffffffff810526ac>] lock_acquire+0x8a/0xa7 [ 304.789686] [<ffffffff812b3758>] _raw_spin_lock+0x2c/0x3b [ 304.789686] [<ffffffffa0009cf0>] hci_blacklist_del+0x1f/0x8a [bluetooth] [ 304.789686] [<ffffffffa00139fd>] hci_sock_ioctl+0x2d9/0x314 [bluetooth] [ 304.789686] [<ffffffff812197d8>] sock_ioctl+0x1f2/0x214 [ 304.789686] [<ffffffff810b0fd6>] do_vfs_ioctl+0x46c/0x4ad [ 304.789686] [<ffffffff810b1059>] sys_ioctl+0x42/0x65 [ 304.789686] [<ffffffff812b4892>] system_call_fastpath+0x16/0x1b [ 304.789686] irq event stamp: 9768 [ 304.789686] hardirqs last enabled at (9768): [<ffffffff812b40d4>] restore_args+0x0/0x30 [ 304.789686] hardirqs last disabled at (9767): [<ffffffff812b3f6a>] save_args+0x6a/0x70 [ 304.789686] softirqs last enabled at (9726): [<ffffffff8102fa9b>] __do_softirq+0x129/0x13f [ 304.789686] softirqs last disabled at (9739): [<ffffffff8102fb33>] run_ksoftirqd+0x82/0x133 [ 304.789686] [ 304.789686] other info that might help us debug this: [ 304.789686] Possible unsafe locking scenario: [ 304.789686] [ 304.789686] CPU0 [ 304.789686] ---- [ 304.789686] lock(&(&hdev->lock)->rlock); [ 304.789686] <Interrupt> [ 304.789686] lock(&(&hdev->lock)->rlock); [ 304.789686] [ 304.789686] *** DEADLOCK *** [ 304.789686] [ 304.789686] 1 lock held by ksoftirqd/0/3: [ 304.789686] #0: (hci_task_lock){++.-..}, at: [<ffffffffa0008353>] hci_rx_task+0x49/0x2f3 [bluetooth] [ 304.789686] [ 304.789686] stack backtrace: [ 304.789686] Pid: 3, comm: ksoftirqd/0 Not tainted 2.6.39+ #1 [ 304.789686] Call Trace: [ 304.789686] [<ffffffff812ae901>] print_usage_bug+0x1e7/0x1f8 [ 304.789686] [<ffffffff8100a796>] ? save_stack_trace+0x27/0x44 [ 304.789686] [<ffffffff8104fc3f>] ? print_irq_inversion_bug.part.26+0x19a/0x19a [ 304.789686] [<ffffffff810504bb>] mark_lock+0x106/0x258 [ 304.789686] [<ffffffff812b40d4>] ? retint_restore_args+0x13/0x13 [ 304.789686] [<ffffffff81051817>] __lock_acquire+0x2d3/0xd52 [ 304.789686] [<ffffffff8102be73>] ? vprintk+0x3ab/0x3d7 [ 304.789686] [<ffffffff812ae126>] ? printk+0x3c/0x3e [ 304.789686] [<ffffffff810526ac>] lock_acquire+0x8a/0xa7 [ 304.789686] [<ffffffffa000bbfe>] ? hci_conn_check_pending+0x38/0x76 [bluetooth] [ 304.789686] [<ffffffff811601c6>] ? __dynamic_pr_debug+0x10c/0x11a [ 304.789686] [<ffffffff812b3758>] _raw_spin_lock+0x2c/0x3b [ 304.789686] [<ffffffffa000bbfe>] ? hci_conn_check_pending+0x38/0x76 [bluetooth] [ 304.789686] [<ffffffffa000bbfe>] hci_conn_check_pending+0x38/0x76 [bluetooth] [ 304.789686] [<ffffffffa000c561>] hci_event_packet+0x38e/0x3e12 [bluetooth] [ 304.789686] [<ffffffff81052615>] ? lock_release+0x16c/0x179 [ 304.789686] [<ffffffff812b3b41>] ? _raw_read_unlock+0x23/0x27 [ 304.789686] [<ffffffffa0013e7f>] ? hci_send_to_sock+0x179/0x188 [bluetooth] [ 304.789686] [<ffffffffa00083d2>] hci_rx_task+0xc8/0x2f3 [bluetooth] [ 304.789686] [<ffffffff8102f5a9>] tasklet_action+0x87/0xe6 [ 304.789686] [<ffffffff8102fa11>] __do_softirq+0x9f/0x13f [ 304.789686] [<ffffffff8102fb33>] run_ksoftirqd+0x82/0x133 [ 304.789686] [<ffffffff8102fab1>] ? __do_softirq+0x13f/0x13f [ 304.789686] [<ffffffff81040f0a>] kthread+0x7f/0x87 [ 304.789686] [<ffffffff812b55c4>] kernel_thread_helper+0x4/0x10 [ 304.789686] [<ffffffff812b40d4>] ? retint_restore_args+0x13/0x13 [ 304.789686] [<ffffffff81040e8b>] ? __init_kthread_worker+0x53/0x53 [ 304.789686] [<ffffffff812b55c0>] ? gs_change+0x13/0x13 Signed-off-by: Andre Guedes <andre.guedes@openbossa.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-07-06Bluetooth: Remove enable_smp parameterAndre Guedes
The enable_smp parameter is no longer needed. It can be replaced by checking lmp_host_le_capable. Signed-off-by: Andre Guedes <andre.guedes@openbossa.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-07-06Bluetooth: Add lmp_host_le_capable() macroAndre Guedes
Since we have the extended LMP features properly implemented, we should check the LMP_HOST_LE bit to know if the host supports LE. Signed-off-by: Andre Guedes <andre.guedes@openbossa.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-07-06Bluetooth: Add enable_le module parameterAndre Guedes
This patch adds a new module parameter to enable/disable host LE support. By default host LE support is disabled. Signed-off-by: Andre Guedes <andre.guedes@openbossa.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-07-06Bluetooth: Write LE Host Supported commandAndre Guedes
This patch adds a handler to Write LE Host Supported command complete events. Once this commands has completed successfully, we should read the extended LMP features and update the extfeatures field in hci_dev. Signed-off-by: Andre Guedes <andre.guedes@openbossa.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-07-06Bluetooth: Add extfeatures to struct hci_devAndre Guedes
This new field holds the extended LMP features value. Some LE mechanism such as discovery procedure needs to read the extended LMP features to work properly. Signed-off-by: Andre Guedes <andre.guedes@openbossa.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-07-01Bluetooth: Check earlier for L2CAP ERTM frames to dropMat Martineau
Even when the received tx_seq is expected, the frame still needs to be dropped if the TX window is exceeded or the receiver is in the local busy state. Signed-off-by: Mat Martineau <mathewm@codeaurora.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-07-01Bluetooth: Fix bad locking balanceGustavo F. Padovan
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-06-30Bluetooth: Add bt_printkJoe Perches
Add a local logging function to emit bluetooth specific messages. Using vsprintf extension %pV saves code/text space. Convert the current BT_INFO and BT_ERR macros to use bt_printk. Remove __func__ from BT_ERR macro (and the uses). Prefix "Bluetooth: " to BT_ERR Remove __func__ from BT_DBG as function can be prefixed when using dynamic_debug. With allyesconfig: text data bss dec hex filename 129956 8632 36096 174684 2aa5c drivers/bluetooth/built-in.o.new2 134402 8632 36064 179098 2bb9a drivers/bluetooth/built-in.o.old 14778 1012 3408 19198 4afe net/bluetooth/bnep/built-in.o.new2 15067 1012 3408 19487 4c1f net/bluetooth/bnep/built-in.o.old 346595 19163 86080 451838 6e4fe net/bluetooth/built-in.o.new2 353751 19163 86064 458978 700e2 net/bluetooth/built-in.o.old 18483 1172 4264 23919 5d6f net/bluetooth/cmtp/built-in.o.new2 18927 1172 4264 24363 5f2b net/bluetooth/cmtp/built-in.o.old 19237 1172 5152 25561 63d9 net/bluetooth/hidp/built-in.o.new2 19581 1172 5152 25905 6531 net/bluetooth/hidp/built-in.o.old 59461 3884 14464 77809 12ff1 net/bluetooth/rfcomm/built-in.o.new2 61206 3884 14464 79554 136c2 net/bluetooth/rfcomm/built-in.o.old with x86 defconfig (and just bluetooth): $ size net/bluetooth/built-in.o.defconfig.* text data bss dec hex filename 66358 933 100 67391 1073f net/bluetooth/built-in.o.defconfig.new 66643 933 100 67676 1085c net/bluetooth/built-in.o.defconfig.old Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-06-30Bluetooth: Rename function bt_err to bt_to_errnoJoe Perches
Make it easier to use more normal logging styles later. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-06-30Bluetooth: ERTM timeouts need to be converted to jiffiesMat Martineau
ERTM timeouts are defined in milliseconds, but need to be converted to jiffies when passed to mod_timer(). Signed-off-by: Mat Martineau <mathewm@codeaurora.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-06-30Bluetooth: Fix indentation whitespaceMat Martineau
Signed-off-by: Mat Martineau <mathewm@codeaurora.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-06-30Bluetooth: Fix memory leak under page timeoutsTomas Targownik
If the remote device is not present, the connections attemp fails and the struct hci_conn was not freed Signed-off-by: Tomas Targownik <ttargownik@geicp.com> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-06-30Bluetooth: Fix regression with incoming L2CAP connectionsGustavo F. Padovan
PTS test A2DP/SRC/SRC_SET/TC_SRC_SET_BV_02_I revealed that ( probably after the df3c3931e commit ) the l2cap connection could not be established in case when the "Auth Complete" HCI event does not arive before the initiator send "Configuration request", in which case l2cap replies with "Command rejected" since the channel is still in BT_CONNECT2 state. Based on patch from: Ilia Kolomisnky <iliak@ti.com> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-06-30Bluetooth: Fix hidp disconnect deadlocks and lost wakeupPeter Hurley
Partial revert of commit aabf6f89. When the hidp session thread was converted from kernel_thread to kthread, the atomic/wakeups were replaced with kthread_stop. kthread_stop has blocking semantics which are inappropriate for the hidp session kthread. In addition, the kthread signals itself to terminate in hidp_process_hid_control() - it cannot do this with kthread_stop(). Lastly, a wakeup can be lost if the wakeup happens between checking for the loop exit condition and setting the current state to TASK_INTERRUPTIBLE. (Without appropriate synchronization mechanisms, the task state should not be changed between the condition test and the yield - via schedule() - as this creates a race between the wakeup and resetting the state back to interruptible.) Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-06-30Merge branch 'master' of ↵John W. Linville
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6 into for-davem
2011-06-28Bluetooth: Prevent buffer overflow in l2cap config requestDan Rosenberg
A remote user can provide a small value for the command size field in the command header of an l2cap configuration request, resulting in an integer underflow when subtracting the size of the configuration request header. This results in copying a very large amount of data via memcpy() and destroying the kernel heap. Check for underflow. Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com> Cc: stable <stable@kernel.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-06-27bluetooth: uses crypto interfaces, select CRYPTORandy Dunlap
Recent changes to hci_core.c use crypto interfaces, so select CRYPTO to make sure that those interfaces are present. Fixes these build errors when CRYPTO is not enabled: net/built-in.o: In function `hci_register_dev': (.text+0x4cf86): undefined reference to `crypto_alloc_base' net/built-in.o: In function `hci_unregister_dev': (.text+0x4f912): undefined reference to `crypto_destroy_tfm' Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-06-27Bluetooth: uses crypto interfaces, select CRYPTORandy Dunlap
Recent changes to hci_core.c use crypto interfaces, so select CRYPTO to make sure that those interfaces are present. Fixes these build errors when CRYPTO is not enabled: net/built-in.o: In function `hci_register_dev': (.text+0x4cf86): undefined reference to `crypto_alloc_base' net/built-in.o: In function `hci_unregister_dev': (.text+0x4f912): undefined reference to `crypto_destroy_tfm' Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-06-24Merge branch 'master' of ↵John W. Linville
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6 into for-davem Conflicts: drivers/net/wireless/rtlwifi/pci.c include/linux/netlink.h
2011-06-24Bluetooth: include scatterlist.h where neededStephen Rothwell
net/bluetooth/smp.c: In function 'smp_e': net/bluetooth/smp.c:49:21: error: storage size of 'sg' isn't known net/bluetooth/smp.c:67:2: error: implicit declaration of function 'sg_init_one' net/bluetooth/smp.c:49:21: warning: unused variable 'sg' Caused by commit d22ef0bc83c5 ("Bluetooth: Add LE SMP Cryptoolbox functions"). Missing include file, presumably. This batch has been in the bluetooth tree since June 14, so it may have been exposed by the removal of linux/mm.h from netdevice.h ... Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-06-21Bluetooth: Fix not setting the chan stateVinicius Costa Gomes
When the connection is ready we should set the connection to CONNECTED so userspace can use it. Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-06-21Merge master.kernel.org:/pub/scm/linux/kernel/git/padovan/bluetooth-2.6Gustavo F. Padovan
Conflicts: net/bluetooth/l2cap_core.c
2011-06-20Merge branch 'master' of ↵David S. Miller
master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6 Conflicts: drivers/net/wireless/iwlwifi/iwl-agn-rxon.c drivers/net/wireless/rtlwifi/pci.c net/netfilter/ipvs/ip_vs_core.c
2011-06-20Bluetooth: Remove useless access to the socketVinicius Costa Gomes
We already have access to the chan, we don't have to access the socket to get its imtu. Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-06-20Bluetooth: Fix crash when setting a LE socket to readyVinicius Costa Gomes
We should not try to do any other type of configuration for LE links when they become ready. Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
generated by cgit v1.2.3 (git 2.25.1) at 2024-10-30 07:31:28 +0000