1. 07 Jul, 2019 6 commits
  2. 06 Jul, 2019 34 commits
    • David S. Miller's avatar
      Merge tag 'wireless-drivers-next-for-davem-2019-07-06' of... · 437fde6c
      David S. Miller authored
      Merge tag 'wireless-drivers-next-for-davem-2019-07-06' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next
      
      Kalle Valo says:
      
      ====================
      wireless-drivers-next patches for 5.3
      
      Second, and last, set of patches for 5.3.
      
      Major changes:
      
      mt76
      
      * use NAPI polling for tx cleanup on mt7603/mt7615
      
      * add support for toggling edcca on mt7603
      
      * fix rate control / tx status reporting issues on mt76x02/mt7603
      
      * add support for eeprom calibration data from mtd on mt7615
      
      * support configuring tx power on mt7615
      
      * per-chain signal reporting on mt7615
      
      iwlwifi
      
      * Update the FW API for Channel State Information (CSI)
      
      * Special Specific Absorption Rate (SAR) implementation for South Korea
      
      ath10k
      
      * fixes for SDIO support
      
      * add support for firmware logging via WMI
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      437fde6c
    • Sean Wang's avatar
      Bluetooth: btusb: Add protocol support for MediaTek MT7663U USB devices · 9ce67c32
      Sean Wang authored
      This adds the support of enabling MT7663U Bluetooth function running
      on the top of btusb driver.
      
      The information in /sys/kernel/debug/usb/devices about the Bluetooth
      device is listed as the below.
      
      T:  Bus=04 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  5 Spd=5000 MxCh= 0
      D:  Ver= 3.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs=  1
      P:  Vendor=0e8d ProdID=7663 Rev= 1.00
      S:  Manufacturer=MediaTek Inc.
      S:  Product=Wireless_Device
      S:  SerialNumber=000000000
      C:* #Ifs= 3 Cfg#= 1 Atr=a0 MxPwr=160mA
      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
      E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=125us
      E:  Ad=82(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
      E:  Ad=02(O) Atr=02(Bulk) MxPS=1024 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
      I:  If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  63 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  63 Ivl=1ms
      Signed-off-by: default avatarSean Wang <sean.wang@mediatek.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      9ce67c32
    • Sean Wang's avatar
      Bluetooth: btusb: Add protocol support for MediaTek MT7668U USB devices · a1c49c43
      Sean Wang authored
      This adds the support of enabling MT7668U Bluetooth function running
      on the top of btusb driver.
      
      The information in /sys/kernel/debug/usb/devices about the Bluetooth
      device is listed as the below.
      
      T:  Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=5000 MxCh= 0
      D:  Ver= 3.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs=  1
      P:  Vendor=0e8d ProdID=7668 Rev= 1.00
      S:  Manufacturer=MediaTek Inc.
      S:  Product=Wireless_Device
      S:  SerialNumber=000000000
      C:* #Ifs= 3 Cfg#= 1 Atr=a0 MxPwr=160mA
      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
      E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=125us
      E:  Ad=82(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
      E:  Ad=02(O) Atr=02(Bulk) MxPS=1024 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
      I:  If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  63 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  63 Ivl=1ms
      Signed-off-by: default avatarSean Wang <sean.wang@mediatek.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      a1c49c43
    • Josua Mayer's avatar
      Bluetooth: 6lowpan: always check destination address · 688d94fd
      Josua Mayer authored
      BLE based 6LoWPAN networks are highly constrained in bandwidth.
      Do not take a short-cut, always check if the destination address is
      known to belong to a peer.
      
      As a side-effect this also removes any behavioral differences between
      one, and two or more connected peers.
      Acked-by: default avatarJukka Rissanen <jukka.rissanen@linux.intel.com>
      Tested-by: default avatarMichael Scott <mike@foundries.io>
      Signed-off-by: default avatarJosua Mayer <josua.mayer@jm0.eu>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      688d94fd
    • Josua Mayer's avatar
      Bluetooth: 6lowpan: check neighbour table for SLAAC · 5636376c
      Josua Mayer authored
      Like any IPv6 capable device, 6LNs can have multiple addresses assigned
      using SLAAC and made known through neighbour advertisements.
      After checking the destination address against all peers link-local
      addresses, consult the neighbour cache for additional known addresses.
      
      RFC7668 defines the scope of Neighbor Advertisements in Section 3.2.3:
      1. "A Bluetooth LE 6LN MUST NOT register its link-local address"
      2. "A Bluetooth LE 6LN MUST register its non-link-local addresses with
      the 6LBR by sending Neighbor Solicitation (NS) messages ..."
      
      Due to these constranits both the link-local addresses tracked in the
      list of 6lowpan peers, and the neighbour cache have to be used when
      identifying the 6lowpan peer for a destination address.
      Acked-by: default avatarJukka Rissanen <jukka.rissanen@linux.intel.com>
      Tested-by: default avatarMichael Scott <mike@foundries.io>
      Signed-off-by: default avatarJosua Mayer <josua.mayer@jm0.eu>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      5636376c
    • Josua Mayer's avatar
      Bluetooth: 6lowpan: search for destination address in all peers · b188b032
      Josua Mayer authored
      Handle overlooked case where the target address is assigned to a peer
      and neither route nor gateway exist.
      
      For one peer, no checks are performed to see if it is meant to receive
      packets for a given address.
      
      As soon as there is a second peer however, checks are performed
      to deal with routes and gateways for handling complex setups with
      multiple hops to a target address.
      This logic assumed that no route and no gateway imply that the
      destination address can not be reached, which is false in case of a
      direct peer.
      Acked-by: default avatarJukka Rissanen <jukka.rissanen@linux.intel.com>
      Tested-by: default avatarMichael Scott <mike@foundries.io>
      Signed-off-by: default avatarJosua Mayer <josua.mayer@jm0.eu>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      b188b032
    • Szymon Janc's avatar
      Bluetooth: Add SMP workaround Microsoft Surface Precision Mouse bug · 1d87b88b
      Szymon Janc authored
      Microsoft Surface Precision Mouse provides bogus identity address when
      pairing. It connects with Static Random address but provides Public
      Address in SMP Identity Address Information PDU. Address has same
      value but type is different. Workaround this by dropping IRK if ID
      address discrepancy is detected.
      
      > HCI Event: LE Meta Event (0x3e) plen 19
            LE Connection Complete (0x01)
              Status: Success (0x00)
              Handle: 75
              Role: Master (0x00)
              Peer address type: Random (0x01)
              Peer address: E0:52:33:93:3B:21 (Static)
              Connection interval: 50.00 msec (0x0028)
              Connection latency: 0 (0x0000)
              Supervision timeout: 420 msec (0x002a)
              Master clock accuracy: 0x00
      
      ....
      
      > ACL Data RX: Handle 75 flags 0x02 dlen 12
            SMP: Identity Address Information (0x09) len 7
              Address type: Public (0x00)
              Address: E0:52:33:93:3B:21
      Signed-off-by: default avatarSzymon Janc <szymon.janc@codecoup.pl>
      Tested-by: default avatarMaarten Fonville <maarten.fonville@gmail.com>
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=199461
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      1d87b88b
    • Luiz Augusto von Dentz's avatar
      Bluetooth: L2CAP: Check bearer type on __l2cap_global_chan_by_addr · 00f62726
      Luiz Augusto von Dentz authored
      The spec defines PSM and LE_PSM as different domains so a listen on the
      same PSM is valid if the address type points to a different bearer.
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      00f62726
    • Luiz Augusto von Dentz's avatar
      Bluetooth: Use controller sets when available · 1d0fac2c
      Luiz Augusto von Dentz authored
      This makes use of controller sets when using Extended Advertising
      feature thus offloading the scheduling to the controller.
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      1d0fac2c
    • csonsino's avatar
      Bluetooth: validate BLE connection interval updates · c49a8682
      csonsino authored
      Problem: The Linux Bluetooth stack yields complete control over the BLE
      connection interval to the remote device.
      
      The Linux Bluetooth stack provides access to the BLE connection interval
      min and max values through /sys/kernel/debug/bluetooth/hci0/
      conn_min_interval and /sys/kernel/debug/bluetooth/hci0/conn_max_interval.
      These values are used for initial BLE connections, but the remote device
      has the ability to request a connection parameter update. In the event
      that the remote side requests to change the connection interval, the Linux
      kernel currently only validates that the desired value is within the
      acceptable range in the Bluetooth specification (6 - 3200, corresponding to
      7.5ms - 4000ms). There is currently no validation that the desired value
      requested by the remote device is within the min/max limits specified in
      the conn_min_interval/conn_max_interval configurations. This essentially
      leads to Linux yielding complete control over the connection interval to
      the remote device.
      
      The proposed patch adds a verification step to the connection parameter
      update mechanism, ensuring that the desired value is within the min/max
      bounds of the current connection. If the desired value is outside of the
      current connection min/max values, then the connection parameter update
      request is rejected and the negative response is returned to the remote
      device. Recall that the initial connection is established using the local
      conn_min_interval/conn_max_interval values, so this allows the Linux
      administrator to retain control over the BLE connection interval.
      
      The one downside that I see is that the current default Linux values for
      conn_min_interval and conn_max_interval typically correspond to 30ms and
      50ms respectively. If this change were accepted, then it is feasible that
      some devices would no longer be able to negotiate to their desired
      connection interval values. This might be remedied by setting the default
      Linux conn_min_interval and conn_max_interval values to the widest
      supported range (6 - 3200 / 7.5ms - 4000ms). This could lead to the same
      behavior as the current implementation, where the remote device could
      request to change the connection interval value to any value that is
      permitted by the Bluetooth specification, and Linux would accept the
      desired value.
      Signed-off-by: default avatarCarey Sonsino <csonsino@gmail.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      c49a8682
    • Spoorthi Ravishankar Koppad's avatar
      Bluetooth: Add support for LE ping feature · 302975cb
      Spoorthi Ravishankar Koppad authored
      Changes made to add HCI Write Authenticated Payload timeout
      command for LE Ping feature.
      
      As per the Core Specification 5.0 Volume 2 Part E Section 7.3.94,
      the following code changes implements
      HCI Write Authenticated Payload timeout command for LE Ping feature.
      Signed-off-by: default avatarSpoorthi Ravishankar Koppad <spoorthix.k@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      302975cb
    • Matias Karhumaa's avatar
      Bluetooth: Check state in l2cap_disconnect_rsp · 28261da8
      Matias Karhumaa authored
      Because of both sides doing L2CAP disconnection at the same time, it
      was possible to receive L2CAP Disconnection Response with CID that was
      already freed. That caused problems if CID was already reused and L2CAP
      Connection Request with same CID was sent out. Before this patch kernel
      deleted channel context regardless of the state of the channel.
      
      Example where leftover Disconnection Response (frame #402) causes local
      device to delete L2CAP channel which was not yet connected. This in
      turn confuses remote device's stack because same CID is re-used without
      properly disconnecting.
      
      Btmon capture before patch:
      ** snip **
      > ACL Data RX: Handle 43 flags 0x02 dlen 8                #394 [hci1] 10.748949
            Channel: 65 len 4 [PSM 3 mode 0] {chan 2}
            RFCOMM: Disconnect (DISC) (0x43)
               Address: 0x03 cr 1 dlci 0x00
               Control: 0x53 poll/final 1
               Length: 0
               FCS: 0xfd
      < ACL Data TX: Handle 43 flags 0x00 dlen 8                #395 [hci1] 10.749062
            Channel: 65 len 4 [PSM 3 mode 0] {chan 2}
            RFCOMM: Unnumbered Ack (UA) (0x63)
               Address: 0x03 cr 1 dlci 0x00
               Control: 0x73 poll/final 1
               Length: 0
               FCS: 0xd7
      < ACL Data TX: Handle 43 flags 0x00 dlen 12               #396 [hci1] 10.749073
            L2CAP: Disconnection Request (0x06) ident 17 len 4
              Destination CID: 65
              Source CID: 65
      > HCI Event: Number of Completed Packets (0x13) plen 5    #397 [hci1] 10.752391
              Num handles: 1
              Handle: 43
              Count: 1
      > HCI Event: Number of Completed Packets (0x13) plen 5    #398 [hci1] 10.753394
              Num handles: 1
              Handle: 43
              Count: 1
      > ACL Data RX: Handle 43 flags 0x02 dlen 12               #399 [hci1] 10.756499
            L2CAP: Disconnection Request (0x06) ident 26 len 4
              Destination CID: 65
              Source CID: 65
      < ACL Data TX: Handle 43 flags 0x00 dlen 12               #400 [hci1] 10.756548
            L2CAP: Disconnection Response (0x07) ident 26 len 4
              Destination CID: 65
              Source CID: 65
      < ACL Data TX: Handle 43 flags 0x00 dlen 12               #401 [hci1] 10.757459
            L2CAP: Connection Request (0x02) ident 18 len 4
              PSM: 1 (0x0001)
              Source CID: 65
      > ACL Data RX: Handle 43 flags 0x02 dlen 12               #402 [hci1] 10.759148
            L2CAP: Disconnection Response (0x07) ident 17 len 4
              Destination CID: 65
              Source CID: 65
      = bluetoothd: 00:1E:AB:4C:56:54: error updating services: Input/o..   10.759447
      > HCI Event: Number of Completed Packets (0x13) plen 5    #403 [hci1] 10.759386
              Num handles: 1
              Handle: 43
              Count: 1
      > ACL Data RX: Handle 43 flags 0x02 dlen 12               #404 [hci1] 10.760397
            L2CAP: Connection Request (0x02) ident 27 len 4
              PSM: 3 (0x0003)
              Source CID: 65
      < ACL Data TX: Handle 43 flags 0x00 dlen 16               #405 [hci1] 10.760441
            L2CAP: Connection Response (0x03) ident 27 len 8
              Destination CID: 65
              Source CID: 65
              Result: Connection successful (0x0000)
              Status: No further information available (0x0000)
      < ACL Data TX: Handle 43 flags 0x00 dlen 27               #406 [hci1] 10.760449
            L2CAP: Configure Request (0x04) ident 19 len 19
              Destination CID: 65
              Flags: 0x0000
              Option: Maximum Transmission Unit (0x01) [mandatory]
                MTU: 1013
              Option: Retransmission and Flow Control (0x04) [mandatory]
                Mode: Basic (0x00)
                TX window size: 0
                Max transmit: 0
                Retransmission timeout: 0
                Monitor timeout: 0
                Maximum PDU size: 0
      > HCI Event: Number of Completed Packets (0x13) plen 5    #407 [hci1] 10.761399
              Num handles: 1
              Handle: 43
              Count: 1
      > ACL Data RX: Handle 43 flags 0x02 dlen 16               #408 [hci1] 10.762942
            L2CAP: Connection Response (0x03) ident 18 len 8
              Destination CID: 66
              Source CID: 65
              Result: Connection successful (0x0000)
              Status: No further information available (0x0000)
      *snip*
      
      Similar case after the patch:
      *snip*
      > ACL Data RX: Handle 43 flags 0x02 dlen 8            #22702 [hci0] 1664.411056
            Channel: 65 len 4 [PSM 3 mode 0] {chan 3}
            RFCOMM: Disconnect (DISC) (0x43)
               Address: 0x03 cr 1 dlci 0x00
               Control: 0x53 poll/final 1
               Length: 0
               FCS: 0xfd
      < ACL Data TX: Handle 43 flags 0x00 dlen 8            #22703 [hci0] 1664.411136
            Channel: 65 len 4 [PSM 3 mode 0] {chan 3}
            RFCOMM: Unnumbered Ack (UA) (0x63)
               Address: 0x03 cr 1 dlci 0x00
               Control: 0x73 poll/final 1
               Length: 0
               FCS: 0xd7
      < ACL Data TX: Handle 43 flags 0x00 dlen 12           #22704 [hci0] 1664.411143
            L2CAP: Disconnection Request (0x06) ident 11 len 4
              Destination CID: 65
              Source CID: 65
      > HCI Event: Number of Completed Pac.. (0x13) plen 5  #22705 [hci0] 1664.414009
              Num handles: 1
              Handle: 43
              Count: 1
      > HCI Event: Number of Completed Pac.. (0x13) plen 5  #22706 [hci0] 1664.415007
              Num handles: 1
              Handle: 43
              Count: 1
      > ACL Data RX: Handle 43 flags 0x02 dlen 12           #22707 [hci0] 1664.418674
            L2CAP: Disconnection Request (0x06) ident 17 len 4
              Destination CID: 65
              Source CID: 65
      < ACL Data TX: Handle 43 flags 0x00 dlen 12           #22708 [hci0] 1664.418762
            L2CAP: Disconnection Response (0x07) ident 17 len 4
              Destination CID: 65
              Source CID: 65
      < ACL Data TX: Handle 43 flags 0x00 dlen 12           #22709 [hci0] 1664.421073
            L2CAP: Connection Request (0x02) ident 12 len 4
              PSM: 1 (0x0001)
              Source CID: 65
      > ACL Data RX: Handle 43 flags 0x02 dlen 12           #22710 [hci0] 1664.421371
            L2CAP: Disconnection Response (0x07) ident 11 len 4
              Destination CID: 65
              Source CID: 65
      > HCI Event: Number of Completed Pac.. (0x13) plen 5  #22711 [hci0] 1664.424082
              Num handles: 1
              Handle: 43
              Count: 1
      > HCI Event: Number of Completed Pac.. (0x13) plen 5  #22712 [hci0] 1664.425040
              Num handles: 1
              Handle: 43
              Count: 1
      > ACL Data RX: Handle 43 flags 0x02 dlen 12           #22713 [hci0] 1664.426103
            L2CAP: Connection Request (0x02) ident 18 len 4
              PSM: 3 (0x0003)
              Source CID: 65
      < ACL Data TX: Handle 43 flags 0x00 dlen 16           #22714 [hci0] 1664.426186
            L2CAP: Connection Response (0x03) ident 18 len 8
              Destination CID: 66
              Source CID: 65
              Result: Connection successful (0x0000)
              Status: No further information available (0x0000)
      < ACL Data TX: Handle 43 flags 0x00 dlen 27           #22715 [hci0] 1664.426196
            L2CAP: Configure Request (0x04) ident 13 len 19
              Destination CID: 65
              Flags: 0x0000
              Option: Maximum Transmission Unit (0x01) [mandatory]
                MTU: 1013
              Option: Retransmission and Flow Control (0x04) [mandatory]
                Mode: Basic (0x00)
                TX window size: 0
                Max transmit: 0
                Retransmission timeout: 0
                Monitor timeout: 0
                Maximum PDU size: 0
      > ACL Data RX: Handle 43 flags 0x02 dlen 16           #22716 [hci0] 1664.428804
            L2CAP: Connection Response (0x03) ident 12 len 8
              Destination CID: 66
              Source CID: 65
              Result: Connection successful (0x0000)
              Status: No further information available (0x0000)
      *snip*
      
      Fix is to check that channel is in state BT_DISCONN before deleting the
      channel.
      
      This bug was found while fuzzing Bluez's OBEX implementation using
      Synopsys Defensics.
      Reported-by: default avatarMatti Kamunen <matti.kamunen@synopsys.com>
      Reported-by: default avatarAri Timonen <ari.timonen@synopsys.com>
      Signed-off-by: default avatarMatias Karhumaa <matias.karhumaa@gmail.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      28261da8
    • Dan Carpenter's avatar
      Bluetooth: hidp: NUL terminate a string in the compat ioctl · dcae9052
      Dan Carpenter authored
      This change is similar to commit a1616a5a ("Bluetooth: hidp: fix
      buffer overflow") but for the compat ioctl.  We take a string from the
      user and forgot to ensure that it's NUL terminated.
      
      I have also changed the strncpy() in to strscpy() in hidp_setup_hid().
      The difference is the strncpy() doesn't necessarily NUL terminate the
      destination string.  Either change would fix the problem but it's nice
      to take a belt and suspenders approach and do both.
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      dcae9052
    • João Paulo Rechi Vita's avatar
      Bluetooth: Add new 13d3:3491 QCA_ROME device · 44d34af2
      João Paulo Rechi Vita authored
      Without the QCA ROME setup routine this adapter fails to establish a SCO
      connection.
      
      T:  Bus=01 Lev=01 Prnt=01 Port=08 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=13d3 ProdID=3491 Rev=00.01
      C:  #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
      I:  If#=0x0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      I:  If#=0x1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      Signed-off-by: default avatarJoão Paulo Rechi Vita <jprvita@endlessm.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      44d34af2
    • João Paulo Rechi Vita's avatar
      Bluetooth: Add new 13d3:3501 QCA_ROME device · 881cec4f
      João Paulo Rechi Vita authored
      Without the QCA ROME setup routine this adapter fails to establish a SCO
      connection.
      
      T:  Bus=01 Lev=01 Prnt=01 Port=04 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=13d3 ProdID=3501 Rev=00.01
      C:  #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
      I:  If#=0x0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      I:  If#=0x1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      Signed-off-by: default avatarJoão Paulo Rechi Vita <jprvita@endlessm.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      881cec4f
    • Tomas Bortoli's avatar
      Bluetooth: hci_bcsp: Fix memory leak in rx_skb · 4ce9146e
      Tomas Bortoli authored
      Syzkaller found that it is possible to provoke a memory leak by
      never freeing rx_skb in struct bcsp_struct.
      
      Fix by freeing in bcsp_close()
      Signed-off-by: default avatarTomas Bortoli <tomasbortoli@gmail.com>
      Reported-by: syzbot+98162c885993b72f19c4@syzkaller.appspotmail.com
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      4ce9146e
    • Larry Finger's avatar
      Bluetooth:: btrtl: Add support for RTL8723DU · 6c595ea8
      Larry Finger authored
      This device is functionally equivalent to the BT part of the RTL8723DE,
      uses the same firmware, but the LMP subversion and HCI revision are unique.
      Signed-off-by: default avatarLarry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      6c595ea8
    • Sean Wang's avatar
      Bluetooth: btmtkuart: add an implementation for clock osc property · 05582561
      Sean Wang authored
      Some board requires explicitily control external osscilator via GPIO.
      So, add an implementation of a clock property for an external oscillator
      to the device.
      Signed-off-by: default avatarSean Wang <sean.wang@mediatek.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      05582561
    • Sean Wang's avatar
      Bluetooth: btmtkuart: add an implementation for boot-gpios property · a3cb6d60
      Sean Wang authored
      Not every platform has the pinctrl device integrates the GPIO the function
      such as MT7621 whose pinctrl and GPIO are separate hardware so the driver
      adds additional boot-gpios to let the MT766[3,8]U can enter the proper boot
      mode by gpiod for such platform.
      Signed-off-by: default avatarSean Wang <sean.wang@mediatek.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      a3cb6d60
    • Sean Wang's avatar
      dt-bindings: net: bluetooth: add clock property to UART-based device · 14e3ed84
      Sean Wang authored
      Some board requires explicitily control external osscilator via GPIO.
      So, add a clock property for an external oscillator for the device.
      Signed-off-by: default avatarSean Wang <sean.wang@mediatek.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      14e3ed84
    • Sean Wang's avatar
      dt-bindings: net: bluetooth: add boot-gpios property to UART-based device · 1c576f38
      Sean Wang authored
      Not every platform has the pinctrl device integrates the GPIO the function
      such as MT7621 whose pinctrl and GPIO are separate hardware so adding an
      additional boot-gpios property for such platform allows them to bring up
      the device.
      Signed-off-by: default avatarSean Wang <sean.wang@mediatek.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      1c576f38
    • Neil Armstrong's avatar
      Bluetooth: btbcm: Add entry for BCM4359C0 UART bluetooth · f4d297ee
      Neil Armstrong authored
      The BCM4359C0 BT/Wi-Fi compo chip needs an entry to be discovered
      by the btbcm driver.
      
      Tested using an AP6398S module from Ampak.
      Signed-off-by: default avatarNeil Armstrong <narmstrong@baylibre.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      f4d297ee
    • Rocky Liao's avatar
      dt-bindings: net: bluetooth: Add device property firmware-name for QCA6174 · 956f6646
      Rocky Liao authored
      This patch adds an optional device property "firmware-name" to allow the
      driver to load customized nvm firmware file based on this property.
      Signed-off-by: default avatarRocky Liao <rjliao@codeaurora.org>
      Reviewed-by: default avatarRob Herring <robh@kernel.org>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      956f6646
    • Rocky Liao's avatar
      Bluetooth: hci_qca: Load customized NVM based on the device property · 99c905c6
      Rocky Liao authored
      QCA BTSOC NVM is a customized firmware file and different vendors may
      want to have different BTSOC configuration (e.g. Configure SCO over PCM
      or I2S, Setting Tx power, etc.) via this file. This patch will allow
      vendors to download different NVM firmware file by reading a device
      property "firmware-name".
      Signed-off-by: default avatarRocky Liao <rjliao@codeaurora.org>
      Tested-by: default avatarHarish Bandi <c-hbandi@codeaurora.org>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      99c905c6
    • Sascha Hauer's avatar
      Bluetooth: hci_mrvl: Add serdev support · be70e5e7
      Sascha Hauer authored
      This adds serdev support to the Marvell hci uart driver. Only basic
      serdev support, none of the fancier features like regulator or enable
      GPIO support is added for now.
      Signed-off-by: default avatarSascha Hauer <s.hauer@pengutronix.de>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      be70e5e7
    • Sascha Hauer's avatar
      Bluetooth: hci_mrvl: Wait for final ack before switching baudrate · a55b8964
      Sascha Hauer authored
      For the Marvell HCI UART we have to upload two firmware files. The first
      one is only for switching the baudrate of the device to a higher
      baudrate. After the baudrate switching firmware has been uploaded the
      device waits for a final ack (0x5a) before actually switching the
      baudrate. To send this final ack with the old baudrate give the hci
      ldisc workqueue a chance to run before switching the baudrate. Without
      this the final ack will never be received by the device and firmware
      upload fails.
      Signed-off-by: default avatarSascha Hauer <s.hauer@pengutronix.de>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      a55b8964
    • Sascha Hauer's avatar
      Bluetooth: hci_ldisc: Add function to wait for characters to be sent · 40fbb915
      Sascha Hauer authored
      The hci UART line discipline sends its characters in a workqueue. Some
      devices like the Marvell Bluetooth chips need to make sure that all
      queued characters are sent before switching the baudrate. This adds
      a function to synchronize with the workqueue.
      Signed-off-by: default avatarSascha Hauer <s.hauer@pengutronix.de>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      40fbb915
    • Greg Kroah-Hartman's avatar
      6lowpan: no need to check return value of debugfs_create functions · db50450d
      Greg Kroah-Hartman authored
      When calling debugfs functions, there is no need to ever check the
      return value.  The function can work or not, but the code logic should
      never do something different based on this.
      
      Because we don't care if debugfs works or not, this trickles back a bit
      so we can clean things up by making some functions return void instead
      of an error value that is never going to fail.
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Acked-by: default avatarJukka Rissanen <jukka.rissanen@linux.intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      db50450d
    • Matthias Kaehlcke's avatar
      Bluetooth: hci_qca: wcn3990: Drop baudrate change vendor event · 2faa3f15
      Matthias Kaehlcke authored
      Firmware download to the WCN3990 often fails with a 'TLV response size
      mismatch' error:
      
      [  133.064659] Bluetooth: hci0: setting up wcn3990
      [  133.489150] Bluetooth: hci0: QCA controller version 0x02140201
      [  133.495245] Bluetooth: hci0: QCA Downloading qca/crbtfw21.tlv
      [  133.507214] Bluetooth: hci0: QCA TLV response size mismatch
      [  133.513265] Bluetooth: hci0: QCA Failed to download patch (-84)
      
      This is caused by a vendor event that corresponds to an earlier command
      to change the baudrate. The event is not processed in the context of the
      baudrate change and is later interpreted as response to the firmware
      download command (which is also a vendor command), but the driver detects
      that the event doesn't have the expected amount of associated data.
      
      More details:
      
      For the WCN3990 the vendor command for a baudrate change isn't sent as
      synchronous HCI command, because the controller sends the corresponding
      vendor event with the new baudrate. The event is received and decoded
      after the baudrate change of the host port.
      
      Identify the 'unused' event when it is received and don't add it to
      the queue of RX frames.
      Signed-off-by: default avatarMatthias Kaehlcke <mka@chromium.org>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      2faa3f15
    • Balakrishna Godavarthi's avatar
      Bluetooth: btqca: inject command complete event during fw download · 32646db8
      Balakrishna Godavarthi authored
      Latest qualcomm chips are not sending an command complete event for
      every firmware packet sent to chip. They only respond with a vendor
      specific event for the last firmware packet. This optimization will
      decrease the BT ON time. Due to this we are seeing a timeout error
      message logs on the console during firmware download. Now we are
      injecting a command complete event once we receive an vendor specific
      event for the last RAM firmware packet.
      Signed-off-by: default avatarBalakrishna Godavarthi <bgodavar@codeaurora.org>
      Tested-by: default avatarMatthias Kaehlcke <mka@chromium.org>
      Reviewed-by: default avatarMatthias Kaehlcke <mka@chromium.org>
      Signed-off-by: default avatarMatthias Kaehlcke <mka@chromium.org>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      32646db8
    • Fabian Schindlatz's avatar
      Bluetooth: Cleanup formatting and coding style · 82b7d856
      Fabian Schindlatz authored
      Fix some warnings and one error reported by checkpatch.pl:
      - lines longer than 80 characters are wrapped
      - empty lines inserted to separate variable declarations from the actual
        code
      - line break inserted after if (...)
      Co-developed-by: default avatarThomas Röthenbacher <thomas.roethenbacher@fau.de>
      Signed-off-by: default avatarThomas Röthenbacher <thomas.roethenbacher@fau.de>
      Signed-off-by: default avatarFabian Schindlatz <fabian.schindlatz@fau.de>
      Cc: linux-kernel@i4.cs.fau.de
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      82b7d856
    • Jian-Hong Pan's avatar
      Bluetooth: btrtl: HCI reset on close for Realtek BT chip · 7af3f558
      Jian-Hong Pan authored
      Realtek RTL8822BE BT chip on ASUS X420FA cannot be turned on correctly
      after on-off several times. Bluetooth daemon sets BT mode failed when
      this issue happens. Scanning must be active while turning off for this
      bug to be hit.
      
      bluetoothd[1576]: Failed to set mode: Failed (0x03)
      
      If BT is turned off, then turned on again, it works correctly again.
      
      According to the vendor driver, the HCI_QUIRK_RESET_ON_CLOSE flag is set
      during probing. So, this patch makes Realtek's BT reset on close to fix
      this issue.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=203429Signed-off-by: default avatarJian-Hong Pan <jian-hong@endlessm.com>
      Reviewed-by: default avatarDaniel Drake <drake@endlessm.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      7af3f558
    • Fabian Schindlatz's avatar
      Bluetooth: hci_ll: Refactor download_firmware · 6322f377
      Fabian Schindlatz authored
      Extract the new function send_command_from_firmware from
      download_firmware, which helps with the readability of the switch
      statement. This way the code is less deeply nested and also no longer
      exceeds the 80 character limit.
      Co-developed-by: default avatarThomas Röthenbacher <thomas.roethenbacher@fau.de>
      Signed-off-by: default avatarThomas Röthenbacher <thomas.roethenbacher@fau.de>
      Signed-off-by: default avatarFabian Schindlatz <fabian.schindlatz@fau.de>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      6322f377
    • Philipp Puschmann's avatar
      Bluetooth: hci_ll: set operational frequency earlier · a2e02f38
      Philipp Puschmann authored
      Uploading the firmware needs quite a few seconds if done at 115200 kbps. So set
      the operational frequency, usually 3 MHz, before uploading the firmware.
      
      I have successfully tested this with a wl1837mod.
      Signed-off-by: default avatarPhilipp Puschmann <philipp.puschmann@emlix.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      a2e02f38