linux-2.6-microblaze.git
22 months agowifi: mac80211: rx: track link in RX data
Johannes Berg [Thu, 21 Jul 2022 11:08:13 +0000 (13:08 +0200)]
wifi: mac80211: rx: track link in RX data

We'll need the link e.g. for decrypt, and shouldn't be
looking it up all the time later, so track it in the RX
data.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
22 months agowifi: mac80211: optionally implement MLO multicast TX
Johannes Berg [Thu, 21 Jul 2022 08:56:48 +0000 (10:56 +0200)]
wifi: mac80211: optionally implement MLO multicast TX

For drivers using software encryption for multicast TX, such
as mac80211_hwsim, mac80211 needs to duplicate the multicast
frames on each link, if MLO is enabled. Do this, but don't
just make it dependent on the key but provide a separate flag
for drivers to opt out of this.

This is not very efficient, I expect that drivers will do it
in firmware/hardware or at least with DMA engine assistence,
so this is mostly for hwsim.

To make this work, also implement the SNS11 sequence number
space that an AP MLD shall have, and modify the API to the
__ieee80211_subif_start_xmit() function to always require the
link ID bits to be set.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
22 months agowifi: mac80211: expand ieee80211_mgmt_tx() for MLO
Johannes Berg [Mon, 18 Jul 2022 19:36:08 +0000 (21:36 +0200)]
wifi: mac80211: expand ieee80211_mgmt_tx() for MLO

There are a couple of new things that should be possible
with MLO:
 * selecting the link to transmit to a station by link ID,
   which a previous patch added to the nl80211 API
 * selecting the link by frequency, similarly
 * allowing transmittion to an MLD without specifying any
   channel or link ID, with MLD addresses

Enable these use cases. Also fix the address comparison
in client mode to use the AP (MLD) address.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
22 months agowifi: nl80211: add MLO link ID to the NL80211_CMD_FRAME TX API
Johannes Berg [Mon, 18 Jul 2022 10:13:46 +0000 (12:13 +0200)]
wifi: nl80211: add MLO link ID to the NL80211_CMD_FRAME TX API

Allow optionally specifying the link ID to transmit on,
which can be done instead of the link frequency, on an
MLD addressed frame. Both can also be omitted in which
case the frame must be MLD addressed and link selection
(and address translation) will be done on lower layers.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
22 months agowifi: mac80211: report link ID to cfg80211 on mgmt RX
Johannes Berg [Mon, 18 Jul 2022 08:42:19 +0000 (10:42 +0200)]
wifi: mac80211: report link ID to cfg80211 on mgmt RX

For frames received on an MLD, report the link ID to
userspace.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
22 months agowifi: cfg80211: report link ID in NL80211_CMD_FRAME
Johannes Berg [Mon, 18 Jul 2022 08:40:44 +0000 (10:40 +0200)]
wifi: cfg80211: report link ID in NL80211_CMD_FRAME

If given by the underlying driver, report the link ID for
MLO in NL80211_CMD_FRAME.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
22 months agowifi: mac80211: add hardware timestamps for RX and TX
Avraham Stern [Wed, 26 Jan 2022 09:15:31 +0000 (11:15 +0200)]
wifi: mac80211: add hardware timestamps for RX and TX

When the low level driver reports hardware timestamps for frame
TX status or frame RX, pass the timestamps to cfg80211.

Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
22 months agowifi: cfg80211: add hardware timestamps to frame RX info
Avraham Stern [Thu, 27 Jan 2022 11:56:29 +0000 (13:56 +0200)]
wifi: cfg80211: add hardware timestamps to frame RX info

Add hardware timestamps to management frame RX info.
This shall be used by drivers that support hardware timestamping for
Timing measurement and Fine timing measurement action frames RX.

Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
22 months agowifi: cfg80211/nl80211: move rx management data into a struct
Avraham Stern [Sun, 30 Jan 2022 16:17:51 +0000 (18:17 +0200)]
wifi: cfg80211/nl80211: move rx management data into a struct

The functions for reporting rx management take many arguments.
Collect all the arguments into a struct, which also make it easier
to add more arguments if needed.

Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
22 months agowifi: cfg80211: add a function for reporting TX status with hardware timestamps
Avraham Stern [Wed, 26 Jan 2022 17:13:47 +0000 (19:13 +0200)]
wifi: cfg80211: add a function for reporting TX status with hardware timestamps

Add a function for reporting TX status with hardware timestamps. This
function shall be used for reporting the TX status of Timing
measurement and Fine timing measurement action frames by devices that
support reporting hardware timestamps.

Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
22 months agowifi: nl80211: add RX and TX timestamp attributes
Avraham Stern [Wed, 26 Jan 2022 14:06:35 +0000 (16:06 +0200)]
wifi: nl80211: add RX and TX timestamp attributes

Add attributes for reporting hardware timestamps for management frames
RX and TX. These attributes will be used for reporting hardware
timestamps for Timing measurement and Fine Timing Measurement action
frames, which will allow userspace applications to measure the path
delay between devices and sync clocks.

For TX, these attributes are used for reporting the frame RX time and
the ack TX time. For TX, they are used for reporting the frame TX time
and the ack RX time.

Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
22 months agowifi: ieee80211: add helper functions for detecting TM/FTM frames
Avraham Stern [Thu, 27 Jan 2022 12:39:46 +0000 (14:39 +0200)]
wifi: ieee80211: add helper functions for detecting TM/FTM frames

Add helper functions for detection timing measurement
and fine timing measurement frames.

Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
22 months agowifi: mac80211_hwsim: handle links for wmediumd/virtio
Johannes Berg [Wed, 20 Jul 2022 20:35:44 +0000 (22:35 +0200)]
wifi: mac80211_hwsim: handle links for wmediumd/virtio

For wmediumd/virtio, handle both the RX channel for links,
as well as the link addresses when links are added/removed.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
22 months agowifi: mac80211: sta_info: fix link_sta insertion
Johannes Berg [Tue, 19 Jul 2022 10:08:29 +0000 (12:08 +0200)]
wifi: mac80211: sta_info: fix link_sta insertion

When inserting a link STA, make sure it doesn't exist first
and add lockdep assertions that we cannot modify the hash
table without holding the sta_mtx, so this check is really
correct.

Also return without hashing if the driver failed, and warn
if the hashing fails, which shouldn't happen due to the
check described above.

Fixes: cb71f1d136a6 ("wifi: mac80211: add sta link addition/removal")
Fixes: ba6ddab94fc6 ("wifi: mac80211: maintain link-sta hash table")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
22 months agowifi: mac80211: mlme: fix link_sta setup
Johannes Berg [Tue, 19 Jul 2022 10:06:17 +0000 (12:06 +0200)]
wifi: mac80211: mlme: fix link_sta setup

We need to copy the address to both the private and public
portion of the link_sta (the private one is needed for the
hash table). Fix this.

Fixes: bbe90107e1d9 ("wifi: mac80211: mlme: refactor link station setup")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
22 months agowifi: nl80211/mac80211: clarify link ID in control port TX
Johannes Berg [Tue, 19 Jul 2022 08:26:50 +0000 (10:26 +0200)]
wifi: nl80211/mac80211: clarify link ID in control port TX

Clarify the link ID behaviour in control port TX, we need it
to select the link to transmit on for both MLD and non-MLD
receivers, but select the link address as the SA only if the
receiver is not an MLD.

Fixes: 67207bab9341 ("wifi: cfg80211/mac80211: Support control port TX from specific link")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
22 months agowifi: mac80211: return error from control port TX for drops
Johannes Berg [Tue, 19 Jul 2022 07:37:59 +0000 (09:37 +0200)]
wifi: mac80211: return error from control port TX for drops

If the frame is going to be dropped anyway because
ieee80211_lookup_ra_sta() returned an error (and
even though it's a bit racy, it will likely continue
to do so), return the error out instead of just
silently dropping the frame.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
22 months agowifi: nl80211: require MLD address on link STA add/modify
Johannes Berg [Tue, 19 Jul 2022 06:44:25 +0000 (08:44 +0200)]
wifi: nl80211: require MLD address on link STA add/modify

We always need the MLD address and link ID to add or
modify the link STA, so require it in the API.

Fixes: 577e5b8c3924 ("wifi: cfg80211: add API to add/modify/remove a link station")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
22 months agowifi: mac80211: more station handling sanity checks
Johannes Berg [Mon, 18 Jul 2022 21:01:19 +0000 (23:01 +0200)]
wifi: mac80211: more station handling sanity checks

Add more sanity checks to the API handling, we shouldn't
be able to create a station without links, nor should we
be able to add a link to a station that wasn't created as
an MLD with links in the first place.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
22 months agowifi: mac80211: fix link sta hash table handling
Johannes Berg [Mon, 18 Jul 2022 20:54:27 +0000 (22:54 +0200)]
wifi: mac80211: fix link sta hash table handling

There are two issues here: we unhash the link stations only
directly before freeing the station they belong to, and we
also don't unhash all the links correctly in all cases. Fix
these issues.

Fixes: ba6ddab94fc6 ("wifi: mac80211: maintain link-sta hash table")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
22 months agowifi: mac80211: validate link address doesn't change
Johannes Berg [Mon, 18 Jul 2022 20:23:53 +0000 (22:23 +0200)]
wifi: mac80211: validate link address doesn't change

When modifying a link station, validate that the link address
doesn't change, except the first time the link is created.

Fixes: b95eb7f0eee4 ("wifi: cfg80211/mac80211: separate link params from station params")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
22 months agowifi: mac80211: mlme: set sta.mlo to mlo state
Johannes Berg [Mon, 18 Jul 2022 14:04:05 +0000 (16:04 +0200)]
wifi: mac80211: mlme: set sta.mlo to mlo state

At this point, we've already changed link_id to be zero for
a non-MLO connection, so use the 'mlo' variable rather than
link ID to determine the MLO status of the station.

Fixes: bd363ee53302 ("wifi: mac80211: mlme: set sta.mlo correctly")
Fixes: 81151ce462e5 ("wifi: mac80211: support MLO authentication/association with one link")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
22 months agowifi: mac80211: fast-xmit: handle non-MLO clients
Johannes Berg [Mon, 18 Jul 2022 14:58:18 +0000 (16:58 +0200)]
wifi: mac80211: fast-xmit: handle non-MLO clients

If there's a non-MLO client, the A2 must be set to the BSSID
of the link since no translation will happen in lower layers
and it's needed that way for encryption.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
22 months agowifi: mac80211_hwsim: fix address translation for MLO
Johannes Berg [Mon, 18 Jul 2022 14:45:50 +0000 (16:45 +0200)]
wifi: mac80211_hwsim: fix address translation for MLO

There are two issues here: we need to do the translation
even in case mac80211 selected a link, and we should only
translate the A3 if it's the BSSID. Fix both.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
22 months agowifi: mac80211: fix RX MLD address translation
Johannes Berg [Mon, 18 Jul 2022 14:40:36 +0000 (16:40 +0200)]
wifi: mac80211: fix RX MLD address translation

We should only translate addr3 here if it's the BSSID.

Fixes: 42fb9148c078 ("wifi: mac80211: do link->MLD address translation on RX")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
22 months agowifi: mac80211: fix NULL pointer deref with non-MLD STA
Johannes Berg [Mon, 18 Jul 2022 07:14:30 +0000 (09:14 +0200)]
wifi: mac80211: fix NULL pointer deref with non-MLD STA

If we have a non-MLD STA on an AP MLD, we crash while
adding the station. Fix that, in this case we need to
use the STA's address also on the link data structure.

Fixes: f36fe0a2df03 ("wifi: mac80211: fix up link station creation/insertion")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
22 months agowifi: mac80211: mlme: fix override calculation
Johannes Berg [Sun, 17 Jul 2022 16:16:51 +0000 (18:16 +0200)]
wifi: mac80211: mlme: fix override calculation

In my previous changes here, I neglected to take the old
conn_flags into account that might still be present from
the authentication, and thus ieee80211_setup_assoc_link()
can misbehave, as well as the override calculation being
wrong. Fix that by ORing in the old flags.

Fixes: 1845c1d4a455 ("wifi: mac80211: mlme: refactor assoc link setup")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
22 months agowifi: mac80211: tx: use AP address in some places for MLO
Johannes Berg [Fri, 15 Jul 2022 13:37:23 +0000 (15:37 +0200)]
wifi: mac80211: tx: use AP address in some places for MLO

In a few places we need to use the AP (MLD) address, not the
deflink BSSID, the link address translation will happen later.

To make that work properly for fast-xmit, set up the ap_addr
in the vif.cfg earlier.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
22 months agonet: add missing includes and forward declarations under net/
Jakub Kicinski [Wed, 20 Jul 2022 23:57:58 +0000 (16:57 -0700)]
net: add missing includes and forward declarations under net/

This patch adds missing includes to headers under include/net.
All these problems are currently masked by the existing users
including the missing dependency before the broken header.

Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
22 months agoMerge branch 'sfc-E100-VF-respresenters'
David S. Miller [Fri, 22 Jul 2022 11:50:07 +0000 (12:50 +0100)]
Merge branch 'sfc-E100-VF-respresenters'

Edward Cree says:

====================
sfc: VF representors for EF100

This series adds representor netdevices for EF100 VFs, as a step towards
 supporting TC offload and vDPA usecases in future patches.
In this first series is basic netdevice creation and packet TX; the
 following series will add the RX path.

v3: dropped massive mcdi_pcol.h patch which was applied separately.
v2: converted comments on struct efx_nic members added in patch #4 to
 kernel-doc (Jakub).  While at it, also gave struct efx_rep its own kdoc
 since several members had comments on them.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>
22 months agosfc: attach/detach EF100 representors along with their owning PF
Edward Cree [Wed, 20 Jul 2022 18:33:49 +0000 (19:33 +0100)]
sfc: attach/detach EF100 representors along with their owning PF

Since representors piggy-back on the PF's queues for TX, they can
 only accept new TXes while the PF is up.  Thus, any operation which
 detaches the PF must first detach all its VFreps.

Signed-off-by: Edward Cree <ecree.xilinx@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
22 months agosfc: hook up ef100 representor TX
Edward Cree [Wed, 20 Jul 2022 18:33:48 +0000 (19:33 +0100)]
sfc: hook up ef100 representor TX

Implement .ndo_start_xmit() by calling into the parent PF's TX path.

Signed-off-by: Edward Cree <ecree.xilinx@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
22 months agosfc: support passing a representor to the EF100 TX path
Edward Cree [Wed, 20 Jul 2022 18:33:47 +0000 (19:33 +0100)]
sfc: support passing a representor to the EF100 TX path

A non-null efv in __ef100_enqueue_skb() indicates that the packet is
 from that representor, should be transmitted with a suitable option
 descriptor (to instruct the switch to deliver it to the representee),
 and should not be accounted to the parent PF's stats or BQL.

Signed-off-by: Edward Cree <ecree.xilinx@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
22 months agosfc: determine representee m-port for EF100 representors
Edward Cree [Wed, 20 Jul 2022 18:29:34 +0000 (19:29 +0100)]
sfc: determine representee m-port for EF100 representors

An MAE port, or m-port, is a port (source/destination for traffic) on
 the Match-Action Engine (the internal switch on EF100).
Representors will use their representee's m-port for two purposes: as
 a destination override on TX from the representor, and as a source
 match in 'default rules' to steer representee traffic (when not
 matched by e.g. a TC flower rule) to representor RX via the parent
 PF's receive queue.

Signed-off-by: Edward Cree <ecree.xilinx@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
22 months agosfc: phys port/switch identification for ef100 reps
Edward Cree [Wed, 20 Jul 2022 18:29:33 +0000 (19:29 +0100)]
sfc: phys port/switch identification for ef100 reps

Requires storing VF index in struct efx_rep.

Signed-off-by: Edward Cree <ecree.xilinx@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
22 months agosfc: add basic ethtool ops to ef100 reps
Edward Cree [Wed, 20 Jul 2022 18:29:30 +0000 (19:29 +0100)]
sfc: add basic ethtool ops to ef100 reps

Signed-off-by: Edward Cree <ecree.xilinx@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
22 months agosfc: add skeleton ef100 VF representors
Edward Cree [Wed, 20 Jul 2022 18:29:28 +0000 (19:29 +0100)]
sfc: add skeleton ef100 VF representors

No net_device_ops yet, just a placeholder netdev created per VF.

Signed-off-by: Edward Cree <ecree.xilinx@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
22 months agosfc: detect ef100 MAE admin privilege/capability at probe time
Edward Cree [Wed, 20 Jul 2022 18:29:26 +0000 (19:29 +0100)]
sfc: detect ef100 MAE admin privilege/capability at probe time

One PCIe function per network port (more precisely, per m-port group) is
 responsible for configuring the Match-Action Engine which performs
 switching and packet modification in the slice to support flower/OVS
 offload.  The GRP_MAE bit in the privilege mask indicates whether a
 given function has this capability.
At probe time, call MCDIs to read the calling function's privilege mask,
 and store the GRP_MAE bit in a new ef100_nic_data member.

Signed-off-by: Edward Cree <ecree.xilinx@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
22 months agosfc: update EF100 register descriptions
Edward Cree [Wed, 20 Jul 2022 18:29:24 +0000 (19:29 +0100)]
sfc: update EF100 register descriptions

Signed-off-by: Edward Cree <ecree.xilinx@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
22 months agoping: support ipv6 ping socket flow labels
Alan Brady [Wed, 20 Jul 2022 18:13:10 +0000 (11:13 -0700)]
ping: support ipv6 ping socket flow labels

Ping sockets don't appear to make any attempt to preserve flow labels
created and set by userspace using IPV6_FLOWINFO_SEND. Instead they are
clobbered by autolabels (if enabled) or zero.

Grab the flowlabel out of the msghdr similar to how rawv6_sendmsg does
it and move the memset up so it doesn't get zeroed after.

Signed-off-by: Alan Brady <alan.brady@intel.com>
Tested-by: Gurucharan <gurucharanx.g@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
22 months agonet: marvell: prestera: use netif_is_any_bridge_port instead of open code
Juhee Kang [Thu, 21 Jul 2022 10:26:48 +0000 (19:26 +0900)]
net: marvell: prestera: use netif_is_any_bridge_port instead of open code

The open code which is netif_is_bridge_port() || netif_is_ovs_port() is
defined as a new helper function on netdev.h like netif_is_any_bridge_port
that can check both IFF flags in 1 go. So use netif_is_any_bridge_port()
function instead of open code. This patch doesn't change logic.

Signed-off-by: Juhee Kang <claudiajkang@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
22 months agomlxsw: use netif_is_any_bridge_port() instead of open code
Juhee Kang [Thu, 21 Jul 2022 10:26:47 +0000 (19:26 +0900)]
mlxsw: use netif_is_any_bridge_port() instead of open code

The open code which is netif_is_bridge_port() || netif_is_ovs_port() is
defined as a new helper function on netdev.h like netif_is_any_bridge_port
that can check both IFF flags in 1 go. So use netif_is_any_bridge_port()
function instead of open code. This patch doesn't change logic.

Signed-off-by: Juhee Kang <claudiajkang@gmail.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
22 months agoMerge branch 'New nf_conntrack kfuncs for insertion, changing timeout, status'
Alexei Starovoitov [Fri, 22 Jul 2022 03:59:43 +0000 (20:59 -0700)]
Merge branch 'New nf_conntrack kfuncs for insertion, changing timeout, status'

Kumar Kartikeya Dwivedi says:

====================

Introduce the following new kfuncs:
 - bpf_{xdp,skb}_ct_alloc
 - bpf_ct_insert_entry
 - bpf_ct_{set,change}_timeout
 - bpf_ct_{set,change}_status

The setting of timeout and status on allocated or inserted/looked up CT
is same as the ctnetlink interface, hence code is refactored and shared
with the kfuncs. It is ensured allocated CT cannot be passed to kfuncs
that expected inserted CT, and vice versa. Please see individual patches
for details.

Changelog:
----------
v6 -> v7:
v6: https://lore.kernel.org/bpf/20220719132430.19993-1-memxor@gmail.com

 * Use .long to encode flags (Alexei)
 * Fix description of KF_RET_NULL in documentation (Toke)

v5 -> v6:
v5: https://lore.kernel.org/bpf/20220623192637.3866852-1-memxor@gmail.com

 * Introduce kfunc flags, rework verifier to work with them
 * Add documentation for kfuncs
 * Add comment explaining TRUSTED_ARGS kfunc flag (Alexei)
 * Fix missing offset check for trusted arguments (Alexei)
 * Change nf_conntrack test minimum delta value to 8

v4 -> v5:
v4: https://lore.kernel.org/bpf/cover.1653600577.git.lorenzo@kernel.org

 * Drop read-only PTR_TO_BTF_ID approach, use struct nf_conn___init (Alexei)
 * Drop acquire release pair code that is no longer required (Alexei)
 * Disable writes into nf_conn, use dedicated helpers (Florian, Alexei)
 * Refactor and share ctnetlink code for setting timeout and status
 * Do strict type matching on finding __ref suffix on argument to
   prevent passing nf_conn___init as nf_conn (offset = 0, match on walk)
 * Remove bpf_ct_opts parameter from bpf_ct_insert_entry
 * Update selftests for new additions, add more negative tests

v3 -> v4:
v3: https://lore.kernel.org/bpf/cover.1652870182.git.lorenzo@kernel.org

 * split bpf_xdp_ct_add in bpf_xdp_ct_alloc/bpf_skb_ct_alloc and
   bpf_ct_insert_entry
 * add verifier code to properly populate/configure ct entry
 * improve selftests

v2 -> v3:
v2: https://lore.kernel.org/bpf/cover.1652372970.git.lorenzo@kernel.org

 * add bpf_xdp_ct_add and bpf_ct_refresh_timeout kfunc helpers
 * remove conntrack dependency from selftests
 * add support for forcing kfunc args to be referenced and related selftests

v1 -> v2:
v1: https://lore.kernel.org/bpf/1327f8f5696ff2bc60400e8f3b79047914ccc837.1651595019.git.lorenzo@kernel.org

 * add bpf_ct_refresh_timeout kfunc selftest

Kumar Kartikeya Dwivedi (10):
  bpf: Introduce 8-byte BTF set
  tools/resolve_btfids: Add support for 8-byte BTF sets
  bpf: Switch to new kfunc flags infrastructure
  bpf: Add support for forcing kfunc args to be trusted
  bpf: Add documentation for kfuncs
  net: netfilter: Deduplicate code in bpf_{xdp,skb}_ct_lookup
  net: netfilter: Add kfuncs to set and change CT timeout
  selftests/bpf: Add verifier tests for trusted kfunc args
  selftests/bpf: Add negative tests for new nf_conntrack kfuncs
  selftests/bpf: Fix test_verifier failed test in unprivileged mode
====================

Signed-off-by: Alexei Starovoitov <ast@kernel.org>
22 months agoselftests/bpf: Fix test_verifier failed test in unprivileged mode
Kumar Kartikeya Dwivedi [Thu, 21 Jul 2022 13:42:45 +0000 (15:42 +0200)]
selftests/bpf: Fix test_verifier failed test in unprivileged mode

Loading the BTF won't be permitted without privileges, hence only test
for privileged mode by setting the prog type. This makes the
test_verifier show 0 failures when unprivileged BPF is enabled.

Fixes: 41188e9e9def ("selftest/bpf: Test for use-after-free bug fix in inline_bpf_loop")
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Link: https://lore.kernel.org/r/20220721134245.2450-14-memxor@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
22 months agoselftests/bpf: Add negative tests for new nf_conntrack kfuncs
Kumar Kartikeya Dwivedi [Thu, 21 Jul 2022 13:42:44 +0000 (15:42 +0200)]
selftests/bpf: Add negative tests for new nf_conntrack kfuncs

Test cases we care about and ensure improper usage is caught and
rejected by the verifier.

Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Link: https://lore.kernel.org/r/20220721134245.2450-13-memxor@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
22 months agoselftests/bpf: Add tests for new nf_conntrack kfuncs
Lorenzo Bianconi [Thu, 21 Jul 2022 13:42:43 +0000 (15:42 +0200)]
selftests/bpf: Add tests for new nf_conntrack kfuncs

Introduce selftests for the following kfunc helpers:
- bpf_xdp_ct_alloc
- bpf_skb_ct_alloc
- bpf_ct_insert_entry
- bpf_ct_set_timeout
- bpf_ct_change_timeout
- bpf_ct_set_status
- bpf_ct_change_status

Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Link: https://lore.kernel.org/r/20220721134245.2450-12-memxor@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
22 months agoselftests/bpf: Add verifier tests for trusted kfunc args
Kumar Kartikeya Dwivedi [Thu, 21 Jul 2022 13:42:42 +0000 (15:42 +0200)]
selftests/bpf: Add verifier tests for trusted kfunc args

Make sure verifier rejects the bad cases and ensure the good case keeps
working. The selftests make use of the bpf_kfunc_call_test_ref kfunc
added in the previous patch only for verification.

Acked-by: Yonghong Song <yhs@fb.com>
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Link: https://lore.kernel.org/r/20220721134245.2450-11-memxor@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
22 months agonet: netfilter: Add kfuncs to set and change CT status
Lorenzo Bianconi [Thu, 21 Jul 2022 13:42:41 +0000 (15:42 +0200)]
net: netfilter: Add kfuncs to set and change CT status

Introduce bpf_ct_set_status and bpf_ct_change_status kfunc helpers in
order to set nf_conn field of allocated entry or update nf_conn status
field of existing inserted entry. Use nf_ct_change_status_common to
share the permitted status field changes between netlink and BPF side
by refactoring ctnetlink_change_status.

It is required to introduce two kfuncs taking nf_conn___init and nf_conn
instead of sharing one because KF_TRUSTED_ARGS flag causes strict type
checking. This would disallow passing nf_conn___init to kfunc taking
nf_conn, and vice versa. We cannot remove the KF_TRUSTED_ARGS flag as we
only want to accept refcounted pointers and not e.g. ct->master.

Hence, bpf_ct_set_* kfuncs are meant to be used on allocated CT, and
bpf_ct_change_* kfuncs are meant to be used on inserted or looked up
CT entry.

Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Co-developed-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Link: https://lore.kernel.org/r/20220721134245.2450-10-memxor@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
22 months agonet: netfilter: Add kfuncs to set and change CT timeout
Kumar Kartikeya Dwivedi [Thu, 21 Jul 2022 13:42:40 +0000 (15:42 +0200)]
net: netfilter: Add kfuncs to set and change CT timeout

Introduce bpf_ct_set_timeout and bpf_ct_change_timeout kfunc helpers in
order to change nf_conn timeout. This is same as ctnetlink_change_timeout,
hence code is shared between both by extracting it out to
__nf_ct_change_timeout. It is also updated to return an error when it
sees IPS_FIXED_TIMEOUT_BIT bit in ct->status, as that check was missing.

It is required to introduce two kfuncs taking nf_conn___init and nf_conn
instead of sharing one because KF_TRUSTED_ARGS flag causes strict type
checking. This would disallow passing nf_conn___init to kfunc taking
nf_conn, and vice versa. We cannot remove the KF_TRUSTED_ARGS flag as we
only want to accept refcounted pointers and not e.g. ct->master.

Apart from this, bpf_ct_set_timeout is only called for newly allocated
CT so it doesn't need to inspect the status field just yet. Sharing the
helpers even if it was possible would make timeout setting helper
sensitive to order of setting status and timeout after allocation.

Hence, bpf_ct_set_* kfuncs are meant to be used on allocated CT, and
bpf_ct_change_* kfuncs are meant to be used on inserted or looked up
CT entry.

Co-developed-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Link: https://lore.kernel.org/r/20220721134245.2450-9-memxor@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
22 months agonet: netfilter: Add kfuncs to allocate and insert CT
Lorenzo Bianconi [Thu, 21 Jul 2022 13:42:39 +0000 (15:42 +0200)]
net: netfilter: Add kfuncs to allocate and insert CT

Introduce bpf_xdp_ct_alloc, bpf_skb_ct_alloc and bpf_ct_insert_entry
kfuncs in order to insert a new entry from XDP and TC programs.
Introduce bpf_nf_ct_tuple_parse utility routine to consolidate common
code.

We extract out a helper __nf_ct_set_timeout, used by the ctnetlink and
nf_conntrack_bpf code, extract it out to nf_conntrack_core, so that
nf_conntrack_bpf doesn't need a dependency on CONFIG_NF_CT_NETLINK.
Later this helper will be reused as a helper to set timeout of allocated
but not yet inserted CT entry.

The allocation functions return struct nf_conn___init instead of
nf_conn, to distinguish allocated CT from an already inserted or looked
up CT. This is later used to enforce restrictions on what kfuncs
allocated CT can be used with.

Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Co-developed-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Link: https://lore.kernel.org/r/20220721134245.2450-8-memxor@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
22 months agonet: netfilter: Deduplicate code in bpf_{xdp,skb}_ct_lookup
Kumar Kartikeya Dwivedi [Thu, 21 Jul 2022 13:42:38 +0000 (15:42 +0200)]
net: netfilter: Deduplicate code in bpf_{xdp,skb}_ct_lookup

Move common checks inside the common function, and maintain the only
difference the two being how to obtain the struct net * from ctx.
No functional change intended.

Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Link: https://lore.kernel.org/r/20220721134245.2450-7-memxor@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
22 months agobpf: Add documentation for kfuncs
Kumar Kartikeya Dwivedi [Thu, 21 Jul 2022 13:42:37 +0000 (15:42 +0200)]
bpf: Add documentation for kfuncs

As the usage of kfuncs grows, we are starting to form consensus on the
kinds of attributes and annotations that kfuncs can have. To better help
developers make sense of the various options available at their disposal
to present an unstable API to the BPF users, document the various kfunc
flags and annotations, their expected usage, and explain the process of
defining and registering a kfunc set.

Cc: KP Singh <kpsingh@kernel.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Link: https://lore.kernel.org/r/20220721134245.2450-6-memxor@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
22 months agobpf: Add support for forcing kfunc args to be trusted
Kumar Kartikeya Dwivedi [Thu, 21 Jul 2022 13:42:36 +0000 (15:42 +0200)]
bpf: Add support for forcing kfunc args to be trusted

Teach the verifier to detect a new KF_TRUSTED_ARGS kfunc flag, which
means each pointer argument must be trusted, which we define as a
pointer that is referenced (has non-zero ref_obj_id) and also needs to
have its offset unchanged, similar to how release functions expect their
argument. This allows a kfunc to receive pointer arguments unchanged
from the result of the acquire kfunc.

This is required to ensure that kfunc that operate on some object only
work on acquired pointers and not normal PTR_TO_BTF_ID with same type
which can be obtained by pointer walking. The restrictions applied to
release arguments also apply to trusted arguments. This implies that
strict type matching (not deducing type by recursively following members
at offset) and OBJ_RELEASE offset checks (ensuring they are zero) are
used for trusted pointer arguments.

Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Link: https://lore.kernel.org/r/20220721134245.2450-5-memxor@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
22 months agobpf: Switch to new kfunc flags infrastructure
Kumar Kartikeya Dwivedi [Thu, 21 Jul 2022 13:42:35 +0000 (15:42 +0200)]
bpf: Switch to new kfunc flags infrastructure

Instead of populating multiple sets to indicate some attribute and then
researching the same BTF ID in them, prepare a single unified BTF set
which indicates whether a kfunc is allowed to be called, and also its
attributes if any at the same time. Now, only one call is needed to
perform the lookup for both kfunc availability and its attributes.

Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Link: https://lore.kernel.org/r/20220721134245.2450-4-memxor@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
22 months agotools/resolve_btfids: Add support for 8-byte BTF sets
Kumar Kartikeya Dwivedi [Thu, 21 Jul 2022 13:42:34 +0000 (15:42 +0200)]
tools/resolve_btfids: Add support for 8-byte BTF sets

A flag is a 4-byte symbol that may follow a BTF ID in a set8. This is
used in the kernel to tag kfuncs in BTF sets with certain flags. Add
support to adjust the sorting code so that it passes size as 8 bytes
for 8-byte BTF sets.

Cc: Jiri Olsa <jolsa@kernel.org>
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Link: https://lore.kernel.org/r/20220721134245.2450-3-memxor@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
22 months agobpf: Introduce 8-byte BTF set
Kumar Kartikeya Dwivedi [Thu, 21 Jul 2022 13:42:33 +0000 (15:42 +0200)]
bpf: Introduce 8-byte BTF set

Introduce support for defining flags for kfuncs using a new set of
macros, BTF_SET8_START/BTF_SET8_END, which define a set which contains
8 byte elements (each of which consists of a pair of BTF ID and flags),
using a new BTF_ID_FLAGS macro.

This will be used to tag kfuncs registered for a certain program type
as acquire, release, sleepable, ret_null, etc. without having to create
more and more sets which was proving to be an unscalable solution.

Now, when looking up whether a kfunc is allowed for a certain program,
we can also obtain its kfunc flags in the same call and avoid further
lookups.

The resolve_btfids change is split into a separate patch.

Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Link: https://lore.kernel.org/r/20220721134245.2450-2-memxor@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
22 months agonet: ipv6: avoid accepting values greater than 2 for accept_untracked_na
Jaehee Park [Wed, 20 Jul 2022 18:36:32 +0000 (14:36 -0400)]
net: ipv6: avoid accepting values greater than 2 for accept_untracked_na

The accept_untracked_na sysctl changed from a boolean to an integer
when a new knob '2' was added. This patch provides a safeguard to avoid
accepting values that are not defined in the sysctl. When setting a
value greater than 2, the user will get an 'invalid argument' warning.

Fixes: aaa5f515b16b ("net: ipv6: new accept_untracked_na option to accept na only if in-network")
Signed-off-by: Jaehee Park <jhpark1013@gmail.com>
Suggested-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Suggested-by: Roopa Prabhu <roopa@nvidia.com>
Reviewed-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Link: https://lore.kernel.org/r/20220720183632.376138-1-jhpark1013@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
22 months agoselftests: tls: add a test for timeo vs lock
Jakub Kicinski [Wed, 20 Jul 2022 20:37:01 +0000 (13:37 -0700)]
selftests: tls: add a test for timeo vs lock

Add a test for recv timeout. Place it in the tls_err
group, so it only runs for TLS 1.2 and 1.3 but not
for every AEAD out there.

Link: https://lore.kernel.org/r/20220720203701.2179034-2-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
22 months agotls: rx: release the sock lock on locking timeout
Jakub Kicinski [Wed, 20 Jul 2022 20:37:00 +0000 (13:37 -0700)]
tls: rx: release the sock lock on locking timeout

Eric reports we should release the socket lock if the entire
"grab reader lock" operation has failed. The callers assume
they don't have to release it or otherwise unwind.

Reported-by: Eric Dumazet <edumazet@google.com>
Reported-by: syzbot+16e72110feb2b653ef27@syzkaller.appspotmail.com
Fixes: 4cbc325ed6b4 ("tls: rx: allow only one reader at a time")
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://lore.kernel.org/r/20220720203701.2179034-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
22 months agoMerge tag 'linux-can-next-for-5.20-20220721' of git://git.kernel.org/pub/scm/linux...
Jakub Kicinski [Fri, 22 Jul 2022 01:45:34 +0000 (18:45 -0700)]
Merge tag 'linux-can-next-for-5.20-20220721' of git://git./linux/kernel/git/mkl/linux-can-next

Marc Kleine-Budde says:

====================
can-next 2022-07-21

The patch is by Vincent Mailhol and fixes a use on an uninitialized
variable in the pch_can driver (introduced in last pull request to
net-next).

* tag 'linux-can-next-for-5.20-20220721' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next:
  can: pch_can: pch_can_error(): initialize errc before using it
====================

Link: https://lore.kernel.org/r/20220721163042.3448384-1-mkl@pengutronix.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
22 months agoBluetooth: mgmt: Fix using hci_conn_abort
Luiz Augusto von Dentz [Tue, 21 Jun 2022 18:58:34 +0000 (11:58 -0700)]
Bluetooth: mgmt: Fix using hci_conn_abort

This fixes using hci_conn_abort instead of using hci_conn_abort_sync.

Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
22 months agoBluetooth: Use bt_status to convert from errno
Luiz Augusto von Dentz [Wed, 4 May 2022 23:49:17 +0000 (16:49 -0700)]
Bluetooth: Use bt_status to convert from errno

If a command cannot be sent or there is a internal error an errno maybe
set instead of a command status.

Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
22 months agoBluetooth: Add bt_status
Luiz Augusto von Dentz [Fri, 8 Apr 2022 22:07:44 +0000 (15:07 -0700)]
Bluetooth: Add bt_status

This adds bt_status which can be used to convert Unix errno to
Bluetooth status.

Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
22 months agoBluetooth: hci_sync: Split hci_dev_open_sync
Luiz Augusto von Dentz [Fri, 1 Apr 2022 23:12:27 +0000 (16:12 -0700)]
Bluetooth: hci_sync: Split hci_dev_open_sync

This splits hci_dev_open_sync so each stage is handle by its own
function so it is easier to identify each stage.

Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
22 months agoBluetooth: hci_sync: Refactor remove Adv Monitor
Manish Mandlik [Wed, 20 Jul 2022 23:21:14 +0000 (16:21 -0700)]
Bluetooth: hci_sync: Refactor remove Adv Monitor

Make use of hci_cmd_sync_queue for removing an advertisement monitor.

Signed-off-by: Manish Mandlik <mmandlik@google.com>
Reviewed-by: Miao-chen Chou <mcchou@google.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
22 months agoBluetooth: hci_sync: Refactor add Adv Monitor
Manish Mandlik [Wed, 20 Jul 2022 23:21:13 +0000 (16:21 -0700)]
Bluetooth: hci_sync: Refactor add Adv Monitor

Make use of hci_cmd_sync_queue for adding an advertisement monitor.

Signed-off-by: Manish Mandlik <mmandlik@google.com>
Reviewed-by: Miao-chen Chou <mcchou@google.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
22 months agoBluetooth: hci_sync: Remove HCI_QUIRK_BROKEN_ERR_DATA_REPORTING
Zijun Hu [Thu, 21 Jul 2022 06:04:33 +0000 (14:04 +0800)]
Bluetooth: hci_sync: Remove HCI_QUIRK_BROKEN_ERR_DATA_REPORTING

Core driver addtionally checks LMP feature bit "Erroneous Data Reporting"
instead of quirk HCI_QUIRK_BROKEN_ERR_DATA_REPORTING to decide if HCI
commands HCI_Read|Write_Default_Erroneous_Data_Reporting are broken, so
remove this unnecessary quirk.

Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com>
Tested-by: Zijun Hu <quic_zijuhu@quicinc.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
22 months agoBluetooth: btusb: Remove HCI_QUIRK_BROKEN_ERR_DATA_REPORTING for fake CSR
Zijun Hu [Thu, 21 Jul 2022 06:04:32 +0000 (14:04 +0800)]
Bluetooth: btusb: Remove HCI_QUIRK_BROKEN_ERR_DATA_REPORTING for fake CSR

Core driver addtionally checks LMP feature bit "Erroneous Data Reporting"
instead of quirk HCI_QUIRK_BROKEN_ERR_DATA_REPORTING to decide if HCI
commands HCI_Read|Write_Default_Erroneous_Data_Reporting are broken, so
remove this unnecessary quirk for fake CSR controllers.

Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
22 months agoBluetooth: btusb: Remove HCI_QUIRK_BROKEN_ERR_DATA_REPORTING for QCA
Zijun Hu [Thu, 21 Jul 2022 06:04:31 +0000 (14:04 +0800)]
Bluetooth: btusb: Remove HCI_QUIRK_BROKEN_ERR_DATA_REPORTING for QCA

Core driver addtionally checks LMP feature bit "Erroneous Data Reporting"
instead of quirk HCI_QUIRK_BROKEN_ERR_DATA_REPORTING to decide if HCI
commands HCI_Read|Write_Default_Erroneous_Data_Reporting are broken, so
remove this unnecessary quirk for QCA controllers.

The reason why these two HCI commands are broken for QCA controllers is
that feature "Erroneous Data Reporting" is not enabled by their firmware
as shown by below log:

@ RAW Open: hcitool (privileged) version 2.22
< HCI Command: Read Local Supported Commands (0x04|0x0002) plen 0
> HCI Event: Command Complete (0x0e) plen 68
  Read Local Supported Commands (0x04|0x0002) ncmd 1
    Status: Success (0x00)
    Commands: 288 entries
......
      Read Default Erroneous Data Reporting (Octet 18 - Bit 2)
      Write Default Erroneous Data Reporting (Octet 18 - Bit 3)
......

< HCI Command: Read Default Erroneous Data Reporting (0x03|0x005a) plen 0
> HCI Event: Command Complete (0x0e) plen 4
  Read Default Erroneous Data Reporting (0x03|0x005a) ncmd 1
    Status: Unknown HCI Command (0x01)

< HCI Command: Read Local Supported Features (0x04|0x0003) plen 0
> HCI Event: Command Complete (0x0e) plen 12
  Read Local Supported Features (0x04|0x0003) ncmd 1
    Status: Success (0x00)
    Features: 0xff 0xfe 0x0f 0xfe 0xd8 0x3f 0x5b 0x87
      3 slot packets
......

Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com>
Tested-by: Zijun Hu <quic_zijuhu@quicinc.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
22 months agoBluetooth: hci_sync: Check LMP feature bit instead of quirk
Zijun Hu [Thu, 21 Jul 2022 06:04:30 +0000 (14:04 +0800)]
Bluetooth: hci_sync: Check LMP feature bit instead of quirk

BT core driver should addtionally check LMP feature bit
"Erroneous Data Reporting" instead of quirk
HCI_QUIRK_BROKEN_ERR_DATA_REPORTING set by BT device driver to decide if
HCI commands HCI_Read|Write_Default_Erroneous_Data_Reporting are broken.

BLUETOOTH CORE SPECIFICATION Version 5.3 | Vol 2, Part C | page 587
This feature indicates whether the device is able to support the
Packet_Status_Flag and the HCI commands HCI_Write_Default_-
Erroneous_Data_Reporting and HCI_Read_Default_Erroneous_-
Data_Reporting.

the quirk was introduced by 'commit cde1a8a99287 ("Bluetooth: btusb: Fix
and detect most of the Chinese Bluetooth controllers")' to mark HCI
commands HCI_Read|Write_Default_Erroneous_Data_Reporting broken by BT
device driver, but the reason why these two HCI commands are broken is
that feature "Erroneous Data Reporting" is not enabled by firmware, this
scenario is illustrated by below log of QCA controllers with USB I/F:

@ RAW Open: hcitool (privileged) version 2.22
< HCI Command: Read Local Supported Commands (0x04|0x0002) plen 0
> HCI Event: Command Complete (0x0e) plen 68
      Read Local Supported Commands (0x04|0x0002) ncmd 1
        Status: Success (0x00)
        Commands: 288 entries
......
          Read Default Erroneous Data Reporting (Octet 18 - Bit 2)
          Write Default Erroneous Data Reporting (Octet 18 - Bit 3)
......

< HCI Command: Read Default Erroneous Data Reporting (0x03|0x005a) plen 0
> HCI Event: Command Complete (0x0e) plen 4
      Read Default Erroneous Data Reporting (0x03|0x005a) ncmd 1
        Status: Unknown HCI Command (0x01)

< HCI Command: Read Local Supported Features (0x04|0x0003) plen 0
> HCI Event: Command Complete (0x0e) plen 12
      Read Local Supported Features (0x04|0x0003) ncmd 1
        Status: Success (0x00)
        Features: 0xff 0xfe 0x0f 0xfe 0xd8 0x3f 0x5b 0x87
          3 slot packets
......

Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com>
Tested-by: Zijun Hu <quic_zijuhu@quicinc.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
22 months agoBluetooth: hci_sync: Correct hci_set_event_mask_page_2_sync() event mask
Zijun Hu [Wed, 13 Jul 2022 06:53:14 +0000 (14:53 +0800)]
Bluetooth: hci_sync: Correct hci_set_event_mask_page_2_sync() event mask

Event HCI_Truncated_Page_Complete should belong to central
and HCI_Peripheral_Page_Response_Timeout should belong to
peripheral, but hci_set_event_mask_page_2_sync() take these
two events for wrong roles, so correct it by this change.

Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
22 months agoBluetooth: btusb: Add a new VID/PID 0489/e0e2 for MT7922
He Wang [Sat, 25 Jun 2022 09:03:57 +0000 (17:03 +0800)]
Bluetooth: btusb: Add a new VID/PID 0489/e0e2 for MT7922

Add VID/PID 0489:e0e2 for MediaTek MT7922 Bluetooth chip. Found and
tested with Asus UM5302TA.

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=e0e2 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: He Wang <xw897002528@gmail.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
22 months agoBluetooth: btusb: Set HCI_QUIRK_BROKEN_ENHANCED_SETUP_SYNC_CONN for MTK
Yuri D'Elia [Wed, 13 Jul 2022 15:29:13 +0000 (17:29 +0200)]
Bluetooth: btusb: Set HCI_QUIRK_BROKEN_ENHANCED_SETUP_SYNC_CONN for MTK

This sets HCI_QUIRK_BROKEN_ENHANCED_SETUP_SYNC_CONN for MTK controllers
since SCO appear to not work when using HCI_OP_ENHANCED_SETUP_SYNC_CONN.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=215576
Signed-off-by: Yuri D'Elia <wavexx@thregr.org>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
22 months agoBluetooth: hci_bcm: Increase host baudrate for CYW55572 in autobaud mode
Hakan Jansson [Thu, 30 Jun 2022 12:53:45 +0000 (14:53 +0200)]
Bluetooth: hci_bcm: Increase host baudrate for CYW55572 in autobaud mode

Add device specific data for max baudrate in autobaud mode. This allows the
host to use a baudrate higher than "init speed" when loading FW in autobaud
mode.

The device specific max baudrate in autobaud mode for CYW55572 is set to
921600 bps. Devices without device specific max baudrate in autobaud mode
will use init speed as before. If no device specific init speed has been
specified, it will default to the bcm_proto default 115200 bps.

The increased baud rate improves FW load time. The exact load time will
depend on the specific system and FW being used. As a rough indication,
the FW load time dropped from ~9s @ 115.2kbps to ~1.7s @ 921.6kbps in one
test.

Signed-off-by: Hakan Jansson <hakan.jansson@infineon.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
22 months agoBluetooth: hci_bcm: Prevent early baudrate setting in autobaud mode
Hakan Jansson [Thu, 30 Jun 2022 12:45:23 +0000 (14:45 +0200)]
Bluetooth: hci_bcm: Prevent early baudrate setting in autobaud mode

Always prevent trying to set device baudrate before calling setup() when
using autobaud mode.

This was previously happening for devices which had device specific data
with member no_early_set_baudrate set to 0.

Signed-off-by: Hakan Jansson <hakan.jansson@infineon.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
22 months agoBluetooth: hci_bcm: Add DT compatible for CYW55572
Hakan Jansson [Thu, 30 Jun 2022 12:45:22 +0000 (14:45 +0200)]
Bluetooth: hci_bcm: Add DT compatible for CYW55572

CYW55572 is a Wi-Fi + Bluetooth combo device from Infineon.

Signed-off-by: Hakan Jansson <hakan.jansson@infineon.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
22 months agodt-bindings: net: broadcom-bluetooth: Add conditional constraints
Hakan Jansson [Thu, 30 Jun 2022 12:45:21 +0000 (14:45 +0200)]
dt-bindings: net: broadcom-bluetooth: Add conditional constraints

Add conditional constraint to make property "reset-gpios" available only
for compatible devices acually having the reset pin.

Make property "brcm,requires-autobaud-mode" depend on property
"shutdown-gpios" as the shutdown pin is required to enter autobaud mode.

I looked at all compatible devices and compiled the matrix below before
formulating the conditional constraint. This was a pure paper exercise and
no verification testing has been performed.

                                d
                                e
                                v h
                                i o
                                c s
                            s   e t
                            h   - -
                            u   w w       v
                            t r a a     v d
                            d e k k     b d
                            o s e e     a i
                            w e u u     t o
                            n t p p     - -
                            - - - -     s s
                            g g g g     u u
                            p p p p t   p p
                            i i i i x l p p
                            o o o o c p l l
                            s s s s o o y y
    ---------------------------------------
    brcm,bcm20702a1         X X X X X X X X
    brcm,bcm4329-bt         X X X X X X X X
    brcm,bcm4330-bt         X X X X X X X X
    brcm,bcm4334-bt         X - X X X X X X
    brcm,bcm43438-bt        X - X X X X X X
    brcm,bcm4345c5          X - X X X X X X
    brcm,bcm43540-bt        X - X X X X X X
    brcm,bcm4335a0          X - X X X X X X
    brcm,bcm4349-bt         X - X X X X X X
    infineon,cyw55572-bt    X - X X X X X X

Signed-off-by: Hakan Jansson <hakan.jansson@infineon.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
22 months agodt-bindings: net: broadcom-bluetooth: Add CYW55572 DT binding
Hakan Jansson [Thu, 30 Jun 2022 12:45:20 +0000 (14:45 +0200)]
dt-bindings: net: broadcom-bluetooth: Add CYW55572 DT binding

CYW55572 is a Wi-Fi + Bluetooth combo device from Infineon.
Extend the binding with its DT compatible.

Signed-off-by: Hakan Jansson <hakan.jansson@infineon.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
22 months agoBluetooth: clean up error pointer checking
Dan Carpenter [Wed, 20 Jul 2022 11:23:49 +0000 (14:23 +0300)]
Bluetooth: clean up error pointer checking

The bt_skb_sendmsg() function can't return NULL so there is no need to
check for that.  Several of these checks were removed previously but
this one was missed.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
22 months agoBluetooth: btusb: Add Realtek RTL8852C support ID 0x13D3:0x3586
Hilda Wu [Thu, 14 Jul 2022 11:25:23 +0000 (19:25 +0800)]
Bluetooth: btusb: Add Realtek RTL8852C support ID 0x13D3:0x3586

Add the support ID(0x13D3, 0x3586) to usb_device_id table for
Realtek RTL8852C.

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=13d3 ProdID=3586 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: Hilda Wu <hildawu@realtek.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
22 months agoBluetooth: btusb: Add Realtek RTL8852C support ID 0x13D3:0x3587
Hilda Wu [Thu, 14 Jul 2022 11:25:22 +0000 (19:25 +0800)]
Bluetooth: btusb: Add Realtek RTL8852C support ID 0x13D3:0x3587

Add the support ID(0x13D3, 0x3587) to usb_device_id table for
Realtek RTL8852C.

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=13d3 ProdID=3587 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: Hilda Wu <hildawu@realtek.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
22 months agoBluetooth: btusb: Add Realtek RTL8852C support ID 0x0CB8:0xC558
Hilda Wu [Thu, 14 Jul 2022 11:25:21 +0000 (19:25 +0800)]
Bluetooth: btusb: Add Realtek RTL8852C support ID 0x0CB8:0xC558

Add the support ID(0x0CB8, 0xC558) to usb_device_id table for
Realtek RTL8852C.

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=c558 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: Hilda Wu <hildawu@realtek.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
22 months agoBluetooth: btusb: Add Realtek RTL8852C support ID 0x04C5:0x1675
Hilda Wu [Thu, 14 Jul 2022 11:25:20 +0000 (19:25 +0800)]
Bluetooth: btusb: Add Realtek RTL8852C support ID 0x04C5:0x1675

Add the support ID(0x04c5, 0x1675) to usb_device_id table for
Realtek RTL8852C.

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=04c5 ProdID=1675 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: Hilda Wu <hildawu@realtek.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
22 months agoBluetooth: btusb: Add Realtek RTL8852C support ID 0x04CA:0x4007
Hilda Wu [Thu, 14 Jul 2022 11:25:19 +0000 (19:25 +0800)]
Bluetooth: btusb: Add Realtek RTL8852C support ID 0x04CA:0x4007

Add the support ID(0x04CA, 0x4007) to usb_device_id table for
Realtek RTL8852C.

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=04ca ProdID=4007 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: Hilda Wu <hildawu@realtek.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
22 months agoBluetooth: Add default wakeup callback for HCI UART driver
Ying Hsu [Mon, 4 Jul 2022 10:33:24 +0000 (18:33 +0800)]
Bluetooth: Add default wakeup callback for HCI UART driver

Bluetooth HCI devices indicate if they are able to wakeup in the wakeup
callback since 'commit 4539ca67fe8e ("Bluetooth: Rename driver
.prevent_wake to .wakeup")'. This patch adds a default wakeup callback
for Bluetooth HCI UAR devices. It assumes Bluetooth HCI UART devices are
wakeable for backward compatibility. For those who need a customized
behavior, one can override it before calling hci_uart_register_device().

Fixes: 4539ca67fe8e ("Bluetooth: Rename driver .prevent_wake to .wakeup")
Signed-off-by: Ying Hsu <yinghsu@chromium.org>
Reviewed-by: Alain Michaud <alainm@chromium.org>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
22 months agoBluetooth: hci_sync: Don't remove connected devices from accept list
Luiz Augusto von Dentz [Thu, 14 Jul 2022 00:17:55 +0000 (17:17 -0700)]
Bluetooth: hci_sync: Don't remove connected devices from accept list

These devices are likely going to be reprogrammed when disconnected so
this avoid a whole bunch of commands attempt to remove and the add back
to the list.

Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Tested-by: Zhengping Jiang <jiangzp@google.com>
22 months agoBluetooth: hci_sync: Fix not updating privacy_mode
Luiz Augusto von Dentz [Thu, 14 Jul 2022 00:12:14 +0000 (17:12 -0700)]
Bluetooth: hci_sync: Fix not updating privacy_mode

When programming a new entry into the resolving list it shall default
to network mode since the params may contain the mode programmed when
the device was last added to the resolving list.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=209745
Fixes: 853b70b506a20 ("Bluetooth: hci_sync: Set Privacy Mode when updating the resolving list")
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Tested-by: Zhengping Jiang <jiangzp@google.com>
22 months agoBluetooth: Collect kcov coverage from hci_rx_work
Tamas Koczka [Thu, 14 Jul 2022 10:48:14 +0000 (10:48 +0000)]
Bluetooth: Collect kcov coverage from hci_rx_work

Annotate hci_rx_work() with kcov_remote_start() and kcov_remote_stop()
calls, so remote KCOV coverage is collected while processing the rx_q
queue which is the main incoming Bluetooth packet queue.

Coverage is associated with the thread which created the packet skb.

The collected extra coverage helps kernel fuzzing efforts in finding
vulnerabilities.

This change only has effect if the kernel is compiled with CONFIG_KCOV,
otherwise kcov_ functions don't do anything.

Signed-off-by: Tamas Koczka <poprdi@google.com>
Tested-by: Aleksandr Nogikh <nogikh@google.com>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
22 months agoBluetooth: hci_sync: Fix resuming scan after suspend resume
Zhengping Jiang [Tue, 12 Jul 2022 00:05:30 +0000 (17:05 -0700)]
Bluetooth: hci_sync: Fix resuming scan after suspend resume

After resuming, remove setting scanning_paused to false, because it is
checked and set to false in hci_resume_scan_sync. Also move setting
the value to false before updating passive scan, because the value is
used when resuming passive scan.

Fixes: 3b42055388c30 (Bluetooth: hci_sync: Fix attempting to suspend with
unfiltered passive scan)

Signed-off-by: Zhengping Jiang <jiangzp@google.com>
Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
22 months agoBluetooth: btmtksdio: Add in-band wakeup support
Sean Wang [Sun, 26 Jun 2022 23:27:36 +0000 (07:27 +0800)]
Bluetooth: btmtksdio: Add in-band wakeup support

Commit ce64b3e94919 ("Bluetooth: mt7921s: Support wake on bluetooth")
adds the wake on bluethooth via a dedicated GPIO.

Extend the wake-on-bluetooth to use the SDIO DAT1 pin (in-band wakeup),
when supported by the SDIO host driver.

Co-developed-by: Yake Yang <yake.yang@mediatek.com>
Signed-off-by: Yake Yang <yake.yang@mediatek.com>
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
22 months agoBluetooth: mgmt: Fix refresh cached connection info
Zhengping Jiang [Mon, 13 Jun 2022 21:43:27 +0000 (14:43 -0700)]
Bluetooth: mgmt: Fix refresh cached connection info

Set the connection data before calling get_conn_info_sync, so it can be
verified the connection is still connected, before refreshing cached
values.

Fixes: 47db6b42991e6 ("Bluetooth: hci_sync: Convert MGMT_OP_GET_CONN_INFO")
Signed-off-by: Zhengping Jiang <jiangzp@google.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
22 months agoBluetooth: HCI: Fix not always setting Scan Response/Advertising Data
Luiz Augusto von Dentz [Wed, 8 Jun 2022 22:00:01 +0000 (15:00 -0700)]
Bluetooth: HCI: Fix not always setting Scan Response/Advertising Data

The scan response and advertising data needs to be tracked on a per
instance (adv_info) since when these instaces are removed so are their
data, to fix that new flags are introduced which is used to mark when
the data changes and then checked to confirm when the data needs to be
synced with the controller.

Tested-by: Tedd Ho-Jeong An <tedd.an@intel.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
22 months agoBluetooth: eir: Fix using strlen with hdev->{dev_name,short_name}
Luiz Augusto von Dentz [Tue, 24 May 2022 20:02:45 +0000 (13:02 -0700)]
Bluetooth: eir: Fix using strlen with hdev->{dev_name,short_name}

Both dev_name and short_name are not guaranteed to be NULL terminated so
this instead use strnlen and then attempt to determine if the resulting
string needs to be truncated or not.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=216018
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
22 months agoBluetooth: use memset avoid memory leaks
Xiaohui Zhang [Tue, 7 Jun 2022 15:30:20 +0000 (23:30 +0800)]
Bluetooth: use memset avoid memory leaks

Similar to the handling of l2cap_ecred_connect in commit d3715b2333e9
("Bluetooth: use memset avoid memory leaks"), we thought a patch
might be needed here as well.

Use memset to initialize structs to prevent memory leaks
in l2cap_le_connect

Signed-off-by: Xiaohui Zhang <xiaohuizhang@ruc.edu.cn>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
22 months agoBluetooth: fix an error code in hci_register_dev()
Dan Carpenter [Wed, 8 Jun 2022 13:46:13 +0000 (16:46 +0300)]
Bluetooth: fix an error code in hci_register_dev()

Preserve the error code from hci_register_suspend_notifier().  Don't
return success.

Fixes: d6bb2a91f95b ("Bluetooth: Unregister suspend with userchannel")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
22 months agoBluetooth: hci_bcm: Add BCM4349B1 variant
Ahmad Fatoum [Tue, 24 May 2022 05:56:41 +0000 (07:56 +0200)]
Bluetooth: hci_bcm: Add BCM4349B1 variant

The BCM4349B1, aka CYW/BCM89359, is a WiFi+BT chip and its Bluetooth
portion can be controlled over serial.

Two subversions are added for the chip, because ROM firmware reports
002.002.013 (at least for the chips I have here), while depending on
patchram firmware revision, either 002.002.013 or 002.002.014 is
reported.

Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
22 months agodt-bindings: bluetooth: broadcom: Add BCM4349B1 DT binding
Ahmad Fatoum [Tue, 24 May 2022 05:56:40 +0000 (07:56 +0200)]
dt-bindings: bluetooth: broadcom: Add BCM4349B1 DT binding

The BCM4349B1, aka CYW/BCM89359, is a WiFi+BT chip and its Bluetooth
portion can be controlled over serial.
Extend the binding with its DT compatible.

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
22 months agoBluetooth: Unregister suspend with userchannel
Abhishek Pandit-Subedi [Thu, 2 Jun 2022 16:46:50 +0000 (09:46 -0700)]
Bluetooth: Unregister suspend with userchannel

When HCI_USERCHANNEL is used, unregister the suspend notifier when
binding and register when releasing. The userchannel socket should be
left alone after open is completed.

Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
22 months agoBluetooth: Fix index added after unregister
Abhishek Pandit-Subedi [Thu, 2 Jun 2022 16:46:49 +0000 (09:46 -0700)]
Bluetooth: Fix index added after unregister

When a userchannel socket is released, we should check whether the hdev
is already unregistered before sending out an IndexAdded.

Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
22 months agoBluetooth: When HCI work queue is drained, only queue chained work
Schspa Shi [Fri, 3 Jun 2022 08:19:14 +0000 (16:19 +0800)]
Bluetooth: When HCI work queue is drained, only queue chained work

The HCI command, event, and data packet processing workqueue is drained
to avoid deadlock in commit
76727c02c1e1 ("Bluetooth: Call drain_workqueue() before resetting state").

There is another delayed work, which will queue command to this drained
workqueue. Which results in the following error report:

Bluetooth: hci2: command 0x040f tx timeout
WARNING: CPU: 1 PID: 18374 at kernel/workqueue.c:1438 __queue_work+0xdad/0x1140
Workqueue: events hci_cmd_timeout
RIP: 0010:__queue_work+0xdad/0x1140
RSP: 0000:ffffc90002cffc60 EFLAGS: 00010093
RAX: 0000000000000000 RBX: ffff8880b9d3ec00 RCX: 0000000000000000
RDX: ffff888024ba0000 RSI: ffffffff814e048d RDI: ffff8880b9d3ec08
RBP: 0000000000000008 R08: 0000000000000000 R09: 00000000b9d39700
R10: ffffffff814f73c6 R11: 0000000000000000 R12: ffff88807cce4c60
R13: 0000000000000000 R14: ffff8880796d8800 R15: ffff8880796d8800
FS:  0000000000000000(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000c0174b4000 CR3: 000000007cae9000 CR4: 00000000003506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 <TASK>
 ? queue_work_on+0xcb/0x110
 ? lockdep_hardirqs_off+0x90/0xd0
 queue_work_on+0xee/0x110
 process_one_work+0x996/0x1610
 ? pwq_dec_nr_in_flight+0x2a0/0x2a0
 ? rwlock_bug.part.0+0x90/0x90
 ? _raw_spin_lock_irq+0x41/0x50
 worker_thread+0x665/0x1080
 ? process_one_work+0x1610/0x1610
 kthread+0x2e9/0x3a0
 ? kthread_complete_and_exit+0x40/0x40
 ret_from_fork+0x1f/0x30
 </TASK>

To fix this, we can add a new HCI_DRAIN_WQ flag, and don't queue the
timeout workqueue while command workqueue is draining.

Fixes: 76727c02c1e1 ("Bluetooth: Call drain_workqueue() before resetting state")
Reported-by: syzbot+63bed493aebbf6872647@syzkaller.appspotmail.com
Signed-off-by: Schspa Shi <schspa@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>