summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-12-15selftests/bpf: Add test for abnormal cnt during multi-uprobe attachmentHou Tao
If an abnormally huge cnt is used for multi-uprobes attachment, the following warning will be reported: ------------[ cut here ]------------ WARNING: CPU: 7 PID: 406 at mm/util.c:632 kvmalloc_node+0xd9/0xe0 Modules linked in: bpf_testmod(O) CPU: 7 PID: 406 Comm: test_progs Tainted: G ...... 6.7.0-rc3+ #32 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) ...... RIP: 0010:kvmalloc_node+0xd9/0xe0 ...... Call Trace: <TASK> ? __warn+0x89/0x150 ? kvmalloc_node+0xd9/0xe0 bpf_uprobe_multi_link_attach+0x14a/0x480 __sys_bpf+0x14a9/0x2bc0 do_syscall_64+0x36/0xb0 entry_SYSCALL_64_after_hwframe+0x6e/0x76 ...... </TASK> ---[ end trace 0000000000000000 ]--- So add a test to ensure the warning is fixed. Signed-off-by: Hou Tao <houtao1@huawei.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Jiri Olsa <jolsa@kernel.org> Acked-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20231215100708.2265609-4-houtao@huaweicloud.com
2023-12-15bpf: Limit the number of kprobes when attaching program to multiple kprobesHou Tao
An abnormally big cnt may also be assigned to kprobe_multi.cnt when attaching multiple kprobes. It will trigger the following warning in kvmalloc_node(): if (unlikely(size > INT_MAX)) { WARN_ON_ONCE(!(flags & __GFP_NOWARN)); return NULL; } Fix the warning by limiting the maximal number of kprobes in bpf_kprobe_multi_link_attach(). If the number of kprobes is greater than MAX_KPROBE_MULTI_CNT, the attachment will fail and return -E2BIG. Fixes: 0dcac2725406 ("bpf: Add multi kprobe link") Signed-off-by: Hou Tao <houtao1@huawei.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Jiri Olsa <jolsa@kernel.org> Acked-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20231215100708.2265609-3-houtao@huaweicloud.com
2023-12-15bpf: Limit the number of uprobes when attaching program to multiple uprobesHou Tao
An abnormally big cnt may be passed to link_create.uprobe_multi.cnt, and it will trigger the following warning in kvmalloc_node(): if (unlikely(size > INT_MAX)) { WARN_ON_ONCE(!(flags & __GFP_NOWARN)); return NULL; } Fix the warning by limiting the maximal number of uprobes in bpf_uprobe_multi_link_attach(). If the number of uprobes is greater than MAX_UPROBE_MULTI_CNT, the attachment will return -E2BIG. Fixes: 89ae89f53d20 ("bpf: Add multi uprobe link") Reported-by: Xingwei Lee <xrivendell7@gmail.com> Signed-off-by: Hou Tao <houtao1@huawei.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Jiri Olsa <jolsa@kernel.org> Acked-by: Andrii Nakryiko <andrii@kernel.org> Closes: https://lore.kernel.org/bpf/CABOYnLwwJY=yFAGie59LFsUsBAgHfroVqbzZ5edAXbFE3YiNVA@mail.gmail.com Link: https://lore.kernel.org/bpf/20231215100708.2265609-2-houtao@huaweicloud.com
2023-12-15wifi: ath11k: workaround too long expansion sparse warningsKalle Valo
In v6.7-rc1 sparse warns: drivers/net/wireless/ath/ath11k/mac.c:4702:15: error: too long token expansion drivers/net/wireless/ath/ath11k/mac.c:4702:15: error: too long token expansion drivers/net/wireless/ath/ath11k/mac.c:8393:23: error: too long token expansion drivers/net/wireless/ath/ath11k/mac.c:8393:23: error: too long token expansion Workaround the warnings by refactoring the code to a new function, which also reduces code duplication. And in the new function use max3() to make the code more readable. No functional changes, compile tested only. Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://msgid.link/20231214161740.1582340-1-kvalo@kernel.org
2023-12-15Revert "wifi: ath12k: use ATH12K_PCI_IRQ_DP_OFFSET for DP IRQ"Karthikeyan Periyasamy
This reverts commit 1f1f7d548a00ebe50808cb1f580df9693e194a7c. The commit caused bootup failure on QCN9274 hw2.0 platform. Incorrect hardcode DP irq offset overwrite the CE irq, which caused the driver to miss the mandatory bootup message from the firmware through the CE interrupt. This occurs because the CE count differs between platforms. The revert has no impact since the original change was based on an incorrect assumption. Log: ath12k_pci 0000:06:00.0: fw_version 0x1011001d fw_build_timestamp 2022-12-02 01:16 fw_build_id QC_IMAGE_VERSION_STRING=WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 ath12k_pci 0000:06:00.0: failed to receive control response completion, polling.. ath12k_pci 0000:06:00.0: Service connect timeout ath12k_pci 0000:06:00.0: failed to connect to HTT: -110 ath12k_pci 0000:06:00.0: failed to start core: -110 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0-03427-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.15378.4 Signed-off-by: Karthikeyan Periyasamy <quic_periyasa@quicinc.com> Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://msgid.link/20231214053215.2087308-1-quic_periyasa@quicinc.com
2023-12-15wifi: rt2x00: remove useless code in rt2x00queue_create_tx_descriptor()Dmitry Antipov
In 'rt2x00queue_create_tx_descriptor()', there is no need to call 'ieee80211_get_rts_cts_rate()' while checking for RTS/CTS frame since this function returns NULL or pointer to internal bitrate table entry, and the return value is not actually used. Compile tested only. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Acked-by: Stanislaw Gruszka <stf_xl@wp.pl> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20231213051449.126963-1-dmantipov@yandex.ru
2023-12-15wifi: rtw89: only reset BB/RF for existing WiFi 6 chips while starting upPing-Ke Shih
The new WiFi 7 chips change the design, so no need to disable/enable BB/RF when core_start(). Keep the same logic for existing chips. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20231211083341.118047-7-pkshih@realtek.com
2023-12-15wifi: rtw89: add DBCC H2C to notify firmware the statusPing-Ke Shih
To support MLO of WiFi 7, we should configure hardware as DBCC mode, and notify this status to firmware. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20231211083341.118047-6-pkshih@realtek.com
2023-12-15wifi: rtw89: mac: add suffix _ax to MAC functionsPing-Ke Shih
Many existing MAC access functions are used by WiFi 6 chips only, so add suffix _ax to be clearer. Some are common and can be used by WiFi 7, so export this kind of functions. This patch doesn't change logic at all. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20231211083341.118047-5-pkshih@realtek.com
2023-12-15wifi: rtw89: mac: add flags to check if CMAC and DMAC are enabledPing-Ke Shih
Before accessing CMAC and DMAC registers, we should ensure they have been powered on, so add flag to determine the state. For old chips, we read registers and check corresponding bit, but it takes extra cost to read. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20231211083341.118047-4-pkshih@realtek.com
2023-12-15wifi: rtw89: 8922a: add power on/off functionsPing-Ke Shih
The power on/off functions are to turn on hardware function blocks and to turn off them if we are going to stay in idle state. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20231211083341.118047-3-pkshih@realtek.com
2023-12-15wifi: rtw89: add XTAL SI for WiFi 7 chipsPing-Ke Shih
The XTAL SI is a serial interface to indirectly access registers of analog hardware circuit. Since WiFi 7 chips use different registers, add a ops to access them via common functions. This patch doesn't change logic for existing chips. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20231211083341.118047-2-pkshih@realtek.com
2023-12-15wifi: rtw89: phy: print out RFK log with formatted stringPing-Ke Shih
With formatted string loaded from firmware file, we can use the formatted string ID and get corresponding string, and then use regular rtw89_debug() to show the message if debug mask of RFK is enabled. If the string ID doesn't present, fallback to print plain hexadecimal. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20231213005054.10568-7-pkshih@realtek.com
2023-12-15wifi: rtw89: parse and print out RFK log from C2H eventsPing-Ke Shih
RFK log events contains two types. One called RUN log is to reflect state during RFK is running, and it replies on formatted string loaded from firmware file, but print this type as plain hexadecimal only in this patch. The other is REPORT log that reflects the final result of a RFK, and each calibration has its own struct to carry many specific information. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20231213005054.10568-6-pkshih@realtek.com
2023-12-15wifi: rtw89: add C2H event handlers of RFK log and reportPing-Ke Shih
Trigger a RFK (RF calibration) in firmware by a H2C command, and in progress it reports log and a result finally by C2H events. Firstly, add prototype of the C2H event handlers to have a simple picture of framework. The callers who trigger H2C will wait until a C2H event is received, so we must process these C2H events in receiving process. Thus, mark this kind of C2H events as atomic. Also, timestamp is also useful for debugging, mark C2H events carrying RFK log as atomic as well. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20231213005054.10568-5-pkshih@realtek.com
2023-12-15wifi: rtw89: load RFK log format string from firmware filePing-Ke Shih
To debug RFK (RF calibration) in firmware, it sends log via firmware C2H events to driver with string format ID and four arguments. Load formatted string from firmware file, and the string ID can get back its string. Then, use regular print format to show the message. This firmware element layout looks like +============================================+ | elm ID | elm size | version | | +----------+----------+----------+-----------+ | | nr |rsvd |rfk_id|rsvd| +--------------------------------------------+ | offset[] (__le16 * nr) | | ... | +--------------------------------------------+ | formatted string with null termintor (*nr) | | ... | +============================================+ * a firmware file can contains more than one elements with this element ID named RTW89_FW_ELEMENT_ID_RFKLOG_FMT (19), because many RFK needs its own formatted strings, so add 'rfk_id' to know it belongs to which RFK. * the 'formatted string' just follow 'offset[]' without padding to align 32bits. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20231213005054.10568-4-pkshih@realtek.com
2023-12-15wifi: rtw89: fw: add version field to BB MCU firmware elementPing-Ke Shih
8922AE has more than one hardware version, and they use different BB MCU firmware, so occupy a byte from element priv[] to annotate version. Since there are more than one firmware and only matched version is adopted, return 1 to ignore not matched firmware. +===========================================+ | elm ID | elm size | version | | +----------+----------+----------+----------+ | | element_priv[] | +-------------------------------------------+ change to | v +===========================================+ | elm ID | elm size | version | | +----------+----------+----------+----------+ | | cv | element_rsvd[] | +-------------------------------------------+ Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20231213005054.10568-3-pkshih@realtek.com
2023-12-15wifi: rtw89: fw: load TX power track tables from fw_elementPing-Ke Shih
The TX power track tables are used to define compensation power reflected to thermal value. Currently, we have 16 (2 * 4 * 2) tables made by combinations of {negative/positive thermal value, 2GHz/2GHz-CCK/5GHz/6GHz, path A/B} Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20231213005054.10568-2-pkshih@realtek.com
2023-12-15wifi: mwifiex: configure BSSID consistently when starting APDavid Lin
AP BSSID configuration is missing at AP start. Without this fix, FW returns STA interface MAC address after first init. When hostapd restarts, it gets MAC address from netdev before driver sets STA MAC to netdev again. Now MAC address between hostapd and net interface are different causes STA cannot connect to AP. After that MAC address of uap0 mlan0 become the same. And issue disappears after following hostapd restart (another issue is AP/STA MAC address become the same). This patch fixes the issue cleanly. Signed-off-by: David Lin <yu-hao.lin@nxp.com> Fixes: 12190c5d80bd ("mwifiex: add cfg80211 start_ap and stop_ap handlers") Cc: stable@vger.kernel.org Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com> Tested-by: Rafael Beims <rafael.beims@toradex.com> # Verdin iMX8MP/SD8997 SD Acked-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20231215005118.17031-1-yu-hao.lin@nxp.com
2023-12-15wifi: mwifiex: add extra delay for firmware readyDavid Lin
For SDIO IW416, due to a bug, FW may return ready before complete full initialization. Command timeout may occur at driver load after reboot. Workaround by adding 100ms delay at checking FW status. Signed-off-by: David Lin <yu-hao.lin@nxp.com> Cc: stable@vger.kernel.org Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com> Acked-by: Brian Norris <briannorris@chromium.org> Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> # Verdin AM62 (IW416) Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20231208234029.2197-1-yu-hao.lin@nxp.com
2023-12-15hv_netvsc: remove duplicated including of slab.hWang Jinchao
rm the second include <linux/slab.h> Signed-off-by: Wang Jinchao <wangjinchao@xfusion.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-12-15Merge branch 'netlink-specs-legacy'David S. Miller
Jakub Kicinski says: ==================== netlink: specs: prep legacy specs for C code gen Minor adjustments to some specs to make them ready for C code gen. v2: - fix MAINATINERS and subject of patch 3 ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2023-12-15netlink: specs: mptcp: rename the MPTCP path management specJakub Kicinski
We assume in handful of places that the name of the spec is the same as the name of the family. We could fix that but it seems like a fair assumption to make. Rename the MPTCP spec instead. Reviewed-by: Mat Martineau <martineau@kernel.org> Reviewed-by: Donald Hunter <donald.hunter@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-12-15netlink: specs: ovs: correct enum names in specsJakub Kicinski
Align the enum-names of OVS with what's actually in the uAPI. Either correct the names, or mark the enum as empty because the values are in fact #defines. Reviewed-by: Donald Hunter <donald.hunter@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-12-15netlink: specs: ovs: remove fixed header fields from attrsJakub Kicinski
Op's "attributes" list is a workaround for families with a single attr set. We don't want to render a single huge request structure, the same for each op since we know that most ops accept only a small set of attributes. "Attributes" list lets us narrow down the attributes to what op acctually pays attention to. It doesn't make sense to put names of fixed headers in there. They are not "attributes" and we can't really narrow down the struct members. Remove the fixed header fields from attrs for ovs families in preparation for C codegen support. Reviewed-by: Donald Hunter <donald.hunter@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-12-15Merge branch '100GbE' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue Tony Nguyen says: ==================== add v2 FW logging for ice driver Paul Stillwell says: Firmware (FW) log support was added to the ice driver, but that version is no longer supported. There is a newer version of FW logging (v2) that adds more control knobs to get the exact data out of the FW for debugging. The interface for FW logging is debugfs. This was chosen based on discussions here: https://lore.kernel.org/netdev/20230214180712.53fc8ba2@kernel.org/ and https://lore.kernel.org/netdev/20231012164033.1069fb4b@kernel.org/ We talked about using devlink in a variety of ways, but none of those options made any sense for the way the FW reports data. We briefly talked about using ethtool, but that seemed to go by the wayside. Ultimately it seems like using debugfs is the way to go so re-implement the code to use that. FW logging is across all the PFs on the device so restrict the commands to only PF0. If the device supports FW logging then a directory named 'fwlog' will be created under '/sys/kernel/debug/ice/<pci_dev>'. A variety of files will be created to manage the behavior of logging. The following files will be created: - modules/<module> - nr_messages - enable - log_size - data where modules/<module> is used to read/write the log level for a specific module nr_messages is used to determine how many events should be in each message sent to the driver enable is used to start/stop FW logging. This is a boolean value so only 1 or 0 are permissible values log_size is used to configure the amount of memory the driver uses for log data data is used to read/clear the log data Generally there is a lot of data and dumping that data to syslog will result in a loss of data. This causes problems when decoding the data and the user doesn't know that data is missing until later. Instead of dumping the FW log output to syslog use debugfs. This ensures that all the data the driver has gets retrieved correctly. The FW log data is binary data that the FW team decodes to determine what happened in firmware. The binary blob is sent to Intel for decoding. --- v6: - use seq_printf() for outputting module info when reading from 'module' file - replace code that created argc and argv for handling command line input - removed checks in all the _read() and _write() functions to see if FW logging is supported because the files will not exist if it is not supported - removed warnings on allocation failures on debugfs file creation failures - removed a newline between memory allocation and checking if the memory was allocated - fixed cases where we could just return the value from a function call instead of saving the value in a variable - moved the check for PFO in ice_fwlog_init() to an earlier patch - reworked all of argument scanning in the _write() functions in ice_debugfs.c to remove adding characters past the end of the buffer v5: https://lore.kernel.org/netdev/20231205211251.2122874-1-anthony.l.nguyen@intel.com/ - changed the log level configuration from a single file for all modules to a file per module. - changed 'nr_buffs' to 'log_size' because users understand memory sizes better than a number of buffers - changed 'resolution' to 'nr_messages' to better reflect what it represents - updated documentation to reflect these changes - updated documentation to indicate that FW logging must be disabled to clear the data. also clarified that any value written to the 'data' file will clear the data v4: https://lore.kernel.org/netdev/20231005170110.3221306-1-anthony.l.nguyen@intel.com/ - removed CONFIG_DEBUG_FS wrapper around code because the debugfs calls handle this case already - moved ice_debugfs_exit() call to remove unreachable code issue - minor changes to documentation based on feedback v3: https://lore.kernel.org/netdev/20230815165750.2789609-1-anthony.l.nguyen@intel.com/ - Adjust error path cleanup in ice_module_init() for unreachable code. v2: https://lore.kernel.org/netdev/20230810170109.1963832-1-anthony.l.nguyen@intel.com/ - Rewrote code to use debugfs instead of devlink v1: https://lore.kernel.org/netdev/20230209190702.3638688-1-anthony.l.nguyen@intel.com/ ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2023-12-15Merge branch 'mv88e6xxx-counters'David S. Miller
Tobias Waldekranz says: ==================== net: dsa: mv88e6xxx: Add "eth-mac" and "rmon" counter group support The majority of the changes (2/8) are about refactoring the existing ethtool statistics support to make it possible to read individual counters, rather than the whole set. 4/8 tries to collect all information about a stat in a single place using a mapper macro, which is then used to generate the original list of stats, along with a matching enum. checkpatch is less than amused with this construct, but prior art exists (__BPF_FUNC_MAPPER in include/uapi/linux/bpf.h, for example). To support the histogram counters from the "rmon" group, we have to change mv88e6xxx's configuration of them. Instead of counting rx and tx, we restrict them to rx-only. 6/8 has the details. With that in place, adding the actual counter groups is pretty straight forward (5,7/8). Tie it all together with a selftest (8/8). v3 -> v4: - Return size_t from mv88e6xxx_stats_get_stats - Spelling errors in commit message of 6/8 - Improve selftest: - Report progress per-bucket - Test both ports in the pair - Increase MTU, if required v2 -> v3: - Added 6/8 - Added 8/8 v1 -> v2: - Added 1/6 - Added 3/6 - Changed prototype of stats operation to reflect the fact that the number of read stats are returned, no errors - Moved comma into MV88E6XXX_HW_STAT_MAPPER definition - Avoid the construction of mapping table iteration which relied on struct layouts outside of mv88e6xxx's control ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2023-12-15selftests: forwarding: ethtool_rmon: Add histogram counter testTobias Waldekranz
Validate the operation of rx and tx histogram counters, if supported by the interface, by sending batches of packets targeted for each bucket. Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com> Tested-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-12-15net: dsa: mv88e6xxx: Add "rmon" counter group supportTobias Waldekranz
Report the applicable subset of an mv88e6xxx port's counters using ethtool's standardized "rmon" counter group. Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-12-15net: dsa: mv88e6xxx: Limit histogram counters to ingress trafficTobias Waldekranz
Chips in this family only have one set of histogram counters, which can be used to count ingressing and/or egressing traffic. mv88e6xxx has, up until this point, kept the hardware default of counting both directions. In the mean time, standard counter group support has been added to ethtool. Via that interface, drivers may report ingress-only and egress-only histograms separately - but not combined. In order for mv88e6xxx to maximize amount of diagnostic information that can be exported via standard interfaces, we opt to limit the histogram counters to ingress traffic only. Which will allow us to export them via the standard "rmon" group in an upcoming commit. The reason for choosing ingress-only over egress-only, is to be compatible with RFC2819 (RMON MIB). Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-12-15net: dsa: mv88e6xxx: Add "eth-mac" counter group supportTobias Waldekranz
Report the applicable subset of an mv88e6xxx port's counters using ethtool's standardized "eth-mac" counter group. Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-12-15net: dsa: mv88e6xxx: Give each hw stat an IDTobias Waldekranz
With the upcoming standard counter group support, we are no longer reading out the whole set of counters, but rather mapping a subset to the requested group. Therefore, create an enum with an ID for each stat, such that mv88e6xxx_hw_stats[] can be subscripted with a human-readable ID corresponding to the counter's name. Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-12-15net: dsa: mv88e6xxx: Fix mv88e6352_serdes_get_stats error pathTobias Waldekranz
mv88e6xxx_get_stats, which collects stats from various sources, expects all callees to return the number of stats read. If an error occurs, 0 should be returned. Prevent future mishaps of this kind by updating the return type to reflect this contract. Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-12-15net: dsa: mv88e6xxx: Create API to read a single stat counterTobias Waldekranz
This change contains no functional change. We simply push the hardware specific stats logic to a function reading a single counter, rather than the whole set. This is a preparatory change for the upcoming standard ethtool statistics support (i.e. "eth-mac", "eth-ctrl" etc.). Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-12-15net: dsa: mv88e6xxx: Push locking into stats snapshottingTobias Waldekranz
This is more consistent with the driver's general structure. Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-12-15Merge branch 'net-optmem_max-changes'David S. Miller
Eric Dumazet says: ==================== net: optmem_max changes optmem_max default value is too small for tx zerocopy workloads. First patch increases default from 20KB to 128 KB, which is the value we have used for seven years. Second patch makes optmem_max sysctl per netns. Last patch tweaks two tests accordingly. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2023-12-15selftests/net: optmem_max became per netnsEric Dumazet
/proc/sys/net/core/optmem_max is now per netns, change two tests that were saving/changing/restoring its value on the parent netns. Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-12-15net: Namespace-ify sysctl_optmem_maxEric Dumazet
optmem_max being used in tx zerocopy, we want to be able to control it on a netns basis. Following patch changes two tests. Tested: oqq130:~# cat /proc/sys/net/core/optmem_max 131072 oqq130:~# echo 1000000 >/proc/sys/net/core/optmem_max oqq130:~# cat /proc/sys/net/core/optmem_max 1000000 oqq130:~# unshare -n oqq130:~# cat /proc/sys/net/core/optmem_max 131072 oqq130:~# exit logout oqq130:~# cat /proc/sys/net/core/optmem_max 1000000 Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Acked-by: Neal Cardwell <ncardwell@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-12-15net: increase optmem_max default valueEric Dumazet
For many years, /proc/sys/net/core/optmem_max default value on a 64bit kernel has been 20 KB. Regular usage of TCP tx zerocopy needs a bit more. Google has used 128KB as the default value for 7 years without any problem. Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Acked-by: Neal Cardwell <ncardwell@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-12-15Merge branch 'mlxsw-CFF-flood-mode'David S. Miller
Petr Machata says: ==================== mlxsw: CFF flood mode: NVE underlay configuration Recently, support for CFF flood mode (for Compressed FID Flooding) was added to the mlxsw driver. The most recent patchset has a detailed coverage of what CFF is and what has changed and how: https://lore.kernel.org/netdev/cover.1701183891.git.petrm@nvidia.com/ In CFF flood mode, each FID allocates a handful (in our implementation two or three) consecutive PGT entries. One entry holds the flood vector for unknown-UC traffic, one for MC, one for BC. To determine how to look up flood vectors, the CFF flood mode uses a concept of flood profiles, which are IDs that reference mappings from traffic types to offsets. In the case of CFF flood mode, the offset in question is applied to the PGT address configured at a FID. The same mechanism is used by NVE underlay for flooding. Again the profile ID and the traffic type determine the offset to apply, this time to KVD address used to look up flooding entries. Since mlxsw configures NVE underlay flood the same regardless of traffic type, only one offset was ever needed: the zero, which is the default, and thus no explicit configuration was needed. Now that CFF uses profiles as well, it would be better to configure the profile used by NVE explicitly, to make the configuration visible in the source code. In this patchset, add the register support (in patch #1), add a new traffic type to refer to "any traffic at all" (in patch #2) and finally configure the NVE profile explicitly for FIDs (in patch #3). So far, the implicitly configured flood profile was the ID 0. With this patchset, it changes to 3, leaving the 0 free to allow us to spot missed configuration. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2023-12-15mlxsw: spectrum_fid: Set NVE flood profile as part of FID configurationPetr Machata
The NVE flood profile is used for determining of offset applied to KVD address for NVE flood. We currently do not set it, leaving it at the default value of 0. That is not an issue: all the traffic-type-to-offset mappings (as configured by SFFP) default to offset of 0. This is what we need anyway, as mlxsw only allocates a single KVD entry for NVE underlay. The field is only relevant on Spectrum-2 and above. So to be fully consistent, we should split the existing controlled ops to Spectrum-1 and Spectrum>1 variants, with only the latter setting the field. But that seems like a lot of overhead for a single field whose meaning is "everything is the default". So instead pretend that the NVE flood profile does not exist in the controlled flood mode, like we have so far, and only set it when flood mode is CFF. Setting this at all serves dual purpose. First, it is now clear which profile belongs to NVE, because in the CFF mode, we have multiple users. This should prevent bugs in flood profile management. Second, using specifically non-zero value means there will be no valid uses of the profile 0, which we can therefore use as a sentinel. Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-12-15mlxsw: spectrum_fid: Add an "any" packet typePetr Machata
Flood profiles have been used prior to CFF support for NVE underlay. Like is the case with FID flooding, an NVE profile describes at which offset a datum is located given traffic type. mlxsw currently only ever uses one KVD entry for NVE lookup, i.e. regardless of traffic type, the offset is always zero. To be able to describe this, add a traffic type enumerator describing "any traffic type". Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-12-15mlxsw: reg: Add nve_flood_prf_id field to SFMRPetr Machata
The field is used for setting a flood profile for lookup of KVD entry for NVE underlay. As the other uses of flood profile, this references a traffic type-to-offset mapping, except here it is not applied to PGT offsets, but KVD offsets. Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-12-15Merge branch 'net-at803x-cleanups'David S. Miller
Christian Marangi says: ==================== net: phy: at803x: additional cleanup for qca808x This small series is a preparation for the big code split. While the qca808x code is waiting to be reviwed and merged, we can further cleanup and generalize shared functions between at803x and qca808x. With these last 2 patch everything is ready to move the driver to a dedicated directory and split the code by creating a library module for the few shared functions between the 2 driver. Eventually at803x can be further cleaned and generalized but everything will be already self contained and related only to at803x family of PHYs. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2023-12-15net: phy: at803x: make read specific status function more genericChristian Marangi
Rework read specific status function to be more generic. The function apply different speed mask based on the PHY ID. Make it more generic by adding an additional arg to pass the specific speed (ss) mask and use the provided mask to parse the speed value. This is needed to permit an easier deatch of qca808x code from the at803x driver. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-12-15net: phy: at803x: move specific qca808x config_aneg to dedicated functionChristian Marangi
Move specific qca808x config_aneg to dedicated function to permit easier split of qca808x portion from at803x driver. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-12-15Merge branch 'vsock-credit-update'David S. Miller
Arseniy Krasnov says: ==================== send credit update during setting SO_RCVLOWAT DESCRIPTION This patchset fixes old problem with hungup of both rx/tx sides and adds test for it. This happens due to non-default SO_RCVLOWAT value and deferred credit update in virtio/vsock. Link to previous old patchset: https://lore.kernel.org/netdev/39b2e9fd-601b-189d-39a9-914e5574524c@sberdevices.ru/ Here is what happens step by step: TEST INITIAL CONDITIONS 1) Vsock buffer size is 128KB. 2) Maximum packet size is also 64KB as defined in header (yes it is hardcoded, just to remind about that value). 3) SO_RCVLOWAT is default, e.g. 1 byte. STEPS SENDER RECEIVER 1) sends 128KB + 1 byte in a single buffer. 128KB will be sent, but for 1 byte sender will wait for free space at peer. Sender goes to sleep. 2) reads 64KB, credit update not sent 3) sets SO_RCVLOWAT to 64KB + 1 4) poll() -> wait forever, there is only 64KB available to read. So in step 4) receiver also goes to sleep, waiting for enough data or connection shutdown message from the sender. Idea to fix it is that rx kicks tx side to continue transmission (and may be close connection) when rx changes number of bytes to be woken up (e.g. SO_RCVLOWAT) and this value is bigger than number of available bytes to read. I've added small test for this, but not sure as it uses hardcoded value for maximum packet length, this value is defined in kernel header and used to control deferred credit update. And as this is not available to userspace, I can't control test parameters correctly (if one day this define will be changed - test may become useless). Head for this patchset is: https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=9bab51bd662be4c3ebb18a28879981d69f3ef15a Link to v1: https://lore.kernel.org/netdev/20231108072004.1045669-1-avkrasnov@salutedevices.com/ Link to v2: https://lore.kernel.org/netdev/20231119204922.2251912-1-avkrasnov@salutedevices.com/ Link to v3: https://lore.kernel.org/netdev/20231122180510.2297075-1-avkrasnov@salutedevices.com/ Link to v4: https://lore.kernel.org/netdev/20231129212519.2938875-1-avkrasnov@salutedevices.com/ Link to v5: https://lore.kernel.org/netdev/20231130130840.253733-1-avkrasnov@salutedevices.com/ Link to v6: https://lore.kernel.org/netdev/20231205064806.2851305-1-avkrasnov@salutedevices.com/ Link to v7: https://lore.kernel.org/netdev/20231206211849.2707151-1-avkrasnov@salutedevices.com/ Link to v8: https://lore.kernel.org/netdev/20231211211658.2904268-1-avkrasnov@salutedevices.com/ Link to v9: https://lore.kernel.org/netdev/20231214091947.395892-1-avkrasnov@salutedevices.com/ Changelog: v1 -> v2: * Patchset rebased and tested on new HEAD of net-next (see hash above). * New patch is added as 0001 - it removes return from SO_RCVLOWAT set callback in 'af_vsock.c' when transport callback is set - with that we can set 'sk_rcvlowat' only once in 'af_vsock.c' and in future do not copy-paste it to every transport. It was discussed in v1. * See per-patch changelog after ---. v2 -> v3: * See changelog after --- in 0003 only (0001 and 0002 still same). v3 -> v4: * Patchset rebased and tested on new HEAD of net-next (see hash above). * See per-patch changelog after ---. v4 -> v5: * Change patchset tag 'RFC' -> 'net-next'. * See per-patch changelog after ---. v5 -> v6: * New patch 0003 which sends credit update during reading bytes from socket. * See per-patch changelog after ---. v6 -> v7: * Patchset rebased and tested on new HEAD of net-next (see hash above). * See per-patch changelog after ---. v7 -> v8: * See per-patch changelog after ---. v8 -> v9: * Patchset rebased and tested on new HEAD of net-next (see hash above). * Add 'Fixes' tag for the current 0002. * Reorder patches by moving two fixes first. v9 -> v10: * Squash 0002 and 0003 and update commit message in result. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2023-12-15vsock/test: two tests to check credit update logicArseniy Krasnov
Both tests are almost same, only differs in two 'if' conditions, so implemented in a single function. Tests check, that credit update message is sent: 1) During setting SO_RCVLOWAT value of the socket. 2) When number of 'rx_bytes' become smaller than SO_RCVLOWAT value. Signed-off-by: Arseniy Krasnov <avkrasnov@salutedevices.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-12-15virtio/vsock: send credit update during setting SO_RCVLOWATArseniy Krasnov
Send credit update message when SO_RCVLOWAT is updated and it is bigger than number of bytes in rx queue. It is needed, because 'poll()' will wait until number of bytes in rx queue will be not smaller than O_RCVLOWAT, so kick sender to send more data. Otherwise mutual hungup for tx/rx is possible: sender waits for free space and receiver is waiting data in 'poll()'. Rename 'set_rcvlowat' callback to 'notify_set_rcvlowat' and set 'sk->sk_rcvlowat' only in one place (i.e. 'vsock_set_rcvlowat'), so the transport doesn't need to do it. Fixes: b89d882dc9fc ("vsock/virtio: reduce credit update messages") Signed-off-by: Arseniy Krasnov <avkrasnov@salutedevices.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-12-15virtio/vsock: fix logic which reduces credit update messagesArseniy Krasnov
Add one more condition for sending credit update during dequeue from stream socket: when number of bytes in the rx queue is smaller than SO_RCVLOWAT value of the socket. This is actual for non-default value of SO_RCVLOWAT (e.g. not 1) - idea is to "kick" peer to continue data transmission, because we need at least SO_RCVLOWAT bytes in our rx queue to wake up user for reading data (in corner case it is also possible to stuck both tx and rx sides, this is why 'Fixes' is used). Fixes: b89d882dc9fc ("vsock/virtio: reduce credit update messages") Signed-off-by: Arseniy Krasnov <avkrasnov@salutedevices.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
generated by cgit (git 2.34.1) at 2025-07-16 01:34:12 +0000