Luca Weiss [Thu, 8 Dec 2022 21:15:28 +0000 (15:15 -0600)]
dt-bindings: net: qcom,ipa: Add SM6350 compatible
Add support for SM6350, which uses IPA v4.7.
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
Signed-off-by: Alex Elder <elder@linaro.org>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Coco Li [Sat, 10 Dec 2022 04:16:46 +0000 (04:16 +0000)]
bnxt: Use generic HBH removal helper in tx path
Eric Dumazet implemented Big TCP that allowed bigger TSO/GRO packet sizes
for IPv6 traffic. See patch series:
'commit
89527be8d8d6 ("net: add IFLA_TSO_{MAX_SIZE|SEGS} attributes")'
This reduces the number of packets traversing the networking stack and
should usually improves performance. However, it also inserts a
temporary Hop-by-hop IPv6 extension header.
Using the HBH header removal method in the previous patch, the extra header
be removed in bnxt drivers to allow it to send big TCP packets (bigger
TSO packets) as well.
Tested:
Compiled locally
To further test functional correctness, update the GSO/GRO limit on the
physical NIC:
ip link set eth0 gso_max_size 181000
ip link set eth0 gro_max_size 181000
Note that if there are bonding or ipvan devices on top of the physical
NIC, their GSO sizes need to be updated as well.
Then, IPv6/TCP packets with sizes larger than 64k can be observed.
Signed-off-by: Coco Li <lixiaoyan@google.com>
Reviewed-by: Michael Chan <michael.chan@broadcom.com>
Tested-by: Michael Chan <michael.chan@broadcom.com>
Link: https://lore.kernel.org/r/20221210041646.3587757-2-lixiaoyan@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Coco Li [Sat, 10 Dec 2022 04:16:45 +0000 (04:16 +0000)]
IPv6/GRO: generic helper to remove temporary HBH/jumbo header in driver
IPv6/TCP and GRO stacks can build big TCP packets with an added
temporary Hop By Hop header.
Is GSO is not involved, then the temporary header needs to be removed in
the driver. This patch provides a generic helper for drivers that need
to modify their headers in place.
Tested:
Compiled and ran with ethtool -K eth1 tso off
Could send Big TCP packets
Signed-off-by: Coco Li <lixiaoyan@google.com>
Link: https://lore.kernel.org/r/20221210041646.3587757-1-lixiaoyan@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Jakub Kicinski [Mon, 12 Dec 2022 23:33:39 +0000 (15:33 -0800)]
Merge branch 'bridge-mcast-extensions-for-evpn'
Ido Schimmel says:
====================
bridge: mcast: Extensions for EVPN
tl;dr
=====
This patchset creates feature parity between user space and the kernel
and allows the former to install and replace MDB port group entries with
a source list and associated filter mode. This is required for EVPN use
cases where multicast state is not derived from snooped IGMP/MLD
packets, but instead derived from EVPN routes exchanged by the control
plane in user space.
Background
==========
IGMPv3 [1] and MLDv2 [2] differ from earlier versions of the protocols
in that they add support for source-specific multicast. That is, hosts
can advertise interest in listening to a particular multicast address
only from specific source addresses or from all sources except for
specific source addresses.
In kernel 5.10 [3][4], the bridge driver gained the ability to snoop
IGMPv3/MLDv2 packets and install corresponding MDB port group entries.
For example, a snooped IGMPv3 Membership Report that contains a single
MODE_IS_EXCLUDE record for group 239.10.10.10 with sources 192.0.2.1,
192.0.2.2, 192.0.2.20 and 192.0.2.21 would trigger the creation of these
entries:
# bridge -d mdb show
dev br0 port veth1 grp 239.10.10.10 src 192.0.2.21 temp filter_mode include proto kernel blocked
dev br0 port veth1 grp 239.10.10.10 src 192.0.2.20 temp filter_mode include proto kernel blocked
dev br0 port veth1 grp 239.10.10.10 src 192.0.2.2 temp filter_mode include proto kernel blocked
dev br0 port veth1 grp 239.10.10.10 src 192.0.2.1 temp filter_mode include proto kernel blocked
dev br0 port veth1 grp 239.10.10.10 temp filter_mode exclude source_list 192.0.2.21/0.00,192.0.2.20/0.00,192.0.2.2/0.00,192.0.2.1/0.00 proto kernel
While the kernel can install and replace entries with a filter mode and
source list, user space cannot. It can only add EXCLUDE entries with an
empty source list, which is sufficient for IGMPv2/MLDv1, but not for
IGMPv3/MLDv2.
Use cases where the multicast state is not derived from snooped packets,
but instead derived from routes exchanged by the user space control
plane require feature parity between user space and the kernel in terms
of MDB configuration. Such a use case is detailed in the next section.
Motivation
==========
RFC 7432 [5] defines a "MAC/IP Advertisement route" (type 2) [6] that
allows NVE switches in the EVPN network to advertise and learn
reachability information for unicast MAC addresses. Traffic destined to
a unicast MAC address can therefore be selectively forwarded to a single
NVE switch behind which the MAC is located.
The same is not true for IP multicast traffic. Such traffic is simply
flooded as BUM to all NVE switches in the broadcast domain (BD),
regardless if a switch has interested receivers for the multicast stream
or not. This is especially problematic for overlay networks that make
heavy use of multicast.
The issue is addressed by RFC 9251 [7] that defines a "Selective
Multicast Ethernet Tag Route" (type 6) [8] which allows NVE switches in
the EVPN network to advertise multicast streams that they are interested
in. This is done by having each switch suppress IGMP/MLD packets from
being transmitted to the NVE network and instead communicate the
information over BGP to other switches.
As far as the bridge driver is concerned, the above means that the
multicast state (i.e., {multicast address, group timer, filter-mode,
(source records)}) for the VXLAN bridge port is not populated by the
kernel from snooped IGMP/MLD packets (they are suppressed), but instead
by user space. Specifically, by the routing daemon that is exchanging
EVPN routes with other NVE switches.
Changes are obviously also required in the VXLAN driver, but they are
the subject of future patchsets. See the "Future work" section.
Implementation
==============
The user interface is extended to allow user space to specify the filter
mode of the MDB port group entry and its source list. Replace support is
also added so that user space would not need to remove an entry and
re-add it only to edit its source list or filter mode, as that would
result in packet loss. Example usage:
# bridge mdb replace dev br0 port dummy10 grp 239.1.1.1 permanent \
source_list 192.0.2.1,192.0.2.3 filter_mode exclude proto zebra
# bridge -d -s mdb show
dev br0 port dummy10 grp 239.1.1.1 src 192.0.2.3 permanent filter_mode include proto zebra blocked 0.00
dev br0 port dummy10 grp 239.1.1.1 src 192.0.2.1 permanent filter_mode include proto zebra blocked 0.00
dev br0 port dummy10 grp 239.1.1.1 permanent filter_mode exclude source_list 192.0.2.3/0.00,192.0.2.1/0.00 proto zebra 0.00
The netlink interface is extended with a few new attributes in the
RTM_NEWMDB request message:
[ struct nlmsghdr ]
[ struct br_port_msg ]
[ MDBA_SET_ENTRY ]
struct br_mdb_entry
[ MDBA_SET_ENTRY_ATTRS ]
[ MDBE_ATTR_SOURCE ]
struct in_addr / struct in6_addr
[ MDBE_ATTR_SRC_LIST ] // new
[ MDBE_SRC_LIST_ENTRY ]
[ MDBE_SRCATTR_ADDRESS ]
struct in_addr / struct in6_addr
[ ...]
[ MDBE_ATTR_GROUP_MODE ] // new
u8
[ MDBE_ATTR_RTPORT ] // new
u8
No changes are required in RTM_NEWMDB responses and notifications, as
all the information can already be dumped by the kernel today.
Testing
=======
Tested with existing bridge multicast selftests: bridge_igmp.sh,
bridge_mdb_port_down.sh, bridge_mdb.sh, bridge_mld.sh,
bridge_vlan_mcast.sh.
In addition, added many new test cases for existing as well as for new
MDB functionality.
Patchset overview
=================
Patches #1-#8 are non-functional preparations for the core changes in
later patches.
Patches #9-#10 allow user space to install (*, G) entries with a source
list and associated filter mode. Specifically, patch #9 adds the
necessary kernel plumbing and patch #10 exposes the new functionality to
user space via a few new attributes.
Patch #11 allows user space to specify the routing protocol of new MDB
port group entries so that a routing daemon could differentiate between
entries installed by it and those installed by an administrator.
Patch #12 allows user space to replace MDB port group entries. This is
useful, for example, when user space wants to add a new source to a
source list. Instead of deleting a (*, G) entry and re-adding it with an
extended source list (which would result in packet loss), user space can
simply replace the current entry.
Patches #13-#14 add tests for existing MDB functionality as well as for
all new functionality added in this patchset.
Future work
===========
The VXLAN driver will need to be extended with an MDB so that it could
selectively forward IP multicast traffic to NVE switches with interested
receivers instead of simply flooding it to all switches as BUM.
The idea is to reuse the existing MDB interface for the VXLAN driver in
a similar way to how the FDB interface is shared between the bridge and
VXLAN drivers.
From command line perspective, configuration will look as follows:
# bridge mdb add dev br0 port vxlan0 grp 239.1.1.1 permanent \
filter_mode exclude source_list 198.50.100.1,198.50.100.2
# bridge mdb add dev vxlan0 port vxlan0 grp 239.1.1.1 permanent \
filter_mode include source_list 198.50.100.3,198.50.100.4 \
dst 192.0.2.1 dst_port 4789 src_vni 2
# bridge mdb add dev vxlan0 port vxlan0 grp 239.1.1.1 permanent \
filter_mode exclude source_list 198.50.100.1,198.50.100.2 \
dst 192.0.2.2 dst_port 4789 src_vni 2
Where the first command is enabled by this set, but the next two will be
the subject of future work.
From netlink perspective, the existing PF_BRIDGE/RTM_*MDB messages will
be extended to the VXLAN driver. This means that a few new attributes
will be added (e.g., 'MDBE_ATTR_SRC_VNI') and that the handlers for
these messages will need to move to net/core/rtnetlink.c. The rtnetlink
code will call into the appropriate driver based on the ifindex
specified in the ancillary header.
iproute2 patches can be found here [9].
Changelog
=========
Since v1 [10]:
* Patch #12: Remove extack from br_mdb_replace_group_sg().
* Patch #12: Change 'nlflags' to u16 and move it after 'filter_mode' to
pack the structure.
Since RFC [11]:
* Patch #6: New patch.
* Patch #9: Use an array instead of a list to store source entries.
* Patch #10: Use an array instead of list to store source entries.
* Patch #10: Drop br_mdb_config_attrs_fini().
* Patch #11: Reject protocol for host entries.
* Patch #13: New patch.
* Patch #14: New patch.
[1] https://datatracker.ietf.org/doc/html/rfc3376
[2] https://www.rfc-editor.org/rfc/rfc3810
[3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=
6af52ae2ed14a6bc756d5606b29097dfd76740b8
[4] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=
68d4fd30c83b1b208e08c954cd45e6474b148c87
[5] https://datatracker.ietf.org/doc/html/rfc7432
[6] https://datatracker.ietf.org/doc/html/rfc7432#section-7.2
[7] https://datatracker.ietf.org/doc/html/rfc9251
[8] https://datatracker.ietf.org/doc/html/rfc9251#section-9.1
[9] https://github.com/idosch/iproute2/commits/submit/mdb_v1
[10] https://lore.kernel.org/netdev/
20221208152839.1016350-1-idosch@nvidia.com/
[11] https://lore.kernel.org/netdev/
20221018120420.561846-1-idosch@nvidia.com/
====================
Link: https://lore.kernel.org/r/20221210145633.1328511-1-idosch@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Ido Schimmel [Sat, 10 Dec 2022 14:56:33 +0000 (16:56 +0200)]
selftests: forwarding: Add bridge MDB test
Add a selftests that includes the following test cases:
1. Configuration tests. Both valid and invalid configurations are
tested across all entry types (e.g., L2, IPv4).
2. Forwarding tests. Both host and port group entries are tested across
all entry types.
3. Interaction between user installed MDB entries and IGMP / MLD control
packets.
Example output:
INFO: # Host entries configuration tests
TEST: Common host entries configuration tests (IPv4) [ OK ]
TEST: Common host entries configuration tests (IPv6) [ OK ]
TEST: Common host entries configuration tests (L2) [ OK ]
INFO: # Port group entries configuration tests - (*, G)
TEST: Common port group entries configuration tests (IPv4 (*, G)) [ OK ]
TEST: Common port group entries configuration tests (IPv6 (*, G)) [ OK ]
TEST: IPv4 (*, G) port group entries configuration tests [ OK ]
TEST: IPv6 (*, G) port group entries configuration tests [ OK ]
INFO: # Port group entries configuration tests - (S, G)
TEST: Common port group entries configuration tests (IPv4 (S, G)) [ OK ]
TEST: Common port group entries configuration tests (IPv6 (S, G)) [ OK ]
TEST: IPv4 (S, G) port group entries configuration tests [ OK ]
TEST: IPv6 (S, G) port group entries configuration tests [ OK ]
INFO: # Port group entries configuration tests - L2
TEST: Common port group entries configuration tests (L2 (*, G)) [ OK ]
TEST: L2 (*, G) port group entries configuration tests [ OK ]
INFO: # Forwarding tests
TEST: IPv4 host entries forwarding tests [ OK ]
TEST: IPv6 host entries forwarding tests [ OK ]
TEST: L2 host entries forwarding tests [ OK ]
TEST: IPv4 port group "exclude" entries forwarding tests [ OK ]
TEST: IPv6 port group "exclude" entries forwarding tests [ OK ]
TEST: IPv4 port group "include" entries forwarding tests [ OK ]
TEST: IPv6 port group "include" entries forwarding tests [ OK ]
TEST: L2 port entries forwarding tests [ OK ]
INFO: # Control packets tests
TEST: IGMPv3 MODE_IS_INCLUE tests [ OK ]
TEST: MLDv2 MODE_IS_INCLUDE tests [ OK ]
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Ido Schimmel [Sat, 10 Dec 2022 14:56:32 +0000 (16:56 +0200)]
selftests: forwarding: Rename bridge_mdb test
The test is only concerned with host MDB entries and not with MDB
entries as a whole. Rename the test to reflect that.
Subsequent patches will add a more general test that will contain the
test cases for host MDB entries and remove the current test.
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Ido Schimmel [Sat, 10 Dec 2022 14:56:31 +0000 (16:56 +0200)]
bridge: mcast: Support replacement of MDB port group entries
Now that user space can specify additional attributes of port group
entries such as filter mode and source list, it makes sense to allow
user space to atomically modify these attributes by replacing entries
instead of forcing user space to delete the entries and add them back.
Replace MDB port group entries when the 'NLM_F_REPLACE' flag is
specified in the netlink message header.
When a (*, G) entry is replaced, update the following attributes: Source
list, state, filter mode, protocol and flags. If the entry is temporary
and in EXCLUDE mode, reset the group timer to the group membership
interval. If the entry is temporary and in INCLUDE mode, reset the
source timers of associated sources to the group membership interval.
Examples:
# bridge mdb replace dev br0 port dummy10 grp 239.1.1.1 permanent source_list 192.0.2.1,192.0.2.2 filter_mode include
# bridge -d -s mdb show
dev br0 port dummy10 grp 239.1.1.1 src 192.0.2.2 permanent filter_mode include proto static 0.00
dev br0 port dummy10 grp 239.1.1.1 src 192.0.2.1 permanent filter_mode include proto static 0.00
dev br0 port dummy10 grp 239.1.1.1 permanent filter_mode include source_list 192.0.2.2/0.00,192.0.2.1/0.00 proto static 0.00
# bridge mdb replace dev br0 port dummy10 grp 239.1.1.1 permanent source_list 192.0.2.1,192.0.2.3 filter_mode exclude proto zebra
# bridge -d -s mdb show
dev br0 port dummy10 grp 239.1.1.1 src 192.0.2.3 permanent filter_mode include proto zebra blocked 0.00
dev br0 port dummy10 grp 239.1.1.1 src 192.0.2.1 permanent filter_mode include proto zebra blocked 0.00
dev br0 port dummy10 grp 239.1.1.1 permanent filter_mode exclude source_list 192.0.2.3/0.00,192.0.2.1/0.00 proto zebra 0.00
# bridge mdb replace dev br0 port dummy10 grp 239.1.1.1 temp source_list 192.0.2.4,192.0.2.3 filter_mode include proto bgp
# bridge -d -s mdb show
dev br0 port dummy10 grp 239.1.1.1 src 192.0.2.4 temp filter_mode include proto bgp 0.00
dev br0 port dummy10 grp 239.1.1.1 src 192.0.2.3 temp filter_mode include proto bgp 0.00
dev br0 port dummy10 grp 239.1.1.1 temp filter_mode include source_list 192.0.2.4/259.44,192.0.2.3/259.44 proto bgp 0.00
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Ido Schimmel [Sat, 10 Dec 2022 14:56:30 +0000 (16:56 +0200)]
bridge: mcast: Allow user space to specify MDB entry routing protocol
Add the 'MDBE_ATTR_RTPORT' attribute to allow user space to specify the
routing protocol of the MDB port group entry. Enforce a minimum value of
'RTPROT_STATIC' to prevent user space from using protocol values that
should only be set by the kernel (e.g., 'RTPROT_KERNEL'). Maintain
backward compatibility by defaulting to 'RTPROT_STATIC'.
The protocol is already visible to user space in RTM_NEWMDB responses
and notifications via the 'MDBA_MDB_EATTR_RTPROT' attribute.
The routing protocol allows a routing daemon to distinguish between
entries configured by it and those configured by the administrator. Once
MDB flush is supported, the protocol can be used as a criterion
according to which the flush is performed.
Examples:
# bridge mdb add dev br0 port dummy10 grp 239.1.1.1 permanent proto kernel
Error: integer out of range.
# bridge mdb add dev br0 port dummy10 grp 239.1.1.1 permanent proto static
# bridge mdb add dev br0 port dummy10 grp 239.1.1.1 src 192.0.2.1 permanent proto zebra
# bridge mdb add dev br0 port dummy10 grp 239.1.1.2 permanent source_list 198.51.100.1,198.51.100.2 filter_mode include proto 250
# bridge -d mdb show
dev br0 port dummy10 grp 239.1.1.2 src 198.51.100.2 permanent filter_mode include proto 250
dev br0 port dummy10 grp 239.1.1.2 src 198.51.100.1 permanent filter_mode include proto 250
dev br0 port dummy10 grp 239.1.1.2 permanent filter_mode include source_list 198.51.100.2/0.00,198.51.100.1/0.00 proto 250
dev br0 port dummy10 grp 239.1.1.1 src 192.0.2.1 permanent filter_mode include proto zebra
dev br0 port dummy10 grp 239.1.1.1 permanent filter_mode exclude proto static
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Ido Schimmel [Sat, 10 Dec 2022 14:56:29 +0000 (16:56 +0200)]
bridge: mcast: Allow user space to add (*, G) with a source list and filter mode
Add new netlink attributes to the RTM_NEWMDB request that allow user
space to add (*, G) with a source list and filter mode.
The RTM_NEWMDB message can already dump such entries (created by the
kernel) so there is no need to add dump support. However, the message
contains a different set of attributes depending if it is a request or a
response. The naming and structure of the new attributes try to follow
the existing ones used in the response.
Request:
[ struct nlmsghdr ]
[ struct br_port_msg ]
[ MDBA_SET_ENTRY ]
struct br_mdb_entry
[ MDBA_SET_ENTRY_ATTRS ]
[ MDBE_ATTR_SOURCE ]
struct in_addr / struct in6_addr
[ MDBE_ATTR_SRC_LIST ] // new
[ MDBE_SRC_LIST_ENTRY ]
[ MDBE_SRCATTR_ADDRESS ]
struct in_addr / struct in6_addr
[ ...]
[ MDBE_ATTR_GROUP_MODE ] // new
u8
Response:
[ struct nlmsghdr ]
[ struct br_port_msg ]
[ MDBA_MDB ]
[ MDBA_MDB_ENTRY ]
[ MDBA_MDB_ENTRY_INFO ]
struct br_mdb_entry
[ MDBA_MDB_EATTR_TIMER ]
u32
[ MDBA_MDB_EATTR_SOURCE ]
struct in_addr / struct in6_addr
[ MDBA_MDB_EATTR_RTPROT ]
u8
[ MDBA_MDB_EATTR_SRC_LIST ]
[ MDBA_MDB_SRCLIST_ENTRY ]
[ MDBA_MDB_SRCATTR_ADDRESS ]
struct in_addr / struct in6_addr
[ MDBA_MDB_SRCATTR_TIMER ]
u8
[...]
[ MDBA_MDB_EATTR_GROUP_MODE ]
u8
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Ido Schimmel [Sat, 10 Dec 2022 14:56:28 +0000 (16:56 +0200)]
bridge: mcast: Add support for (*, G) with a source list and filter mode
In preparation for allowing user space to add (*, G) entries with a
source list and associated filter mode, add the necessary plumbing to
handle such requests.
Extend the MDB configuration structure with a currently empty source
array and filter mode that is currently hard coded to EXCLUDE.
Add the source entries and the corresponding (S, G) entries before
making the new (*, G) port group entry visible to the data path.
Handle the creation of each source entry in a similar fashion to how it
is created from the data path in response to received Membership
Reports: Create the source entry, arm the source timer (if needed), add
a corresponding (S, G) forwarding entry and finally mark the source
entry as installed (by user space).
Add the (S, G) entry by populating an MDB configuration structure and
calling br_mdb_add_group_sg() as if a new entry is created by user
space, with the sole difference that the 'src_entry' field is set to
make sure that the group timer of such entries is never armed.
Note that it is not currently possible to add more than 32 source
entries to a port group entry. If this proves to be a problem we can
either increase 'PG_SRC_ENT_LIMIT' or avoid forcing a limit on entries
created by user space.
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Ido Schimmel [Sat, 10 Dec 2022 14:56:27 +0000 (16:56 +0200)]
bridge: mcast: Avoid arming group timer when (S, G) corresponds to a source
User space will soon be able to install a (*, G) with a source list,
prompting the creation of a (S, G) entry for each source.
In this case, the group timer of the (S, G) entry should never be set.
Solve this by adding a new field to the MDB configuration structure that
denotes whether the (S, G) corresponds to a source or not.
The field will be set in a subsequent patch where br_mdb_add_group_sg()
is called in order to create a (S, G) entry for each user provided
source.
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Ido Schimmel [Sat, 10 Dec 2022 14:56:26 +0000 (16:56 +0200)]
bridge: mcast: Add a flag for user installed source entries
There are a few places where the bridge driver differentiates between
(S, G) entries installed by the kernel (in response to Membership
Reports) and those installed by user space. One of them is when deleting
an (S, G) entry corresponding to a source entry that is being deleted.
While user space cannot currently add a source entry to a (*, G), it can
add an (S, G) entry that later corresponds to a source entry created by
the reception of a Membership Report. If this source entry is later
deleted because its source timer expired or because the (*, G) entry is
being deleted, the bridge driver will not delete the corresponding (S,
G) entry if it was added by user space as permanent.
This is going to be a problem when the ability to install a (*, G) with
a source list is exposed to user space. In this case, when user space
installs the (*, G) as permanent, then all the (S, G) entries
corresponding to its source list will also be installed as permanent.
When user space deletes the (*, G), all the source entries will be
deleted and the expectation is that the corresponding (S, G) entries
will be deleted as well.
Solve this by introducing a new source entry flag denoting that the
entry was installed by user space. When the entry is deleted, delete the
corresponding (S, G) entry even if it was installed by user space as
permanent, as the flag tells us that it was installed in response to the
source entry being created.
The flag will be set in a subsequent patch where source entries are
created in response to user requests.
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Ido Schimmel [Sat, 10 Dec 2022 14:56:25 +0000 (16:56 +0200)]
bridge: mcast: Expose __br_multicast_del_group_src()
Expose __br_multicast_del_group_src() which is symmetric to
br_multicast_new_group_src() and does not remove the installed {S, G}
forwarding entry, unlike br_multicast_del_group_src().
The function will be used in the error path when user space was able to
add a new source entry, but failed to install a corresponding forwarding
entry.
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Ido Schimmel [Sat, 10 Dec 2022 14:56:24 +0000 (16:56 +0200)]
bridge: mcast: Expose br_multicast_new_group_src()
Currently, new group source entries are only created in response to
received Membership Reports. Subsequent patches are going to allow user
space to install (*, G) entries with a source list.
As a preparatory step, expose br_multicast_new_group_src() so that it
could later be invoked from the MDB code (i.e., br_mdb.c) that handles
RTM_NEWMDB messages.
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Ido Schimmel [Sat, 10 Dec 2022 14:56:23 +0000 (16:56 +0200)]
bridge: mcast: Add a centralized error path
Subsequent patches will add memory allocations in br_mdb_config_init()
as the MDB configuration structure will include a linked list of source
entries. This memory will need to be freed regardless if br_mdb_add()
succeeded or failed.
As a preparation for this change, add a centralized error path where the
memory will be freed.
Note that br_mdb_del() already has one error path and therefore does not
require any changes.
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Ido Schimmel [Sat, 10 Dec 2022 14:56:22 +0000 (16:56 +0200)]
bridge: mcast: Place netlink policy before validation functions
Subsequent patches are going to add additional validation functions and
netlink policies. Some of these functions will need to perform parsing
using nla_parse_nested() and the new policies.
In order to keep all the policies next to each other, move the current
policy to before the validation functions.
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Ido Schimmel [Sat, 10 Dec 2022 14:56:21 +0000 (16:56 +0200)]
bridge: mcast: Split (*, G) and (S, G) addition into different functions
When the bridge is using IGMP version 3 or MLD version 2, it handles the
addition of (*, G) and (S, G) entries differently.
When a new (S, G) port group entry is added, all the (*, G) EXCLUDE
ports need to be added to the port group of the new entry. Similarly,
when a new (*, G) EXCLUDE port group entry is added, the port needs to
be added to the port group of all the matching (S, G) entries.
Subsequent patches will create more differences between both entry
types. Namely, filter mode and source list can only be specified for (*,
G) entries.
Given the current and future differences between both entry types,
handle the addition of each entry type in a different function, thereby
avoiding the creation of one complex function.
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Ido Schimmel [Sat, 10 Dec 2022 14:56:20 +0000 (16:56 +0200)]
bridge: mcast: Do not derive entry type from its filter mode
Currently, the filter mode (i.e., INCLUDE / EXCLUDE) of MDB entries
cannot be set from user space. Instead, it is set by the kernel
according to the entry type: (*, G) entries are treated as EXCLUDE and
(S, G) entries are treated as INCLUDE. This allows the kernel to derive
the entry type from its filter mode.
Subsequent patches will allow user space to set the filter mode of (*,
G) entries, making the current assumption incorrect.
As a preparation, remove the current assumption and instead determine
the entry type from its key, which is a more direct way.
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Jiapeng Chong [Mon, 12 Dec 2022 05:58:13 +0000 (13:58 +0800)]
qlcnic: Clean up some inconsistent indenting
No functional modification involved.
drivers/net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c:714 qlcnic_validate_ring_count() warn: inconsistent indenting.
Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=3419
Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
Link: https://lore.kernel.org/r/20221212055813.91154-1-jiapeng.chong@linux.alibaba.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Tirthendu Sarkar [Fri, 9 Dec 2022 18:55:53 +0000 (10:55 -0800)]
i40e: allow toggling loopback mode via ndo_set_features callback
Add support for NETIF_F_LOOPBACK. This feature can be set via:
$ ethtool -K eth0 loopback <on|off>
This sets the MAC Tx->Rx loopback.
This feature is used for the xsk selftests, and might have other uses
too.
Signed-off-by: Tirthendu Sarkar <tirthendu.sarkar@intel.com>
Reviewed-by: Alexander Lobakin <alexandr.lobakin@intel.com>
Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
Tested-by: Magnus Karlsson <magnus.karlsson@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Link: https://lore.kernel.org/r/20221209185553.2520088-1-anthony.l.nguyen@intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Jakub Kicinski [Mon, 12 Dec 2022 23:18:28 +0000 (15:18 -0800)]
Merge branch 'net-add-iff_no_addrconf-to-prevent-ipv6-addrconf'
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.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Xin Long [Fri, 9 Dec 2022 15:21:40 +0000 (10:21 -0500)]
net: failover: use IFF_NO_ADDRCONF flag to prevent ipv6 addrconf
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: Xin Long <lucien.xin@gmail.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Xin Long [Fri, 9 Dec 2022 15:21:39 +0000 (10:21 -0500)]
net: team: use IFF_NO_ADDRCONF flag to prevent ipv6 addrconf
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: Xin Long <lucien.xin@gmail.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Xin Long [Fri, 9 Dec 2022 15:21:38 +0000 (10:21 -0500)]
net: add IFF_NO_ADDRCONF and use it in bonding to prevent ipv6 addrconf
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: Xin Long <lucien.xin@gmail.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Uladzislau Koshchanka [Sat, 10 Dec 2022 00:44:23 +0000 (03:44 +0300)]
lib: packing: replace bit_reverse() with bitrev8()
Remove bit_reverse() function. Instead use bitrev8() from linux/bitrev.h +
bitshift. Reduces code-repetition.
Signed-off-by: Uladzislau Koshchanka <koshchanka@gmail.com>
Link: https://lore.kernel.org/r/20221210004423.32332-1-koshchanka@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Kurt Kanzenbach [Mon, 12 Dec 2022 08:15:46 +0000 (09:15 +0100)]
dt-bindings: net: dsa: hellcreek: Sync DSA maintainers
The current DSA maintainers are Florian Fainelli, Andrew Lunn and Vladimir
Oltean. Update the hellcreek binding accordingly.
Signed-off-by: Kurt Kanzenbach <kurt@linutronix.de>
Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Link: https://lore.kernel.org/r/20221212081546.6916-1-kurt@linutronix.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Yunsheng Lin [Mon, 12 Dec 2022 03:24:26 +0000 (11:24 +0800)]
net: tso: inline tso_count_descs()
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: Yunsheng Lin <linyunsheng@huawei.com>
Link: https://lore.kernel.org/r/20221212032426.16050-1-linyunsheng@huawei.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Vladimir Oltean [Fri, 9 Dec 2022 17:58:40 +0000 (19:58 +0200)]
net: dsa: don't call ptp_classify_raw() if switch doesn't provide RX timestamping
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: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Kurt Kanzenbach <kurt@linutronix.de>
Link: https://lore.kernel.org/r/20221209175840.390707-1-vladimir.oltean@nxp.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Jakub Kicinski [Mon, 12 Dec 2022 23:01:23 +0000 (15:01 -0800)]
Merge branch 'trace-points-for-mv88e6xxx'
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.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Vladimir Oltean [Fri, 9 Dec 2022 17:28:17 +0000 (19:28 +0200)]
net: dsa: mv88e6xxx: replace VTU violation prints with trace points
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: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Saeed Mahameed <saeed@kernel.org>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Vladimir Oltean [Fri, 9 Dec 2022 17:28:16 +0000 (19:28 +0200)]
net: dsa: mv88e6xxx: replace ATU violation prints with trace points
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: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Saeed Mahameed <saeed@kernel.org>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Hans J. Schultz [Fri, 9 Dec 2022 17:28:15 +0000 (19:28 +0200)]
net: dsa: mv88e6xxx: read FID when handling ATU violations
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: Hans J. Schultz <netdev@kapio-technology.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Vladimir Oltean [Fri, 9 Dec 2022 17:28:14 +0000 (19:28 +0200)]
net: dsa: mv88e6xxx: remove ATU age out violation print
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: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Jakub Kicinski [Mon, 12 Dec 2022 22:51:29 +0000 (14:51 -0800)]
Merge tag 'for-net-next-2022-12-12' of git://git./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.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Jakub Kicinski [Mon, 12 Dec 2022 22:45:36 +0000 (14:45 -0800)]
Merge git://git./linux/kernel/git/netfilter/nf-next
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.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Luiz Augusto von Dentz [Wed, 7 Dec 2022 19:56:57 +0000 (11:56 -0800)]
Bluetooth: Wait for HCI_OP_WRITE_AUTH_PAYLOAD_TO to complete
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: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Luiz Augusto von Dentz [Wed, 7 Dec 2022 00:34:42 +0000 (16:34 -0800)]
Bluetooth: ISO: Avoid circular locking dependency
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: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Yang Yingliang [Wed, 7 Dec 2022 02:18:35 +0000 (10:18 +0800)]
Bluetooth: RFCOMM: don't call kfree_skb() under spin_lock_irqsave()
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:
81be03e026dc ("Bluetooth: RFCOMM: Replace use of memcpy_from_msg with bt_skb_sendmmsg")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Yang Yingliang [Wed, 7 Dec 2022 02:18:34 +0000 (10:18 +0800)]
Bluetooth: hci_core: don't call kfree_skb() under spin_lock_irqsave()
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:
9238f36a5a50 ("Bluetooth: Add request cmd_complete and cmd_status functions")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Yang Yingliang [Wed, 7 Dec 2022 02:18:33 +0000 (10:18 +0800)]
Bluetooth: hci_bcsp: don't call kfree_skb() under spin_lock_irqsave()
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:
1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Yang Yingliang [Wed, 7 Dec 2022 02:18:32 +0000 (10:18 +0800)]
Bluetooth: hci_h5: don't call kfree_skb() under spin_lock_irqsave()
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:
43eb12d78960 ("Bluetooth: Fix/implement Three-wire reliable packet sending")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Yang Yingliang [Wed, 7 Dec 2022 02:18:31 +0000 (10:18 +0800)]
Bluetooth: hci_ll: don't call kfree_skb() under spin_lock_irqsave()
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:
166d2f6a4332 ("[Bluetooth] Add UART driver for Texas Instruments' BRF63xx chips")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Yang Yingliang [Wed, 7 Dec 2022 02:18:30 +0000 (10:18 +0800)]
Bluetooth: hci_qca: don't call kfree_skb() under spin_lock_irqsave()
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:
0ff252c1976d ("Bluetooth: hciuart: Add support QCA chipset for UART")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Yang Yingliang [Tue, 6 Dec 2022 12:59:10 +0000 (20:59 +0800)]
Bluetooth: btusb: don't call kfree_skb() under spin_lock_irqsave()
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:
803b58367ffb ("Bluetooth: btusb: Implement driver internal packet reassembly")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Wang ShaoBo [Mon, 5 Dec 2022 13:53:57 +0000 (21:53 +0800)]
Bluetooth: btintel: Fix missing free skb in btintel_setup_combined()
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:
c86c7285bb08 ("Bluetooth: btintel: Fix the legacy bootloader returns tlv based version")
Fixes:
019a1caa7fd2 ("Bluetooth: btintel: Refactoring setup routine for bootloader devices")
Signed-off-by: Wang ShaoBo <bobo.shaobowang@huawei.com>
Reviewed-by: Tedd Ho-Jeong An <tedd.an@intel.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Luiz Augusto von Dentz [Tue, 6 Dec 2022 01:11:57 +0000 (17:11 -0800)]
Bluetooth: hci_conn: Fix crash on hci_create_cis_sync
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:
26afbd826ee3 ("Bluetooth: Add initial implementation of CIS connections")
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Luiz Augusto von Dentz [Mon, 5 Dec 2022 18:25:52 +0000 (10:25 -0800)]
Bluetooth: btintel: Fix existing sparce warnings
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: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Luiz Augusto von Dentz [Mon, 5 Dec 2022 17:58:43 +0000 (09:58 -0800)]
Bluetooth: btusb: Fix existing sparce warning
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: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Luiz Augusto von Dentz [Mon, 5 Dec 2022 17:49:15 +0000 (09:49 -0800)]
Bluetooth: btusb: Fix new sparce warnings
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: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Gongwei Li [Thu, 1 Dec 2022 09:43:53 +0000 (17:43 +0800)]
Bluetooth: btusb: Add a new PID/VID 13d3/3549 for RTL8822CU
* /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: Gongwei Li <ligongwei@kylinos.cn>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Artem Lukyanov [Wed, 23 Nov 2022 08:10:05 +0000 (11:10 +0300)]
Bluetooth: btusb: Add Realtek RTL8852BE support ID 0x0cb8:0xc559
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: Artem Lukyanov <dukzcry@ya.ru>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Samuel Holland [Fri, 25 Nov 2022 04:09:56 +0000 (22:09 -0600)]
dt-bindings: net: realtek-bluetooth: Add RTL8723DS
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: Rob Herring <robh@kernel.org>
Reviewed-by: Alistair Francis <alistair@alistair23.me>
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Andy Chi [Mon, 28 Nov 2022 07:49:57 +0000 (15:49 +0800)]
Bluetooth: btusb: Add a new VID/PID 0489/e0f2 for MT7922
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: Andy Chi <andy.chi@canonical.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Luca Weiss [Sat, 24 Sep 2022 14:21:55 +0000 (16:21 +0200)]
dt-bindings: bluetooth: broadcom: add BCM43430A0 & BCM43430A1
Document the compatible string for BCM43430A0 bluetooth used in lg-lenok
and BCM43430A1 used in asus-sparrow.
Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Yang Yingliang [Sat, 12 Nov 2022 09:04:37 +0000 (17:04 +0800)]
Bluetooth: hci_bcm4377: Fix missing pci_disable_device() on error in bcm4377_probe()
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: Yang Yingliang <yangyingliang@huawei.com>
Reviewed-by: Sven Peter <sven@svenpeter.dev>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Raman Varabets [Tue, 8 Nov 2022 12:54:13 +0000 (20:54 +0800)]
Bluetooth: btusb: Add Realtek 8761BUV support ID 0x2B89:0x8761
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: Raman Varabets <linux-bluetooth@cyborgize.sg>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Sven Peter [Fri, 4 Nov 2022 21:13:03 +0000 (22:13 +0100)]
Bluetooth: hci_bcm4377: Add new driver for BCM4377 PCIe boards
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: Sven Peter <sven@svenpeter.dev>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Sven Peter [Fri, 4 Nov 2022 21:13:02 +0000 (22:13 +0100)]
Bluetooth: Add quirk to disable MWS Transport Configuration
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: Sven Peter <sven@svenpeter.dev>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Sven Peter [Fri, 4 Nov 2022 21:13:01 +0000 (22:13 +0100)]
Bluetooth: Add quirk to disable extended scanning
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: Sven Peter <sven@svenpeter.dev>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Sven Peter [Fri, 4 Nov 2022 21:13:00 +0000 (22:13 +0100)]
Bluetooth: hci_event: Ignore reserved bits in LE Extended Adv Report
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: Sven Peter <sven@svenpeter.dev>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Sven Peter [Fri, 4 Nov 2022 21:12:59 +0000 (22:12 +0100)]
arm64: dts: apple: t8103: Add Bluetooth controller
Add bluetooth controller nodes and the required brcm,board-type
properties to be able to select the correct firmware to all board
device trees.
Signed-off-by: Sven Peter <sven@svenpeter.dev>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Sven Peter [Fri, 4 Nov 2022 21:12:58 +0000 (22:12 +0100)]
dt-bindings: net: Add Broadcom BCM4377 family PCIe Bluetooth
These chips are combined Wi-Fi/Bluetooth radios which expose a
PCI subfunction for the Bluetooth part.
They are found in Apple machines such as the x86 models with the T2
chip or the arm64 models with the M1 or M2 chips.
Signed-off-by: Sven Peter <sven@svenpeter.dev>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Sven Peter [Fri, 4 Nov 2022 21:12:57 +0000 (22:12 +0100)]
dt-bindings: net: Add generic Bluetooth controller
Bluetooth controllers share the common local-bd-address property.
Add a generic YAML schema to replace bluetooth.txt for those.
Signed-off-by: Sven Peter <sven@svenpeter.dev>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Marek Vasut [Wed, 2 Nov 2022 16:47:05 +0000 (17:47 +0100)]
Bluetooth: hci_bcm: Add CYW4373A0 support
CYW4373A0 is a Wi-Fi + Bluetooth combo device from Cypress.
This chip is present e.g. on muRata 2AE module.
This chip has additional quirk where the HCI command 0xfc45, used on
older chips to switch UART clock from 24 MHz to 48 MHz, to support
baudrates over 3 Mbdps, is no longer recognized by this newer chip.
This newer chip can configure the 4 Mbdps baudrate without the need
to issue HCI command 0xfc45, so add flag to indicate this and do not
issue the command on this chip to avoid failure to set 4 Mbdps baud
rate.
It is not clear whether there is a way to determine which chip does
and which chip does not support the HCI command 0xfc45, other than
trial and error.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Marek Vasut [Wed, 2 Nov 2022 16:47:04 +0000 (17:47 +0100)]
dt-bindings: net: broadcom-bluetooth: Add CYW4373A0 DT binding
CYW4373A0 is a Wi-Fi + Bluetooth combo device from Cypress.
This chip is present e.g. on muRata 2AE module. Extend the
binding with its DT compatible.
Acked-by: Rob Herring <robh@kernel.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Kang Minchul [Sun, 30 Oct 2022 18:17:22 +0000 (03:17 +0900)]
Bluetooth: Use kzalloc instead of kmalloc/memset
Replace kmalloc+memset by kzalloc
for better readability and simplicity.
This addresses the cocci warning below:
WARNING: kzalloc should be used for d, instead of kmalloc/memset
Signed-off-by: Kang Minchul <tegongkang@gmail.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Shengyu Qu [Sat, 29 Oct 2022 17:22:54 +0000 (01:22 +0800)]
Bluetooth: btusb: Add more device IDs for WCN6855
Add IDs to usb_device_id table for WCN6855. IDs are extracted from Windows
driver of Lenovo Thinkpad T14 Gen 2(Driver version 1.0.0.1205 Windows 10)
Windows driver download address:
https://pcsupport.lenovo.com/us/en/products/laptops-and-netbooks/
thinkpad-t-series-laptops/thinkpad-t14-gen-2-type-20xk-20xl/downloads
/driver-list/
Signed-off-by: Shengyu Qu <wiagn233@outlook.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Christophe JAILLET [Sun, 30 Oct 2022 07:00:03 +0000 (08:00 +0100)]
Bluetooth: Fix EALREADY and ELOOP cases in bt_status()
'err' is known to be <0 at this point.
So, some cases can not be reached because of a missing "-".
Add it.
Fixes:
ca2045e059c3 ("Bluetooth: Add bt_status")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Luiz Augusto von Dentz [Thu, 27 Oct 2022 23:18:04 +0000 (16:18 -0700)]
Bluetooth: Add CONFIG_BT_LE_L2CAP_ECRED
This adds CONFIG_BT_LE_L2CAP_ECRED which can be used to enable L2CAP
Enhanced Credit Flow Control Mode by default, previously it was only
possible to set it via module parameter (e.g. bluetooth.enable_ecred=1).
Since L2CAP ECRED mode is required by the likes of EATT which is
recommended for LE Audio this enables it by default.
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Tested-By: Tedd Ho-Jeong An <tedd.an@intel.com>
Luiz Augusto von Dentz [Tue, 25 Oct 2022 21:12:58 +0000 (14:12 -0700)]
Bluetooth: btusb: Default CONFIG_BT_HCIBTUSB_POLL_SYNC=y
poll_sync has been proven to fix races of USB data and event endpoints
so this enables it by default.
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Tested-by: Tedd Ho-Jeong An <tedd.an@intel.com>
Luiz Augusto von Dentz [Tue, 25 Oct 2022 21:12:57 +0000 (14:12 -0700)]
Bluetooth: btusb: Add CONFIG_BT_HCIBTUSB_POLL_SYNC
This adds CONFIG_BT_HCIBTUSB_POLL_SYNC which can be used to set the
default behavior of Bluetooth USB controller with respect to poll
synchronization of its endpoits.
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Tested-by: Tedd Ho-Jeong An <tedd.an@intel.com>
Igor Skalkin [Mon, 24 Oct 2022 13:40:33 +0000 (15:40 +0200)]
virtio_bt: Fix alignment in configuration struct
The current version of the configuration structure has unaligned
16-bit fields, but according to the specification [1], access to
the configuration space must be aligned.
Add a second, aligned version of the configuration structure
and a new feature bit indicating that this version is being used.
[1] https://docs.oasis-open.org/virtio/virtio/v1.1/virtio-v1.1.pdf
Signed-off-by: Igor Skalkin <Igor.Skalkin@opensynergy.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Inga Stotland [Sat, 22 Oct 2022 00:48:56 +0000 (17:48 -0700)]
Bluetooth: MGMT: Fix error report for ADD_EXT_ADV_PARAMS
When validating the parameter length for MGMT_OP_ADD_EXT_ADV_PARAMS
command, use the correct op code in error status report:
was MGMT_OP_ADD_ADVERTISING, changed to MGMT_OP_ADD_EXT_ADV_PARAMS.
Fixes:
12410572833a2 ("Bluetooth: Break add adv into two mgmt commands")
Signed-off-by: Inga Stotland <inga.stotland@intel.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Yang Yingliang [Thu, 20 Oct 2022 02:16:56 +0000 (10:16 +0800)]
Bluetooth: hci_core: fix error handling in hci_register_dev()
If hci_register_suspend_notifier() returns error, the hdev and rfkill
are leaked. We could disregard the error and print a warning message
instead to avoid leaks, as it just means we won't be handing suspend
requests.
Fixes:
9952d90ea288 ("Bluetooth: Handle PM_SUSPEND_PREPARE and PM_POST_SUSPEND")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Jiapeng Chong [Mon, 17 Oct 2022 05:47:13 +0000 (13:47 +0800)]
Bluetooth: Use kzalloc instead of kmalloc/memset
Use kzalloc rather than duplicating its implementation, which makes code
simple and easy to understand.
./net/bluetooth/hci_conn.c:2038:6-13: WARNING: kzalloc should be used for cp, instead of kmalloc/memset.
Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=2406
Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Zhengping Jiang [Thu, 13 Oct 2022 21:45:08 +0000 (14:45 -0700)]
Bluetooth: hci_qca: only assign wakeup with serial port support
Only assign hdev->wakeup if the serial port supports wakeup. Otherwise
it will fall back to the hci_uart_wakeup or the behavior that can be
overridden before calling the hci_uart_register_device().
Signed-off-by: Zhengping Jiang <jiangzp@google.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Pauli Virtanen [Tue, 11 Oct 2022 19:25:34 +0000 (22:25 +0300)]
Bluetooth: hci_conn: use HCI dst_type values also for BIS
For ISO BIS related functions in hci_conn.c, make dst_type values be HCI
address type values, not ISO socket address type values. This makes it
consistent with CIS functions.
Signed-off-by: Pauli Virtanen <pav@iki.fi>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Hilda Wu [Wed, 5 Oct 2022 08:43:31 +0000 (16:43 +0800)]
Bluetooth: btusb: Ignore zero length of USB packets on ALT 6 for specific chip
For USB ALT 6 settings some Realtek chips need to transmit mSBC data
continuously without the zero length of USB packets.
In this commit, create BTUSB_ALT6_CONTINUOUS_TX to manage the behavior.
Therefore, create REALTEK_ALT6_CONTINUOUS_TX_CHIP to manage the specific
chip model for the behavior.
Signed-off-by: Max Chou <max.chou@realtek.com>
Signed-off-by: Hilda Wu <hildawu@realtek.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Hilda Wu [Wed, 5 Oct 2022 08:43:30 +0000 (16:43 +0800)]
Bluetooth: btrtl: Add btrealtek data struct
This patch adds a data structure for btrealtek object, and the
definition of vendor behavior flags. It also adds macros to set/test/get
the flags.
Signed-off-by: Hilda Wu <hildawu@realtek.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Michael S. Tsirkin [Mon, 10 Oct 2022 17:14:37 +0000 (13:14 -0400)]
Bluetooth: virtio_bt: fix device removal
Device removal is clearly out of virtio spec: it attempts to remove
unused buffers from a VQ before invoking device reset. To fix, make
open/close NOPs and do all cleanup/setup in probe/remove.
NB: This is a hacky way to handle this - virtbt_{open,close} as NOP is
not really what a driver is supposed to be doing. These are transport
enable/disable callbacks from the BT core towards the driver. It maps to
a device being enabled/disabled by something like bluetoothd for
example. So if disabled, users expect that no resources/queues are in
use. It does work with all other transports like USB, SDIO, UART etc.
There should be no buffer used if the device is powered off. We also
don’t have any USB URBs in-flight if the transport is not active.
The way to implement a proper fix would be using vq reset if supported,
or even using a full device reset.
The cost of the hack is a single skb wasted on an unused bt device.
NB2: with this fix in place driver still suffers from a race condition
if an interrupt triggers while device is being reset. To fix, in the
virtbt_close() callback we should deactivate all interrupts. To be
fixed.
squashed fixup: bluetooth: virtio_bt: fix an error code in probe()
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <
20220811080943.198245-1-mst@redhat.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Tested-by: Igor Skalkin <Igor.Skalkin@opensynergy.com>
Archie Pusaka [Wed, 5 Oct 2022 07:09:47 +0000 (15:09 +0800)]
Bluetooth: hci_sync: cancel cmd_timer if hci_open failed
If a command is already sent, we take care of freeing it, but we
also need to cancel the timeout as well.
Signed-off-by: Archie Pusaka <apusaka@chromium.org>
Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@google.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Luiz Augusto von Dentz [Sat, 8 Oct 2022 01:08:43 +0000 (18:08 -0700)]
Bluetooth: hci_sync: Fix not able to set force_static_address
force_static_address shall be writable while hdev is initing but is not
considered powered yet since the static address is written only when
powered.
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Tested-by: Brian Gix <brian.gix@intel.com>
Luiz Augusto von Dentz [Fri, 7 Oct 2022 20:25:38 +0000 (13:25 -0700)]
Bluetooth: hci_sync: Fix not setting static address
This attempts to program the address stored in hdev->static_addr after
the init sequence has been complete:
@ MGMT Command: Set Static A.. (0x002b) plen 6
Address: C0:55:44:33:22:11 (Static)
@ MGMT Event: Command Complete (0x0001) plen 7
Set Static Address (0x002b) plen 4
Status: Success (0x00)
Current settings: 0x00008200
Low Energy
Static Address
@ MGMT Event: New Settings (0x0006) plen 4
Current settings: 0x00008200
Low Energy
Static Address
< HCI Command: LE Set Random.. (0x08|0x0005) plen 6
Address: C0:55:44:33:22:11 (Static)
> HCI Event: Command Complete (0x0e) plen 4
LE Set Random Address (0x08|0x0005) ncmd 1
Status: Success (0x00)
@ MGMT Event: Command Complete (0x0001) plen 7
Set Powered (0x0005) plen 4
Status: Success (0x00)
Current settings: 0x00008201
Powered
Low Energy
Static Address
@ MGMT Event: New Settings (0x0006) plen 4
Current settings: 0x00008201
Powered
Low Energy
Static Address
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Tested-by: Brian Gix <brian.gix@intel.com>
Nicolas Cavallari [Wed, 5 Oct 2022 15:06:21 +0000 (17:06 +0200)]
Bluetooth: Work around SCO over USB HCI design defect
The USB interface between the host and the bluetooth adapter used for
SCO packets uses an USB isochronous endpoint with a fragmentation scheme
that does not tolerate errors. Except USB isochronous transfers do
not provide a reliable stream with guaranteed delivery. (There is no
retry on error, see USB spec v2.0 5.6 and 8.5.5.)
To fragment a packet, the bluetooth HCI simply splits it in parts and
transfer them as-is. The receiver is expected to reconstruct the packet
by assuming the first fragment contains the header and parsing its size
field. There is no error detection either.
If a fragment is lost, the end result is that the kernel is no longer
synchronized and will pass malformed data to the upper layers, since it
has no way to tell if the first fragment is an actual first fragment or
a continuation fragment. Resynchronization can only happen by luck and
requires an unbounded amount of time.
The typical symptom for a HSP/HFP bluetooth headset is that the
microphone stops working and dmesg contains piles of rate-limited
"Bluetooth: hci0: SCO packet for unknown connection handle XXXX"
errors for an indeterminate amount of time, until the kernel accidentally
resynchronize.
A workaround is to ask the upper layer to prevalidate the first fragment
header. This is not possible with user channels so this workaround is
disabled in this case.
This problem is the most severe when using an ath3k adapter on an i.MX 6
board, where packet loss occur regularly, possibly because it is an USB1
device connected on an USB2 hub and this is a special case requiring
split transactions.
Signed-off-by: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Archie Pusaka [Thu, 6 Oct 2022 09:09:31 +0000 (17:09 +0800)]
Bluetooth: btusb: Introduce generic USB reset
On cmd_timeout with no reset_gpio, reset the USB port as a last
resort.
This patch changes the behavior of btusb_intel_cmd_timeout and
btusb_rtl_cmd_timeout.
Signed-off-by: Archie Pusaka <apusaka@chromium.org>
Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@google.com>
Reviewed-by: Ying Hsu <yinghsu@chromium.org>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Chethan Tumkur Narayan [Mon, 3 Oct 2022 06:48:36 +0000 (12:18 +0530)]
btusb: Avoid reset of ISOC endpoint alt settings to zero
In case of suspend/resume and HCI_RESET (BT On and Off),
ISOC endpoint set to alt setting 0 when no SCO connection exists.
This patch shall avoid resetting of ISOC endpoint to alt setting to 0.
Signed-off-by: Chethan Tumkur Narayan <chethan.tumkur.narayan@intel.com>
Signed-off-by: Kiran K <kiran.k@intel.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Rob Herring [Fri, 9 Dec 2022 17:15:52 +0000 (11:15 -0600)]
dt-bindings: net: Convert Socionext NetSec Ethernet to DT schema
Convert the Socionext NetSec Ethernet binding to DT schema format.
Signed-off-by: Rob Herring <robh@kernel.org>
Acked-by: Jassi Brar <jaswinder.singh@linaro.org>
Link: https://lore.kernel.org/r/20221209171553.3350583-1-robh@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Taras Chornyi [Fri, 9 Dec 2022 15:45:21 +0000 (17:45 +0200)]
MAINTAINERS: Update email address for Marvell Prestera Ethernet Switch driver
Taras's Marvell email account will be shut down soon so change it to Plvision.
Signed-off-by: Taras Chornyi <taras.chornyi@plvision.eu>
Signed-off-by: Vadym Kochan <vadym.kochan@plvision.eu>
Link: https://lore.kernel.org/r/20221209154521.1246881-1-vadym.kochan@plvision.eu
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Xu Panda [Fri, 9 Dec 2022 07:38:59 +0000 (15:38 +0800)]
net: hns3: use strscpy() to instead of strncpy()
The implementation of strscpy() is more robust and safer.
That's now the recommended way to copy NUL terminated strings.
Signed-off-by: Xu Panda <xu.panda@zte.com.cn>
Signed-off-by: Yang Yang <yang.yang29@zte.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Link: https://lore.kernel.org/r/202212091538591375035@zte.com.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Firo Yang [Fri, 9 Dec 2022 05:48:54 +0000 (13:48 +0800)]
sctp: sysctl: make extra pointers netns aware
Recently, a customer reported that from their container whose
net namespace is different to the host's init_net, they can't set
the container's net.sctp.rto_max to any value smaller than
init_net.sctp.rto_min.
For instance,
Host:
sudo sysctl net.sctp.rto_min
net.sctp.rto_min = 1000
Container:
echo 100 > /mnt/proc-net/sctp/rto_min
echo 400 > /mnt/proc-net/sctp/rto_max
echo: write error: Invalid argument
This is caused by the check made from this'commit
4f3fdf3bc59c
("sctp: add check rto_min and rto_max in sysctl")'
When validating the input value, it's always referring the boundary
value set for the init_net namespace.
Having container's rto_max smaller than host's init_net.sctp.rto_min
does make sense. Consider that the rto between two containers on the
same host is very likely smaller than it for two hosts.
So to fix this problem, as suggested by Marcelo, this patch makes the
extra pointers of rto_min, rto_max, pf_retrans, and ps_retrans point
to the corresponding variables from the newly created net namespace while
the new net namespace is being registered in sctp_sysctl_net_register.
Fixes:
4f3fdf3bc59c ("sctp: add check rto_min and rto_max in sysctl")
Reviewed-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Reviewed-by: Jakub Kicinski <kuba@kernel.org>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: Firo Yang <firo.yang@suse.com>
Link: https://lore.kernel.org/r/20221209054854.23889-1-firo.yang@suse.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Roger Quadros [Thu, 8 Dec 2022 10:55:34 +0000 (12:55 +0200)]
net: ethernet: ti: am65-cpsw: Fix PM runtime leakage in am65_cpsw_nuss_ndo_slave_open()
Ensure pm_runtime_put() is issued in error path.
Reported-by: Jakub Kicinski <kuba@kernel.org>
Fixes:
93a76530316a ("net: ethernet: ti: introduce am65x/j721e gigabit eth subsystem driver")
Signed-off-by: Roger Quadros <rogerq@kernel.org>
Reviewed-by: Saeed Mahameed <saeed@kernel.org>
Link: https://lore.kernel.org/r/20221208105534.63709-1-rogerq@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Jakub Kicinski [Mon, 12 Dec 2022 20:15:23 +0000 (12:15 -0800)]
Merge tag 'wireless-next-2022-12-12' of git://git./linux/kernel/git/wireless/wireless-next
Kalle Valo says:
====================
wireless-next patches for v6.2
Fourth set of patches for v6.2. Few final patches, a big change is
that rtw88 now has USB support.
Major changes:
rtw88
* support USB devices rtw8821cu, rtw8822bu, rtw8822cu and rtw8723du
* tag 'wireless-next-2022-12-12' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (43 commits)
wifi: rtl8xxxu: fixing IQK failures for rtl8192eu
wifi: rtlwifi: btcoexist: fix conditions branches that are never executed
wifi: rtlwifi: rtl8192se: remove redundant rtl_get_bbreg() call
wifi: rtw88: Add rtw8723du chipset support
wifi: rtw88: Add rtw8822cu chipset support
wifi: rtw88: Add rtw8822bu chipset support
wifi: rtw88: Add rtw8821cu chipset support
wifi: rtw88: Add common USB chip support
wifi: rtw88: iterate over vif/sta list non-atomically
wifi: rtw88: Drop coex mutex
wifi: rtw88: Drop h2c.lock
wifi: rtw88: Drop rf_lock
wifi: rtw88: Call rtw_fw_beacon_filter_config() with rtwdev->mutex held
wifi: rtw88: print firmware type in info message
wifi: rtw89: add join info upon create interface
wifi: rtw89: fix unsuccessful interface_add flow
wifi: rtw89: stop mac port function when stop_ap()
wifi: rtw89: add mac TSF sync function
wifi: rtw89: request full firmware only once if it's early requested
wifi: rtw89: don't request partial firmware if SECURITY_LOADPIN_ENFORCE
...
====================
Link: https://lore.kernel.org/r/20221212093026.5C5AEC433D2@smtp.kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Jakub Kicinski [Mon, 12 Dec 2022 19:27:41 +0000 (11:27 -0800)]
Merge tag 'for-netdev' of https://git./linux/kernel/git/bpf/bpf-next
Alexei Starovoitov says:
====================
pull-request: bpf-next 2022-12-11
We've added 74 non-merge commits during the last 11 day(s) which contain
a total of 88 files changed, 3362 insertions(+), 789 deletions(-).
The main changes are:
1) Decouple prune and jump points handling in the verifier, from Andrii.
2) Do not rely on ALLOW_ERROR_INJECTION for fmod_ret, from Benjamin.
Merged from hid tree.
3) Do not zero-extend kfunc return values. Necessary fix for 32-bit archs,
from Björn.
4) Don't use rcu_users to refcount in task kfuncs, from David.
5) Three reg_state->id fixes in the verifier, from Eduard.
6) Optimize bpf_mem_alloc by reusing elements from free_by_rcu, from Hou.
7) Refactor dynptr handling in the verifier, from Kumar.
8) Remove the "/sys" mount and umount dance in {open,close}_netns
in bpf selftests, from Martin.
9) Enable sleepable support for cgrp local storage, from Yonghong.
* tag 'for-netdev' of https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next: (74 commits)
selftests/bpf: test case for relaxed prunning of active_lock.id
selftests/bpf: Add pruning test case for bpf_spin_lock
bpf: use check_ids() for active_lock comparison
selftests/bpf: verify states_equal() maintains idmap across all frames
bpf: states_equal() must build idmap for all function frames
selftests/bpf: test cases for regsafe() bug skipping check_id()
bpf: regsafe() must not skip check_ids()
docs/bpf: Add documentation for BPF_MAP_TYPE_SK_STORAGE
selftests/bpf: Add test for dynptr reinit in user_ringbuf callback
bpf: Use memmove for bpf_dynptr_{read,write}
bpf: Move PTR_TO_STACK alignment check to process_dynptr_func
bpf: Rework check_func_arg_reg_off
bpf: Rework process_dynptr_func
bpf: Propagate errors from process_* checks in check_func_arg
bpf: Refactor ARG_PTR_TO_DYNPTR checks into process_dynptr_func
bpf: Skip rcu_barrier() if rcu_trace_implies_rcu_gp() is true
bpf: Reuse freed element in free_by_rcu during allocation
selftests/bpf: Bring test_offload.py back to life
bpf: Fix comment error in fixup_kfunc_call function
bpf: Do not zero-extend kfunc return values
...
====================
Link: https://lore.kernel.org/r/20221212024701.73809-1-alexei.starovoitov@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
David S. Miller [Mon, 12 Dec 2022 12:11:37 +0000 (12:11 +0000)]
Merge tag 'linux-can-next-for-6.2-
20221212' of git://git./linux/kernel/git/mkl/linux-can-next
Marc Kleine-Budde says:
====================
linux-can-next-for-6.2-
20221212
this is a pull request of 39 patches for net-next/master.
The first 2 patches are by me fix a warning and coding style in the
kvaser_usb driver.
Vivek Yadav's patch sorts the includes of the m_can driver.
Biju Das contributes 5 patches for the rcar_canfd driver improve the
support for different IP core variants.
Jean Delvare's patch for the ctucanfd drops the dependency on
COMPILE_TEST.
Vincent Mailhol's patch sorts the includes of the etas_es58x driver.
Haibo Chen's contributes 2 patches that add i.MX93 support to the
flexcan driver.
Lad Prabhakar's patch updates the dt-bindings documentation of the
rcar_canfd driver.
Minghao Chi's patch converts the c_can platform driver to
devm_platform_get_and_ioremap_resource().
In the next 7 patches Vincent Mailhol adds devlink support to the
etas_es58x driver to report firmware, bootloader and hardware version.
Xu Panda's patch converts a strncpy() -> strscpy() in the ucan driver.
Ye Bin's patch removes a useless parameter from the AF_CAN protocol.
The next 2 patches by Vincent Mailhol and remove unneeded or unused
pointers to struct usb_interface in device's priv struct in the ucan
and gs_usb driver.
Vivek Yadav's patch cleans up the usage of the RAM initialization in
the m_can driver.
A patch by me add support for SO_MARK to the AF_CAN protocol.
Geert Uytterhoeven's patch fixes the number of CAN channels in the
rcan_canfd bindings documentation.
In the last 11 patches Markus Schneider-Pargmann optimizes the
register access in the t_can driver and cleans up the tcan glue
driver.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Marc Kleine-Budde [Mon, 12 Dec 2022 11:01:26 +0000 (12:01 +0100)]
Merge patch series "can: m_can: Optimizations for tcan and peripheral chips"
Markus Schneider-Pargmann <msp@baylibre.com> says:
as requested I split the series into two parts. This is the first
parts with simple improvements to reduce the number of SPI transfers.
The second part will be the rest with coalescing support and more
complex optimizations.
Changes since v1: https://lore.kernel.org/all/
20221116205308.2996556-1-msp@baylibre.com
- Fixed register ranges
- Added fixes: tag for two patches
Link: https://lore.kernel.org/all/20221206115728.1056014-1-msp@baylibre.com
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Markus Schneider-Pargmann [Tue, 6 Dec 2022 11:57:28 +0000 (12:57 +0100)]
can: tcan4x5x: Specify separate read/write ranges
Specify exactly which registers are read/writeable in the chip. This
is supposed to help detect any violations in the future.
Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
Link: https://lore.kernel.org/all/20221206115728.1056014-12-msp@baylibre.com
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Markus Schneider-Pargmann [Tue, 6 Dec 2022 11:57:27 +0000 (12:57 +0100)]
can: tcan4x5x: Fix register range of first two blocks
According to the datasheet 0x10 is the last register in the first block,
not register 0x2c.
The datasheet lists the last register of the second block as 0x830, not
0x83c.
Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
Link: https://lore.kernel.org/all/20221206115728.1056014-11-msp@baylibre.com
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Markus Schneider-Pargmann [Tue, 6 Dec 2022 11:57:26 +0000 (12:57 +0100)]
can: tcan4x5x: Fix use of register error status mask
TCAN4X5X_ERROR_STATUS is not a status register that needs clearing
during interrupt handling. Instead this is a masking register that masks
error interrupts. Writing TCAN4X5X_CLEAR_ALL_INT to this register
effectively masks everything.
Rename the register and mask all error interrupts only once by writing
to the register in tcan4x5x_init.
Fixes:
5443c226ba91 ("can: tcan4x5x: Add tcan4x5x driver to the kernel")
Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
Link: https://lore.kernel.org/all/20221206115728.1056014-10-msp@baylibre.com
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Markus Schneider-Pargmann [Tue, 6 Dec 2022 11:57:25 +0000 (12:57 +0100)]
can: tcan4x5x: Remove invalid write in clear_interrupts
Register 0x824 TCAN4X5X_MCAN_INT_REG is a read-only register. Any writes
to this register do not have any effect.
Remove this write. The m_can driver aldready clears the interrupts in
m_can_isr() by writing to M_CAN_IR which is translated to register
0x1050 which is a writable version of this register.
Fixes:
5443c226ba91 ("can: tcan4x5x: Add tcan4x5x driver to the kernel")
Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
Link: https://lore.kernel.org/all/20221206115728.1056014-9-msp@baylibre.com
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Markus Schneider-Pargmann [Tue, 6 Dec 2022 11:57:24 +0000 (12:57 +0100)]
can: m_can: Batch acknowledge rx fifo
Instead of acknowledging every item of the fifo, only acknowledge the
last item read. This behavior is documented in the datasheet. The new
getindex will be the acknowledged item + 1.
Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
Link: https://lore.kernel.org/all/20221206115728.1056014-8-msp@baylibre.com
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
projects / platform / kernel / linux-rpi.git / log