1. 08 Jul, 2019 24 commits
  2. 07 Jul, 2019 8 commits
  3. 06 Jul, 2019 8 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