1. 12 Dec, 2022 40 commits
    • Jakub Kicinski's avatar
      Merge branch 'net-add-iff_no_addrconf-to-prevent-ipv6-addrconf' · 2a78dd22
      Jakub Kicinski authored
      Xin Long says:
      
      ====================
      net: add IFF_NO_ADDRCONF to prevent ipv6 addrconf
      
      This patchset adds IFF_NO_ADDRCONF flag for dev->priv_flags
      to prevent ipv6 addrconf, as Jiri Pirko's suggestion.
      
      For Bonding it changes to use this flag instead of IFF_SLAVE
      flag in Patch 1, and for Teaming and Net Failover it sets
      this flag before calling dev_open() in Patch 2 and 3.
      ====================
      
      Link: https://lore.kernel.org/r/cover.1670599241.git.lucien.xin@gmail.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      2a78dd22
    • Xin Long's avatar
      net: failover: use IFF_NO_ADDRCONF flag to prevent ipv6 addrconf · cb54d392
      Xin Long authored
      Similar to Bonding and Team, to prevent ipv6 addrconf with
      IFF_NO_ADDRCONF in slave_dev->priv_flags for slave ports
      is also needed in net failover.
      
      Note that dev_open(slave_dev) is called in .slave_register,
      which is called after the IFF_NO_ADDRCONF flag is set in
      failover_slave_register().
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      cb54d392
    • Xin Long's avatar
      net: team: use IFF_NO_ADDRCONF flag to prevent ipv6 addrconf · 0aa64df3
      Xin Long authored
      This patch is to use IFF_NO_ADDRCONF flag to prevent ipv6 addrconf
      for Team port. This flag will be set in team_port_enter(), which
      is called before dev_open(), and cleared in team_port_leave(),
      called after dev_close() and the err path in team_port_add().
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      0aa64df3
    • Xin Long's avatar
      net: add IFF_NO_ADDRCONF and use it in bonding to prevent ipv6 addrconf · 8a321cf7
      Xin Long authored
      Currently, in bonding it reused the IFF_SLAVE flag and checked it
      in ipv6 addrconf to prevent ipv6 addrconf.
      
      However, it is not a proper flag to use for no ipv6 addrconf, for
      bonding it has to move IFF_SLAVE flag setting ahead of dev_open()
      in bond_enslave(). Also, IFF_MASTER/SLAVE are historical flags
      used in bonding and eql, as Jiri mentioned, the new devices like
      Team, Failover do not use this flag.
      
      So as Jiri suggested, this patch adds IFF_NO_ADDRCONF in priv_flags
      of the device to indicate no ipv6 addconf, and uses it in bonding
      and moves IFF_SLAVE flag setting back to its original place.
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      8a321cf7
    • Uladzislau Koshchanka's avatar
      lib: packing: replace bit_reverse() with bitrev8() · 1280d4b7
      Uladzislau Koshchanka authored
      Remove bit_reverse() function.  Instead use bitrev8() from linux/bitrev.h +
      bitshift.  Reduces code-repetition.
      Signed-off-by: default avatarUladzislau Koshchanka <koshchanka@gmail.com>
      Link: https://lore.kernel.org/r/20221210004423.32332-1-koshchanka@gmail.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      1280d4b7
    • Kurt Kanzenbach's avatar
      dt-bindings: net: dsa: hellcreek: Sync DSA maintainers · 93e637a3
      Kurt Kanzenbach authored
      The current DSA maintainers are Florian Fainelli, Andrew Lunn and Vladimir
      Oltean. Update the hellcreek binding accordingly.
      Signed-off-by: Kurt Kanzenbach's avatarKurt Kanzenbach <kurt@linutronix.de>
      Reviewed-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Acked-by: default avatarRob Herring <robh@kernel.org>
      Acked-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Link: https://lore.kernel.org/r/20221212081546.6916-1-kurt@linutronix.deSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      93e637a3
    • Yunsheng Lin's avatar
      net: tso: inline tso_count_descs() · d7b061b8
      Yunsheng Lin authored
      tso_count_descs() is a small function doing simple calculation,
      and tso_count_descs() is used in fast path, so inline it to
      reduce the overhead of calls.
      Signed-off-by: default avatarYunsheng Lin <linyunsheng@huawei.com>
      Link: https://lore.kernel.org/r/20221212032426.16050-1-linyunsheng@huawei.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      d7b061b8
    • Vladimir Oltean's avatar
      net: dsa: don't call ptp_classify_raw() if switch doesn't provide RX timestamping · 8f18655c
      Vladimir Oltean authored
      ptp_classify_raw() is not exactly cheap, since it invokes a BPF program
      for every skb in the receive path. For switches which do not provide
      ds->ops->port_rxtstamp(), running ptp_classify_raw() provides precisely
      nothing, so check for the presence of the function pointer first, since
      that is much cheaper.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Reviewed-by: Kurt Kanzenbach's avatarKurt Kanzenbach <kurt@linutronix.de>
      Link: https://lore.kernel.org/r/20221209175840.390707-1-vladimir.oltean@nxp.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      8f18655c
    • Jakub Kicinski's avatar
      Merge branch 'trace-points-for-mv88e6xxx' · cd2aafa2
      Jakub Kicinski authored
      Vladimir Oltean says:
      
      ====================
      Trace points for mv88e6xxx
      
      While testing Hans Schultz' attempt at offloading MAB on mv88e6xxx:
      https://patchwork.kernel.org/project/netdevbpf/cover/20221205185908.217520-1-netdev@kapio-technology.com/
      I noticed that he still didn't get rid of the huge log spam caused by
      ATU and VTU violations, even if we discussed about this:
      https://patchwork.kernel.org/project/netdevbpf/cover/20221112203748.68995-1-netdev@kapio-technology.com/#25091076
      
      It seems unlikely he's going to ever do this, so here is my own stab at
      converting those messages to trace points. This is IMO an improvement
      regardless of whether Hans' work with MAB lands or not, especially the
      VTU violations which were quite annoying to me as well.
      
      A small sample of before:
      
      $ ./bridge_locked_port.sh lan1 lan2 lan3 lan4
      [  114.465272] mv88e6085 d0032004.mdio-mii:10: VTU member violation for vid 100, source port 9
      [  119.550508] mv88e6xxx_g1_vtu_prob_irq_thread_fn: 34 callbacks suppressed
      [  120.369586] mv88e6085 d0032004.mdio-mii:10: VTU member violation for vid 100, source port 9
      [  120.473658] mv88e6085 d0032004.mdio-mii:10: VTU member violation for vid 100, source port 9
      [  125.535209] mv88e6xxx_g1_vtu_prob_irq_thread_fn: 21 callbacks suppressed
      [  125.535243] mv88e6085 d0032004.mdio-mii:10: VTU member violation for vid 100, source port 9
      [  126.174558] mv88e6085 d0032004.mdio-mii:10: VTU member violation for vid 100, source port 9
      [  130.234055] mv88e6085 d0032004.mdio-mii:10: ATU miss violation for 00:01:02:03:04:01 fid 3 portvec 4 spid 2
      [  130.338193] mv88e6085 d0032004.mdio-mii:10: ATU miss violation for 00:01:02:03:04:01 fid 3 portvec 4 spid 2
      [  134.626099] mv88e6xxx_g1_atu_prob_irq_thread_fn: 38 callbacks suppressed
      [  134.626132] mv88e6085 d0032004.mdio-mii:10: ATU miss violation for 00:01:02:03:04:01 fid 3 portvec 4 spid 2
      
      and after:
      
      $ trace-cmd record -e mv88e6xxx ./bridge_locked_port.sh lan1 lan2 lan3 lan4
      $ trace-cmd report
         irq/35-moxtet-60    [001]    93.929734: mv88e6xxx_vtu_miss_violation: dev d0032004.mdio-mii:10 spid 9 vid 100
         irq/35-moxtet-60    [001]    94.183209: mv88e6xxx_vtu_miss_violation: dev d0032004.mdio-mii:10 spid 9 vid 100
         irq/35-moxtet-60    [001]   101.865545: mv88e6xxx_vtu_miss_violation: dev d0032004.mdio-mii:10 spid 9 vid 100
         irq/35-moxtet-60    [001]   121.831261: mv88e6xxx_vtu_member_violation: dev d0032004.mdio-mii:10 spid 9 vid 100
         irq/35-moxtet-60    [001]   122.371238: mv88e6xxx_vtu_member_violation: dev d0032004.mdio-mii:10 spid 9 vid 100
         irq/35-moxtet-60    [001]   148.452932: mv88e6xxx_atu_miss_violation: dev d0032004.mdio-mii:10 spid 2 portvec 0x4 addr 00:01:02:03:04:01 fid 0
      
      v1 at:
      https://patchwork.kernel.org/project/netdevbpf/cover/20221207233954.3619276-1-vladimir.oltean@nxp.com/
      ====================
      
      Link: https://lore.kernel.org/r/20221209172817.371434-1-vladimir.oltean@nxp.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      cd2aafa2
    • Vladimir Oltean's avatar
      net: dsa: mv88e6xxx: replace VTU violation prints with trace points · 9e3d9ae5
      Vladimir Oltean authored
      It is possible to trigger these VTU violation messages very easily,
      it's only necessary to send packets with an unknown VLAN ID to a port
      that belongs to a VLAN-aware bridge.
      
      Do a similar thing as for ATU violation messages, and hide them in the
      kernel's trace buffer.
      
      New usage model:
      
      $ trace-cmd list | grep mv88e6xxx
      mv88e6xxx
      mv88e6xxx:mv88e6xxx_vtu_miss_violation
      mv88e6xxx:mv88e6xxx_vtu_member_violation
      $ trace-cmd report
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarSaeed Mahameed <saeed@kernel.org>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      9e3d9ae5
    • Vladimir Oltean's avatar
      net: dsa: mv88e6xxx: replace ATU violation prints with trace points · 8646384d
      Vladimir Oltean authored
      In applications where the switch ports must perform 802.1X based
      authentication and are therefore locked, ATU violation interrupts are
      quite to be expected as part of normal operation. The problem is that
      they currently spam the kernel log, even if rate limited.
      
      Create a series of trace points, all derived from the same event class,
      which log these violations to the kernel's trace buffer, which is both
      much faster and much easier to ignore than printing to a serial console.
      
      New usage model:
      
      $ trace-cmd list | grep mv88e6xxx
      mv88e6xxx
      mv88e6xxx:mv88e6xxx_atu_full_violation
      mv88e6xxx:mv88e6xxx_atu_miss_violation
      mv88e6xxx:mv88e6xxx_atu_member_violation
      $ trace-cmd record -e mv88e6xxx sleep 10
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarSaeed Mahameed <saeed@kernel.org>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      8646384d
    • Hans J. Schultz's avatar
      net: dsa: mv88e6xxx: read FID when handling ATU violations · 4bf24ad0
      Hans J. Schultz authored
      When an ATU violation occurs, the switch uses the ATU FID register to
      report the FID of the MAC address that incurred the violation. It would
      be good for the driver to know the FID value for purposes such as
      logging and CPU-based authentication.
      
      Up until now, the driver has been calling the mv88e6xxx_g1_atu_op()
      function to read ATU violations, but that doesn't do exactly what we
      want, namely it calls mv88e6xxx_g1_atu_fid_write() with FID 0.
      (side note, the documentation for the ATU Get/Clear Violation command
      says that writes to the ATU FID register have no effect before the
      operation starts, it's only that we disregard the value that this
      register provides once the operation completes)
      
      So mv88e6xxx_g1_atu_fid_write() is not what we want, but rather
      mv88e6xxx_g1_atu_fid_read(). However, the latter doesn't exist, we need
      to write it.
      
      The remainder of mv88e6xxx_g1_atu_op() except for
      mv88e6xxx_g1_atu_fid_write() is still needed, namely to send a
      GET_CLR_VIOLATION command to the ATU. In principle we could have still
      kept calling mv88e6xxx_g1_atu_op(), but the MDIO writes to the ATU FID
      register are pointless, but in the interest of doing less CPU work per
      interrupt, write a new function called mv88e6xxx_g1_read_atu_violation()
      and call it.
      
      The FID will be the port default FID as set by mv88e6xxx_port_set_fid()
      if the VID from the packet cannot be found in the VTU. Otherwise it is
      the FID derived from the VTU entry associated with that VID.
      Signed-off-by: default avatarHans J. Schultz <netdev@kapio-technology.com>
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      4bf24ad0
    • Vladimir Oltean's avatar
      net: dsa: mv88e6xxx: remove ATU age out violation print · 8a1786b7
      Vladimir Oltean authored
      Currently, the MV88E6XXX_PORT_ASSOC_VECTOR_INT_AGE_OUT bit (interrupt on
      age out) is not enabled by the driver, and as a result, the print for
      age out violations is dead code.
      
      Remove it until there is some way for this to be triggered.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      8a1786b7
    • Jakub Kicinski's avatar
      Merge tag 'for-net-next-2022-12-12' of... · 4cc58a08
      Jakub Kicinski authored
      Merge tag 'for-net-next-2022-12-12' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next
      
      Luiz Augusto von Dentz says:
      
      ====================
      bluetooth-next pull request for net-next:
      
       - Add a new VID/PID 0489/e0f2 for MT7922
       - Add Realtek RTL8852BE support ID 0x0cb8:0xc559
       - Add a new PID/VID 13d3/3549 for RTL8822CU
       - Add support for broadcom BCM43430A0 & BCM43430A1
       - Add CONFIG_BT_HCIBTUSB_POLL_SYNC
       - Add CONFIG_BT_LE_L2CAP_ECRED
       - Add support for CYW4373A0
       - Add support for RTL8723DS
       - Add more device IDs for WCN6855
       - Add Broadcom BCM4377 family PCIe Bluetooth
      
      * tag 'for-net-next-2022-12-12' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next: (51 commits)
        Bluetooth: Wait for HCI_OP_WRITE_AUTH_PAYLOAD_TO to complete
        Bluetooth: ISO: Avoid circular locking dependency
        Bluetooth: RFCOMM: don't call kfree_skb() under spin_lock_irqsave()
        Bluetooth: hci_core: don't call kfree_skb() under spin_lock_irqsave()
        Bluetooth: hci_bcsp: don't call kfree_skb() under spin_lock_irqsave()
        Bluetooth: hci_h5: don't call kfree_skb() under spin_lock_irqsave()
        Bluetooth: hci_ll: don't call kfree_skb() under spin_lock_irqsave()
        Bluetooth: hci_qca: don't call kfree_skb() under spin_lock_irqsave()
        Bluetooth: btusb: don't call kfree_skb() under spin_lock_irqsave()
        Bluetooth: btintel: Fix missing free skb in btintel_setup_combined()
        Bluetooth: hci_conn: Fix crash on hci_create_cis_sync
        Bluetooth: btintel: Fix existing sparce warnings
        Bluetooth: btusb: Fix existing sparce warning
        Bluetooth: btusb: Fix new sparce warnings
        Bluetooth: btusb: Add a new PID/VID 13d3/3549 for RTL8822CU
        Bluetooth: btusb: Add Realtek RTL8852BE support ID 0x0cb8:0xc559
        dt-bindings: net: realtek-bluetooth: Add RTL8723DS
        Bluetooth: btusb: Add a new VID/PID 0489/e0f2 for MT7922
        dt-bindings: bluetooth: broadcom: add BCM43430A0 & BCM43430A1
        Bluetooth: hci_bcm4377: Fix missing pci_disable_device() on error in bcm4377_probe()
        ...
      ====================
      
      Link: https://lore.kernel.org/r/20221212222322.1690780-1-luiz.dentz@gmail.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      4cc58a08
    • Jakub Kicinski's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf-next · 95d1815f
      Jakub Kicinski authored
      Pablo Neira Ayuso says:
      
      ====================
      Netfilter/IPVS updates for net-next
      
      1) Incorrect error check in nft_expr_inner_parse(), from Dan Carpenter.
      
      2) Add DATA_SENT state to SCTP connection tracking helper, from
         Sriram Yagnaraman.
      
      3) Consolidate nf_confirm for ipv4 and ipv6, from Florian Westphal.
      
      4) Add bitmask support for ipset, from Vishwanath Pai.
      
      5) Handle icmpv6 redirects as RELATED, from Florian Westphal.
      
      6) Add WARN_ON_ONCE() to impossible case in flowtable datapath,
         from Li Qiong.
      
      7) A large batch of IPVS updates to replace timer-based estimators by
         kthreads to scale up wrt. CPUs and workload (millions of estimators).
      
      Julian Anastasov says:
      
      	This patchset implements stats estimation in kthread context.
      It replaces the code that runs on single CPU in timer context every 2
      seconds and causing latency splats as shown in reports [1], [2], [3].
      The solution targets setups with thousands of IPVS services,
      destinations and multi-CPU boxes.
      
      	Spread the estimation on multiple (configured) CPUs and multiple
      time slots (timer ticks) by using multiple chains organized under RCU
      rules.  When stats are not needed, it is recommended to use
      run_estimation=0 as already implemented before this change.
      
      RCU Locking:
      
      - As stats are now RCU-locked, tot_stats, svc and dest which
      hold estimator structures are now always freed from RCU
      callback. This ensures RCU grace period after the
      ip_vs_stop_estimator() call.
      
      Kthread data:
      
      - every kthread works over its own data structure and all
      such structures are attached to array. For now we limit
      kthreads depending on the number of CPUs.
      
      - even while there can be a kthread structure, its task
      may not be running, eg. before first service is added or
      while the sysctl var is set to an empty cpulist or
      when run_estimation is set to 0 to disable the estimation.
      
      - the allocated kthread context may grow from 1 to 50
      allocated structures for timer ticks which saves memory for
      setups with small number of estimators
      
      - a task and its structure may be released if all
      estimators are unlinked from its chains, leaving the
      slot in the array empty
      
      - every kthread data structure allows limited number
      of estimators. Kthread 0 is also used to initially
      calculate the max number of estimators to allow in every
      chain considering a sub-100 microsecond cond_resched
      rate. This number can be from 1 to hundreds.
      
      - kthread 0 has an additional job of optimizing the
      adding of estimators: they are first added in
      temp list (est_temp_list) and later kthread 0
      distributes them to other kthreads. The optimization
      is based on the fact that newly added estimator
      should be estimated after 2 seconds, so we have the
      time to offload the adding to chain from controlling
      process to kthread 0.
      
      - to add new estimators we use the last added kthread
      context (est_add_ktid). The new estimators are linked to
      the chains just before the estimated one, based on add_row.
      This ensures their estimation will start after 2 seconds.
      If estimators are added in bursts, common case if all
      services and dests are initially configured, we may
      spread the estimators to more chains and as result,
      reducing the initial delay below 2 seconds.
      
      Many thanks to Jiri Wiesner for his valuable comments
      and for spending a lot of time reviewing and testing
      the changes on different platforms with 48-256 CPUs and
      1-8 NUMA nodes under different cpufreq governors.
      
      The new IPVS estimators do not use workqueue infrastructure
      because:
      
      - The estimation can take long time when using multiple IPVS rules (eg.
        millions estimator structures) and especially when box has multiple
        CPUs due to the for_each_possible_cpu usage that expects packets from
        any CPU. With est_nice sysctl we have more control how to prioritize the
        estimation kthreads compared to other processes/kthreads that have
        latency requirements (such as servers). As a benefit, we can see these
        kthreads in top and decide if we will need some further control to limit
        their CPU usage (max number of structure to estimate per kthread).
      
      - with kthreads we run code that is read-mostly, no write/lock
        operations to process the estimators in 2-second intervals.
      
      - work items are one-shot: as estimators are processed every
        2 seconds, they need to be re-added every time. This again
        loads the timers (add_timer) if we use delayed works, as there are
        no kthreads to do the timings.
      
      [1] Report from Yunhong Jiang:
          https://lore.kernel.org/netdev/D25792C1-1B89-45DE-9F10-EC350DC04ADC@gmail.com/
      [2] https://marc.info/?l=linux-virtual-server&m=159679809118027&w=2
      [3] Report from Dust:
          https://archive.linuxvirtualserver.org/html/lvs-devel/2020-12/msg00000.html
      
      * git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf-next:
        ipvs: run_estimation should control the kthread tasks
        ipvs: add est_cpulist and est_nice sysctl vars
        ipvs: use kthreads for stats estimation
        ipvs: use u64_stats_t for the per-cpu counters
        ipvs: use common functions for stats allocation
        ipvs: add rcu protection to stats
        netfilter: flowtable: add a 'default' case to flowtable datapath
        netfilter: conntrack: set icmpv6 redirects as RELATED
        netfilter: ipset: Add support for new bitmask parameter
        netfilter: conntrack: merge ipv4+ipv6 confirm functions
        netfilter: conntrack: add sctp DATA_SENT state
        netfilter: nft_inner: fix IS_ERR() vs NULL check
      ====================
      
      Link: https://lore.kernel.org/r/20221211101204.1751-1-pablo@netfilter.orgSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      95d1815f
    • Luiz Augusto von Dentz's avatar
      Bluetooth: Wait for HCI_OP_WRITE_AUTH_PAYLOAD_TO to complete · 7aca0ac4
      Luiz Augusto von Dentz authored
      This make sure HCI_OP_WRITE_AUTH_PAYLOAD_TO completes before notifying
      the encryption change just as is done with HCI_OP_READ_ENC_KEY_SIZE.
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      7aca0ac4
    • Luiz Augusto von Dentz's avatar
      Bluetooth: ISO: Avoid circular locking dependency · 241f5193
      Luiz Augusto von Dentz authored
      This attempts to avoid circular locking dependency between sock_lock
      and hdev_lock:
      
      WARNING: possible circular locking dependency detected
      6.0.0-rc7-03728-g18dd8ab0a783 #3 Not tainted
      ------------------------------------------------------
      kworker/u3:2/53 is trying to acquire lock:
      ffff888000254130 (sk_lock-AF_BLUETOOTH-BTPROTO_ISO){+.+.}-{0:0}, at:
      iso_conn_del+0xbd/0x1d0
      but task is already holding lock:
      ffffffff9f39a080 (hci_cb_list_lock){+.+.}-{3:3}, at:
      hci_le_cis_estabilished_evt+0x1b5/0x500
      which lock already depends on the new lock.
      the existing dependency chain (in reverse order) is:
      -> #2 (hci_cb_list_lock){+.+.}-{3:3}:
             __mutex_lock+0x10e/0xfe0
             hci_le_remote_feat_complete_evt+0x17f/0x320
             hci_event_packet+0x39c/0x7d0
             hci_rx_work+0x2bf/0x950
             process_one_work+0x569/0x980
             worker_thread+0x2a3/0x6f0
             kthread+0x153/0x180
             ret_from_fork+0x22/0x30
      -> #1 (&hdev->lock){+.+.}-{3:3}:
             __mutex_lock+0x10e/0xfe0
             iso_connect_cis+0x6f/0x5a0
             iso_sock_connect+0x1af/0x710
             __sys_connect+0x17e/0x1b0
             __x64_sys_connect+0x37/0x50
             do_syscall_64+0x43/0x90
             entry_SYSCALL_64_after_hwframe+0x62/0xcc
      -> #0 (sk_lock-AF_BLUETOOTH-BTPROTO_ISO){+.+.}-{0:0}:
             __lock_acquire+0x1b51/0x33d0
             lock_acquire+0x16f/0x3b0
             lock_sock_nested+0x32/0x80
             iso_conn_del+0xbd/0x1d0
             iso_connect_cfm+0x226/0x680
             hci_le_cis_estabilished_evt+0x1ed/0x500
             hci_event_packet+0x39c/0x7d0
             hci_rx_work+0x2bf/0x950
             process_one_work+0x569/0x980
             worker_thread+0x2a3/0x6f0
             kthread+0x153/0x180
             ret_from_fork+0x22/0x30
      other info that might help us debug this:
      Chain exists of:
        sk_lock-AF_BLUETOOTH-BTPROTO_ISO --> &hdev->lock --> hci_cb_list_lock
       Possible unsafe locking scenario:
             CPU0                    CPU1
             ----                    ----
        lock(hci_cb_list_lock);
                                     lock(&hdev->lock);
                                     lock(hci_cb_list_lock);
        lock(sk_lock-AF_BLUETOOTH-BTPROTO_ISO);
       *** DEADLOCK ***
      4 locks held by kworker/u3:2/53:
       #0: ffff8880021d9130 ((wq_completion)hci0#2){+.+.}-{0:0}, at:
       process_one_work+0x4ad/0x980
       #1: ffff888002387de0 ((work_completion)(&hdev->rx_work)){+.+.}-{0:0},
       at: process_one_work+0x4ad/0x980
       #2: ffff888001ac0070 (&hdev->lock){+.+.}-{3:3}, at:
       hci_le_cis_estabilished_evt+0xc3/0x500
       #3: ffffffff9f39a080 (hci_cb_list_lock){+.+.}-{3:3}, at:
       hci_le_cis_estabilished_evt+0x1b5/0x500
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      241f5193
    • Yang Yingliang's avatar
      Bluetooth: RFCOMM: don't call kfree_skb() under spin_lock_irqsave() · 0ba18967
      Yang Yingliang authored
      It is not allowed to call kfree_skb() from hardware interrupt
      context or with interrupts being disabled. So replace kfree_skb()
      with dev_kfree_skb_irq() under spin_lock_irqsave().
      
      Fixes: 81be03e0 ("Bluetooth: RFCOMM: Replace use of memcpy_from_msg with bt_skb_sendmmsg")
      Signed-off-by: default avatarYang Yingliang <yangyingliang@huawei.com>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      0ba18967
    • Yang Yingliang's avatar
      Bluetooth: hci_core: don't call kfree_skb() under spin_lock_irqsave() · 39c1eb6f
      Yang Yingliang authored
      It is not allowed to call kfree_skb() from hardware interrupt
      context or with interrupts being disabled. So replace kfree_skb()
      with dev_kfree_skb_irq() under spin_lock_irqsave().
      
      Fixes: 9238f36a ("Bluetooth: Add request cmd_complete and cmd_status functions")
      Signed-off-by: default avatarYang Yingliang <yangyingliang@huawei.com>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      39c1eb6f
    • Yang Yingliang's avatar
      Bluetooth: hci_bcsp: don't call kfree_skb() under spin_lock_irqsave() · 7b503e33
      Yang Yingliang authored
      It is not allowed to call kfree_skb() from hardware interrupt
      context or with interrupts being disabled. So replace kfree_skb()
      with dev_kfree_skb_irq() under spin_lock_irqsave().
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: default avatarYang Yingliang <yangyingliang@huawei.com>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      7b503e33
    • Yang Yingliang's avatar
      Bluetooth: hci_h5: don't call kfree_skb() under spin_lock_irqsave() · 383630cc
      Yang Yingliang authored
      It is not allowed to call kfree_skb() from hardware interrupt
      context or with interrupts being disabled. So replace kfree_skb()
      with dev_kfree_skb_irq() under spin_lock_irqsave().
      
      Fixes: 43eb12d7 ("Bluetooth: Fix/implement Three-wire reliable packet sending")
      Signed-off-by: default avatarYang Yingliang <yangyingliang@huawei.com>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      383630cc
    • Yang Yingliang's avatar
      Bluetooth: hci_ll: don't call kfree_skb() under spin_lock_irqsave() · 8f458f78
      Yang Yingliang authored
      It is not allowed to call kfree_skb() from hardware interrupt
      context or with interrupts being disabled. So replace kfree_skb()
      with dev_kfree_skb_irq() under spin_lock_irqsave().
      
      Fixes: 166d2f6a ("[Bluetooth] Add UART driver for Texas Instruments' BRF63xx chips")
      Signed-off-by: default avatarYang Yingliang <yangyingliang@huawei.com>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      8f458f78
    • Yang Yingliang's avatar
      Bluetooth: hci_qca: don't call kfree_skb() under spin_lock_irqsave() · df4cfc91
      Yang Yingliang authored
      It is not allowed to call kfree_skb() from hardware interrupt
      context or with interrupts being disabled. So replace kfree_skb()
      with dev_kfree_skb_irq() under spin_lock_irqsave().
      
      Fixes: 0ff252c1 ("Bluetooth: hciuart: Add support QCA chipset for UART")
      Signed-off-by: default avatarYang Yingliang <yangyingliang@huawei.com>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      df4cfc91
    • Yang Yingliang's avatar
      Bluetooth: btusb: don't call kfree_skb() under spin_lock_irqsave() · b15a6bd3
      Yang Yingliang authored
      It is not allowed to call kfree_skb() from hardware interrupt
      context or with interrupts being disabled. So replace kfree_skb()
      with dev_kfree_skb_irq() under spin_lock_irqsave().
      
      Fixes: 803b5836 ("Bluetooth: btusb: Implement driver internal packet reassembly")
      Signed-off-by: default avatarYang Yingliang <yangyingliang@huawei.com>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      b15a6bd3
    • Wang ShaoBo's avatar
      Bluetooth: btintel: Fix missing free skb in btintel_setup_combined() · cee50ce8
      Wang ShaoBo authored
      skb allocated by __hci_cmd_sync would not be used whether in checking
      for supported iBT hardware variants or after, we should free it in all
      error branches, this patch makes the case read version failed or default
      error case free skb before return.
      
      Fixes: c86c7285 ("Bluetooth: btintel: Fix the legacy bootloader returns tlv based version")
      Fixes: 019a1caa ("Bluetooth: btintel: Refactoring setup routine for bootloader devices")
      Signed-off-by: default avatarWang ShaoBo <bobo.shaobowang@huawei.com>
      Reviewed-by: default avatarTedd Ho-Jeong An <tedd.an@intel.com>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      cee50ce8
    • Luiz Augusto von Dentz's avatar
      Bluetooth: hci_conn: Fix crash on hci_create_cis_sync · 50757a25
      Luiz Augusto von Dentz authored
      When attempting to connect multiple ISO sockets without using
      DEFER_SETUP may result in the following crash:
      
      BUG: KASAN: null-ptr-deref in hci_create_cis_sync+0x18b/0x2b0
      Read of size 2 at addr 0000000000000036 by task kworker/u3:1/50
      
      CPU: 0 PID: 50 Comm: kworker/u3:1 Not tainted
      6.0.0-rc7-02243-gb84a13ff4eda #4373
      Hardware name: QEMU Standard PC (Q35 + ICH9, 2009),
      BIOS 1.16.0-1.fc36 04/01/2014
      Workqueue: hci0 hci_cmd_sync_work
      Call Trace:
       <TASK>
       dump_stack_lvl+0x19/0x27
       kasan_report+0xbc/0xf0
       ? hci_create_cis_sync+0x18b/0x2b0
       hci_create_cis_sync+0x18b/0x2b0
       ? get_link_mode+0xd0/0xd0
       ? __ww_mutex_lock_slowpath+0x10/0x10
       ? mutex_lock+0xe0/0xe0
       ? get_link_mode+0xd0/0xd0
       hci_cmd_sync_work+0x111/0x190
       process_one_work+0x427/0x650
       worker_thread+0x87/0x750
       ? process_one_work+0x650/0x650
       kthread+0x14e/0x180
       ? kthread_exit+0x50/0x50
       ret_from_fork+0x22/0x30
       </TASK>
      
      Fixes: 26afbd82 ("Bluetooth: Add initial implementation of CIS connections")
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      50757a25
    • Luiz Augusto von Dentz's avatar
      Bluetooth: btintel: Fix existing sparce warnings · 069ab3f9
      Luiz Augusto von Dentz authored
      This fix the following warnings detect with make W=1 C=1:
      
      drivers/bluetooth/btintel.c:1041:38: warning: cast to restricted __le32
      drivers/bluetooth/btintel.c:1786:25: warning: cast to restricted __le16
      drivers/bluetooth/btintel.c:1795:25: warning: cast to restricted __le16
      drivers/bluetooth/btintel.c:1796:25: warning: cast to restricted __le16
      drivers/bluetooth/btintel.c:1797:25: warning: cast to restricted __le16
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      069ab3f9
    • Luiz Augusto von Dentz's avatar
      Bluetooth: btusb: Fix existing sparce warning · 42d3b43e
      Luiz Augusto von Dentz authored
      This fix the following warnings detect with make W=1 C=1:
      
      drivers/bluetooth/btusb.c:3426:28: warning: cast to restricted __le32
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      42d3b43e
    • Luiz Augusto von Dentz's avatar
      Bluetooth: btusb: Fix new sparce warnings · cb3648a7
      Luiz Augusto von Dentz authored
      This fix the following warnings detect with make W=1 C=1:
      
      drivers/bluetooth/btusb.c:2212:9: warning: cast to restricted __le16
      drivers/bluetooth/btusb.c:2212:9: warning: cast to restricted __le16
      drivers/bluetooth/btusb.c:2245:18: warning: cast to restricted __le16
      drivers/bluetooth/btusb.c:2249:18: warning: cast to restricted __le16
      drivers/bluetooth/btusb.c:2253:18: warning: cast to restricted __le16
      drivers/bluetooth/btusb.c:2257:18: warning: cast to restricted __le16
      drivers/bluetooth/btusb.c:2261:18: warning: cast to restricted __le16
      drivers/bluetooth/btusb.c:2267:18: warning: cast to restricted __le16
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      cb3648a7
    • Gongwei Li's avatar
      Bluetooth: btusb: Add a new PID/VID 13d3/3549 for RTL8822CU · 6d0a4fe2
      Gongwei Li authored
      * /sys/kernel/debug/usb/devices
      T:  Bus=03 Lev=02 Prnt=02 Port=02 Cnt=03 Dev#=  5 Spd=12   MxCh= 0
      D:  Ver= 1.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
      P:  Vendor=0bda ProdID=b85b Rev= 0.00
      S:  Manufacturer=Realtek
      S:  Product=Bluetooth Radio
      S:  SerialNumber=00e04c000001
      C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA
      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=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
      E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
      I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
      E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
      I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
      I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
      I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
      I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
      Signed-off-by: default avatarGongwei Li <ligongwei@kylinos.cn>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      6d0a4fe2
    • Artem Lukyanov's avatar
      Bluetooth: btusb: Add Realtek RTL8852BE support ID 0x0cb8:0xc559 · 393b4916
      Artem Lukyanov authored
      Add the support ID(0x0cb8, 0xc559) to usb_device_id table for
      Realtek RTL8852BE.
      
      The device info from /sys/kernel/debug/usb/devices as below.
      
      T:  Bus=03 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#=  2 Spd=12   MxCh= 0
      D:  Ver= 1.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
      P:  Vendor=0cb8 ProdID=c559 Rev= 0.00
      S:  Manufacturer=Realtek
      S:  Product=Bluetooth Radio
      S:  SerialNumber=00e04c000001
      C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA
      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=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
      E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
      I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
      E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
      I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
      I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
      I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
      I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
      Signed-off-by: default avatarArtem Lukyanov <dukzcry@ya.ru>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      393b4916
    • Samuel Holland's avatar
      dt-bindings: net: realtek-bluetooth: Add RTL8723DS · ba6ae1fb
      Samuel Holland authored
      RTL8723DS is another variant of the RTL8723 WiFi + Bluetooth chip. It is
      already supported by the hci_uart/btrtl driver. Document the compatible.
      Acked-by: default avatarRob Herring <robh@kernel.org>
      Reviewed-by: default avatarAlistair Francis <alistair@alistair23.me>
      Signed-off-by: default avatarSamuel Holland <samuel@sholland.org>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      ba6ae1fb
    • Andy Chi's avatar
      Bluetooth: btusb: Add a new VID/PID 0489/e0f2 for MT7922 · 13fcc94d
      Andy Chi authored
      Add VID/PID 0489/e0f2 for MediaTek MT7922 Bluetooth chip. Found
      and tested with HP ProBook.
      
      From /sys/kernel/debug/usb/devices:
      
      T:  Bus=03 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#=  2 Spd=480  MxCh= 0
      D:  Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
      P:  Vendor=0489 ProdID=e0f2 Rev= 1.00
      S:  Manufacturer=MediaTek Inc.
      S:  Product=Wireless_Device
      S:  SerialNumber=000000000
      C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=100mA
      A:  FirstIf#= 0 IfCount= 3 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= 512 Ivl=0ms
      E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 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
      I:* If#= 2 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
      E:  Ad=8a(I) Atr=03(Int.) MxPS=  64 Ivl=125us
      E:  Ad=0a(O) Atr=03(Int.) MxPS=  64 Ivl=125us
      I:  If#= 2 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
      E:  Ad=8a(I) Atr=03(Int.) MxPS= 512 Ivl=125us
      E:  Ad=0a(O) Atr=03(Int.) MxPS= 512 Ivl=125us
      Signed-off-by: default avatarAndy Chi <andy.chi@canonical.com>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      13fcc94d
    • Luca Weiss's avatar
      dt-bindings: bluetooth: broadcom: add BCM43430A0 & BCM43430A1 · d4e9b8b8
      Luca Weiss authored
      Document the compatible string for BCM43430A0 bluetooth used in lg-lenok
      and BCM43430A1 used in asus-sparrow.
      Signed-off-by: default avatarLuca Weiss <luca@z3ntu.xyz>
      Reviewed-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Acked-by: default avatarRob Herring <robh@kernel.org>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      d4e9b8b8
    • Yang Yingliang's avatar
      Bluetooth: hci_bcm4377: Fix missing pci_disable_device() on error in bcm4377_probe() · b1e05cfb
      Yang Yingliang authored
      pci_disable_device() need be called while module exiting, switch to use
      pcim_enable(), pci_disable_device() will be called in pcim_release()
      after probe() failure.
      
      Fixes: ab80b2cec05f ("Bluetooth: hci_bcm4377: Add new driver for BCM4377 PCIe boards")
      Signed-off-by: default avatarYang Yingliang <yangyingliang@huawei.com>
      Reviewed-by: default avatarSven Peter <sven@svenpeter.dev>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      b1e05cfb
    • Raman Varabets's avatar
      Bluetooth: btusb: Add Realtek 8761BUV support ID 0x2B89:0x8761 · ac09bb3f
      Raman Varabets authored
      Identifies as "Realtek Bluetooth Radio";
      used in UGREEN CM390 (P/N 80889).
      
      Device description at /sys/kernel/debug/usb/devices:
      
      T:  Bus=01 Lev=02 Prnt=02 Port=01 Cnt=01 Dev#=  7 Spd=12   MxCh= 0
      D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
      P:  Vendor=2b89 ProdID=8761 Rev= 2.00
      S:  Manufacturer=Realtek
      S:  Product=Bluetooth Radio
      S:  SerialNumber=00E04C239987
      C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA
      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=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
      E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
      I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
      E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
      I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
      I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
      I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
      I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
      Signed-off-by: default avatarRaman Varabets <linux-bluetooth@cyborgize.sg>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      ac09bb3f
    • Sven Peter's avatar
      Bluetooth: hci_bcm4377: Add new driver for BCM4377 PCIe boards · 8a061276
      Sven Peter authored
      Broadcom BCM4377/4378/4387 are dual WiFi/Bluetooth boards found in Apple
      machines. This driver adds support for the Bluetooth function which
      exposes a shared memory IPC protocol over PCIe to tunnel HCI traffic.
      Signed-off-by: default avatarSven Peter <sven@svenpeter.dev>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      8a061276
    • Sven Peter's avatar
      Bluetooth: Add quirk to disable MWS Transport Configuration · ffcb0a44
      Sven Peter authored
      Broadcom 4378/4387 controllers found in Apple Silicon Macs claim to
      support getting MWS Transport Layer Configuration,
      
      < HCI Command: Read Local Supported... (0x04|0x0002) plen 0
      > HCI Event: Command Complete (0x0e) plen 68
            Read Local Supported Commands (0x04|0x0002) ncmd 1
              Status: Success (0x00)
      [...]
                Get MWS Transport Layer Configuration (Octet 30 - Bit 3)]
      [...]
      
      , but then don't actually allow the required command:
      
      > HCI Event: Command Complete (0x0e) plen 15
            Get MWS Transport Layer Configuration (0x05|0x000c) ncmd 1
              Status: Command Disallowed (0x0c)
              Number of transports: 0
              Baud rate list: 0 entries
              00 00 00 00 00 00 00 00 00 00
      Signed-off-by: default avatarSven Peter <sven@svenpeter.dev>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      ffcb0a44
    • Sven Peter's avatar
      Bluetooth: Add quirk to disable extended scanning · 392fca35
      Sven Peter authored
      Broadcom 4377 controllers found in Apple x86 Macs with the T2 chip
      claim to support extended scanning when querying supported states,
      
      < HCI Command: LE Read Supported St.. (0x08|0x001c) plen 0
      > HCI Event: Command Complete (0x0e) plen 12
            LE Read Supported States (0x08|0x001c) ncmd 1
              Status: Success (0x00)
              States: 0x000003ffffffffff
      [...]
                LE Set Extended Scan Parameters (Octet 37 - Bit 5)
                LE Set Extended Scan Enable (Octet 37 - Bit 6)
      [...]
      
      , but then fail to actually implement the extended scanning:
      
      < HCI Command: LE Set Extended Sca.. (0x08|0x0041) plen 8
              Own address type: Random (0x01)
              Filter policy: Accept all advertisement (0x00)
              PHYs: 0x01
              Entry 0: LE 1M
                Type: Active (0x01)
                Interval: 11.250 msec (0x0012)
                Window: 11.250 msec (0x0012)
      > HCI Event: Command Complete (0x0e) plen 4
            LE Set Extended Scan Parameters (0x08|0x0041) ncmd 1
              Status: Unknown HCI Command (0x01)
      Signed-off-by: default avatarSven Peter <sven@svenpeter.dev>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      392fca35
    • Sven Peter's avatar
      Bluetooth: hci_event: Ignore reserved bits in LE Extended Adv Report · ad38e55e
      Sven Peter authored
      Broadcom controllers present on Apple Silicon devices use the upper
      8 bits of the event type in the LE Extended Advertising Report for
      the channel on which the frame has been received.
      These bits are reserved according to the Bluetooth spec anyway such that
      we can just drop them to ensure that the advertising results are parsed
      correctly.
      
      The following excerpt from a btmon trace shows a report received on
      channel 37 by these controllers:
      
      > HCI Event: LE Meta Event (0x3e) plen 55
            LE Extended Advertising Report (0x0d)
              Num reports: 1
              Entry 0
                Event type: 0x2513
                  Props: 0x0013
                    Connectable
                    Scannable
                    Use legacy advertising PDUs
                  Data status: Complete
                  Reserved (0x2500)
                Legacy PDU Type: Reserved (0x2513)
                Address type: Public (0x00)
                Address: XX:XX:XX:XX:XX:XX (Shenzhen Jingxun Software [...])
                Primary PHY: LE 1M
                Secondary PHY: No packets
                SID: no ADI field (0xff)
                TX power: 127 dBm
                RSSI: -76 dBm (0xb4)
                Periodic advertising interval: 0.00 msec (0x0000)
                Direct address type: Public (0x00)
                Direct address: 00:00:00:00:00:00 (OUI 00-00-00)
                Data length: 0x1d
                [...]
              Flags: 0x18
                Simultaneous LE and BR/EDR (Controller)
                Simultaneous LE and BR/EDR (Host)
              Company: Harman International Industries, Inc. (87)
                Data: [...]
              Service Data (UUID 0xfddf):
              Name (complete): JBL Flip 5
      Signed-off-by: default avatarSven Peter <sven@svenpeter.dev>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      ad38e55e