1. 08 2月, 2011 11 次提交
  2. 20 1月, 2011 1 次提交
  3. 23 12月, 2010 2 次提交
  4. 08 12月, 2010 2 次提交
  5. 02 12月, 2010 1 次提交
  6. 24 9月, 2010 1 次提交
  7. 01 8月, 2010 1 次提交
  8. 28 7月, 2010 1 次提交
    • M
      Bluetooth: Defer SCO setup if mode change is pending · e73439d8
      Marcel Holtmann 提交于
      Certain headsets such as the Motorola H350 will reject SCO and eSCO
      connection requests while the ACL is transitioning from sniff mode
      to active mode. Add synchronization so that SCO and eSCO connection
      requests will wait until the ACL has fully transitioned to active mode.
      
      < HCI Command: Exit Sniff Mode (0x02|0x0004) plen 2
          handle 12
      > HCI Event: Command Status (0x0f) plen 4
          Exit Sniff Mode (0x02|0x0004) status 0x00 ncmd 1
      < HCI Command:  Setup Synchronous Connection (0x01|0x0028) plen 17
          handle 12 voice setting 0x0040
      > HCI Event: Command Status (0x0f) plen 4
          Setup Synchronous Connection (0x01|0x0028) status 0x00 ncmd 1
      > HCI Event: Number of Completed Packets (0x13) plen 5
          handle 12 packets 1
      > HCI Event: Mode Change (0x14) plen 6
          status 0x00 handle 12 mode 0x00 interval 0
          Mode: Active
      > HCI Event: Synchronous Connect Complete (0x2c) plen 17
          status 0x10 handle 14 bdaddr 00:1A:0E:50:28:A4 type SCO
          Error: Connection Accept Timeout Exceeded
      Signed-off-by: NRon Shaffer <rshaffer@codeaurora.org>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      e73439d8
  9. 22 7月, 2010 5 次提交
  10. 10 5月, 2010 3 次提交
  11. 27 2月, 2010 3 次提交
  12. 04 12月, 2009 2 次提交
  13. 23 8月, 2009 2 次提交
    • T
      Bluetooth: Convert hdev->req_lock to a mutex · a6a67efd
      Thomas Gleixner 提交于
      hdev->req_lock is used as mutex so make it a mutex.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      a6a67efd
    • M
      Bluetooth: Add extra device reference counting for connections · 9eba32b8
      Marcel Holtmann 提交于
      The device model itself has no real usable reference counting at the
      moment and this causes problems if parents are deleted before their
      children. The device model itself handles the memory details of this
      correctly, but the uevent order is not consistent. This causes various
      problems for systems like HAL or even X.
      
      So until device_put() does a proper cleanup, the device for Bluetooth
      connection will be protected with an extra reference counting to ensure
      the correct order of uevents when connections are terminated.
      
      This is not an automatic feature. Higher Bluetooth layers like HIDP or
      BNEP should grab this new reference to ensure that their uevents are
      send before the ones from the parent device.
      
      Based on a report by Brian Rogers <brian@xyzw.org>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      9eba32b8
  14. 08 6月, 2009 1 次提交
  15. 05 5月, 2009 1 次提交
    • M
      Bluetooth: Fix issue with sysfs handling for connections · a67e899c
      Marcel Holtmann 提交于
      Due to a semantic changes in flush_workqueue() the current approach of
      synchronizing the sysfs handling for connections doesn't work anymore. The
      whole approach is actually fully broken and based on assumptions that are
      no longer valid.
      
      With the introduction of Simple Pairing support, the creation of low-level
      ACL links got changed. This change invalidates the reason why in the past
      two independent work queues have been used for adding/removing sysfs
      devices. The adding of the actual sysfs device is now postponed until the
      host controller successfully assigns an unique handle to that link. So
      the real synchronization happens inside the controller and not the host.
      
      The only left-over problem is that some internals of the sysfs device
      handling are not initialized ahead of time. This leaves potential access
      to invalid data and can cause various NULL pointer dereferences. To fix
      this a new function makes sure that all sysfs details are initialized
      when an connection attempt is made. The actual sysfs device is only
      registered when the connection has been successfully established. To
      avoid a race condition with the registration, the check if a device is
      registered has been moved into the removal work.
      
      As an extra protection two flush_work() calls are left in place to
      make sure a previous add/del work has been completed first.
      
      Based on a report by Marc Pignat <marc.pignat@hevs.ch>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Tested-by: NJustin P. Mattock <justinmattock@gmail.com>
      Tested-by: NRoger Quadros <ext-roger.quadros@nokia.com>
      Tested-by: NMarc Pignat <marc.pignat@hevs.ch>
      a67e899c
  16. 29 4月, 2009 2 次提交
    • M
      Bluetooth: Add different pairing timeout for Legacy Pairing · 052b30b0
      Marcel Holtmann 提交于
      The Bluetooth stack uses a reference counting for all established ACL
      links and if no user (L2CAP connection) is present, the link will be
      terminated to save power. The problem part is the dedicated pairing
      when using Legacy Pairing (Bluetooth 2.0 and before). At that point
      no user is present and pairing attempts will be disconnected within
      10 seconds or less. In previous kernel version this was not a problem
      since the disconnect timeout wasn't triggered on incoming connections
      for the first time. However this caused issues with broken host stacks
      that kept the connections around after dedicated pairing. When the
      support for Simple Pairing got added, the link establishment procedure
      needed to be changed and now causes issues when using Legacy Pairing
      
      When using Simple Pairing it is possible to do a proper reference
      counting of ACL link users. With Legacy Pairing this is not possible
      since the specification is unclear in some areas and too many broken
      Bluetooth devices have already been deployed. So instead of trying to
      deal with all the broken devices, a special pairing timeout will be
      introduced that increases the timeout to 60 seconds when pairing is
      triggered.
      
      If a broken devices now puts the stack into an unforeseen state, the
      worst that happens is the disconnect timeout triggers after 120 seconds
      instead of 4 seconds. This allows successful pairings with legacy and
      broken devices now.
      
      Based on a report by Johan Hedberg <johan.hedberg@nokia.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      052b30b0
    • R
      Bluetooth: Ensure that HCI sysfs add/del is preempt safe · f3784d83
      Roger Quadros 提交于
      Use a different work_struct variables for add_conn() and del_conn() and
      use single work queue instead of two for adding and deleting connections.
      
      It eliminates the following error on a preemptible kernel:
      
      [  204.358032] Unable to handle kernel NULL pointer dereference at virtual address 0000000c
      [  204.370697] pgd = c0004000
      [  204.373443] [0000000c] *pgd=00000000
      [  204.378601] Internal error: Oops: 17 [#1] PREEMPT
      [  204.383361] Modules linked in: vfat fat rfcomm sco l2cap sd_mod scsi_mod iphb pvr2d drm omaplfb ps
      [  204.438537] CPU: 0    Not tainted  (2.6.28-maemo2 #1)
      [  204.443664] PC is at klist_put+0x2c/0xb4
      [  204.447601] LR is at klist_put+0x18/0xb4
      [  204.451568] pc : [<c0270f08>]    lr : [<c0270ef4>]    psr: a0000113
      [  204.451568] sp : cf1b3f10  ip : cf1b3f10  fp : cf1b3f2c
      [  204.463104] r10: 00000000  r9 : 00000000  r8 : bf08029c
      [  204.468353] r7 : c7869200  r6 : cfbe2690  r5 : c78692c8  r4 : 00000001
      [  204.474945] r3 : 00000001  r2 : cf1b2000  r1 : 00000001  r0 : 00000000
      [  204.481506] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM Segment kernel
      [  204.488861] Control: 10c5387d  Table: 887fc018  DAC: 00000017
      [  204.494628] Process btdelconn (pid: 515, stack limit = 0xcf1b22e0)
      Signed-off-by: NRoger Quadros <ext-roger.quadros@nokia.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      f3784d83
  17. 27 2月, 2009 1 次提交
    • M
      Bluetooth: Ask upper layers for HCI disconnect reason · 2950f21a
      Marcel Holtmann 提交于
      Some of the qualification tests demand that in case of failures in L2CAP
      the HCI disconnect should indicate a reason why L2CAP fails. This is a
      bluntly layer violation since multiple L2CAP connections could be using
      the same ACL and thus forcing a disconnect reason is not a good idea.
      
      To comply with the Bluetooth test specification, the disconnect reason
      is now stored in the L2CAP connection structure and every time a new
      L2CAP channel is added it will set back to its default. So only in the
      case where the L2CAP channel with the disconnect reason is really the
      last one, it will propagated to the HCI layer.
      
      The HCI layer has been extended with a disconnect indication that allows
      it to ask upper layers for a disconnect reason. The upper layer must not
      support this callback and in that case it will nicely default to the
      existing behavior. If an upper layer like L2CAP can provide a disconnect
      reason that one will be used to disconnect the ACL or SCO link.
      
      No modification to the ACL disconnect timeout have been made. So in case
      of Linux to Linux connection the initiator will disconnect the ACL link
      before the acceptor side can signal the specific disconnect reason. That
      is perfectly fine since Linux doesn't make use of this value anyway. The
      L2CAP layer has a perfect valid error code for rejecting connection due
      to a security violation. It is unclear why the Bluetooth specification
      insists on having specific HCI disconnect reason.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      2950f21a