Norbert van Bolhuis [Thu, 7 Nov 2024 13:28:13 +0000 (14:28 +0100)]
wifi: brcmfmac: Fix oops due to NULL pointer dereference in brcmf_sdiod_sglist_rw()
This patch fixes a NULL pointer dereference bug in brcmfmac that occurs
when a high 'sd_sgentry_align' value applies (e.g. 512) and a lot of queued SKBs
are sent from the pkt queue.
The problem is the number of entries in the pre-allocated sgtable, it is
nents = max(rxglom_size, txglom_size) + max(rxglom_size, txglom_size) >> 4 + 1.
Given the default [rt]xglom_size=32 it's actually 35 which is too small.
Worst case, the pkt queue can end up with 64 SKBs. This occurs when a new SKB
is added for each original SKB if tailroom isn't enough to hold tail_pad.
At least one sg entry is needed for each SKB. So, eventually the "skb_queue_walk loop"
in brcmf_sdiod_sglist_rw may run out of sg entries. This makes sg_next return
NULL and this causes the oops.
The patch sets nents to max(rxglom_size, txglom_size) * 2 to be able handle
the worst-case.
Btw. this requires only 64-35=29 * 16 (or 20 if CONFIG_NEED_SG_DMA_LENGTH) = 464
additional bytes of memory.
Uwe Kleine-König [Wed, 6 Nov 2024 17:07:06 +0000 (18:07 +0100)]
wifi: Switch back to struct platform_driver::remove()
After commit 0edb555a65d1 ("platform: Make platform_driver::remove()
return void") .remove() is (again) the right callback to implement for
platform drivers.
Convert all platform drivers below drivers/net/wireless to use
.remove(), with the eventual goal to drop struct
platform_driver::remove_new(). As .remove() and .remove_new() have the
same prototypes, conversion is done by just changing the structure
member name in the driver initializer.
En passant several whitespace changes are done to make indentation
consistent in the struct initializers.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com> Acked-by: Toke Høiland-Jørgensen <toke@toke.dk> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Acked-by: Jiri Slaby <jirislaby@kernel.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20241106170706.38922-2-u.kleine-koenig@baylibre.com
Jiapeng Chong [Fri, 1 Nov 2024 06:07:25 +0000 (14:07 +0800)]
wifi: ipw2x00: libipw_rx_any(): fix bad alignment
This patch fixes incorrect code alignment.
./drivers/net/wireless/intel/ipw2x00/libipw_rx.c:871:2-3: code aligned with following code on line 882.
./drivers/net/wireless/intel/ipw2x00/libipw_rx.c:886:2-3: code aligned with following code on line 900.
Javier Carrasco [Wed, 30 Oct 2024 17:34:45 +0000 (18:34 +0100)]
wifi: brcmfmac: release 'root' node in all execution paths
The fixed patch introduced an additional condition to enter the scope
where the 'root' device_node is released (!settings->board_type,
currently 'err'), which avoid decrementing the refcount with a call to
of_node_put() if that second condition is not satisfied.
Move the call to of_node_put() to the point where 'root' is no longer
required to avoid leaking the resource if err is not zero.
Emmanuel Grumbach [Mon, 28 Oct 2024 11:54:59 +0000 (13:54 +0200)]
wifi: iwlwifi: mvm: don't call power_update_mac in fast suspend
We don't have any interface anyway.
Trying to send a command after the D3_CONFIG command is also a really
bad idea.
No harm done since this function wouldn't send anything to the firmware
anyway.
Emmanuel Grumbach [Mon, 28 Oct 2024 11:54:55 +0000 (13:54 +0200)]
wifi: iwlwifi: be less noisy if the NIC is dead in S3
If the NIC is dead upon resume, try to catch the error earlier and exit
earlier. We'll print less error messages and get to the same recovery
path as before: reload the firmware.
Emmanuel Grumbach [Mon, 28 Oct 2024 11:54:54 +0000 (13:54 +0200)]
wifi: iwlwifi: mvm: tell iwlmei when we finished suspending
Since we no longer shut down the device in suspend, we also no longer
call iwl_mvm_mei_device_state() and this is a problem because iwlmei
expects this to be called when it runs its own suspend sequence. It
checks mei->device_down in iwl_mei_remove() which is called upon
suspend.
Fix this by telling iwlmei when we're done accessing the device.
When we'll wake up, the device should be untouched if CSME didn't use it
during the suspend time. If CSME used it, we'll notice it through the
CSR_FUNC_SCRATCH register.
Emmanuel Grumbach [Mon, 28 Oct 2024 11:54:53 +0000 (13:54 +0200)]
wifi: iwlwifi: allow fast resume on ax200
This feature can be used on ax200 as well. It'll avoid to restart the
firmware upon suspend / resume flow. Doing so also avoids releasing and
re-allocating all the device related memory which makes the memory's
subsystem task easier.
Avraham Stern [Mon, 28 Oct 2024 11:54:52 +0000 (13:54 +0200)]
wifi: iwlwifi: mvm: support new initiator and responder command version
Add support for range_request_cmd version 15. This version adds a
testing option flag to use bad secure LTF Tx key. The command struct
itself is not changed.
Add support for responder config command version 11. This version only
adds a flag which is part of the MVM_FTM_RESP_FLAGS and does not
require any special handling.
Johannes Berg [Mon, 28 Oct 2024 11:54:51 +0000 (13:54 +0200)]
wifi: iwlwifi: mvm: use wiphy locked debugfs for low-latency
This will call into the OMI control path soon, and that will
require the wiphy mutex to be held. The files are removed by
mac80211 under wiphy mutex, so we must use the wiphy-locked
debugfs for them.
Allow calling iwl_mvm_get_bss_vif() without getting an error
message if multiple vifs are active etc., this is much easier
than having to check beforehand (which would be effectively
the same code as the function itself.)
Christophe JAILLET [Sat, 26 Oct 2024 15:34:49 +0000 (17:34 +0200)]
wifi: cfg80211: Fix an error handling path in nl80211_start_ap()
All error handling paths go to "out", except this one. Before the
commit in Fixes, error in the previous code would also end to "out",
freeing the memory.
Aleksei Vetrov [Tue, 29 Oct 2024 13:22:11 +0000 (13:22 +0000)]
wifi: nl80211: fix bounds checker error in nl80211_parse_sched_scan
The channels array in the cfg80211_scan_request has a __counted_by
attribute attached to it, which points to the n_channels variable. This
attribute is used in bounds checking, and if it is not set before the
array is filled, then the bounds sanitizer will issue a warning or a
kernel panic if CONFIG_UBSAN_TRAP is set.
This patch sets the size of allocated memory as the initial value for
n_channels. It is updated with the actual number of added elements after
the array is filled.
Lingbo Kong [Thu, 31 Oct 2024 13:42:23 +0000 (21:42 +0800)]
wifi: cfg80211: Remove the Medium Synchronization Delay validity check
Currently, when the driver attempts to connect to an AP MLD with multiple
APs, the cfg80211_mlme_check_mlo_compat() function requires the Medium
Synchronization Delay values from different APs of the same AP MLD to be
equal, which may result in connection failures.
This is because when the driver receives a multi-link probe response from
an AP MLD with multiple APs, cfg80211 updates the Elements for each AP
based on the multi-link probe response. If the Medium Synchronization Delay
is set in the multi-link probe response, the Elements for each AP belonging
to the same AP MLD will have the Medium Synchronization Delay set
simultaneously. If non-multi-link probe responses are received from
different APs of the same MLD AP, cfg80211 will still update the Elements
based on the non-multi-link probe response. Since the non-multi-link probe
response does not set the Medium Synchronization Delay
(IEEE 802.11be-2024-35.3.4.4), if the Elements from a non-multi-link probe
response overwrite those from a multi-link probe response that has set the
Medium Synchronization Delay, the Medium Synchronization Delay values for
APs belonging to the same AP MLD will not be equal. This discrepancy causes
the cfg80211_mlme_check_mlo_compat() function to fail, leading to
connection failures. Commit ccb964b4ab16
("wifi: cfg80211: validate MLO connections better") did not take this into
account.
To address this issue, remove this validity check.
Dr. David Alan Gilbert [Mon, 4 Nov 2024 14:43:31 +0000 (14:43 +0000)]
wifi: rtlwifi: Remove some exhalbtc deadcode
exhalbtc_rf_status_notify(), exhalbtc_coex_dm_switch() and
exhalbtc_antenna_detection() are unused since they were added in 2017's
commit 7937f02d1953 ("rtlwifi: btcoex: hook external functions for newer
chips")
Remove them.
This leaves ex_btc8723b1ant_coex_dm_reset() unused.
Remove it.
exhalbtc_dbg_control(), exhalbtc_stack_update_profile_info(),
exhalbtc_set_hci_version(), and exhalbtc_set_bt_patch_version() are
unused since their addition in 2014 by
commit aa45a673b291 ("rtlwifi: btcoexist: Add new mini driver")
Guilherme G. Piccoli [Fri, 1 Nov 2024 19:30:05 +0000 (16:30 -0300)]
wifi: rtlwifi: Drastically reduce the attempts to read efuse in case of failures
Syzkaller reported a hung task with uevent_show() on stack trace. That
specific issue was addressed by another commit [0], but even with that
fix applied (for example, running v6.12-rc5) we face another type of hung
task that comes from the same reproducer [1]. By investigating that, we
could narrow it to the following path:
(a) Syzkaller emulates a Realtek USB WiFi adapter using raw-gadget and
dummy_hcd infrastructure.
(b) During the probe of rtl8192cu, the driver ends-up performing an efuse
read procedure (which is related to EEPROM load IIUC), and here lies the
issue: the function read_efuse() calls read_efuse_byte() many times, as
loop iterations depending on the efuse size (in our example, 512 in total).
This procedure for reading efuse bytes relies in a loop that performs an
I/O read up to *10k* times in case of failures. We measured the time of
the loop inside read_efuse_byte() alone, and in this reproducer (which
involves the dummy_hcd emulation layer), it takes 15 seconds each. As a
consequence, we have the driver stuck in its probe routine for big time,
exposing a stack trace like below if we attempt to reboot the system, for
example:
We propose hereby to drastically reduce the attempts of doing the I/O
reads in case of failures, restricted to USB devices (given that
they're inherently slower than PCIe ones). By retrying up to 10 times
(instead of 10000), we got reponsiveness in the reproducer, while seems
reasonable to believe that there's no sane USB device implementation in
the field requiring this amount of retries at every I/O read in order
to properly work. Based on that assumption, it'd be good to have it
backported to stable but maybe not since driver implementation (the 10k
number comes from day 0), perhaps up to 6.x series makes sense.
[1] A note about that: this syzkaller report presents multiple reproducers
that differs by the type of emulated USB device. For this specific case,
check the entry from 2024/08/08 06:23 in the list of crashes; the C repro
is available at https://syzkaller.appspot.com/text?tag=ReproC&x=1521fc83980000.
Bitterblue Smith [Wed, 30 Oct 2024 18:31:28 +0000 (20:31 +0200)]
wifi: rtw88: Enable the new RTL8821AU/RTL8812AU drivers
These are older Wifi 5 chips. RTL8821AU is 1x1, with or without
Bluetooth. RTL8812AU is 2x2, without Bluetooth.
Beamforming is not implemented. It looks like these chips need a
different implementation than what is in bf.c.
Speed tests with RTL8821AU: 137 Mbps download, 144 Mbps upload.
Speed tests with RTL8812AU: 344 Mbps download, 387 Mbps upload.
Station mode and AP mode were tested.
Bluetooth coexistence works. I used my Bluetooth headphones for
several days, listening to music and watching videos. There is only
a problem with the wifi speeds with one router:
With ISP's HG6544C router:
Official driver: 3/5 Mbps.
rtw88: a bit more, but not steady at all. Not enough to watch a 1080p
Youtube video.
With my D-Link Eagle R32 router running Openwrt, on the same channel:
Official driver: 6/10 Mbps.
rtw88: download starts around 30, climbs to 50 / upload is 10 Mbps.
I can watch a 1080p Youtube video.
The music doesn't cut out during any speed tests.
I also tested transferring files to and from my phone. I don't have
other types of Bluetooth devices to test.
Ching-Te Ku [Thu, 31 Oct 2024 02:30:32 +0000 (10:30 +0800)]
wifi: rtw89: coex: set higher priority to BT when WL scan and BT A2DP exist
If WiFi operation channel & scan channel both at 2.4GHz, original will keep
going at WL > BT priority table for a long time. It makes A2DP can not sent
audio data to SUT device in time then performed a lag audio. Assign
a BT > WL priority table when A2DP exist, to avoid the issue.
Chih-Kang Chang [Wed, 30 Oct 2024 09:16:03 +0000 (17:16 +0800)]
wifi: rtw89: 8852b: change RF mode to normal mode when set channel
Set the RF mode from 0xA(low power mode) to 0x3(Normal mode) to avoid
abnormal TX waveform in OFDM rate. Originally the RF mode will be changed
to normal mode by the firmware after entering LPS once. Therefore, this
change does not affect power saving.
Kuan-Chung Chen [Wed, 30 Oct 2024 02:29:03 +0000 (10:29 +0800)]
wifi: rtw89: 8922a: fill the missing OP1dB configuration
OP1dB stands for Output 1dB Compression Point. At this point, the power
amplifier starts to enter the saturation region, resulting in distortion.
The configuration of OP1dB can optimize the RX gain saturation region,
improving RX throughput from 573 to 675 Mbps.
Ping-Ke Shih [Wed, 30 Oct 2024 02:21:35 +0000 (10:21 +0800)]
wifi: rtw89: mac: no configure CMAC/DMAC tables for firmware secure boot
The initial CMAC/DMAC tables used by WiFi 6 chips are not needed to be
called for firmware secure boot. Otherwise, it causes firmware abnormal
and throw warnings.
rtw89_8852be 0000:03:00.0: FW status = 0x1400
rtw89_8852be 0000:03:00.0: FW BADADDR = 0xb872f800
rtw89_8852be 0000:03:00.0: FW EPC/RA = 0xb89333b7
rtw89_8852be 0000:03:00.0: FW MISC = 0x0
rtw89_8852be 0000:03:00.0: R_AX_HALT_C2H = 0x10002010
rtw89_8852be 0000:03:00.0: R_AX_SER_DBG_INFO = 0x0
rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c97
rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c95
rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c99
rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c9b
rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c9f
rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c9b
rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c99
rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c9d
rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c97
rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c97
rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c97
rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c99
rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c97
rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c9f
rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c99
Ping-Ke Shih [Wed, 30 Oct 2024 02:21:34 +0000 (10:21 +0800)]
wifi: rtw89: fw: use common function to parse security section for WiFi 6 chips
The MSSC (multiple security section count) can be regular number (shown in
below figure) or 0xFF (supported already). For WiFi 7 or newer WiFi 6
chips, the MSSC will be 0xFF. But early WiFi 6 chip such as RTL8852B
could be either one of the cases.
Extend __parse_security_section() to support both with/without secure
boot mode accordingly.
+---------------------------+ -\
| firmware header | |
| | |
| +-----------------------+ | |
| | section type/size * N | | |
| +-----------------------+ | |
+---------------------------+ -/
: :
+---------------------------+ -\
| secure section type (ID:9)| |
| | |
+----|-> [ security key data ] | |
| +---------------------------+ -/
| |MSS Pool for above section |
| | [ security key data 1 ] |
+----|- [ security key data 2 ] |
by mss_idx | [ security key data 3 ] |
| ... M | * M = MSSC (MSSC != 0xFF)
+---------------------------+
Ping-Ke Shih [Wed, 30 Oct 2024 02:21:33 +0000 (10:21 +0800)]
wifi: rtw89: fw: move v1 MSSC out of __parse_security_section() to share with v0
The security section can be a common parser for v0 and v1 format of
firmware header, so move retrieval code of v1 MSSC from the function, and
then sharing becomes possible.
Ping-Ke Shih [Wed, 30 Oct 2024 02:21:32 +0000 (10:21 +0800)]
wifi: rtw89: fw: set recorded IDMEM share mode in firmware header to register
For WiFi 6 chips, firmware secure boot will run on a IDMEM mode specified
in firmware header. Retrieve the mode from firmware, and set to registers
accordingly.
Ping-Ke Shih [Wed, 30 Oct 2024 02:21:31 +0000 (10:21 +0800)]
wifi: rtw89: fw: shrink download size of security section for RTL8852B
For RTL8852B, when current firmware is secure boot, the security section
needs a special treatment that shrink its size to 960.
As figure below, not only shrink the amount of download size of security
section (2), but also need to modify the section size in firmware header
(1) that is also downloaded to chip.
Ping-Ke Shih [Wed, 30 Oct 2024 02:21:30 +0000 (10:21 +0800)]
wifi: rtw89: efuse: read firmware secure info v0 from efuse for WiFi 6 chips
WiFi 6 chips could program secure information in v0 or v1 format. Use
existing v1 parser or newly added v0 parser to recognize firmware key
that is going to be used.
Ping-Ke Shih [Wed, 30 Oct 2024 02:21:28 +0000 (10:21 +0800)]
wifi: rtw89: efuse: move reading efuse of fw secure info to common
The secure key used by certain hardware module is programmed in efuse, so
driver should read the information from efuse before downloading firmware.
Originally only RTL8922AE can support firmware secure boot, and read efuse
during chip power on. To extend to support all chips, move the caller to
common power on flow and add separate functions to read efuse for
WiFi 6 chips.
Chih-Kang Chang [Sat, 26 Oct 2024 02:21:43 +0000 (10:21 +0800)]
wifi: rtw89: set pause_data field to avoid transmitting data in scan channels
Set pause_data to all of the scan channels, excluding the OP channel,
to prevent data frame transmission to the scan channels, which causes
retransmission. Additionally, this flag won't affect the transmission
of probe requests from the scan channels.
Chin-Yen Lee [Thu, 24 Oct 2024 05:55:09 +0000 (13:55 +0800)]
wifi: rtw89: don't check done-ack for entering PS
In WoWLAN mode, driver will disable interrupt after calling H2C command
for entering PS mode, but it may lead to failing to enter deep PS mode by
firmware because the done-ack of the H2C from firmware is not handled by
driver. In fact, the done-ack for entering PS is not necessary for driver
to check, so remove it.
Yuan Can [Tue, 22 Oct 2024 09:04:53 +0000 (17:04 +0800)]
wifi: wfx: Fix error handling in wfx_core_init()
The wfx_core_init() returns without checking the retval from
sdio_register_driver().
If the sdio_register_driver() failed, the module failed to install,
leaving the wfx_spi_driver not unregistered.
Fixes: a7a91ca5a23d ("staging: wfx: add infrastructure for new driver") Signed-off-by: Yuan Can <yuancan@huawei.com> Reviewed-by: Jérôme Pouiller <jerome.pouiller@silabs.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20241022090453.84679-1-yuancan@huawei.com
Kalle Valo [Thu, 31 Oct 2024 14:03:57 +0000 (16:03 +0200)]
Merge tag 'ath-next-20241030' of git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath
ath.git patches for v6.13
This development cycle featured phase 1 of patches to ath12k to
support the new 802.11be MLO feature, along with other ath12k feature
patches. In older drivers, support for some additional devices were
added. And there was the usual set of bug fixes and cleanups across
most drivers.
Per-driver highlights:
ath12k
* Switch to using wiphy_lock() and remove ar->conf_mutex
* Convert struct ath12k_sta::update_wk to use struct wiphy_work
* Add phase 1 of 802.11be MLO support
* Add firmware coredump collection support
* Add debugfs support for a multitude of statistics
* Fix host representation of multiple hal_rx structs
* Fix use-after-free in ath12k_dp_cc_cleanup()
* Skip Rx TID cleanup for self peer
* Fix warning and crash when unloading in a VM
* Convert CE interrupt handling from tasklet to BH workqueue
* Fix A-MSDU indication in monitor mode
ath11k
* Fix double free issue during SRNG deinit
* Enable firmware diagnostic events for WCN6750
* Fix CE offset address calculation for WCN6750 during SSR
* Fix stack frame size warning in ath11k_vif_wow_set_wakeups()
* Document the inputs for ath11k on WCN6855
Jakub Kicinski [Wed, 30 Oct 2024 01:50:57 +0000 (18:50 -0700)]
Merge tag 'wireless-next-2024-10-25' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next
Kalle Valo says:
====================
wireless-next patches for v6.13
The first -next "new features" pull request for v6.13. This is a big
one as we have not been able to send one earlier. We have also some
patches affecting other subsystems: in staging we deleted the rtl8192e
driver and in debugfs added a new interface to save struct
file_operations memory; both were acked by GregKH.
Because of the lib80211/libipw move there were quite a lot of
conflicts and to solve those we decided to merge net-next into
wireless-next.
Major changes:
cfg80211/mac80211
* stop exporting wext symbols
* new mac80211 op to indicate that a new interface is to be added
* support radio separation of multi-band devices
Wireless Extensions
* move wext spy implementation to libiw
* remove iw_public_data from struct net_device
brcmfmac
* optional LPO clock support
ipw2x00
* move remaining lib80211 code into libiw
wilc1000
* WILC3000 support
rtw89
* RTL8852BE and RTL8852BE-VT BT-coexistence improvements
* tag 'wireless-next-2024-10-25' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (126 commits)
mac80211: Remove NOP call to ieee80211_hw_config
wifi: iwlwifi: work around -Wenum-compare-conditional warning
wifi: mac80211: re-order assigning channel in activate links
wifi: mac80211: convert debugfs files to short fops
debugfs: add small file operations for most files
wifi: mac80211: remove misleading j_0 construction parts
wifi: mac80211_hwsim: use hrtimer_active()
wifi: mac80211: refactor BW limitation check for CSA parsing
wifi: mac80211: filter on monitor interfaces based on configured channel
wifi: mac80211: refactor ieee80211_rx_monitor
wifi: mac80211: add support for the monitor SKIP_TX flag
wifi: cfg80211: add monitor SKIP_TX flag
wifi: mac80211: add flag to opt out of virtual monitor support
wifi: cfg80211: pass net_device to .set_monitor_channel
wifi: mac80211: remove status->ampdu_delimiter_crc
wifi: cfg80211: report per wiphy radio antenna mask
wifi: mac80211: use vif radio mask to limit creating chanctx
wifi: mac80211: use vif radio mask to limit ibss scan frequencies
wifi: cfg80211: add option for vif allowed radios
wifi: iwlwifi: allow IWL_FW_CHECK() with just a string
...
Jakub Kicinski [Tue, 29 Oct 2024 23:52:59 +0000 (16:52 -0700)]
Merge branch 'devlink-minor-cleanup'
Przemek Kitszel says:
====================
devlink: minor cleanup
(Patch 1, 2) Add one helper shortcut to put u64 values into skb.
(Patch 3, 4) Minor cleanup for error codes.
(Patch 5, 6, 7) Remove some devlink_resource_*() usage and functions
itself via replacing devlink_* variants by devl_* ones.
Przemek Kitszel [Wed, 23 Oct 2024 13:09:06 +0000 (15:09 +0200)]
devlink: remove unused devlink_resource_occ_get_register() and _unregister()
Remove not used devlink_resource_occ_get_register() and
devlink_resource_occ_get_unregister() functions; current devlink resource
users are fine with devl_ variants of the two.
Reviewed-by: Wojciech Drewek <wojciech.drewek@intel.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Reviewed-by: Joe Damato <jdamato@fastly.com> Signed-off-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Link: https://patch.msgid.link/20241023131248.27192-7-przemyslaw.kitszel@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Przemek Kitszel [Wed, 23 Oct 2024 13:09:05 +0000 (15:09 +0200)]
net: dsa: replace devlink resource registration calls by devl_ variants
Replace devlink_resource_register(), devlink_resource_occ_get_register(),
and devlink_resource_occ_get_unregister() calls by respective devl_*
variants. Mentioned functions have no direct users in any drivers, and are
going to be removed in subsequent patches.
Reviewed-by: Wojciech Drewek <wojciech.drewek@intel.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Reviewed-by: Joe Damato <jdamato@fastly.com> Signed-off-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Link: https://patch.msgid.link/20241023131248.27192-6-przemyslaw.kitszel@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Current code is written to return -EINVAL when tailroom in the skb msg
would be exhausted precisely when it's time to nest, and return -EMSGSIZE
in all other "not enough space" conditions.
Reviewed-by: Wojciech Drewek <wojciech.drewek@intel.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Reviewed-by: Joe Damato <jdamato@fastly.com> Signed-off-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Link: https://patch.msgid.link/20241023131248.27192-5-przemyslaw.kitszel@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Heiner Kallweit [Thu, 24 Oct 2024 20:42:33 +0000 (22:42 +0200)]
r8169: add support for RTL8125D
This adds support for new chip version RTL8125D, which can be found on
boards like Gigabyte X870E AORUS ELITE WIFI7. Firmware rtl8125d-1.fw
for this chip version is available in linux-firmware already.
Use a while loop in mlx5_eq_comp_int() and mlx5_eq_async_int() to
clarify the EQE polling logic. This consolidates the next_eqe_sw() calls
for the first and subequent iterations. It also avoids a goto. Turn the
num_eqes < MLX5_EQ_POLLING_BUDGET check into a break condition.
Rosen Penev [Tue, 22 Oct 2024 23:32:03 +0000 (16:32 -0700)]
amd-xgbe: use ethtool string helpers
The latter is the preferred way to copy ethtool strings.
Avoids manually incrementing the pointer.
Signed-off-by: Rosen Penev <rosenp@gmail.com> Acked-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20241022233203.9670-1-rosenp@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Consolidate the handling of dedicated PHY and fixed-link phy by taking
advantage of logic in of_phy_get_and_connect() which handles both of
these cases, rather than open coding the same logic in ftgmac100_probe().
These two patches simplify how we attach SFP PHYs.
The first patch notices that at the two sites where we call
sfp_select_interface(), if that fails, we always print the same error.
Move this into its own function.
The second patch adds an additional level of validation, checking that
the returned interface is one that is supported by the MAC/PCS.
The last patch simplifies how SFP PHYs are attached, reducing the
number of times that we do validation in this path.
====================
Russell King (Oracle) [Wed, 23 Oct 2024 13:41:57 +0000 (14:41 +0100)]
net: phylink: simplify how SFP PHYs are attached
There are a few issues with how SFP PHYs are attached:
a) The phylink_sfp_connect_phy() and phylink_sfp_config_phy() code
validates the configuration three times:
1. To discover the support/advertising masks that the PHY/PCS/MAC
can support in order to select an interface.
2. To validate the selected interface.
3. When the PHY is brought up after being attached, another validation
is done.
This is needlessly complex.
b) The configuration is set prior to the PHY being attached, which
means we don't have the PHY available in phylink_major_config()
for phylink_pcs_neg_mode() to make decisions upon.
We have already added an extra step to validate the selected interface,
so we can now move the attachment and bringup of the PHY earlier,
inside phylink_sfp_config_phy(). This results in the validation at
step 2 above becoming entirely unnecessary, so remove that too.
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Tested-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1t3bcb-000c8H-3e@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Russell King (Oracle) [Wed, 23 Oct 2024 13:41:51 +0000 (14:41 +0100)]
net: phylink: validate sfp_select_interface() returned interface
Validate that the returned interface from sfp_select_interface() is
supportable by the MAC/PCS. If it isn't, print an error and return
the NA interface type. This is a preparatory step to reorganising
how a PHY on a SFP module is handled.
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Tested-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1t3bcV-000c8B-Vz@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Russell King (Oracle) [Wed, 23 Oct 2024 13:41:46 +0000 (14:41 +0100)]
net: phylink: add common validation for sfp_select_interface()
Whenever we call sfp_select_interface(), we check the returned value
and print an error. There are two cases where this happens with the
same message. Provide a common function to do this.
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Tested-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1t3bcQ-000c85-S4@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Russell King (Oracle) [Tue, 22 Oct 2024 14:17:07 +0000 (15:17 +0100)]
net: phylink: simplify phylink_parse_fixedlink()
phylink_parse_fixedlink() wants to preserve the pause, asym_pause and
autoneg bits in pl->supported. Rather than reading the bits into
separate bools, zeroing pl->supported, and then setting them if they
were previously set, use a mask and linkmode_and() to achieve the same
result.
====================
mlx5e update features on config changes
This small patchset by Dragos adds a call to netdev_update_features()
in configuration changes that could impact the features status.
====================
Dragos Tatulea [Thu, 24 Oct 2024 16:41:33 +0000 (19:41 +0300)]
net/mlx5e: Update features on ring size change
When the ring size changes successfully, trigger
netdev_update_features() to enable features in wanted state if
applicable.
An example of such scenario:
$ ip link set dev eth1 up
$ ethtool --set-ring eth1 rx 8192
$ ip link set dev eth1 mtu 9000
$ ethtool --features eth1 rx-gro-hw on --> fails
$ ethtool --set-ring eth1 rx 1024
With this patch, HW GRO will be turned on automatically because
it is set in the device's wanted_features.
Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com> Reviewed-by: Gal Pressman <gal@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20241024164134.299646-3-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Dragos Tatulea [Thu, 24 Oct 2024 16:41:32 +0000 (19:41 +0300)]
net/mlx5e: Update features on MTU change
When the MTU changes successfully, trigger netdev_update_features() to
enable features in wanted state if applicable.
An example of such scenario:
$ ip link set dev eth1 up
$ ethtool --set-ring eth1 rx 8192
$ ip link set dev eth1 mtu 9000
$ ethtool --features eth1 rx-gro-hw on --> fails
$ ip link set dev eth1 mtu 7000
With this patch, HW GRO will be turned on automatically because
it is set in the device's wanted_features.
Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com> Reviewed-by: Gal Pressman <gal@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20241024164134.299646-2-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Simon Horman [Wed, 23 Oct 2024 12:15:28 +0000 (13:15 +0100)]
wwan: core: Pass string literal as format argument of dev_set_name()
Both gcc-14 and clang-18 report that passing a non-string literal as the
format argument of dev_set_name() is potentially insecure.
E.g. clang-18 says:
drivers/net/wwan/wwan_core.c:442:34: warning: format string is not a string literal (potentially insecure) [-Wformat-security]
442 | return dev_set_name(&port->dev, buf);
| ^~~
drivers/net/wwan/wwan_core.c:442:34: note: treat the string as an argument to avoid this
442 | return dev_set_name(&port->dev, buf);
| ^
| "%s",
It is always the case where the contents of mod is safe to pass as the
format argument. That is, in my understanding, it never contains any
format escape sequences.
But, it seems better to be safe than sorry. And, as a bonus, compiler
output becomes less verbose by addressing this issue as suggested by
clang-18.
Compile tested only.
No functional change intended.
====================
ipv4: Prepare core ipv4 files to future .flowi4_tos conversion.
Continue preparing users of ->flowi4_tos (struct flowi4) to the future
conversion of this field (from __u8 to dscp_t). The objective is to
have type annotation to properly separate DSCP bits from ECN ones. This
way we'll ensure that ECN doesn't interfere with DSCP and avoid
regressions where it break routing descisions (fib rules in particular).
This series concentrates on some easy IPv4 conversions where
->flowi4_tos is set directly from an IPv4 header, so we can get the
DSCP value using the ip4h_dscp() helper function.
====================
Paolo Abeni [Tue, 29 Oct 2024 14:33:24 +0000 (15:33 +0100)]
Merge branch 'ibm-emac-more-cleanups'
Rosen Penev says:
====================
ibm: emac: more cleanups
Tested on Cisco MX60W.
v2: fixed build errors. Also added extra commits to clean the driver up
further.
v3: Added tested message. Removed bad alloc_netdev_dummy commit.
v4: removed modules changes from patchset. Added fix for if MAC not
found.
v5: added of_find_matching_node commit.
v6: resend after net-next merge.
v7: removed of_find_matching_node commit. Adjusted mutex_init patch.
v8: removed patch removing custom init/exit. Needs more work.
====================
Rosen Penev [Tue, 22 Oct 2024 00:22:45 +0000 (17:22 -0700)]
net: ibm: emac: generate random MAC if not found
On this Cisco MX60W, u-boot sets the local-mac-address property.
Unfortunately by default, the MAC is wrong and is actually located on a
UBI partition. Which means nvmem needs to be used to grab it.
In the case where that fails, EMAC fails to initialize instead of
generating a random MAC as many other drivers do.
Match behavior with other drivers to have a working ethernet interface.
Signed-off-by: Rosen Penev <rosenp@gmail.com> Reviewed-by: Shannon Nelson <shannon.nelson@amd.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Rosen Penev [Tue, 22 Oct 2024 00:22:41 +0000 (17:22 -0700)]
net: ibm: emac: use netif_receive_skb_list
Small rx improvement. Would use napi_gro_receive instead but that's a
lot more involved than netif_receive_skb_list because of how the
function is implemented.
Before:
> iperf -c 192.168.1.1
------------------------------------------------------------
Client connecting to 192.168.1.1, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[ 1] local 192.168.1.101 port 51556 connected with 192.168.1.1 port 5001
[ ID] Interval Transfer Bandwidth
[ 1] 0.00-10.04 sec 559 MBytes 467 Mbits/sec
> iperf -c 192.168.1.1
------------------------------------------------------------
Client connecting to 192.168.1.1, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[ 1] local 192.168.1.101 port 48228 connected with 192.168.1.1 port 5001
[ ID] Interval Transfer Bandwidth
[ 1] 0.00-10.03 sec 558 MBytes 467 Mbits/sec
> iperf -c 192.168.1.1
------------------------------------------------------------
Client connecting to 192.168.1.1, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[ 1] local 192.168.1.101 port 47600 connected with 192.168.1.1 port 5001
[ ID] Interval Transfer Bandwidth
[ 1] 0.00-10.04 sec 557 MBytes 466 Mbits/sec
> iperf -c 192.168.1.1
------------------------------------------------------------
Client connecting to 192.168.1.1, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[ 1] local 192.168.1.101 port 37252 connected with 192.168.1.1 port 5001
[ ID] Interval Transfer Bandwidth
[ 1] 0.00-10.05 sec 559 MBytes 467 Mbits/sec
After:
> iperf -c 192.168.1.1
------------------------------------------------------------
Client connecting to 192.168.1.1, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[ 1] local 192.168.1.101 port 40786 connected with 192.168.1.1 port 5001
[ ID] Interval Transfer Bandwidth
[ 1] 0.00-10.05 sec 572 MBytes 478 Mbits/sec
> iperf -c 192.168.1.1
------------------------------------------------------------
Client connecting to 192.168.1.1, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[ 1] local 192.168.1.101 port 52482 connected with 192.168.1.1 port 5001
[ ID] Interval Transfer Bandwidth
[ 1] 0.00-10.04 sec 571 MBytes 477 Mbits/sec
> iperf -c 192.168.1.1
------------------------------------------------------------
Client connecting to 192.168.1.1, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[ 1] local 192.168.1.101 port 48370 connected with 192.168.1.1 port 5001
[ ID] Interval Transfer Bandwidth
[ 1] 0.00-10.04 sec 572 MBytes 478 Mbits/sec
> iperf -c 192.168.1.1
------------------------------------------------------------
Client connecting to 192.168.1.1, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[ 1] local 192.168.1.101 port 46086 connected with 192.168.1.1 port 5001
[ ID] Interval Transfer Bandwidth
[ 1] 0.00-10.05 sec 571 MBytes 476 Mbits/sec
> iperf -c 192.168.1.1
------------------------------------------------------------
Client connecting to 192.168.1.1, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[ 1] local 192.168.1.101 port 46062 connected with 192.168.1.1 port 5001
[ ID] Interval Transfer Bandwidth
[ 1] 0.00-10.04 sec 572 MBytes 478 Mbits/sec
Signed-off-by: Rosen Penev <rosenp@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Reviewed-by: Shannon Nelson <shannon.nelson@amd.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
projects / users / jedix / linux-maple.git / log