1. 09 1月, 2018 2 次提交
    • A
      Bluetooth: hciuart: add nvmem dependency · b71b25fe
      Arnd Bergmann 提交于
      When the hci support is built-in, but mvmem is a loadable module, we
      get a link failure:
      
      drivers/bluetooth/hci_ll.o: In function `hci_ti_probe':
      hci_ll.c:(.text+0x226): undefined reference to `nvmem_cell_get'
      hci_ll.c:(.text+0x238): undefined reference to `nvmem_cell_read'
      hci_ll.c:(.text+0x244): undefined reference to `nvmem_cell_put'
      
      This adds another Kconfig dependency to enforce valid configurations.
      
      Fixes: 0e58d0cd ("Bluetooth: hci_ll: Add optional nvmem BD address source")
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      b71b25fe
    • A
      Bluetooth: btusb: Add support for 0cf3:e010 · e5a49ee9
      AceLan Kao 提交于
      Device 0cf3:e010 is one of the QCA ROME family.
      
      T:  Bus=01 Lev=01 Prnt=01 Port=13 Cnt=03 Dev#=  4 Spd=12  MxCh= 0
      D:  Ver= 2.01 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
      P:  Vendor=0cf3 ProdID=e010 Rev=00.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
      I:  If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      Signed-off-by: NAceLan Kao <acelan.kao@canonical.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      e5a49ee9
  2. 27 12月, 2017 4 次提交
    • K
      Revert "Bluetooth: btusb: fix QCA Rome suspend/resume" · 7d06d589
      Kai-Heng Feng 提交于
      This reverts commit fd865802.
      
      This commit causes a regression on some QCA ROME chips. The USB device
      reset happens in btusb_open(), hence firmware loading gets interrupted.
      
      Furthermore, this commit stops working after commit
      ("a0085f25 Bluetooth: btusb: driver to
      enable the usb-wakeup feature"). Reset-resume quirk only gets enabled in
      btusb_suspend() when it's not a wakeup source.
      
      If we really want to reset the USB device, we need to do it before
      btusb_open(). Let's handle it in drivers/usb/core/quirks.c.
      
      Cc: stable@vger.kernel.org
      Cc: Leif Liddy <leif.linux@gmail.com>
      Cc: Matthias Kaehlcke <mka@chromium.org>
      Cc: Brian Norris <briannorris@chromium.org>
      Cc: Daniel Drake <drake@endlessm.com>
      Signed-off-by: NKai-Heng Feng <kai.heng.feng@canonical.com>
      Reviewed-by: NBrian Norris <briannorris@chromium.org>
      Tested-by: NBrian Norris <briannorris@chromium.org>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      7d06d589
    • L
      Bluetooth: hci_bcm: Streamline runtime PM code · 43fff768
      Lukas Wunner 提交于
      This driver seeks to force the Bluetooth device on for the duration of
      5 seconds when the Bluetooth device has woken the host and after a
      complete packet has been received.  It does that by calling:
      
          pm_runtime_get();
          pm_runtime_mark_last_busy();
          pm_runtime_put_autosuspend();
      
      The same can be achieved more succinctly with:
      
          pm_request_resume();
      
      That's because after runtime resuming the device, rpm_resume() invokes
      pm_runtime_mark_last_busy() followed by rpm_idle(), which will cause
      the device to be suspended after expiration of the autosuspend_delay.
      
      No functional change intended.
      
      Cc: Frédéric Danis <frederic.danis.oss@gmail.com>
      Signed-off-by: NLukas Wunner <lukas@wunner.de>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      43fff768
    • L
      Bluetooth: Avoid WARN splat due to missing GPIOLIB · 27378f4c
      Lukas Wunner 提交于
      Loading hci_bcm with CONFIG_GPIOLIB=n results in the following splat
      when calling gpiod_to_irq() from bcm_get_resources():
      
          WARNING: CPU: 0 PID: 1006 at ./include/linux/gpio/consumer.h:450 bcm_get_resources+0x50/0x80
          CPU: 0 PID: 1006 Comm: kworker/u8:4 Tainted: G       A         4.15.0-rc4custom+ #4
          Hardware name: Apple Inc. MacBook8,1/Mac-BE0E8AC46FE800CC, BIOS MB81.88Z.0168.B00.1708080033 08/08/2017
          Call Trace:
          bcm_serdev_probe+0x8b/0xc0
          driver_probe_device+0x202/0x310
          __driver_attach+0x85/0x90
          ? driver_probe_device+0x310/0x310
          bus_for_each_dev+0x57/0x80
          async_run_entry_fn+0x2c/0xd0
          process_one_work+0x1d2/0x3d0
          worker_thread+0x26/0x3c0
          ? process_one_work+0x3d0/0x3d0
          kthread+0x10c/0x130
          ? kthread_create_on_node+0x40/0x40
          ret_from_fork+0x1f/0x30
      
      We could call gpiod_to_irq() only if IS_ENABLED(CONFIG_GPIOLIB) but
      without GPIOLIB, the driver's power saving features can't be used,
      so selecting GPIOLIB seems more appropriate.
      
      The same issue is present in hci_intel.c and hci_nokia.c, fix those up
      as well.
      Reported-by: NMax Shavrick <mxms@me.com>
      Signed-off-by: NLukas Wunner <lukas@wunner.de>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      27378f4c
    • I
      Bluetooth: Add a new 04ca:3015 QCA_ROME device · 0a03f98b
      Ioan Moldovan 提交于
      This patch adds the 04ca:3015 (from a QCA9377 board) Bluetooth device
      to the btusb blacklist and makes the kernel use the btqca module
      instead of btusb. The patch is necessary because, without it the
      04ca:3015 device defaults to using the btusb driver, which makes the
      WIFI side of the QCA9377 board unusable (obtains 0 MBps in speedtest,
      when the 04ca:3015 bluetooth is used with an audio headset).
      
      /sys/kernel/debug/usb/devices:
      
          T:  Bus=01 Lev=01 Prnt=01 Port=04 Cnt=01 Dev#=  2 Spd=12   MxCh= 0
          D:  Ver= 2.01 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
          P:  Vendor=04ca ProdID=3015 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: NIoan Moldovan <ioan.moldovan1999@gmail.com>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      0a03f98b
  3. 13 12月, 2017 15 次提交
    • J
      Bluetooth: Fix a possible sleep-in-atomic bug in bluecard_write_wakeup · 479f335c
      Jia-Ju Bai 提交于
      The driver may sleep in the interrupt handler.
      The function call path is:
      bluecard_interrupt (interrupt handler)
        bluecard_write_wakeup
          schedule_timeout --> may sleep
      
      To fix it, schedule_timeout is replaced with mdelay.
      
      This bug is found by my static analysis tool(DSAC) and checked by my code review.
      Signed-off-by: NJia-Ju Bai <baijiaju1990@gmail.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      479f335c
    • D
      Bluetooth: hci_ll: add "ti,cc2560" compatible string · 4166493c
      David Lechner 提交于
      This adds the "ti,cc2560" compatible string for a TI CC2560 chip.
      Signed-off-by: NDavid Lechner <david@lechnology.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      4166493c
    • D
      Bluetooth: hci_ll: Add optional nvmem BD address source · 0e58d0cd
      David Lechner 提交于
      This adds an optional nvmem consumer to get a BD address from an external
      source. The BD address is then set in the Bluetooth chip after the
      firmware has been loaded.
      
      This has been tested working with a TI CC2560A chip (in a LEGO MINDSTORMS
      EV3).
      Signed-off-by: NDavid Lechner <david@lechnology.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      0e58d0cd
    • D
      Bluetooth: hci_ll: add support for setting public address · aa099398
      David Lechner 提交于
      This adds support for setting the public address on Texas Instruments
      Bluetooth chips using a vendor-specific command.
      
      This has been tested on a CC2560A chip. The TI wiki also indicates that
      this command should work on TI WL17xx/WL18xx Bluetooth chips.
      
      During review, there was some question as to the correctness of the byte
      swapping since TI's documentation is not clear on this matter. This can
      be tested with the btmgmt utility from bluez. The adapter must be powered
      off to change the address. If the baswap() is omitted, address is reversed.
      
      In case there is a issue in the future, here is the output of btmon during
      the command `btmgmt public-addr 00:11:22:33:44:55`:
      
      Bluetooth monitor ver 5.43
      = Note: Linux version 4.15.0-rc2-08561-gcb132a1-dirty (armv5tejl)      0.707043
      = Note: Bluetooth subsystem version 2.22                               0.707091
      = New Index: 00:17:E7:BD:1C:8E (Primary,UART,hci0)              [hci0] 0.707106
      @ MGMT Open: btmgmt (privileged) version 1.14                 {0x0002} 0.707124
      @ MGMT Open: bluetoothd (privileged) version 1.14             {0x0001} 0.707137
      @ MGMT Open: btmon (privileged) version 1.14                  {0x0003} 0.707540
      @ MGMT Command: Set Public Address (0x0039) plen 6    {0x0002} [hci0] 11.167991
              Address: 00:11:22:33:44:55 (CIMSYS Inc)
      @ MGMT Event: Command Complete (0x0001) plen 7        {0x0002} [hci0] 11.175681
            Set Public Address (0x0039) plen 4
              Status: Success (0x00)
              Missing options: 0x00000000
      @ MGMT Event: Index Removed (0x0005) plen 0           {0x0003} [hci0] 11.175757
      @ MGMT Event: Index Removed (0x0005) plen 0           {0x0002} [hci0] 11.175757
      @ MGMT Event: Index Removed (0x0005) plen 0           {0x0001} [hci0] 11.175757
      = Open Index: 00:17:E7:BD:1C:8E                                [hci0] 11.176807
      < HCI Command: Vendor (0x3f|0x0006) plen 6                     [hci0] 11.176975
              00 11 22 33 44 55                                .."3DU
      > HCI Event: Command Complete (0x0e) plen 4                    [hci0] 11.188260
            Vendor (0x3f|0x0006) ncmd 1
              Status: Success (0x00)
      ...
      < HCI Command: Read Local Version Info.. (0x04|0x0001) plen 0  [hci0] 11.189859
      > HCI Event: Command Complete (0x0e) plen 12                   [hci0] 11.190732
            Read Local Version Information (0x04|0x0001) ncmd 1
              Status: Success (0x00)
              HCI version: Bluetooth 2.1 (0x04) - Revision 0 (0x0000)
              LMP version: Bluetooth 2.1 (0x04) - Subversion 6431 (0x191f)
              Manufacturer: Texas Instruments Inc. (13)
      < HCI Command: Read BD ADDR (0x04|0x0009) plen 0               [hci0] 11.191027
      > HCI Event: Command Complete (0x0e) plen 10                   [hci0] 11.192101
            Read BD ADDR (0x04|0x0009) ncmd 1
              Status: Success (0x00)
              Address: 00:11:22:33:44:55 (CIMSYS Inc)
      ...
      Signed-off-by: NDavid Lechner <david@lechnology.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      aa099398
    • D
      Bluetooth: hci_ll: Add endianness conversion when setting baudrate · c30b93ea
      David Lechner 提交于
      This adds an endianness conversion when setting the baudrate using a
      vendor-specific command. Otherwise, bad things might happen on a big-
      endian system.
      Suggested-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NDavid Lechner <david@lechnology.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      c30b93ea
    • D
      Bluetooth: hci_ll: add constant for vendor-specific command · 7c6ca120
      David Lechner 提交于
      This adds a #define for the vendor-specific HCI command to set the
      baudrate instead of using the bare 0xff36 multiple times.
      Signed-off-by: NDavid Lechner <david@lechnology.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      7c6ca120
    • D
      Bluetooth: serdev: hci_ll: Wait for CTS instead of using msleep · d54fdcf9
      David Lechner 提交于
      When a TI Bluetooth chip is reset, it takes about 100ms for the RTS line of
      the chip to deassert. For my use case with a TI CC2560A chip, this delay
      was not long enough and caused the local UART to never transmit at all (TI
      AM1808 SoC UART2).
      
      We can wait for the CTS signal using serdev_device_wait_for_cts() instead
      of trying to guess using msleep().
      
      Also changed the comment to be more informative while we are touching this
      code.
      Signed-off-by: NDavid Lechner <david@lechnology.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      d54fdcf9
    • D
      Bluetooth: hci_ll: remove \n from kernel messages · 059fb823
      David Lechner 提交于
      The bt_* printk macros include a \n already, so we don't need extra ones
      here.
      Signed-off-by: NDavid Lechner <david@lechnology.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      059fb823
    • H
      Bluetooth: btsdio: Do not bind to non-removable BCM43341 · b4cdaba2
      Hans de Goede 提交于
      BCM43341 devices soldered onto the PCB (non-removable) always (AFAICT)
      use an UART connection for bluetooth. But they also advertise btsdio
      support on their 3th sdio function, this causes 2 problems:
      
      1) A non functioning BT HCI getting registered
      
      2) Since the btsdio driver does not have suspend/resume callbacks,
      mmc_sdio_pre_suspend will return -ENOSYS, causing mmc_pm_notify()
      to react as if the SDIO-card is removed and since the slot is
      marked as non-removable it will never get detected as inserted again.
      Which results in wifi no longer working after a suspend/resume.
      
      This commit fixes both by making btsdio ignore BCM43341 devices
      when connected to a slot which is marked non-removable.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      b4cdaba2
    • H
      Bluetooth: hci_bcm: Add support for BCM2E72 · c23fae11
      Hans de Goede 提交于
      The Asus T100HA laptop uses an ACPI HID of BCM2E72 for the bluetooth
      part of the SDIO bcm43340 wifi/bt combo chip.
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      c23fae11
    • L
      Bluetooth: btqcomsmd: Fix skb double free corruption · 67b8fbea
      Loic Poulain 提交于
      In case of hci send frame failure, skb is still owned
      by the caller (hci_core) and then should not be freed.
      
      This fixes crash on dragonboard-410c when sending SCO
      packet. skb is freed by both btqcomsmd and hci_core.
      
      Fixes: 1511cc75 ("Bluetooth: Introduce Qualcomm WCNSS SMD based HCI driver")
      Signed-off-by: NLoic Poulain <loic.poulain@linaro.org>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      67b8fbea
    • L
      Bluetooth: hci_serdev: Init hci_uart proto_lock to avoid oops · d73e1728
      Lukas Wunner 提交于
      John Stultz reports a boot time crash with the HiKey board (which uses
      hci_serdev) occurring in hci_uart_tx_wakeup().  That function is
      contained in hci_ldisc.c, but also called from the newer hci_serdev.c.
      It acquires the proto_lock in struct hci_uart and it turns out that we
      forgot to init the lock in the serdev code path, thus causing the crash.
      
      John bisected the crash to commit 67d2f878 ("Bluetooth: hci_ldisc:
      Allow sleeping while proto locks are held"), but the issue was present
      before and the commit merely exposed it.  (Perhaps by luck, the crash
      did not occur with rwlocks.)
      
      Init the proto_lock in the serdev code path to avoid the oops.
      
      Stack trace for posterity:
      
      Unable to handle kernel read from unreadable memory at 406f127000
      [000000406f127000] user address but active_mm is swapper
      Internal error: Oops: 96000005 [#1] PREEMPT SMP
      Hardware name: HiKey Development Board (DT)
      Call trace:
       hci_uart_tx_wakeup+0x38/0x148
       hci_uart_send_frame+0x28/0x38
       hci_send_frame+0x64/0xc0
       hci_cmd_work+0x98/0x110
       process_one_work+0x134/0x330
       worker_thread+0x130/0x468
       kthread+0xf8/0x128
       ret_from_fork+0x10/0x18
      
      Link: https://lkml.org/lkml/2017/11/15/908Reported-and-tested-by: NJohn Stultz <john.stultz@linaro.org>
      Cc: Ronald Tschalär <ronald@innovation.ch>
      Cc: Rob Herring <rob.herring@linaro.org>
      Cc: Sumit Semwal <sumit.semwal@linaro.org>
      Signed-off-by: NLukas Wunner <lukas@wunner.de>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      d73e1728
    • H
      Bluetooth: btusb: Fix BT_HCIBTUSB_AUTOSUSPEND Kconfig option name · e7232d18
      Hans de Goede 提交于
      Fix: drivers/bluetooth/Kconfig:35:warning: multi-line strings not
      supported warning.
      Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      e7232d18
    • H
      Bluetooth: btusb: Add a Kconfig option to enable USB autosuspend by default · eff2d68c
      Hans de Goede 提交于
      On many laptops the btusb device is the only USB device not having USB
      autosuspend enabled, this causes not only the HCI but also the USB
      controller to stay awake, together using aprox. 0.4W of power.
      
      Modern ultrabooks idle around 6W (at 50% screen brightness), 3.5W for
      Apollo Lake devices. 0.4W is a significant chunk of this (7 / 11%).
      
      The btusb driver already contains code to allow enabling USB autosuspend,
      but currently leaves it up to the user / userspace to enable it. This
      means that for most people it will not be enabled, leading to an
      unnecessarily high power consumption.
      
      Since enabling it is not entirely without risk of regressions, this
      commit adds a Kconfig option so that Linux distributions can choose to
      enable it by default. This commit also adds a module option so that when
      distros receive bugs they can easily ask the user to disable it again
      for easy debugging.
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      eff2d68c
    • L
      Bluetooth: hci_qca: Avoid setup failure on missing rampatch · ba8f3597
      Loic Poulain 提交于
      Assuming that the original code idea was to enable in-band sleeping
      only if the setup_rome method returns succes and run in 'standard'
      mode otherwise, we should not return setup_rome return value which
      makes qca_setup fail if no rampatch/nvm file found.
      
      This fixes BT issue on the dragonboard-820C p4 which includes the
      following QCA controller:
      hci0: Product:0x00000008
      hci0: Patch  :0x00000111
      hci0: ROM    :0x00000302
      hci0: SOC    :0x00000044
      
      Since there is no rampatch for this controller revision, just make
      it work as is.
      Signed-off-by: NLoic Poulain <loic.poulain@linaro.org>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      ba8f3597
  4. 02 11月, 2017 1 次提交
    • G
      License cleanup: add SPDX GPL-2.0 license identifier to files with no license · b2441318
      Greg Kroah-Hartman 提交于
      Many source files in the tree are missing licensing information, which
      makes it harder for compliance tools to determine the correct license.
      
      By default all files without license information are under the default
      license of the kernel, which is GPL version 2.
      
      Update the files which contain no license information with the 'GPL-2.0'
      SPDX license identifier.  The SPDX identifier is a legally binding
      shorthand, which can be used instead of the full boiler plate text.
      
      This patch is based on work done by Thomas Gleixner and Kate Stewart and
      Philippe Ombredanne.
      
      How this work was done:
      
      Patches were generated and checked against linux-4.14-rc6 for a subset of
      the use cases:
       - file had no licensing information it it.
       - file was a */uapi/* one with no licensing information in it,
       - file was a */uapi/* one with existing licensing information,
      
      Further patches will be generated in subsequent months to fix up cases
      where non-standard license headers were used, and references to license
      had to be inferred by heuristics based on keywords.
      
      The analysis to determine which SPDX License Identifier to be applied to
      a file was done in a spreadsheet of side by side results from of the
      output of two independent scanners (ScanCode & Windriver) producing SPDX
      tag:value files created by Philippe Ombredanne.  Philippe prepared the
      base worksheet, and did an initial spot review of a few 1000 files.
      
      The 4.13 kernel was the starting point of the analysis with 60,537 files
      assessed.  Kate Stewart did a file by file comparison of the scanner
      results in the spreadsheet to determine which SPDX license identifier(s)
      to be applied to the file. She confirmed any determination that was not
      immediately clear with lawyers working with the Linux Foundation.
      
      Criteria used to select files for SPDX license identifier tagging was:
       - Files considered eligible had to be source code files.
       - Make and config files were included as candidates if they contained >5
         lines of source
       - File already had some variant of a license header in it (even if <5
         lines).
      
      All documentation files were explicitly excluded.
      
      The following heuristics were used to determine which SPDX license
      identifiers to apply.
      
       - when both scanners couldn't find any license traces, file was
         considered to have no license information in it, and the top level
         COPYING file license applied.
      
         For non */uapi/* files that summary was:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|-------
         GPL-2.0                                              11139
      
         and resulted in the first patch in this series.
      
         If that file was a */uapi/* path one, it was "GPL-2.0 WITH
         Linux-syscall-note" otherwise it was "GPL-2.0".  Results of that was:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|-------
         GPL-2.0 WITH Linux-syscall-note                        930
      
         and resulted in the second patch in this series.
      
       - if a file had some form of licensing information in it, and was one
         of the */uapi/* ones, it was denoted with the Linux-syscall-note if
         any GPL family license was found in the file or had no licensing in
         it (per prior point).  Results summary:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|------
         GPL-2.0 WITH Linux-syscall-note                       270
         GPL-2.0+ WITH Linux-syscall-note                      169
         ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause)    21
         ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)    17
         LGPL-2.1+ WITH Linux-syscall-note                      15
         GPL-1.0+ WITH Linux-syscall-note                       14
         ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause)    5
         LGPL-2.0+ WITH Linux-syscall-note                       4
         LGPL-2.1 WITH Linux-syscall-note                        3
         ((GPL-2.0 WITH Linux-syscall-note) OR MIT)              3
         ((GPL-2.0 WITH Linux-syscall-note) AND MIT)             1
      
         and that resulted in the third patch in this series.
      
       - when the two scanners agreed on the detected license(s), that became
         the concluded license(s).
      
       - when there was disagreement between the two scanners (one detected a
         license but the other didn't, or they both detected different
         licenses) a manual inspection of the file occurred.
      
       - In most cases a manual inspection of the information in the file
         resulted in a clear resolution of the license that should apply (and
         which scanner probably needed to revisit its heuristics).
      
       - When it was not immediately clear, the license identifier was
         confirmed with lawyers working with the Linux Foundation.
      
       - If there was any question as to the appropriate license identifier,
         the file was flagged for further research and to be revisited later
         in time.
      
      In total, over 70 hours of logged manual review was done on the
      spreadsheet to determine the SPDX license identifiers to apply to the
      source files by Kate, Philippe, Thomas and, in some cases, confirmation
      by lawyers working with the Linux Foundation.
      
      Kate also obtained a third independent scan of the 4.13 code base from
      FOSSology, and compared selected files where the other two scanners
      disagreed against that SPDX file, to see if there was new insights.  The
      Windriver scanner is based on an older version of FOSSology in part, so
      they are related.
      
      Thomas did random spot checks in about 500 files from the spreadsheets
      for the uapi headers and agreed with SPDX license identifier in the
      files he inspected. For the non-uapi files Thomas did random spot checks
      in about 15000 files.
      
      In initial set of patches against 4.14-rc6, 3 files were found to have
      copy/paste license identifier errors, and have been fixed to reflect the
      correct identifier.
      
      Additionally Philippe spent 10 hours this week doing a detailed manual
      inspection and review of the 12,461 patched files from the initial patch
      version early this week with:
       - a full scancode scan run, collecting the matched texts, detected
         license ids and scores
       - reviewing anything where there was a license detected (about 500+
         files) to ensure that the applied SPDX license was correct
       - reviewing anything where there was no detection but the patch license
         was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
         SPDX license was correct
      
      This produced a worksheet with 20 files needing minor correction.  This
      worksheet was then exported into 3 different .csv files for the
      different types of files to be modified.
      
      These .csv files were then reviewed by Greg.  Thomas wrote a script to
      parse the csv files and add the proper SPDX tag to the file, in the
      format that the file expected.  This script was further refined by Greg
      based on the output to detect more types of files automatically and to
      distinguish between header and source .c files (which need different
      comment types.)  Finally Greg ran the script using the .csv files to
      generate the patches.
      Reviewed-by: NKate Stewart <kstewart@linuxfoundation.org>
      Reviewed-by: NPhilippe Ombredanne <pombredanne@nexb.com>
      Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b2441318
  5. 30 10月, 2017 4 次提交
    • R
      Bluetooth: hci_ldisc: Fix another race when closing the tty. · 0338b1b3
      Ronald Tschalär 提交于
      The following race condition still existed:
      
               P1                                P2
        cancel_work_sync()
                                           hci_uart_tx_wakeup()
                                           hci_uart_write_work()
                                           hci_uart_dequeue()
        clear_bit(HCI_UART_PROTO_READY)
        hci_unregister_dev(hdev)
        hci_free_dev(hdev)
        hu->proto->close(hu)
        kfree(hu)
                                           access to hdev and hu
      
      Cancelling the work after clearing the HCI_UART_PROTO_READY bit avoids
      this as any hci_uart_tx_wakeup() issued after the flag is cleared will
      detect that and not schedule further work.
      Signed-off-by: NRonald Tschalär <ronald@innovation.ch>
      Reviewed-by: NLukas Wunner <lukas@wunner.de>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      0338b1b3
    • M
      Bluetooth: btusb: Fix isochronous interface assignments · 459232fc
      Marcel Holtmann 提交于
      The recent MacBook's with multi-function USB interfaces for HID and
      Bluetooth operation have the isochronous interface on number 3 instead
      of number 1. Store the interface number and use it.
      
      P:  Vendor=05ac ProdID=8290 Rev= 1.40
      S:  Manufacturer=Broadcom Corp.
      S:  Product=Bluetooth USB Host Controller
      C:* #Ifs= 6 Cfg#= 1 Atr=e0 MxPwr=  0mA
      A:  FirstIf#= 2 IfCount= 4 Cls=ff(vend.) Sub=01 Prot=01
      I:* If#= 0 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=01 Prot=01 Driver=usbhid
      E:  Ad=85(I) Atr=03(Int.) MxPS=   8 Ivl=10ms
      I:* If#= 1 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=01 Prot=02 Driver=usbhid
      E:  Ad=86(I) Atr=03(Int.) MxPS=   8 Ivl=10ms
      I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) 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#= 3 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#= 3 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#= 3 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#= 3 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#= 3 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#= 3 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
      I:* If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=btusb
      E:  Ad=84(I) Atr=02(Bulk) MxPS=  32 Ivl=0ms
      E:  Ad=04(O) Atr=02(Bulk) MxPS=  32 Ivl=0ms
      I:* If#= 5 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      459232fc
    • J
      Bluetooth: btusb: Update firmware filename for Intel 9x60 and later · af3715e5
      Jaya P G 提交于
      The format of Intel Bluetooth firmware for bootloader product is
      ibt-<hw_variant>-<device_revision_id>.sfi and .ddc.
      
      But for the SKU's 9x60, there a 3 variants of FW, which cannot be
      differentiated just with hw_variant and devision_revision_id.
      So to pick the appropriate FW file for 9x60 SKU's, it will be
      differentiated using hw_variant, hw_revision and fw_revision rather
      than hw_variant and device_revision_id only.
      
      Format will be like this:
      ibt-<hw_variant>-<hw_revision>-<fw_revision>.sfi and .ddc
      Signed-off-by: NJaya P G <jaya.p.g@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      af3715e5
    • M
      Bluetooth: Use bt_dev_err and bt_dev_info when possible · 2064ee33
      Marcel Holtmann 提交于
      In case of using BT_ERR and BT_INFO, convert to bt_dev_err and
      bt_dev_info when possible. This allows for controller specific
      reporting.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      2064ee33
  6. 29 10月, 2017 3 次提交
    • L
      Bluetooth: hci_ath: Add ath_vendor_cmd helper · 13df5000
      Loic Poulain 提交于
      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: NLoic Poulain <loic.poulain@linaro.org>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      13df5000
    • B
      Bluetooth: btusb: Add new NFA344A entry. · 858ff38a
      Bartosz Chronowski 提交于
      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: NBartosz Chronowski <ext.bartosz.chronowski@tieto.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      858ff38a
    • R
      Bluetooth: hci_ldisc: Allow sleeping while proto locks are held. · 67d2f878
      Ronald Tschalär 提交于
      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: NRonald Tschalär <ronald@innovation.ch>
      Reviewed-by: NLukas Wunner <lukas@wunner.de>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      67d2f878
  7. 14 10月, 2017 4 次提交
  8. 12 10月, 2017 2 次提交
  9. 10 10月, 2017 4 次提交
    • I
      Bluetooth: btbcm: Add support for MINIX Z83-4 based devices · 18a39b9a
      Ian W MORRISON 提交于
      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: NIan W MORRISON <ianwmorrison@gmail.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      18a39b9a
    • I
      Bluetooth: hci_bcm: Add support for MINIX Z83-4 based devices · 1bdb68b2
      Ian W MORRISON 提交于
      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: NIan W MORRISON <ianwmorrison@gmail.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      1bdb68b2
    • J
      Bluetooth: avoid silent hci_bcm ACPI PM regression · 4294625e
      Johan Hovold 提交于
      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: NJohan Hovold <johan@kernel.org>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      4294625e
    • I
      Bluetooth: hci_bcm: Correct context of IRQ polarity message · e8bfe868
      Ian W MORRISON 提交于
      As the overwriting of IRQ polarity to active low occurs during the driver
      probe using 'bt_dev_warn' to display the warning results in '(null)' being
      displayed for the device. This patch uses 'dev_warn' to correctly display
      the device in the warning instead.
      Signed-off-by: NIan W MORRISON <ianwmorrison@gmail.com>
      Reviewed-by: NHans de Goede <hdegoede@redhat.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      e8bfe868
  10. 07 10月, 2017 1 次提交