1. 04 Dec, 2013 17 commits
    • Tedd Ho-Jeong An's avatar
      Bluetooth: Enable autosuspend for Intel Bluetooth device · d2bee8fb
      Tedd Ho-Jeong An authored
      This patch enables autosuspend for Intel Bluetooth device.
      
      After btusb is loaded for Intel Bluetooth device, the power/control
      attribute contains "on" value by default which disables the autosuspend.
      Based on the USB PM document(Documentation/usb/power-management.txt),
      kernel disabled the autosuspend for all devices other than hub by default.
      
      "The USB specification states that all USB devices must support power
      management.  Nevertheless, the sad fact is that many devices do not
      support it very well.  You can suspend them all right, but when you
      try to resume them they disconnect themselves from the USB bus or
      they stop working entirely.  This seems to be especially prevalent
      among printers and scanners, but plenty of other types of device have
      the same deficiency.
      
      For this reason, by default the kernel disables autosuspend (the
      power/control attribute is initialized to "on") for all devices other
      than hubs.  Hubs, at least, appear to be reasonably well-behaved in
      this regard."
      
      This document also described how the driver can enables the autosuspend
      by using an USB api.
      
      "Drivers can enable autosuspend for their devices by calling
      
      	usb_enable_autosuspend(struct usb_device *udev);
      
      in their probe() routine, if they know that the device is capable of
      suspending and resuming correctly.  This is exactly equivalent to
      writing "auto" to the device's power/control attribute."
      
      For Intel Bluetooth device, the autosuspend needs to be enabled so the
      device can transit to LPM(Low Power Mode) and ULPM(Ultra LPM) states after
      receiving suspend message from the host.
      Signed-off-by: default avatarTedd Ho-Jeong An <tedd.an@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      d2bee8fb
    • Tedd Ho-Jeong An's avatar
      Bluetooth: Add support for Intel Bluetooth device [8087:0a2a] · ef4e5e4a
      Tedd Ho-Jeong An authored
      This patch adds support for new Intel Bluetooth device.
      
      T:  Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  4 Spd=12   MxCh= 0
      D:  Ver= 2.01 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
      P:  Vendor=8087 ProdID=0a2a 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=  64 Ivl=1ms
      E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      E:  Ad=82(I) 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=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
      E:  Ad=83(I) 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=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
      E:  Ad=83(I) 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=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
      E:  Ad=83(I) 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=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
      E:  Ad=83(I) 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=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
      E:  Ad=83(I) 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=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
      Signed-off-by: default avatarTedd Ho-Jeong An <tedd.an@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      ef4e5e4a
    • Andre Guedes's avatar
      Bluetooth: Refactor hci_disconn_complete_evt · 3846220b
      Andre Guedes authored
      hci_disconn_complete_evt() logic is more complicated than what it
      should be, making it hard to follow and add new features.
      
      So this patch does some code refactoring by handling the error cases
      in the beginning of the function and by moving the main flow into the
      first level of function scope. No change is done in the event handling
      logic itself.
      
      Besides organizing this messy code, this patch makes easier to add
      code for handling LE auto connection (which will be added in a further
      patch).
      Signed-off-by: default avatarAndre Guedes <andre.guedes@openbossa.org>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      3846220b
    • Andre Guedes's avatar
      Bluetooth: Remove unneeded check in hci_disconn_complete_evt() · abf54a50
      Andre Guedes authored
      According to b644ba33 (patch that introduced HCI_CONN_MGMT_CONNECTED
      flag), the HCI_CONN_MGMT_CONNECTED flag tracks when mgmt has been
      notified about the connection.
      
      That being said, there is no point in calling mgmt_disconnect_failed()
      conditionally based on this flag. mgmt_disconnect_failed() removes
      pending MGMT_OP_DISCONNECT commands, it doesn't matter if that
      connection was notified or not.
      
      Moreover, if the Disconnection Complete event has status then we have
      nothing else to do but call mgmt_disconnect_failed() and return.
      Signed-off-by: default avatarAndre Guedes <andre.guedes@openbossa.org>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      abf54a50
    • Sujith Manoharan's avatar
      Bluetooth: ath3k: Add support for a new AR3012 device · 35580d22
      Sujith Manoharan authored
      T:  Bus=02 Lev=01 Prnt=01 Port=04 Cnt=01 Dev#=  9 Spd=12   MxCh= 0
      D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
      P:  Vendor=0489 ProdID=e05f Rev= 0.02
      C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
      A:  FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01
      I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      Reported-by: default avatarJoshua Richenhagen <richenhagen@gmail.com>
      Signed-off-by: default avatarSujith Manoharan <sujith@msujith.org>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      35580d22
    • Sujith Manoharan's avatar
      Bluetooth: ath3k: Add support for another AR3012 card · bd0fca1b
      Sujith Manoharan authored
      T:  Bus=03 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#=  2 Spd=12   MxCh= 0
      D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
      P:  Vendor=04ca ProdID=300b Rev= 0.01
      C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
      A:  FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01
      I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      Reported-by: default avatarFace <falazemi@gmail.com>
      Signed-off-by: default avatarSujith Manoharan <sujith@msujith.org>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      bd0fca1b
    • Johan Hedberg's avatar
      Bluetooth: Remove unnecessary 'send' parameter from smp_failure() · 84794e11
      Johan Hedberg authored
      The send parameter has only been used for determining whether to send a
      Pairing Failed PDU or not. However, the function can equally well use
      the already existing reason parameter to make this choice and send the
      PDU whenever a non-zero value was passed.
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      84794e11
    • Andre Guedes's avatar
      Bluetooth: Remove link type check in hci_disconn_complete_evt() · 4ebbd535
      Andre Guedes authored
      We can safely remove the link type check from hci_disconn_complete_
      evt() since this check in not required for mgmt_disconnect_failed()
      and mgmt_device_disconnected() does it internally.
      Signed-off-by: default avatarAndre Guedes <andre.guedes@openbossa.org>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      4ebbd535
    • Andre Guedes's avatar
      Bluetooth: Add an extra check in mgmt_device_disconnected() · 57eb776f
      Andre Guedes authored
      This patch adds an extra check in mgmt_device_disconnected() so we only
      send the "Device Disconnected" event if it is ACL_LINK or LE_LINK link
      type.
      Signed-off-by: default avatarAndre Guedes <andre.guedes@openbossa.org>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      57eb776f
    • Andre Guedes's avatar
      Bluetooth: Check address in mgmt_disconnect_failed() · 3655bba8
      Andre Guedes authored
      Check the address and address type in mgmt_disconnect_failed() otherwise
      we may wrongly fail the MGMT_OP_DISCONNECT command.
      Signed-off-by: default avatarAndre Guedes <andre.guedes@openbossa.org>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      3655bba8
    • Bing Zhao's avatar
      Bluetooth: btmrvl: remove cal-data byte swapping and redundant mem copy · 8a4934f1
      Bing Zhao authored
      The device tree property can define the cal-data in proper order.
      There is no need to swap the bytes in driver.
      Also remove the redundant cal-data memory copy after removing the
      byte swapping.
      
      Cc: Mike Frysinger <vapier@chromium.org>
      Cc: Amitkumar Karwar <akarwar@marvell.com>
      Signed-off-by: default avatarBing Zhao <bzhao@marvell.com>
      Signed-off-by: default avatarHyuckjoo Lee <hyuckjoo.lee@samsung.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      8a4934f1
    • Bing Zhao's avatar
      Bluetooth: btmrvl: use cal-data from device-tree instead of conf file · 433a9389
      Bing Zhao authored
      Some ARM versions of Chromebook need to download a new calibration
      data from host driver to firmware. They do have EEPROM but still
      need a piece of new calibration data in test mode.
      
      The cal-data is platform dependent. It's simpler and more feasible
      to use device tree based cal-data instead of configuration file
      based cal-data.
      
      This patch remove configuration file based cal-data downloading
      and replace it using cal-data from device tree.
      
      When CONFIG_OF is not selected, or the specific property is not
      present in the device tree, the calibration downloading will not
      happen.
      
      Cc: Mike Frysinger <vapier@chromium.org>
      Cc: Amitkumar Karwar <akarwar@marvell.com>
      Signed-off-by: default avatarBing Zhao <bzhao@marvell.com>
      Signed-off-by: default avatarHyuckjoo Lee <hyuckjoo.lee@samsung.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      433a9389
    • Bing Zhao's avatar
      Bluetooth: btmrvl: operate on 16-bit opcodes instead of ogf/ocf · 3e4543ab
      Bing Zhao authored
      Replace ogf/ocf and its packing with 16-bit opcodes.
      Signed-off-by: default avatarBing Zhao <bzhao@marvell.com>
      Signed-off-by: default avatarAmitkumar Karwar <akarwar@marvell.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      3e4543ab
    • Marcel Holtmann's avatar
      Bluetooth: Store supported commands only during setup procedure · 6a070e6e
      Marcel Holtmann authored
      The list of supported commands of a controller can not change during
      its lifetime. So store the list just once during the setup procedure
      and not every time the HCI command is executed.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      6a070e6e
    • Marcel Holtmann's avatar
      Bluetooth: Remove debug statement for features complete event · d3d5dd3e
      Marcel Holtmann authored
      The complete list of local features are available through debugfs and
      so there is no need to add a debug print here.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      d3d5dd3e
    • Marcel Holtmann's avatar
      Bluetooth: Set default own address type only during controller setup · bef34c0a
      Marcel Holtmann authored
      The default own address type is currently set at every power on of
      a controller. This overwrites the value set via debugfs. To avoid
      this issue, set the default own address type only during controller
      setup.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      bef34c0a
    • Marcel Holtmann's avatar
      Bluetooth: Fix limited discoverable mode for Zeevo modules · 33337dcb
      Marcel Holtmann authored
      There is an old Panasonic module with a Zeevo chip in there that is
      not really operating according to Bluetooth core specification when
      it comes to setting the IAC LAP for limited discoverable mode.
      
      For reference, this is the vendor information about this module:
      
        < HCI Command: Read Local Version Information (0x04|0x0001) plen 0
        > HCI Event: Command Complete (0x0e) plen 12
              Read Local Version Information (0x04|0x0001) ncmd 1
                Status: Success (0x00)
                HCI version: Bluetooth 1.2 (0x02) - Revision 196 (0x00c4)
                LMP version: Bluetooth 1.2 (0x02) - Subversion 61 (0x003d)
                Manufacturer: Zeevo, Inc. (18)
      
      The module reports only the support for one IAC at a time. And that
      is totally acceptable according to the Bluetooth core specification
      since the minimum supported IAC is only one.
      
        < HCI Command: Read Number of Supported IAC (0x03|0x0038) plen 0
        > HCI Event: Command Complete (0x0e) plen 5
              Read Number of Supported IAC (0x03|0x0038) ncmd 1
                Status: Success (0x00)
                Number of IAC: 1
      
      The problem arises when trying to program two IAC into the module
      on a controller that only supports one.
      
        < HCI Command: Write Current IAC LAP (0x03|0x003a) plen 7
                Number of IAC: 2
                Access code: 0x9e8b00 (Limited Inquiry)
                Access code: 0x9e8b33 (General Inquiry)
        > HCI Event: Command Status (0x0f) plen 4
              Write Current IAC LAP (0x03|0x003a) ncmd 1
                Status: Unknown HCI Command (0x01)
      
      While this looks strange, but according to the Bluetooth core
      specification it is a legal operation. The controller has to
      ignore the other values and only program as many as it supports.
      
        This command shall clear any existing IACs and stores Num_Current_IAC
        and the IAC_LAPs in to the controller. If Num_Current_IAC is greater
        than Num_Support_IAC then only the first Num_Support_IAC shall be
        stored in the controller, and a Command Complete event with error
        code Success (0x00) shall be generated.
      
      This specific controller has a bug here and just returns an error. So
      in case the number of supported IAC is less than two and the limited
      discoverable mode is requested, now only the LIAC is written to
      the controller.
      
        < HCI Command: Write Current IAC LAP (0x03|0x003a) plen 4
                Number of IAC: 1
                Access code: 0x9e8b00 (Limited Inquiry)
        > HCI Event: Command Complete (0x0e) plen 4
              Write Current IAC LAP (0x03|0x003a) ncmd 1
                Status: Success (0x00)
      
      All other controllers that only support one IAC seem to handle this
      perfectly fine, but this fix will only write the LIAC for these
      controllers as well.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      33337dcb
  2. 02 Dec, 2013 23 commits