1. 03 Dec, 2012 8 commits
    • Andrei Emeltchenko's avatar
      Bluetooth: AMP: Check that AMP is present and active · 5d05416e
      Andrei Emeltchenko authored
      Before starting quering remote AMP controllers make sure
      that there is local active AMP controller.
      Signed-off-by: default avatarAndrei Emeltchenko <andrei.emeltchenko@intel.com>
      Signed-off-by: default avatarGustavo Padovan <gustavo.padovan@collabora.co.uk>
      5d05416e
    • Andrei Emeltchenko's avatar
      Bluetooth: AMP: Mark controller radio powered down after HCIDEVDOWN · ced5c338
      Andrei Emeltchenko authored
      After getting HCIDEVDOWN controller did not mark itself as 0x00 which
      means: "The Controller radio is available but is currently physically
      powered down". The result was even if the hdev was down we return
      in controller list value 0x01 "status 0x01 (Bluetooth only)".
      Signed-off-by: default avatarAndrei Emeltchenko <andrei.emeltchenko@intel.com>
      Signed-off-by: default avatarGustavo Padovan <gustavo.padovan@collabora.co.uk>
      ced5c338
    • Andrei Emeltchenko's avatar
      Bluetooth: Refactor l2cap_send_disconn_req · 5e4e3972
      Andrei Emeltchenko authored
      l2cap_send_disconn_req takes 3 parameters of which conn might be
      derived from chan. Make this conversion inside l2cap_send_disconn_req.
      Signed-off-by: default avatarAndrei Emeltchenko <andrei.emeltchenko@intel.com>
      Signed-off-by: default avatarGustavo Padovan <gustavo.padovan@collabora.co.uk>
      5e4e3972
    • Gustavo Padovan's avatar
      Bluetooth: Move double negation to macros · ffa88e02
      Gustavo Padovan authored
      Some comparisons needs to double negation(!!) in order to make the value
      of the field boolean. Add it to the macro makes the code more readable.
      Signed-off-by: default avatarGustavo Padovan <gustavo.padovan@collabora.co.uk>
      ffa88e02
    • Frédéric Dalleau's avatar
      Bluetooth: Implement deferred sco socket setup · 20714bfe
      Frédéric Dalleau authored
      In order to authenticate and configure an incoming SCO connection, the
      BT_DEFER_SETUP option was added. This option is intended to defer reply
      to Connect Request on SCO sockets.
      When a connection is requested, the listening socket is unblocked but
      the effective connection setup happens only on first recv. Any send
      between accept and recv fails with -ENOTCONN.
      Signed-off-by: default avatarFrédéric Dalleau <frederic.dalleau@linux.intel.com>
      Signed-off-by: default avatarGustavo Padovan <gustavo.padovan@collabora.co.uk>
      20714bfe
    • Frédéric Dalleau's avatar
      Bluetooth: Add BT_DEFER_SETUP option to sco socket · b96e9c67
      Frédéric Dalleau authored
      This option will set the BT_SK_DEFER_SETUP bit in socket flags.
      Signed-off-by: default avatarFrédéric Dalleau <frederic.dalleau@linux.intel.com>
      Signed-off-by: default avatarGustavo Padovan <gustavo.padovan@collabora.co.uk>
      b96e9c67
    • Gustavo Padovan's avatar
      Bluetooth: cancel power_on work when unregistering the device · b9b5ef18
      Gustavo Padovan authored
      We need to cancel the hci_power_on work in order to avoid it run when we
      try to free the hdev.
      
      [ 1434.201149] ------------[ cut here ]------------
      [ 1434.204998] WARNING: at lib/debugobjects.c:261 debug_print_object+0x8e/0xb0()
      [ 1434.208324] ODEBUG: free active (active state 0) object type: work_struct hint: hci
      _power_on+0x0/0x90
      [ 1434.210386] Pid: 8564, comm: trinity-child25 Tainted: G        W    3.7.0-rc5-next-
      20121112-sasha-00018-g2f4ce0e #127
      [ 1434.210760] Call Trace:
      [ 1434.210760]  [<ffffffff819f3d6e>] ? debug_print_object+0x8e/0xb0
      [ 1434.210760]  [<ffffffff8110b887>] warn_slowpath_common+0x87/0xb0
      [ 1434.210760]  [<ffffffff8110b911>] warn_slowpath_fmt+0x41/0x50
      [ 1434.210760]  [<ffffffff819f3d6e>] debug_print_object+0x8e/0xb0
      [ 1434.210760]  [<ffffffff8376b750>] ? hci_dev_open+0x310/0x310
      [ 1434.210760]  [<ffffffff83bf94e5>] ? _raw_spin_unlock_irqrestore+0x55/0xa0
      [ 1434.210760]  [<ffffffff819f3ee5>] __debug_check_no_obj_freed+0xa5/0x230
      [ 1434.210760]  [<ffffffff83785db0>] ? bt_host_release+0x10/0x20
      [ 1434.210760]  [<ffffffff819f4d15>] debug_check_no_obj_freed+0x15/0x20
      [ 1434.210760]  [<ffffffff8125eee7>] kfree+0x227/0x330
      [ 1434.210760]  [<ffffffff83785db0>] bt_host_release+0x10/0x20
      [ 1434.210760]  [<ffffffff81e539e5>] device_release+0x65/0xc0
      [ 1434.210760]  [<ffffffff819d3975>] kobject_cleanup+0x145/0x190
      [ 1434.210760]  [<ffffffff819d39cd>] kobject_release+0xd/0x10
      [ 1434.210760]  [<ffffffff819d33cc>] kobject_put+0x4c/0x60
      [ 1434.210760]  [<ffffffff81e548b2>] put_device+0x12/0x20
      [ 1434.210760]  [<ffffffff8376a334>] hci_free_dev+0x24/0x30
      [ 1434.210760]  [<ffffffff82fd8fe1>] vhci_release+0x31/0x60
      [ 1434.210760]  [<ffffffff8127be12>] __fput+0x122/0x250
      [ 1434.210760]  [<ffffffff811cab0d>] ? rcu_user_exit+0x9d/0xd0
      [ 1434.210760]  [<ffffffff8127bf49>] ____fput+0x9/0x10
      [ 1434.210760]  [<ffffffff81133402>] task_work_run+0xb2/0xf0
      [ 1434.210760]  [<ffffffff8106cfa7>] do_notify_resume+0x77/0xa0
      [ 1434.210760]  [<ffffffff83bfb0ea>] int_signal+0x12/0x17
      [ 1434.210760] ---[ end trace a6d57fefbc8a8cc7 ]---
      
      Cc: stable@vger.kernel.org
      Reported-by: default avatarSasha Levin <sasha.levin@oracle.com>
      Signed-off-by: default avatarGustavo Padovan <gustavo.padovan@collabora.co.uk>
      b9b5ef18
    • Gustavo Padovan's avatar
      Bluetooth: Add missing lock nesting notation · dc2a0e20
      Gustavo Padovan authored
      This patch fixes the following report, it happens when accepting rfcomm
      connections:
      
      [  228.165378] =============================================
      [  228.165378] [ INFO: possible recursive locking detected ]
      [  228.165378] 3.7.0-rc1-00536-gc1d5dc4a #120 Tainted: G        W
      [  228.165378] ---------------------------------------------
      [  228.165378] bluetoothd/1341 is trying to acquire lock:
      [  228.165378]  (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+...}, at:
      [<ffffffffa0000aa0>] bt_accept_dequeue+0xa0/0x180 [bluetooth]
      [  228.165378]
      [  228.165378] but task is already holding lock:
      [  228.165378]  (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+...}, at:
      [<ffffffffa0205118>] rfcomm_sock_accept+0x58/0x2d0 [rfcomm]
      [  228.165378]
      [  228.165378] other info that might help us debug this:
      [  228.165378]  Possible unsafe locking scenario:
      [  228.165378]
      [  228.165378]        CPU0
      [  228.165378]        ----
      [  228.165378]   lock(sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM);
      [  228.165378]   lock(sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM);
      [  228.165378]
      [  228.165378]  *** DEADLOCK ***
      [  228.165378]
      [  228.165378]  May be due to missing lock nesting notation
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGustavo Padovan <gustavo.padovan@collabora.co.uk>
      dc2a0e20
  2. 20 Nov, 2012 5 commits
  3. 19 Nov, 2012 10 commits
  4. 16 Nov, 2012 17 commits