Felix Fietkau [Mon, 10 Oct 2022 09:43:38 +0000 (11:43 +0200)]
wifi: mac80211: add support for restricting netdev features per vif
This can be used to selectively disable feature flags for checksum offload,
scatter/gather or GSO by changing vif->netdev_features.
Removing features from vif->netdev_features does not affect the netdev
features themselves, but instead fixes up skbs in the tx path so that the
offloads are not needed in the driver.
Aside from making it easier to deal with vif type based hardware limitations,
this also makes it possible to optimize performance on hardware without native
GSO support by declaring GSO support in hw->netdev_features and removing it
from vif->netdev_features. This allows mac80211 to handle GSO segmentation
after the sta lookup, but before itxq enqueue, thus reducing the number of
unnecessary sta lookups, as well as some other per-packet processing.
Johannes Berg [Fri, 14 Oct 2022 16:56:11 +0000 (18:56 +0200)]
wifi: mac80211: don't parse multi-BSSID in assoc resp
It's not valid to have the multiple BSSID element in the
association response (per 802.11 REVme D1.0), so don't
try to parse it there, but only in the fallback beacon
elements if needed.
The other case that was parsing association requests was
already changed in a previous commit.
Change-Id: I659d2ef1253e079cc71c46a017044e116e31c024 Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The call to ieee80211_do_stop() right after will also do
synchronize_rcu() to ensure the SDATA_STATE_RUNNING bit
is cleared, so we don't need to synchronize_net() here.
Change-Id: Id9f9ffcf195002013e5d9fde288877d219780864 Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Chen Zhongjin [Wed, 9 Nov 2022 09:02:37 +0000 (17:02 +0800)]
wifi: cfg80211: Fix not unregister reg_pdev when load_builtin_regdb_keys() fails
In regulatory_init_db(), when it's going to return a error, reg_pdev
should be unregistered. When load_builtin_regdb_keys() fails it doesn't
do it and makes cfg80211 can't be reload with report:
JUN-KYU SHIN [Fri, 11 Nov 2022 02:33:04 +0000 (11:33 +0900)]
wifi: cfg80211: fix comparison of BSS frequencies
If the "channel->freq_offset" comparison is omitted in cmp_bss(),
BSS with different kHz units cannot be distinguished in the S1G Band.
So "freq_offset" should also be included in the comparison.
Kees Cook [Wed, 30 Nov 2022 21:26:45 +0000 (13:26 -0800)]
wifi: ieee80211: Do not open-code qos address offsets
When building with -Wstringop-overflow, GCC's KASAN implementation does
not correctly perform bounds checking within some complex structures
when faced with literal offsets, and can get very confused. For example,
this warning is seen due to literal offsets into sturct ieee80211_hdr
that may or may not be large enough:
drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c: In function 'iwl_mvm_rx_mpdu_mq':
drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c:2022:29: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
2022 | *qc &= ~IEEE80211_QOS_CTL_A_MSDU_PRESENT;
In file included from drivers/net/wireless/intel/iwlwifi/mvm/fw-api.h:32,
from drivers/net/wireless/intel/iwlwifi/mvm/sta.h:15,
from drivers/net/wireless/intel/iwlwifi/mvm/mvm.h:27,
from drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c:10:
drivers/net/wireless/intel/iwlwifi/mvm/../fw/api/rx.h:559:16: note: at offset [78, 166] into destination object 'mpdu_len' of size 2
559 | __le16 mpdu_len;
| ^~~~~~~~
Refactor ieee80211_get_qos_ctl() to avoid using literal offsets,
requiring the creation of the actual structure that is described in the
comments. Explicitly choose the desired offset, making the code more
human-readable too. This is one of the last remaining warning to fix
before enabling -Wstringop-overflow globally.
Zong-Zhe Yang [Tue, 29 Nov 2022 08:31:30 +0000 (16:31 +0800)]
wifi: rtw89: link rtw89_vif and chanctx stuffs
First, introduce struct rtw89_sub_entity for chanctx related stuffs.
Second, add enum rtw89_sub_entity_idx to rtw89_vif for vif operation
to access its/right chanctx stuffs after future multi-channel support.
Besides, RTW89_SUB_ENTITY_0 is the default chanctx entry throughout
driver, i.e. it's used for things which may not have a target chanctx
yet. So, we need to ensure that RTW89_SUB_ENTITY_0 is always working.
If there is at least one alive chanctx, then one of them must take
RTW89_SUB_ENTITY_0. If no alive chanctx, RTW89_SUB_ENTITY_0 will be
filled by rtw89_config_default_chandef().
Zong-Zhe Yang [Tue, 29 Nov 2022 08:31:29 +0000 (16:31 +0800)]
wifi: rtw89: fw: implement MCC related H2C
These MCC H2C(s) require to wait for MCC C2H to determine if the
execution is successful. Through rtw89_wait_for_cond(), we make
them wait for either a completion with data from MCC C2H handlers,
which calls rtw89_complete_cond(), or timeout.
Zong-Zhe Yang [Tue, 29 Nov 2022 08:31:28 +0000 (16:31 +0800)]
wifi: rtw89: mac: process MCC related C2H
Process C2H(s) related to MCC (multi-channel concurrency). These handling,
which either call rtw89_complete_cond() or show message in debug mode, can
be considered atomic/lock-free. So, they should be safe to be processed
directly after C2H pre-check in previous patch.
Zong-Zhe Yang [Tue, 29 Nov 2022 08:31:27 +0000 (16:31 +0800)]
wifi: rtw89: introduce helpers to wait/complete on condition
MCC (multi-channel concurrency) related H2Cs (host to chip commands)
require to wait for C2H (chip to host events) responses to judge the
execution result and data. We introduce helpers to assist this process.
Besides, we would like the helpers to be generic for use in driver even
outside of MCC H2C/C2H, so we make a independent patch for them.
In the following, I describe the things first.
```
(A) C2H is generated by FW, and then transferred upto driver. Hence,
driver cannot get it immediately without a bit waitting/blocking.
For this, we choose to use wait_for_completion_*() instead of
busy polling.
(B) From the driver management perspective, a scenario, e.g. MCC,
may have mulitple kind of H2C functions requiring this process
to wait for corresponding C2Hs. But, the driver management flow
uses mutex to protect each behavior. So, one scenario triggers
one H2C function at one time. To avoid rampant instances of
struct completion for each H2C function, we choose to use one
struct completion with one condition flag for one scenario.
(C) C2Hs, which H2Cs will be waitting for, cannot be ordered with
driver management flow, i.e. cannot enqueue work to the same
ordered workqueue and cannot lock by the same mutex, to prevent
H2C side from getting no C2H responses. So, those C2Hs are parsed
in interrupt context directly as done in previous commit.
(D) Following (C), the above underline H2Cs and C2Hs will be handled
in different contexts without sync. So, we use atomic_cmpxchg()
to compare and change the condition in atomic.
```
So, we introduce struct rtw89_wait_info which combines struct completion
and atomic_t. Then, the below are the descriptions for helper functions.
* rtw89_wait_for_cond() to wait for a completion based on a condition.
* rtw89_complete_cond() to complete a given condition and carry data.
Each rtw89_wait_info instance independently determines the meaning of
its waitting conditions. But, RTW89_WAIT_COND_IDLE (UINT_MAX) is reserved.
Zong-Zhe Yang [Tue, 29 Nov 2022 08:31:26 +0000 (16:31 +0800)]
wifi: rtw89: check if atomic before queuing c2h
Before queuing C2H work, we check atomicity of the C2H's handler first now.
If atomic or lock-free, handle it directly; otherwise, handle it with mutex
in work as previous. This prepares for MAC MCC C2Hs which require to be
processed directly. And, their handlers will be functions which can be
considered atomic.
Zong-Zhe Yang [Tue, 29 Nov 2022 08:31:25 +0000 (16:31 +0800)]
wifi: rtw89: rfk: rename rtw89_mcc_info to rtw89_rfk_mcc_info
The `rtw89_mcc_info mcc` is only for RFK MCC stuffs instead of common
MCC management info. Replace it with `rtw89_rfk_mcc_info rfk_mcc` to
avoid confusion and reserve `struct rtw89_mcc_info mcc` for MCC management
code.
8821ce is a combo card, and BT is a USB device that could get card lost
during stress test, and need WiFi firmware to detect and recover it, so
driver sends a H2C to enable this mechanism.
Ping-Ke Shih [Fri, 25 Nov 2022 07:24:16 +0000 (15:24 +0800)]
wifi: rtw89: 8852b: turn off PoP function in monitor mode
PoP stands for Packet on Packet that can improve performance in noisy
environment, but it could get RX stuck suddenly. In normal mode, firmware
can help to resolve the stuck, but firmware doesn't work in monitor mode.
Therefore, turn off PoP to avoid RX stuck.
Ping-Ke Shih [Fri, 25 Nov 2022 07:24:15 +0000 (15:24 +0800)]
wifi: rtw89: add HE radiotap for monitor mode
With basic HE radiotap, we can check data rate in sniffer data. To store
the radiotap data, we reserve headroom of aligned 64 bytes, and then
update HE radiotap in monitor mode, so it doesn't affect performance in
normal mode.
For running with mac80211 channel context ops and using only as monitor,
we need to enable WANT_MONITOR_VIF to let mac80211 process virtual monitor
interface. Then, we are able to set channel on the monitor from user space.
Minsuk Kang [Wed, 16 Nov 2022 14:29:52 +0000 (23:29 +0900)]
wifi: brcmfmac: Check the count value of channel spec to prevent out-of-bounds reads
This patch fixes slab-out-of-bounds reads in brcmfmac that occur in
brcmf_construct_chaninfo() and brcmf_enable_bw40_2g() when the count
value of channel specifications provided by the device is greater than
the length of 'list->element[]', decided by the size of the 'list'
allocated with kzalloc(). The patch adds checks that make the functions
free the buffer and return -EINVAL if that is the case. Note that the
negative return is handled by the caller, brcmf_setup_wiphybands() or
brcmf_cfg80211_attach().
Found by a modified version of syzkaller.
Crash Report from brcmf_construct_chaninfo():
==================================================================
BUG: KASAN: slab-out-of-bounds in brcmf_setup_wiphybands+0x1238/0x1430
Read of size 4 at addr ffff888115f24600 by task kworker/0:2/1896
The buggy address belongs to the object at ffff888115f24000
which belongs to the cache kmalloc-2k of size 2048
The buggy address is located 1536 bytes inside of
2048-byte region [ffff888115f24000, ffff888115f24800)
Memory state around the buggy address: ffff888115f24500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff888115f24580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffff888115f24600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
^ ffff888115f24680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff888115f24700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================
Crash Report from brcmf_enable_bw40_2g():
==================================================================
BUG: KASAN: slab-out-of-bounds in brcmf_cfg80211_attach+0x3d11/0x3fd0
Read of size 4 at addr ffff888103787600 by task kworker/0:2/1896
The buggy address belongs to the object at ffff888103787000
which belongs to the cache kmalloc-2k of size 2048
The buggy address is located 1536 bytes inside of
2048-byte region [ffff888103787000, ffff888103787800)
Memory state around the buggy address: ffff888103787500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff888103787580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffff888103787600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
^ ffff888103787680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff888103787700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================
Reported-by: Dokyung Song <dokyungs@yonsei.ac.kr> Reported-by: Jisoo Jang <jisoo.jang@yonsei.ac.kr> Reported-by: Minsuk Kang <linuxlovemin@yonsei.ac.kr> Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Minsuk Kang <linuxlovemin@yonsei.ac.kr> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221116142952.518241-1-linuxlovemin@yonsei.ac.kr
Ji-Pin Jou [Thu, 24 Nov 2022 06:44:42 +0000 (14:44 +0800)]
wifi: rtw88: fix race condition when doing H2C command
For SDIO/USB interface, since the tranferring speed is slower than
that in PCIE, it may have race condition when the driver sets down
H2C command to the FW.
In the function rtw_fw_send_h2c_command, before the patch, box_reg
is written first, then box_ex_reg is written. FW starts to work and
fetch the value of box_ex_reg, when the most significant byte of
box_reg(4 bytes) is written. Meanwhile, for SDIO/USB interface,
since the transferring speed is slow, the driver is still in writing
the new value of box_ex_reg through the bus, and FW may get the
wrong value of box_ex_reg at the moment.
To prevent the above driver/FW racing situation, box_ex_reg is
written first then box_reg. Furthermore, it is written in 4 bytes at
a time, instead of written in one byte one by one. It can increase
the speed for SDIO/USB interface.
Bitterblue Smith [Mon, 21 Nov 2022 20:56:58 +0000 (22:56 +0200)]
wifi: rtl8xxxu: Fix use after rcu_read_unlock in rtl8xxxu_bss_info_changed
Commit a8b5aef2cca1 ("wifi: rtl8xxxu: gen2: Enable 40 MHz channel width")
introduced a line where the pointer returned by ieee80211_find_sta() is
used after rcu_read_unlock().
Move rcu_read_unlock() a bit lower to fix this.
Fixes: a8b5aef2cca1 ("wifi: rtl8xxxu: gen2: Enable 40 MHz channel width") Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/3c82ad09-7593-3be1-1d2c-e58505fb43cb@gmail.com
Ziyang Xuan [Sat, 19 Nov 2022 05:19:00 +0000 (13:19 +0800)]
wifi: plfxlc: fix potential memory leak in __lf_x_usb_enable_rx()
urbs does not be freed in exception paths in __lf_x_usb_enable_rx().
That will trigger memory leak. To fix it, add kfree() for urbs within
"error" label. Compile tested only.
Kees Cook [Fri, 18 Nov 2022 21:11:47 +0000 (13:11 -0800)]
wifi: carl9170: Replace zero-length array of trailing structs with flex-array
Zero-length arrays are deprecated[1] and are being replaced with
flexible array members in support of the ongoing efforts to tighten the
FORTIFY_SOURCE routines on memcpy(), correctly instrument array indexing
with UBSAN_BOUNDS, and to globally enable -fstrict-flex-arrays=3.
Replace zero-length array with flexible-array member.
This results in no differences in binary output.
[1] https://github.com/KSPP/linux/issues/78
Cc: Christian Lamparter <chunkeey@googlemail.com> Cc: Kalle Valo <kvalo@kernel.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Eric Dumazet <edumazet@google.com> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Paolo Abeni <pabeni@redhat.com> Cc: "Gustavo A. R. Silva" <gustavoars@kernel.org> Cc: linux-wireless@vger.kernel.org Cc: netdev@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org> Acked-by: Christian Lamparter <chunkeey@gmail.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20221118211146.never.395-kees@kernel.org
Youghandhar Chintala [Thu, 17 Nov 2022 18:05:34 +0000 (23:35 +0530)]
wifi: ath10k: Store WLAN firmware version in SMEM image table
In a SoC based solution, it would be useful to know the versions of the
various binary firmware blobs the system is running on. On a QCOM based
SoC, this info can be obtained from socinfo debugfs infrastructure. For
this to work, respective subsystem drivers have to export the firmware
version information to an SMEM based version information table.
Having firmware version information at one place will help quickly
figure out the firmware versions of various subsystems on the device
instead of going through builds/logs in an event of a system crash.
Fill WLAN firmware version information in SMEM version table to be
printed as part of socinfo debugfs infrastructure on a Qualcomm based
SoC.
This change is applicable only for SNOC/QMI based targets.
Kees Cook [Fri, 18 Nov 2022 23:42:44 +0000 (15:42 -0800)]
wifi: p54: Replace zero-length array of trailing structs with flex-array
Zero-length arrays are deprecated[1] and are being replaced with
flexible array members in support of the ongoing efforts to tighten the
FORTIFY_SOURCE routines on memcpy(), correctly instrument array indexing
with UBSAN_BOUNDS, and to globally enable -fstrict-flex-arrays=3.
Replace zero-length array with flexible-array member.
This results in no differences in binary output (most especially because
struct pda_antenna_gain is unused). The struct is kept for future
reference.
[1] https://github.com/KSPP/linux/issues/78
Cc: Christian Lamparter <chunkeey@googlemail.com> Cc: Kalle Valo <kvalo@kernel.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Eric Dumazet <edumazet@google.com> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Paolo Abeni <pabeni@redhat.com> Cc: "Gustavo A. R. Silva" <gustavoars@kernel.org> Cc: linux-wireless@vger.kernel.org Cc: netdev@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org> Acked-by: Christian Lamparter <chunkeey@gmail.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221118234240.gonna.369-kees@kernel.org
Zong-Zhe Yang [Fri, 18 Nov 2022 04:23:22 +0000 (12:23 +0800)]
wifi: rtw89: fix physts IE page check
The index RTW89_PHYSTS_BITMAP_NUM is not a valid physts IE page.
So, fix the check condition.
Fixes: eb4e52b3f38d ("rtw89: fix incorrect channel info during scan") Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221118042322.26794-1-pkshih@realtek.com
Ping-Ke Shih [Thu, 17 Nov 2022 08:52:35 +0000 (16:52 +0800)]
wifi: rtw89: avoid inaccessible IO operations during doing change_interface()
During doing change_interface(), hardware is power-off, so some components
are inaccessible and return error. This causes things unexpected, and we
don't have a warning message for that. So, ignore some IO operations in
this situation, and add a warning message to indicate something wrong.
Eric Huang [Thu, 17 Nov 2022 06:30:01 +0000 (14:30 +0800)]
wifi: rtw89: switch BANDEDGE and TX_SHAPE based on OFDMA trigger frame
There are some registers for transmit waveform control, two of them used
in this change are for BANDEDGE and TX_SHAPE control. BANDEDGE controls
whether to apply band edge filter to transmit waveform. TX_SHAPE controls
whether to apply triangular mask to transmit waveform. It is found for
some chip, these two should be turned off during OFDMA UL traffic for
better performance.
Eric Huang [Thu, 17 Nov 2022 06:30:00 +0000 (14:30 +0800)]
wifi: rtw89: read CFO from FD or preamble CFO field of phy status ie_type 1 accordingly
Add macro to get FD(frequency domain) CFO field from ie_type 1, and correct
the naming for preamble CFO field. Each IC could assign the CFO source to
either FD CFO or preamble CFO in chip_info. Based on the suggestion from HW
designer, rtw8852b and its derived versions will have better CFO tracking
performance with FD CFO.
Ping-Ke Shih [Thu, 17 Nov 2022 06:18:32 +0000 (14:18 +0800)]
wifi: rtw89: 8852b: correct TX power controlled by BT-coexistence
When coexistence mechanism is under free-run mode, it could adjust WiFi
and BT TX power to avoid interference with each other. For other cases,
it should keep original TX power from regular predefined tables, so
set correct values to 255 for these cases.
where count is the max number of items the flexible array is supposed to
contain.
In this particular case, in the open-coded version sizeof(typeof-flex-array-elements)
is implicit in _count_ because the type of the flex array data is u8:
Gustavo A. R. Silva [Tue, 15 Nov 2022 21:53:27 +0000 (15:53 -0600)]
wifi: brcmfmac: replace one-element array with flexible-array member in struct brcmf_dload_data_le
One-element arrays are deprecated, and we are replacing them with flexible
array members instead. So, replace one-element array with flexible-array
member in struct brcmf_dload_data_le.
Important to mention is that doing a build before/after this patch results
in no binary output differences.
This helps with the ongoing efforts to tighten the FORTIFY_SOURCE routines
on memcpy() and help us make progress towards globally enabling
-fstrict-flex-arrays=3 [1].
Gustavo A. R. Silva [Mon, 14 Nov 2022 23:01:11 +0000 (17:01 -0600)]
wifi: brcmfmac: Replace one-element array with flexible-array member
One-element arrays are deprecated, and we are replacing them with flexible
array members instead. So, replace one-element array with flexible-array
member in struct brcmf_gscan_config.
Important to mention is that doing a build before/after this patch results
in no binary output differences.
This helps with the ongoing efforts to tighten the FORTIFY_SOURCE routines
on memcpy() and help us make progress towards globally enabling
-fstrict-flex-arrays=3 [1].
David S. Miller [Fri, 18 Nov 2022 12:09:20 +0000 (12:09 +0000)]
Merge tag 'rxrpc-next-20221116' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs
David Howells says:
====================
rxrpc: Fix oops and missing config conditionals
The patches that were pulled into net-next previously[1] had some issues
that this patchset fixes:
(1) Fix missing IPV6 config conditionals.
(2) Fix an oops caused by calling udpv6_sendmsg() directly on an AF_INET
socket.
(3) Fix the validation of network addresses on entry to socket functions
so that we don't allow an AF_INET6 address if we've selected an
AF_INET transport socket.
Eric Dumazet [Thu, 17 Nov 2022 09:26:41 +0000 (09:26 +0000)]
net: fix napi_disable() logic error
Dan reported a new warning after my recent patch:
New smatch warnings:
net/core/dev.c:6409 napi_disable() error: uninitialized symbol 'new'.
Indeed, we must first wait for STATE_SCHED and STATE_NPSVC to be cleared,
to make sure @new variable has been initialized properly.
Fixes: 4ffa1d1c6842 ("net: adopt try_cmpxchg() in napi_{enable|disable}()") Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <error27@gmail.com> Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Dan Carpenter [Thu, 17 Nov 2022 07:44:02 +0000 (10:44 +0300)]
rxrpc: uninitialized variable in rxrpc_send_ack_packet()
The "pkt" was supposed to have been deleted in a previous patch. It
leads to an uninitialized variable bug.
Fixes: 72f0c6fb0579 ("rxrpc: Allocate ACK records at proposal and queue for transmission") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: David Howells <dhowells@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Dan Carpenter [Thu, 17 Nov 2022 07:43:38 +0000 (10:43 +0300)]
rxrpc: fix rxkad_verify_response()
The error handling for if skb_copy_bits() fails was accidentally deleted
so the rxkad_decrypt_ticket() function is not called.
Fixes: 5d7edbc9231e ("rxrpc: Get rid of the Rx ring") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: David Howells <dhowells@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Lorenzo Bianconi [Wed, 16 Nov 2022 23:35:04 +0000 (00:35 +0100)]
net: ethernet: mtk_eth_soc: do not overwrite mtu configuration running reset routine
Restore user configured MTU running mtk_hw_init() during tx timeout routine
since it will be overwritten after a hw reset.
Reported-by: Felix Fietkau <nbd@nbd.name> Fixes: 9ea4d311509f ("net: ethernet: mediatek: add the whole ethernet reset into the reset process") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Alex Elder [Wed, 16 Nov 2022 22:37:18 +0000 (16:37 -0600)]
net: ipa: avoid a null pointer dereference
Dan Carpenter reported that Smatch found an instance where a pointer
which had previously been assumed could be null (as indicated by a
null check) was later dereferenced without a similar check.
In practice this doesn't lead to a problem because currently the
pointers used are all non-null. Nevertheless this patch addresses
the reported problem.
In addition, I spotted another bug that arose in the same commit.
When the command to initialize a routing table memory region was
added, the number of entries computed for the non-hashed table
was wrong (it ended up being a Boolean rather than the count
intended). This bug is fixed here as well.
Reported-by: Dan Carpenter <error27@gmail.com> Link: https://lore.kernel.org/kernel-janitors/Y3OOP9dXK6oEydkf@kili Tested-by: Caleb Connolly <caleb.connolly@linaro.com> Fixes: 5cb76899fb47 ("net: ipa: reduce arguments to ipa_table_init_add()") Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Fri, 18 Nov 2022 11:44:36 +0000 (11:44 +0000)]
Merge tag 'wireless-next-2022-11-18' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next
Kalle Valo says:
====================
wireless-next patches for v6.2
Second set of patches for v6.2. Only driver patches this time, nothing
really special. Unused platform data support was removed from wl1251
and rtw89 got WoWLAN support.
Major changes:
ath11k
* support configuring channel dwell time during scan
David S. Miller [Fri, 18 Nov 2022 11:42:54 +0000 (11:42 +0000)]
Merge branch 'sctp-vrf'
Xin Long says:
====================
sctp: support vrf processing
This patchset adds the VRF processing in SCTP. Simliar to TCP/UDP,
it includes socket bind and socket/association lookup changes.
For socket bind change, it allows sockets to bind to a VRF device
and allows multiple sockets with the same IP and PORT to bind to
different interfaces in patch 1-3.
For socket/association lookup change, it adds dif and sdif check
in both asoc and ep lookup in patch 4 and 5, and when binding to
nodev, users can decide if accept the packets received from one
l3mdev by setup a sysctl option in patch 6.
Note with VRF support, in a netns, an association will be decided
by src ip + src port + dst ip + dst port + bound_dev_if, and it's
possible for ss to have:
State Local Address:Port Peer Address:Port
ESTAB 192.168.1.2%vrf-s1:1234
`- ESTAB 192.168.1.2%veth1:1234 192.168.1.1:1234
ESTAB 192.168.1.2%vrf-s2:1234
`- ESTAB 192.168.1.2%veth2:1234 192.168.1.1:1234
See the selftest in patch 7 for more usage.
Also, thanks Carlo for testing this patch series on their use.
v1->v2:
- In Patch 5, move sctp_sk_bound_dev_eq() definition to net/sctp/
input.c to avoid a build error when IP_SCTP is disabled, as Paolo
suggested.
- In Patch 7, avoid one sleep by disabling the IPv6 dad, and remove
another sleep by using ss to check if the server's ready, and also
delete two unncessary sleeps in sctp_hello.c, as Paolo suggested.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Xin Long [Wed, 16 Nov 2022 20:01:22 +0000 (15:01 -0500)]
selftests: add a selftest for sctp vrf
This patch adds 12 small test cases: 01-04 test for the sysctl
net.sctp.l3mdev_accept. 05-10 test for only binding to a right
l3mdev device, the connection can be created. 11-12 test for
two socks binding to different l3mdev devices at the same time,
each of them can process the packets from the corresponding
peer. The tests run for both IPv4 and IPv6 SCTP.
Signed-off-by: Xin Long <lucien.xin@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Xin Long [Wed, 16 Nov 2022 20:01:20 +0000 (15:01 -0500)]
sctp: add dif and sdif check in asoc and ep lookup
This patch at first adds a pernet global l3mdev_accept to decide if it
accepts the packets from a l3mdev when a SCTP socket doesn't bind to
any interface. It's set to 1 to avoid any possible incompatible issue,
and in next patch, a sysctl will be introduced to allow to change it.
Then similar to inet/udp_sk_bound_dev_eq(), sctp_sk_bound_dev_eq() is
added to check either dif or sdif is equal to sk_bound_dev_if, and to
check sid is 0 or l3mdev_accept is 1 if sk_bound_dev_if is not set.
This function is used to match a association or a endpoint, namely
called by sctp_addrs_lookup_transport() and sctp_endpoint_is_match().
All functions that needs updating are:
Xin Long [Wed, 16 Nov 2022 20:01:18 +0000 (15:01 -0500)]
sctp: check sk_bound_dev_if when matching ep in get_port
In sctp_get_port_local(), when binding to IP and PORT, it should
also check sk_bound_dev_if to match listening sk if it's set by
SO_BINDTOIFINDEX, so that multiple sockets with the same IP and
PORT, but different sk_bound_dev_if can be listened at the same
time.
Signed-off-by: Xin Long <lucien.xin@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Xin Long [Wed, 16 Nov 2022 20:01:17 +0000 (15:01 -0500)]
sctp: check ipv6 addr with sk_bound_dev if set
When binding to an ipv6 address, it calls ipv6_chk_addr() to check if
this address is on any dev. If a socket binds to a l3mdev but no dev
is passed to do this check, all l3mdev and slaves will be skipped and
the check will fail.
This patch is to pass the bound_dev to make sure the devices under the
same l3mdev can be returned in ipv6_chk_addr(). When the bound_dev is
not a l3mdev or l3slave, l3mdev_master_dev_rcu() will return NULL in
__ipv6_chk_addr_and_flags(), it will keep compitable with before when
NULL dev was passed.
Signed-off-by: Xin Long <lucien.xin@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Jiawen Wu [Wed, 16 Nov 2022 01:58:35 +0000 (09:58 +0800)]
net: libwx: Fix dead code for duplicate check
Fix duplicate check on polling timeout.
Fixes: 1efa9bfe58c5 ("net: libwx: Implement interaction with firmware") Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Antoine Tenart [Tue, 15 Nov 2022 15:44:51 +0000 (16:44 +0100)]
net: phy: mscc: macsec: do not copy encryption keys
Following 1b16b3fdf675 ("net: phy: mscc: macsec: clear encryption keys when freeing a flow"),
go one step further and instead of calling memzero_explicit on the key
when freeing a flow, simply not copy the key in the first place as it's
only used when a new flow is set up.
Signed-off-by: Antoine Tenart <atenart@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Currently, GSI firmware must be loaded for IPA before it can be
used--either by the modem, or by the AP. New hardware supports a
third option, with the bootloader taking responsibility for loading
GSI firmware. In that case, neither the AP nor the modem needs to
do that.
The first patch in this series deprecates the "modem-init" Device
Tree property in the IPA binding, using a new "qcom,gsi-loader"
property instead. The second and third implement logic in the code
to support either the "old" or the "new" way of specifying how GSI
firmware is loaded.
The last two patches implement a new value for the "qcom,gsi-loader"
property. If the value is "skip", neither the AP nor modem needs to
load the GSI firmware. The first of these patches implements the
change in the IPA binding; the second implements it in the code.
====================
Alex Elder [Wed, 16 Nov 2022 07:32:56 +0000 (01:32 -0600)]
net: ipa: permit GSI firmware loading to be skipped
Define a new value "skip" for the "qcom,gsi-loader" Device Tree
property. If used, it indicates that neither the AP nor the modem
need to load GSI firmware (because it has already been loaded--for
example by the boot loader).
Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Alex Elder [Wed, 16 Nov 2022 07:32:55 +0000 (01:32 -0600)]
dt-bindings: net: qcom,ipa: support skipping GSI firmware load
Add a new enumerated value to those defined for the qcom,gsi-loader
property. If the qcom,gsi-loader is "skip", the GSI firmware will
already be loaded, so neither the AP nor modem is required to load
GSI firmware.
Signed-off-by: Alex Elder <elder@linaro.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Alex Elder [Wed, 16 Nov 2022 07:32:54 +0000 (01:32 -0600)]
net: ipa: introduce "qcom,gsi-loader" property
Introduce a new way of specifying how the GSI firmware gets loaded
for IPA. Currently, this is indicated by the presence or absence of
the Boolean "modem-init" Device Tree property. The new property
must have a value--either "self" or "modem"--which indicates whether
the AP or modem is the GSI firmware loader, respectively.
For legacy systems, the new property will not exist, and the
"modem-init" property will be used. For newer systems, the
"qcom,gsi-loader" property *must* exist, and must have one of the
two prescribed values. It is an error to have both properties
defined, and it is an error for the new property to have an
unrecognized value.
Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Alex Elder [Wed, 16 Nov 2022 07:32:53 +0000 (01:32 -0600)]
net: ipa: encapsulate decision about firmware load
The GSI layer used for IPA requires firmware to be loaded.
Currently either the AP or the modem loads the firmware,
distinguished by whether the "modem-init" Device Tree
property is defined.
Some newer systems implement a third option. In preparation for
that, encapsulate the code that determines how the GSI firmware
gets loaded in a new function, ipa_firmware_loader().
Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Alex Elder [Wed, 16 Nov 2022 07:32:52 +0000 (01:32 -0600)]
dt-bindings: net: qcom,ipa: deprecate modem-init
GSI firmware for IPA must be loaded during initialization, either by
the AP or by the modem. The loader is currently specified based on
whether the Boolean modem-init property is present.
Instead, use a new property with an enumerated value to indicate
explicitly how GSI firmware gets loaded. With this in place, a
third approach can be added in an upcoming patch.
The new qcom,gsi-loader property has two defined values:
- self: The AP loads GSI firmware
- modem: The modem loads GSI firmware
The modem-init property must still be supported, but is now marked
deprecated.
Update the example so it represents the SC7180 SoC, and provide
examples for the qcom,gsi-loader, memory-region, and firmware-name
properties.
Signed-off-by: Alex Elder <elder@linaro.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Xin Long [Tue, 15 Nov 2022 15:40:21 +0000 (10:40 -0500)]
sctp: move SCTP_PAD4 and SCTP_TRUNC4 to linux/sctp.h
Move these two macros from net/sctp/sctp.h to linux/sctp.h, so that
it will be enough to include only linux/sctp.h in nft_exthdr.c and
xt_sctp.c. It should not include "net/sctp/sctp.h" if a module does
not have a dependence on SCTP module.
Xin Long [Tue, 15 Nov 2022 15:39:53 +0000 (10:39 -0500)]
sctp: change to include linux/sctp.h in net/sctp/checksum.h
Currently "net/sctp/checksum.h" including "net/sctp/sctp.h" is
included in quite some places in netfilter and openswitch and
net/sched. It's not necessary to include "net/sctp/sctp.h" if
a module does not have dependence on SCTP, "linux/sctp.h" is
the right one to include.
====================
Implement devlink-rate API and extend it
This patch series implements devlink-rate for ice driver. Unfortunately
current API isn't flexible enough for our use case, so there is a need to
extend it. Some functions have been introduced to enable the driver to
export current Tx scheduling configuration.
Pasting justification for this series from commit implementing devlink-rate
in ice driver(that is a part of this series):
There is a need to support modification of Tx scheduler tree, in the
ice driver. This will allow user to control Tx settings of each node in
the internal hierarchy of nodes. As a result user will be able to use
Hierarchy QoS implemented entirely in the hardware.
This patch implemenents devlink-rate API. It also exports initial
default hierarchy. It's mostly dictated by the fact that the tree
can't be removed entirely, all we can do is enable the user to modify
it. For example root node shouldn't ever be removed, also nodes that
have children are off-limits.
Example initial tree with 2 VF's:
[root@fedora ~]# devlink port function rate show
pci/0000:4b:00.0/node_27: type node parent node_26
pci/0000:4b:00.0/node_26: type node parent node_0
pci/0000:4b:00.0/node_34: type node parent node_33
pci/0000:4b:00.0/node_33: type node parent node_32
pci/0000:4b:00.0/node_32: type node parent node_16
pci/0000:4b:00.0/node_19: type node parent node_18
pci/0000:4b:00.0/node_18: type node parent node_17
pci/0000:4b:00.0/node_17: type node parent node_16
pci/0000:4b:00.0/node_21: type node parent node_20
pci/0000:4b:00.0/node_20: type node parent node_3
pci/0000:4b:00.0/node_14: type node parent node_5
pci/0000:4b:00.0/node_5: type node parent node_3
pci/0000:4b:00.0/node_13: type node parent node_4
pci/0000:4b:00.0/node_12: type node parent node_4
pci/0000:4b:00.0/node_11: type node parent node_4
pci/0000:4b:00.0/node_10: type node parent node_4
pci/0000:4b:00.0/node_9: type node parent node_4
pci/0000:4b:00.0/node_8: type node parent node_4
pci/0000:4b:00.0/node_7: type node parent node_4
pci/0000:4b:00.0/node_6: type node parent node_4
pci/0000:4b:00.0/node_4: type node parent node_3
pci/0000:4b:00.0/node_3: type node parent node_16
pci/0000:4b:00.0/node_16: type node parent node_15
pci/0000:4b:00.0/node_15: type node parent node_0
pci/0000:4b:00.0/node_2: type node parent node_1
pci/0000:4b:00.0/node_1: type node parent node_0
pci/0000:4b:00.0/node_0: type node
pci/0000:4b:00.0/1: type leaf parent node_27
pci/0000:4b:00.0/2: type leaf parent node_27
So at this point there is a couple things that can be done.
For example we could only assign parameters to VF's.
[root@fedora ~]# devlink port function rate set pci/0000:4b:00.0/1 \
tx_max 5Gbps
This would cap the VF 1 BW to 5Gbps.
But let's say you would like to create a completely new branch.
This can be done like this:
[root@fedora ~]# devlink port function rate add \
pci/0000:4b:00.0/node_custom parent node_0
[root@fedora ~]# devlink port function rate add \
pci/0000:4b:00.0/node_custom_1 parent node_custom
[root@fedora ~]# devlink port function rate set \
pci/0000:4b:00.0/1 parent node_custom_1
This creates a completely new branch and reassigns VF 1 to it.
A number of parameters is supported per each node: tx_max, tx_share,
tx_priority and tx_weight.
====================
Michal Wilczynski [Tue, 15 Nov 2022 10:48:24 +0000 (11:48 +0100)]
ice: Add documentation for devlink-rate implementation
Add documentation to a newly added devlink-rate feature. Provide some
examples on how to use the commands, which netlink attributes are
supported and descriptions of the attributes.
Signed-off-by: Michal Wilczynski <michal.wilczynski@intel.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Michal Wilczynski [Tue, 15 Nov 2022 10:48:23 +0000 (11:48 +0100)]
ice: Prevent ADQ, DCB coexistence with Custom Tx scheduler
ADQ, DCB might interfere with Custom Tx Scheduler changes that user
might introduce using devlink-rate API.
Check if ADQ, DCB is active, when user tries to change any setting
in exported Tx scheduler tree. If any of those are active block the user
from doing so, and log an appropriate message.
Remove the exported hierarchy if user enable ADQ or DCB.
Prevent ADQ or DCB from getting configured if user already made some
changes using devlink-rate API.
Signed-off-by: Michal Wilczynski <michal.wilczynski@intel.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Michal Wilczynski [Tue, 15 Nov 2022 10:48:22 +0000 (11:48 +0100)]
ice: Implement devlink-rate API
There is a need to support modification of Tx scheduler tree, in the
ice driver. This will allow user to control Tx settings of each node in
the internal hierarchy of nodes. As a result user will be able to use
Hierarchy QoS implemented entirely in the hardware.
This patch implemenents devlink-rate API. It also exports initial
default hierarchy. It's mostly dictated by the fact that the tree
can't be removed entirely, all we can do is enable the user to modify
it. For example root node shouldn't ever be removed, also nodes that
have children are off-limits.
Example initial tree with 2 VF's:
[root@fedora ~]# devlink port function rate show
pci/0000:4b:00.0/node_27: type node parent node_26
pci/0000:4b:00.0/node_26: type node parent node_0
pci/0000:4b:00.0/node_34: type node parent node_33
pci/0000:4b:00.0/node_33: type node parent node_32
pci/0000:4b:00.0/node_32: type node parent node_16
pci/0000:4b:00.0/node_19: type node parent node_18
pci/0000:4b:00.0/node_18: type node parent node_17
pci/0000:4b:00.0/node_17: type node parent node_16
pci/0000:4b:00.0/node_21: type node parent node_20
pci/0000:4b:00.0/node_20: type node parent node_3
pci/0000:4b:00.0/node_14: type node parent node_5
pci/0000:4b:00.0/node_5: type node parent node_3
pci/0000:4b:00.0/node_13: type node parent node_4
pci/0000:4b:00.0/node_12: type node parent node_4
pci/0000:4b:00.0/node_11: type node parent node_4
pci/0000:4b:00.0/node_10: type node parent node_4
pci/0000:4b:00.0/node_9: type node parent node_4
pci/0000:4b:00.0/node_8: type node parent node_4
pci/0000:4b:00.0/node_7: type node parent node_4
pci/0000:4b:00.0/node_6: type node parent node_4
pci/0000:4b:00.0/node_4: type node parent node_3
pci/0000:4b:00.0/node_3: type node parent node_16
pci/0000:4b:00.0/node_16: type node parent node_15
pci/0000:4b:00.0/node_15: type node parent node_0
pci/0000:4b:00.0/node_2: type node parent node_1
pci/0000:4b:00.0/node_1: type node parent node_0
pci/0000:4b:00.0/node_0: type node
pci/0000:4b:00.0/1: type leaf parent node_27
pci/0000:4b:00.0/2: type leaf parent node_27
So at this point there is a couple things that can be done.
For example we could only assign parameters to VF's.
[root@fedora ~]# devlink port function rate set pci/0000:4b:00.0/1 \
tx_max 5Gbps
This would cap the VF 1 BW to 5Gbps.
But let's say you would like to create a completely new branch.
This can be done like this:
[root@fedora ~]# devlink port function rate add \
pci/0000:4b:00.0/node_custom parent node_0
[root@fedora ~]# devlink port function rate add \
pci/0000:4b:00.0/node_custom_1 parent node_custom
[root@fedora ~]# devlink port function rate set \
pci/0000:4b:00.0/1 parent node_custom_1
This creates a completely new branch and reassigns VF 1 to it.
A number of parameters is supported per each node: tx_max, tx_share,
tx_priority and tx_weight.
Signed-off-by: Michal Wilczynski <michal.wilczynski@intel.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Michal Wilczynski [Tue, 15 Nov 2022 10:48:21 +0000 (11:48 +0100)]
ice: Add an option to pre-allocate memory for ice_sched_node
devlink-rate API requires a priv object to be allocated when node still
doesn't have a parent. This is problematic, because ice_sched_node can't
be currently created without a parent.
Add an option to pre-allocate memory for ice_sched_node struct. Add
new arguments to ice_sched_add() and ice_sched_add_elems() that allow
for pre-allocation of memory for ice_sched_node struct.
Signed-off-by: Michal Wilczynski <michal.wilczynski@intel.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Michal Wilczynski [Tue, 15 Nov 2022 10:48:20 +0000 (11:48 +0100)]
ice: Introduce new parameters in ice_sched_node
To support new devlink-rate API ice_sched_node struct needs to store
a number of additional parameters. This includes tx_max, tx_share,
tx_weight, and tx_priority.
Add new fields to ice_sched_node struct. Add new functions to configure
the hardware with new parameters. Introduce new xarray to identify
nodes uniquely.
Signed-off-by: Michal Wilczynski <michal.wilczynski@intel.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Michal Wilczynski [Tue, 15 Nov 2022 10:48:19 +0000 (11:48 +0100)]
devlink: Allow to set up parent in devl_rate_leaf_create()
Currently the driver is able to create leaf nodes for the devlink-rate,
but is unable to set parent for them. This wasn't as issue before the
possibility to export hierarchy from the driver. After adding the export
feature, in order for the driver to supply correct hierarchy, it's
necessary for it to be able to supply a parent name to
devl_rate_leaf_create().
Introduce a new parameter 'parent_name' in devl_rate_leaf_create().
Signed-off-by: Michal Wilczynski <michal.wilczynski@intel.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Michal Wilczynski [Tue, 15 Nov 2022 10:48:18 +0000 (11:48 +0100)]
devlink: Allow for devlink-rate nodes parent reassignment
Currently it's not possible to reassign the parent of the node using one
command. As the previous commit introduced a way to export entire
hierarchy from the driver, being able to modify and reassign parents
become important. This way user might easily change QoS settings without
interrupting traffic.
Example command:
devlink port function rate set pci/0000:4b:00.0/1 parent node_custom_1
This reassigns leaf node parent to node_custom_1.
Signed-off-by: Michal Wilczynski <michal.wilczynski@intel.com> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Michal Wilczynski [Tue, 15 Nov 2022 10:48:17 +0000 (11:48 +0100)]
devlink: Enable creation of the devlink-rate nodes from the driver
Intel 100G card internal firmware hierarchy for Hierarchicial QoS is very
rigid and can't be easily removed. This requires an ability to export
default hierarchy to allow user to modify it. Currently the driver is
only able to create the 'leaf' nodes, which usually represent the vport.
This is not enough for HQoS implemented in Intel hardware.
Introduce new function devl_rate_node_create() that allows for creation
of the devlink-rate nodes from the driver.
Signed-off-by: Michal Wilczynski <michal.wilczynski@intel.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Michal Wilczynski [Tue, 15 Nov 2022 10:48:16 +0000 (11:48 +0100)]
devlink: Introduce new attribute 'tx_weight' to devlink-rate
To fully utilize offload capabilities of Intel 100G card QoS capabilities
new attribute 'tx_weight' needs to be introduced. This attribute allows
for usage of Weighted Fair Queuing arbitration scheme among siblings.
This arbitration scheme can be used simultaneously with the strict
priority.
Introduce new attribute in devlink-rate that will allow for configuration
of Weighted Fair Queueing. New attribute is optional.
Signed-off-by: Michal Wilczynski <michal.wilczynski@intel.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Michal Wilczynski [Tue, 15 Nov 2022 10:48:15 +0000 (11:48 +0100)]
devlink: Introduce new attribute 'tx_priority' to devlink-rate
To fully utilize offload capabilities of Intel 100G card QoS capabilities
new attribute 'tx_priority' needs to be introduced. This attribute allows
for usage of strict priority arbiter among siblings. This arbitration
scheme attempts to schedule nodes based on their priority as long as the
nodes remain within their bandwidth limit.
Introduce new attribute in devlink-rate that will allow for configuration
of strict priority. New attribute is optional.
Signed-off-by: Michal Wilczynski <michal.wilczynski@intel.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
====================
Autoload DSA tagging driver when dynamically changing protocol
This patch set solves the issue reported by Michael and Heiko here:
https://lore.kernel.org/lkml/20221027113248.420216-1-michael@walle.cc/
making full use of Michael's suggestion of having two modaliases: one
gets used for loading the tagging protocol when it's the default one
reported by the switch driver, the other gets loaded at user's request,
by name.
CONFIG_NET_DSA and everything that depends on it is built as module.
Everything auto-loads, and "cat /sys/class/net/eno2/dsa/tagging" shows
"ocelot-8021q". Traffic works as well. Furthermore, "echo ocelot-8021q"
into the aforementioned sysfs file now auto-loads the driver for it.
====================
Vladimir Oltean [Tue, 15 Nov 2022 01:18:47 +0000 (03:18 +0200)]
net: dsa: autoload tag driver module on tagging protocol change
Issue a request_module() call when an attempt to change the tagging
protocol is made, either by sysfs or by device tree. In the case of
ocelot (the only driver for which the default and the alternative
tagging protocol are compiled as different modules), the user is now no
longer required to insert tag_ocelot_8021q.ko manually.
In the particular case of ocelot, this solves a problem where
tag_ocelot_8021q.ko is built as module, and this is present in the
device tree:
Because no one attempts to load the module into the kernel at boot time,
the switch driver will fail to probe (actually forever defer) until
someone manually inserts tag_ocelot_8021q.ko. This is now no longer
necessary and happens automatically.
Rename dsa_find_tagger_by_name() to denote the change in functionality:
there is now feature parity with dsa_tag_driver_get_by_id(), i.o.w. we
also load the module if it's missing.
Link: https://lore.kernel.org/lkml/20221027113248.420216-1-michael@walle.cc/ Suggested-by: Michael Walle <michael@walle.cc> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Tested-by: Michael Walle <michael@walle.cc> # on kontron-sl28 w/ ocelot_8021q Tested-by: Michael Walle <michael@walle.cc> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Vladimir Oltean [Tue, 15 Nov 2022 01:18:45 +0000 (03:18 +0200)]
net: dsa: strip sysfs "tagging" string of trailing newline
Currently, dsa_find_tagger_by_name() uses sysfs_streq() which works both
with strings that contain \n at the end (echo ocelot > .../dsa/tagging)
and with strings that don't (printf ocelot > .../dsa/tagging).
There will be a problem once we'll want to construct the modalias string
based on which we auto-load the protocol kernel module. If the sysfs
buffer ends in a newline, we need to strip it first. This is a
preparatory patch specifically for that.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Tested-by: Michael Walle <michael@walle.cc> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Vladimir Oltean [Tue, 15 Nov 2022 01:18:44 +0000 (03:18 +0200)]
net: dsa: provide a second modalias to tag proto drivers based on their name
Currently, tagging protocol drivers have a modalias of
"dsa_tag:id-<number>", where the number is one of DSA_TAG_PROTO_*_VALUE.
This modalias makes it possible for the request_module() call in
dsa_tag_driver_get() to work, given the input it has - an integer
returned by ds->ops->get_tag_protocol().
It is also possible to change tagging protocols at (pseudo-)runtime, via
sysfs or via device tree, and this works via the name string of the
tagging protocol rather than via its id (DSA_TAG_PROTO_*_VALUE).
In the latter case, there is no request_module() call, because there is
no association that the DSA core has between the string name and the ID,
to construct the modalias. The module is simply assumed to have been
inserted. This is actually slightly problematic when the tagging
protocol change should take place at probe time, since it's expected
that the dependency module should get autoloaded.
For this purpose, let's introduce a second modalias, so that the DSA
core can call request_module() by name. There is no reason to make the
modalias by name optional, so just modify the MODULE_ALIAS_DSA_TAG_DRIVER()
macro to take both the ID and the name as arguments, and generate two
modaliases behind the scenes.
Suggested-by: Michael Walle <michael@walle.cc> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Tested-by: Michael Walle <michael@walle.cc> # on kontron-sl28 w/ ocelot_8021q Tested-by: Michael Walle <michael@walle.cc> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Vladimir Oltean [Tue, 15 Nov 2022 01:18:43 +0000 (03:18 +0200)]
net: dsa: rename tagging protocol driver modalias
It's autumn cleanup time, and today's target are modaliases.
Michael says that for users of modinfo, "dsa_tag-20" is not the most
suggestive name, and recommends a change to "dsa_tag-id-20".
Andrew points out that other modaliases have a prefix delimited by
colons, so he recommends "dsa_tag:20" instead of "dsa_tag-20".
To satisfy both proposals, Florian recommends "dsa_tag:id-20".
The modaliases are not stable ABI, and the essential information
(protocol ID) is still conveyed in the new string, which
request_module() must be adapted to form.
Link: 20221027210830.3577793-1-vladimir.oltean@nxp.com Suggested-by: Andrew Lunn <andrew@lunn.ch> Suggested-by: Michael Walle <michael@walle.cc> Suggested-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Tested-by: Michael Walle <michael@walle.cc> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Vladimir Oltean [Tue, 15 Nov 2022 01:18:42 +0000 (03:18 +0200)]
net: dsa: stop exposing tag proto module helpers to the world
The DSA tagging protocol driver macros are in the public include/net/dsa.h
probably because that's also where the DSA_TAG_PROTO_*_VALUE macros are
(MODULE_ALIAS_DSA_TAG_DRIVER hinges on those macro definitions).
But there is no reason to expose these helpers to <net/dsa.h>. That
header is shared between switch drivers (drivers/net/dsa/), tagging
protocol drivers (net/dsa/tag_*.c), the DSA core (net/dsa/ sans tag_*.c),
and the rest of the world (DSA master drivers, network stack, etc).
Too much exposure.
On the other hand, net/dsa/dsa_priv.h is included only by the DSA core
and by DSA tagging protocol drivers (or IOW, "friend" modules). Also a
bit too much exposure - I've contemplated creating a new header which is
only included by tagging protocol drivers, but completely separating a
new dsa_tag_proto.h from dsa_priv.h is not immediately trivial - for
example dsa_slave_to_port() is used both from the fast path and from the
control path.
So for now, move these definitions to dsa_priv.h which at least hides
them from the world.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Tested-by: Michael Walle <michael@walle.cc> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
IPQ5018, IPQ6018 and IPQ8074 require clock-names to be set as driver is
requesting the clock based on it and not index, so document that and make
it required for the listed SoC-s.
Allow using IPQ8074 specific compatible along with the fallback IPQ4019
one in order to be able to specify which compatibles require clocks to
be able to validate them via schema.
Document IPQ6018 compatible that is already being used in the DTS along
with the fallback IPQ4019 compatible as driver itself only gets probed
on IPQ4019 and IPQ5018 compatibles.
This is also required in order to specify which platform require clock to
be defined and validate it in schema.
====================
net: dsa: use more appropriate NET_NAME_* constants for user ports
The intention of commit 685343fc3ba6 ("net: add name_assign_type
netdev attribute") was clearly that drivers be switched over one by
one to select appropriate NET_NAME_* constants instead of
NET_NAME_UNKNOWN. This small series attempts to do that for DSA user
ports.
This is obviously and intentionally user-visible changes, so there's a
small chance that it could lead to a regression. To make it easy to
revert either of the "label in DT" and "fallback to eth%d" changes,
this is done as a refactoring which shouldn't introduce any functional
change (but by itself adds code which looks a little odd, with the two
identical assignments in the two branches), followed by changing the
constant used in each case in two different patches.
====================
Rasmus Villemoes [Wed, 16 Nov 2022 10:52:04 +0000 (11:52 +0100)]
net: dsa: set name_assign_type to NET_NAME_ENUM for enumerated user ports
When a user port does not have a label in device tree, and we thus
fall back to the eth%d scheme, the proper constant to use is
NET_NAME_ENUM. See also commit e9f656b7a214 ("net: ethernet: set
default assignment identifier to NET_NAME_ENUM"), which in turn quoted
commit 685343fc3ba6 ("net: add name_assign_type netdev attribute"):
... when the kernel has given the interface a name using global
device enumeration based on order of discovery (ethX, wlanY, etc)
... are labelled NET_NAME_ENUM.
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.faineli@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Rasmus Villemoes [Wed, 16 Nov 2022 10:52:03 +0000 (11:52 +0100)]
net: dsa: use NET_NAME_PREDICTABLE for user ports with name given in DT
When a user port has a label in device tree, the corresponding
netdevice is, to quote include/uapi/linux/netdevice.h, "predictably
named by the kernel". This is also explicitly one of the intended use
cases for NET_NAME_PREDICTABLE, quoting 685343fc3ba6 ("net: add
name_assign_type netdev attribute"):
NET_NAME_PREDICTABLE:
The ifname has been assigned by the kernel in a predictable way
[...] Examples include [...] and names deduced from hardware
properties (including being given explicitly by the firmware).
Expose that information properly for the benefit of userspace tools
that make decisions based on the name_assign_type attribute,
e.g. a systemd-udev rule with "kernel" in NamePolicy.
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.faineli@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Rasmus Villemoes [Wed, 16 Nov 2022 10:52:02 +0000 (11:52 +0100)]
net: dsa: refactor name assignment for user ports
The following two patches each have a (small) chance of causing
regressions for userspace and will in that case of course need to be
reverted.
In order to prepare for that and make those two patches independent
and individually revertable, refactor the code which sets the names
for user ports by moving the "fall back to eth%d if no label is given
in device tree" to dsa_slave_create().
No functional change (at least none intended).
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.faineli@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Vincent Mailhol [Wed, 16 Nov 2022 17:18:28 +0000 (02:18 +0900)]
ethtool: doc: clarify what drivers can implement in their get_drvinfo()
Many of the drivers which implement ethtool_ops::get_drvinfo() will
prints the .driver, .version or .bus_info of struct ethtool_drvinfo.
To have a glance of current state, do:
$ git grep -W "get_drvinfo(struct"
Printing in those three fields is useless because:
- since [1], the driver version should be the kernel version (at
least for upstream drivers). Arguably, out of tree drivers might
still want to set a custom version, but out of tree is not our
focus.
- since [2], the core is able to provide default values for .driver
and .bus_info.
In summary, drivers may provide .fw_version and .erom_version, the
rest is expected to be done by the core.
In struct ethtool_ops doc from linux/ethtool: rephrase field
get_drvinfo() doc to discourage developers from implementing this
callback.
In struct ethtool_drvinfo doc from uapi/linux/ethtool.h: remove the
paragraph mentioning what drivers should do. Rationale: no need to
repeat what is already written in struct ethtool_ops doc. But add a
note that .fw_version and .erom_version are driver defined.
Also update the dummy driver and simply remove the callback in order
not to confuse the newcomers: most of the drivers will not need this
callback function any more.
Dan Carpenter [Tue, 15 Nov 2022 13:09:55 +0000 (16:09 +0300)]
net: ethernet: renesas: Fix return type in rswitch_etha_wait_link_verification()
The rswitch_etha_wait_link_verification() is supposed to return zero
on success or negative error codes. Unfortunately it is declared as a
bool so the caller treats everything as success.
Fixes: 3590918b5d07 ("net: ethernet: renesas: Add support for "Ethernet Switch"") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Link: https://lore.kernel.org/r/Y3OPo6AOL6PTvXFU@kili Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Xiu Jianfeng [Thu, 10 Nov 2022 06:19:26 +0000 (14:19 +0800)]
wifi: ath10k: Fix return value in ath10k_pci_init()
This driver is attempting to register to support two different buses.
if either of these is successful then ath10k_pci_init() should return 0
so that hardware attached to the successful bus can be probed and
supported. only if both of these are unsuccessful should ath10k_pci_init()
return an errno.
Fixes: 0b523ced9a3c ("ath10k: add basic skeleton to support ahb") Signed-off-by: Xiu Jianfeng <xiujianfeng@huawei.com> Reviewed-by: Jeff Johnson <quic_jjohnson@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20221110061926.18163-1-xiujianfeng@huawei.com
projects / users / jedix / linux-maple.git / log