1. 30 Oct, 2017 1 commit
  2. 29 Oct, 2017 5 commits
    • Konrad Zapałowicz's avatar
      Bluetooth: increase timeout for le auto connections · 1f01d8be
      Konrad Zapałowicz authored
      This patch increases the connection timeout for LE connections that are
      triggered by the advertising report to 4 seconds.
      
      It has been observed that devices equipped with wifi+bt combo SoC fail
      to create a connection with BLE devices due to their coexistence issues.
      Increasing this timeout gives them enough time to complete the
      connection with success.
      Signed-off-by: default avatarKonrad Zapałowicz <konrad.zapalowicz@canonical.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      1f01d8be
    • Loic Poulain's avatar
      Bluetooth: hci_ath: Add ath_vendor_cmd helper · 13df5000
      Loic Poulain authored
      Introduce ath_vendor_cmd function which can be used to
      configure 'tags' and patch the firmware.
      
      ATH vendor command has the following format:
      | OPCODE (u8) | INDEX (LE16) | DLEN (U8) | DATA (U8 * DLEN) |
      
      BD address configuration tag is at index 0x0001.
      Signed-off-by: default avatarLoic Poulain <loic.poulain@linaro.org>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      13df5000
    • Jaganath Kanakkassery's avatar
      Bluetooth: Fix potential memory leak · f17d858e
      Jaganath Kanakkassery authored
      If command is added to req then it should be freed in case if
      hdev is down or HCI_ADVERTISING flag is set.
      
      This introduces a helper in hci_request to purge the cmd_q
      to make cmd_q internal to hci_request which is used to fix
      the leak.
      
      This also replace accessing of cmd_q in hci_conn with the
      new helper.
      Signed-off-by: default avatarJaganath Kanakkassery <jaganathx.kanakkassery@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      f17d858e
    • Bartosz Chronowski's avatar
      Bluetooth: btusb: Add new NFA344A entry. · 858ff38a
      Bartosz Chronowski authored
      This change allows proper low power mode entry in suspend.
      
      /sys/kernel/debug/usb/devices entry:
      T:  Bus=01 Lev=01 Prnt=01 Port=05 Cnt=03 Dev#=  3 Spd=12   MxCh= 0
      D:  Ver= 2.01 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
      P:  Vendor=0489 ProdID=e09f Rev= 0.01
      C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
      I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
      E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
      I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
      I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
      I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
      I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
      I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
      Signed-off-by: default avatarBartosz Chronowski <ext.bartosz.chronowski@tieto.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      858ff38a
    • Ronald Tschalär's avatar
      Bluetooth: hci_ldisc: Allow sleeping while proto locks are held. · 67d2f878
      Ronald Tschalär authored
      Commit dec2c928 ("Bluetooth: hci_ldisc:
      Use rwlocking to avoid closing proto races") introduced locks in
      hci_ldisc that are held while calling the proto functions. These locks
      are rwlock's, and hence do not allow sleeping while they are held.
      However, the proto functions that hci_bcm registers use mutexes and
      hence need to be able to sleep.
      
      In more detail: hci_uart_tty_receive() and hci_uart_dequeue() both
      acquire the rwlock, after which they call proto->recv() and
      proto->dequeue(), respectively. In the case of hci_bcm these point to
      bcm_recv() and bcm_dequeue(). The latter both acquire the
      bcm_device_lock, which is a mutex, so doing so results in a call to
      might_sleep(). But since we're holding a rwlock in hci_ldisc, that
      results in the following BUG (this for the dequeue case - a similar
      one for the receive case is omitted for brevity):
      
        BUG: sleeping function called from invalid context at kernel/locking/mutex.c
        in_atomic(): 1, irqs_disabled(): 0, pid: 7303, name: kworker/7:3
        INFO: lockdep is turned off.
        CPU: 7 PID: 7303 Comm: kworker/7:3 Tainted: G        W  OE   4.13.2+ #17
        Hardware name: Apple Inc. MacBookPro13,3/Mac-A5C67F76ED83108C, BIOS MBP133.8
        Workqueue: events hci_uart_write_work [hci_uart]
        Call Trace:
         dump_stack+0x8e/0xd6
         ___might_sleep+0x164/0x250
         __might_sleep+0x4a/0x80
         __mutex_lock+0x59/0xa00
         ? lock_acquire+0xa3/0x1f0
         ? lock_acquire+0xa3/0x1f0
         ? hci_uart_write_work+0xd3/0x160 [hci_uart]
         mutex_lock_nested+0x1b/0x20
         ? mutex_lock_nested+0x1b/0x20
         bcm_dequeue+0x21/0xc0 [hci_uart]
         hci_uart_write_work+0xe6/0x160 [hci_uart]
         process_one_work+0x253/0x6a0
         worker_thread+0x4d/0x3b0
         kthread+0x133/0x150
      
      We can't replace the mutex in hci_bcm, because there are other calls
      there that might sleep. Therefore this replaces the rwlock's in
      hci_ldisc with rw_semaphore's (which allow sleeping). This is a safer
      approach anyway as it reduces the restrictions on the proto callbacks.
      Also, because acquiring write-lock is very rare compared to acquiring
      the read-lock, the percpu variant of rw_semaphore is used.
      
      Lastly, because hci_uart_tx_wakeup() may be called from an IRQ context,
      we can't block (sleep) while trying acquire the read lock there, so we
      use the trylock variant.
      Signed-off-by: default avatarRonald Tschalär <ronald@innovation.ch>
      Reviewed-by: default avatarLukas Wunner <lukas@wunner.de>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      67d2f878
  3. 14 Oct, 2017 4 commits
  4. 11 Oct, 2017 2 commits
  5. 10 Oct, 2017 3 commits
    • Ian W MORRISON's avatar
      Bluetooth: btbcm: Add support for MINIX Z83-4 based devices · 18a39b9a
      Ian W MORRISON authored
      The MINIX NEO Z83-4 and MINIX NEO Z83-4 Pro devices use an AP6255 chip
      for wifi and bluetooth. Bluetooth requires an ACPI device id of BCM2EA4
      with BCM4345 rev C0 firmware.
      
      This patch defines the firmware subversion.
      Signed-off-by: default avatarIan W MORRISON <ianwmorrison@gmail.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      18a39b9a
    • Ian W MORRISON's avatar
      Bluetooth: hci_bcm: Add support for MINIX Z83-4 based devices · 1bdb68b2
      Ian W MORRISON authored
      The MINIX NEO Z83-4 and MINIX NEO Z83-4 Pro devices use an AP6255 chip for
      wifi and bluetooth. Bluetooth requires an ACPI device id of BCM2EA4 with
      BCM4345 rev C0 firmware.
      
      This patch adds the device id and to use trigger type IRQF_TRIGGER_FALLING
      as defined by 'GpioInt' in the ACPI DSDT table:
      
          Device (BLT0)
          {
              Name (_HID, "BCM2EA4")  // _HID: Hardware ID
              Method (_STA, 0, NotSerialized)  // _STA: Status
              {
                  Return (0x0F)
              }
      
              Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
              {
                  Name (UBUF, ResourceTemplate ()
                  {
                      UartSerialBusV2 (0x0001C200, DataBitsEight, StopBitsOne,
                          0xFC, LittleEndian, ParityTypeNone, FlowControlHardware,
                          0x0020, 0x0020, "\\_SB.PCI0.URT1",
                          0x00, ResourceConsumer, , Exclusive,
                          )
                      GpioInt (Level, ActiveLow, Exclusive, PullNone, 0x0000,
                          "\\_SB.GPO1", 0x00, ResourceConsumer, ,
                          )
                          {   // Pin list
                              0x0005
                          }
                      GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
                          "\\_SB.GPO1", 0x00, ResourceConsumer, ,
                          )
                          {   // Pin list
                              0x0007
                          }
                      GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
                          "\\_SB.GPO1", 0x00, ResourceConsumer, ,
                          )
                          {   // Pin list
                              0x0004
                          }
                  })
                  Return (UBUF) /* \_SB_.PCI0.URT1.BLT0._CRS.UBUF */
              }
          }
      Signed-off-by: default avatarIan W MORRISON <ianwmorrison@gmail.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      1bdb68b2
    • Johan Hovold's avatar
      Bluetooth: avoid silent hci_bcm ACPI PM regression · 4294625e
      Johan Hovold authored
      The hci_bcm platform-device hack which was used to implement
      power management for ACPI devices is being replaced by a
      serial-device-bus implementation.
      
      Unfortunately, when the corresponding change to the ACPI code lands (a
      change that will stop enumerating and registering the serial-device-node
      child as a platform device) PM will break silently unless serdev
      TTY-port controller support has been enabled. Specifically, hciattach
      (btattach) would still succeed, but power management would no longer
      work.
      
      Although this is strictly a runtime dependency, let's make the driver
      depend on SERIAL_DEV_CTRL_TTYPORT, which is the particular serdev
      controller implementation used by the ACPI devices currently managed by
      this driver, to avoid breaking PM without anyone noticing.
      
      Note that the driver already has a (build-time) dependency on the serdev
      bus code.
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      4294625e
  6. 09 Oct, 2017 1 commit
  7. 06 Oct, 2017 24 commits