summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-04-20wifi: rtw88: Update spelling in main.hSimon Horman
Update spelling in comments in main.h Found by inspection. Signed-off-by: Simon Horman <horms@kernel.org> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230418-rtw88-starspell-v1-1-70e52a23979b@kernel.org
2023-04-20wifi: airo: remove ISA_DMA_API dependencyArnd Bergmann
This driver does not actually use the ISA DMA API, it is purely PIO based, so remove the dependency. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230417205131.1560074-1-arnd@kernel.org
2023-04-20wifi: rtl8xxxu: Simplify setting the initial gainBitterblue Smith
The goal of writing 0x6954341e / 0x6955341e to REG_OFDM0_XA_AGC_CORE1 appears to be setting the initial gain, which is stored in bits 0..6. Bits 7..31 are the same as what the phy init tables write. Modify only bits 0..6 so that we don't have to care about the values of the others. This way we don't have to add another "else if" for the RTL8192FU. Why we need to change the initial gain from the default 0x20 to 0x1e? Not sure. Some of the vendor drivers change it to 0x1e before scanning and then restore it to the original value after. 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/cf91ca69-70e3-4c20-c0b1-e59d452356a1@gmail.com
2023-04-20wifi: rtl8xxxu: Add rtl8xxxu_write{8,16,32}_{set,clear}Bitterblue Smith
Also add rtl8xxxu_write32_mask, rtl8xxxu_write_rfreg_mask. These helper functions make it easier to modify only parts of a register by eliminating the call to the register reading function and the bit manipulations. 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/9430b841-1048-b27c-14ec-fca447dc32af@gmail.com
2023-04-20wifi: rtl8xxxu: Don't print the vendor/product/serialBitterblue Smith
Most devices have a vendor name, product name, and serial number in the efuse, but it's pretty useless. It duplicates the information already printed by the USB subsystem: usb 1-4: New USB device found, idVendor=0bda, idProduct=8178, bcdDevice= 2.00 usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-4: Product: 802.11n WLAN Adapter usb 1-4: Manufacturer: Realtek usb 1-4: SerialNumber: 00e04c000001 -> usb 1-4: Vendor: Realtek -> usb 1-4: Product: 802.11n WLAN Adapter usb 1-4: New USB device found, idVendor=0bda, idProduct=818b, bcdDevice= 2.00 usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-4: Product: 802.11n NIC usb 1-4: Manufacturer: Realtek usb 1-4: SerialNumber: 00e04c000001 -> usb 1-4: Vendor: Realtek -> usb 1-4: Product: 802.11n NIC -> usb 1-4: Serial not available. usb 1-4: New USB device found, idVendor=0bda, idProduct=f179, bcdDevice= 0.00 usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-4: Product: 802.11n usb 1-4: Manufacturer: Realtek usb 1-4: SerialNumber: 002E2DC0041F -> usb 1-4: Vendor: Realtek -> usb 1-4: Product: 802.11n usb 1-4: New USB device found, idVendor=0bda, idProduct=8179, bcdDevice= 0.00 usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-4: Product: 802.11n NIC usb 1-4: Manufacturer: Realtek usb 1-4: SerialNumber: 00E04C0001 -> usb 1-4: Vendor: Realtek -> usb 1-4: Product: 802.11n NIC -> usb 1-4: Serial: 00E04C0001 Also, that data is not interpreted correctly in all cases: usb 3-1.1.2: New USB device found, idVendor=0bda, idProduct=8179, bcdDevice= 0.00 usb 3-1.1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 3-1.1.2: Product: 802.11n NIC usb 3-1.1.2: Manufacturer: Realtek usb 3-1.1.2: Vendor: Realtek usb 3-1.1.2: Product: \x03802.11n NI usb 3-1.1.2: Serial: \xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff Link: https://bugzilla.kernel.org/show_bug.cgi?id=217231 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/a2a7d9df-0529-7890-3522-48dce613753f@gmail.com
2023-04-20wifi: rtw88: Fix memory leak in rtw88_usbLarry Finger
Kmemleak shows the following leak arising from routine in the usb probe routine: unreferenced object 0xffff895cb29bba00 (size 512): comm "(udev-worker)", pid 534, jiffies 4294903932 (age 102751.088s) hex dump (first 32 bytes): 77 30 30 30 00 00 00 00 02 2f 2d 2b 30 00 00 00 w000...../-+0... 02 00 2a 28 00 00 00 00 ff 55 ff ff ff 00 00 00 ..*(.....U...... backtrace: [<ffffffff9265fa36>] kmalloc_trace+0x26/0x90 [<ffffffffc17eec41>] rtw_usb_probe+0x2f1/0x680 [rtw_usb] [<ffffffffc03e19fd>] usb_probe_interface+0xdd/0x2e0 [usbcore] [<ffffffff92b4f2fe>] really_probe+0x18e/0x3d0 [<ffffffff92b4f5b8>] __driver_probe_device+0x78/0x160 [<ffffffff92b4f6bf>] driver_probe_device+0x1f/0x90 [<ffffffff92b4f8df>] __driver_attach+0xbf/0x1b0 [<ffffffff92b4d350>] bus_for_each_dev+0x70/0xc0 [<ffffffff92b4e51e>] bus_add_driver+0x10e/0x210 [<ffffffff92b50935>] driver_register+0x55/0xf0 [<ffffffffc03e0708>] usb_register_driver+0x88/0x140 [usbcore] [<ffffffff92401153>] do_one_initcall+0x43/0x210 [<ffffffff9254f42a>] do_init_module+0x4a/0x200 [<ffffffff92551d1c>] __do_sys_finit_module+0xac/0x120 [<ffffffff92ee6626>] do_syscall_64+0x56/0x80 [<ffffffff9300006a>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 The leak was verified to be real by unloading the driver, which resulted in a dangling pointer to the allocation. The allocated memory is freed in rtw_usb_intf_deinit(). Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Ping-Ke Shih <pkshih@realtek.com> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230417160331.23071-1-Larry.Finger@lwfinger.net
2023-04-20wifi: rtw88: call rtw8821c_switch_rf_set() according to chip variantSascha Hauer
We have to call rtw8821c_switch_rf_set() with SWITCH_TO_WLG or SWITCH_TO_BTG according to the chip variant as denoted in rfe_option. The information which argument to use for which variant has been taken from the vendor driver. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230417140358.2240429-5-s.hauer@pengutronix.de
2023-04-20wifi: rtw88: set pkg_type correctly for specific rtw8821c variantsSascha Hauer
According to the vendor driver the pkg_type has to be set to '1' for some rtw8821c variants. As the pkg_type has been hardcoded to '0', add a field for it in struct rtw_hal and set this correctly in the rtw8821c part. With this parsing of a rtw_table is influenced and check_positive() in phy.c returns true for some cases here. The same is done in the vendor driver. However, this has no visible effect on the driver here. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230417140358.2240429-4-s.hauer@pengutronix.de
2023-04-20wifi: rtw88: rtw8821c: Fix rfe_option field widthSascha Hauer
On my RTW8821CU chipset rfe_option reads as 0x22. Looking at the vendor driver suggests that the field width of rfe_option is 5 bit, so rfe_option should be masked with 0x1f. Without this the rfe_option comparisons with 2 further down the driver evaluate as false when they should really evaluate as true. The effect is that 2G channels do not work. rfe_option is also used as an array index into rtw8821c_rfe_defs[]. rtw8821c_rfe_defs[34] (0x22) was added as part of adding USB support, likely because rfe_option reads as 0x22. As this now becomes 0x2, rtw8821c_rfe_defs[34] is no longer used and can be removed. Note that this might not be the whole truth. In the vendor driver there are indeed places where the unmasked rfe_option value is used. However, the driver has several places where rfe_option is tested with the pattern if (rfe_option == 2 || rfe_option == 0x22) or if (rfe_option == 4 || rfe_option == 0x24), so that rfe_option BIT(5) has no influence on the code path taken. We therefore mask BIT(5) out from rfe_option entirely until this assumption is proved wrong by some chip variant we do not know yet. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Tested-by: Alexandru gagniuc <mr.nuke.me@gmail.com> Tested-by: Larry Finger <Larry.Finger@lwfinger.net> Tested-by: ValdikSS <iam@valdikss.org.ru> Cc: stable@vger.kernel.org Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230417140358.2240429-3-s.hauer@pengutronix.de
2023-04-20wifi: rtw88: usb: fix priority queue to endpoint mappingSascha Hauer
The RTW88 chipsets have four different priority queues in hardware. For the USB type chipsets the packets destined for a specific priority queue must be sent through the endpoint corresponding to the queue. This was not fully understood when porting from the RTW88 USB out of tree driver and thus violated. This patch implements the qsel to endpoint mapping as in get_usb_bulkout_id_88xx() in the downstream driver. Without this the driver often issues "timed out to flush queue 3" warnings and often TX stalls completely. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Tested-by: ValdikSS <iam@valdikss.org.ru> Tested-by: Alexandru gagniuc <mr.nuke.me@gmail.com> Tested-by: Larry Finger <Larry.Finger@lwfinger.net> Cc: stable@vger.kernel.org Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230417140358.2240429-2-s.hauer@pengutronix.de
2023-04-20wifi: rtw88: 8822c: add iface combinationPo-Hao Huang
Allow 8822c to operate two interface concurrently, only 1 AP mode plus 1 station mode under same frequency is supported. Combination of other types will not be added until requested. Signed-off-by: Po-Hao Huang <phhuang@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/20230414121331.18062-1-pkshih@realtek.com
2023-04-20wifi: rtw88: handle station mode concurrent scan with AP modePo-Hao Huang
This patch allows vifs sharing same hardware with the AP mode vif to do scan, do note that this could lead to packet loss or disconnection of the AP's clients. Since we don't have chanctx, update scan info upon set channel so bandwidth changes won't go unnoticed and get misconfigured after scan. Download beacon just before scan starts to allow hardware to get proper content to do beaconing. Last, beacons should only be transmitted in AP's operating channel. Turn related beacon functions off while we're in other channels so the receiving stations won't get confused. Signed-off-by: Po-Hao Huang <phhuang@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/20230414121323.18008-1-pkshih@realtek.com
2023-04-20wifi: rtw88: prevent scan abort with other VIFsPo-Hao Huang
Only abort scan with current scanning VIF. If we have more than one interface, we could call rtw_hw_scan_abort() with the wrong VIF as input. This avoids potential null pointer being accessed when actually the other VIF is scanning. Signed-off-by: Po-Hao Huang <phhuang@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/20230414121312.17954-1-pkshih@realtek.com
2023-04-20wifi: rtw88: refine reserved page flow for AP modePo-Hao Huang
Only gather reserved pages from AP interface after it has started. Or else ieee80211_beacon_get_*() returns NULL and causes other VIFs' reserved pages fail to download. Update location of current reserved page after beacon renews so offsets changed by beacon can be recognized. Signed-off-by: Po-Hao Huang <phhuang@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/20230414121300.17900-1-pkshih@realtek.com
2023-04-20wifi: rtw88: disallow PS during AP modePo-Hao Huang
Firmware can't support PS mode during AP mode, so disallow this case. Signed-off-by: Po-Hao Huang <phhuang@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/20230414121135.17828-5-pkshih@realtek.com
2023-04-20wifi: rtw88: 8822c: extend reserved page numberPo-Hao Huang
Extend 8822c's reserved page number to accommodate additional required pages. Reserved page is an area of memory in the FIFO dedicated for special purposes. Previously only one interface is supported so 8 pages should suffice, extend it so we can support 2 interfaces concurrently. Signed-off-by: Po-Hao Huang <phhuang@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/20230414121135.17828-4-pkshih@realtek.com
2023-04-20wifi: rtw88: add port switch for AP modePo-Hao Huang
Switch port settings if AP mode does not start on port 0 because of hardware limitation. For some ICs, beacons on ports other than zero could misbehave and do not issue properly, to fix this we change AP VIFs to port zero when multiple interfaces is active. Signed-off-by: Po-Hao Huang <phhuang@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/20230414121135.17828-3-pkshih@realtek.com
2023-04-20wifi: rtw88: add bitmap for dynamic port settingsPo-Hao Huang
In order to support multiple interfaces, multiple port settings will be required. Current code always uses port 0 and should be changed. Declare a bitmap with size equal to hardware port number to record the current usage. Signed-off-by: Po-Hao Huang <phhuang@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/20230414121135.17828-2-pkshih@realtek.com
2023-04-20wifi: rtw89: mac: use regular int as return type of DLE buffer requestPing-Ke Shih
The function to request DLE (data link engine) buffer uses 'u16' as return value that mixes error code, so change it to 'int' as regular error code. Also, treat invalid register value (0xfff) as an error. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230414082228.30766-1-pkshih@realtek.com
2023-04-20wifi: mac80211: remove return value check of debugfs_create_dir()Yingsha Xu
Smatch complains that: debugfs_hw_add() warn: 'statsd' is an error pointer or valid Debugfs checks are generally not supposed to be checked for errors and it is not necessary here. Just delete the dead code. Signed-off-by: Yingsha Xu <ysxu@hust.edu.cn> Reviewed-by: Dongliang Mu <dzm91@hust.edu.cn> Link: https://lore.kernel.org/r/20230419104548.30124-1-ysxu@hust.edu.cn Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-04-20wifi: iwlwifi: mvm: fix RFKILL report when driver is going downAvraham Stern
When CSME takes ownership, the driver sets RFKILL on, and this triggers driver unload and sending the confirmation SAP message. However, when IWL_MVM_MEI_REPORT_RFKILL is set, RFKILL was not reported and as a result, the driver did not confirm the ownership transition. Fix it. Signed-off-by: Avraham Stern <avraham.stern@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230418122405.29ac3cd3df73.I96b32bc274bfe1e3871e54d3fa29c7ac4f40446f@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-04-20wifi: iwlwifi: mei: re-ask for ownership after it was taken by CSMEAvraham Stern
When the host disconnects from the AP CSME takes ownership right away. Since the driver never asks for ownership again wifi is left in rfkill until CSME releases the NIC, although in many cases the host could re-connect shortly after the disconnection. To allow the host to recover from occasional disconnection, re-ask for ownership to let the host connect again. Allow one minute before re-asking for ownership to avoid too frequent ownership transitions. Signed-off-by: Avraham Stern <avraham.stern@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230418122405.a6c6ebc48f2d.I8a17003b86e71b3567521cc69864b9cbe9553ea9@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-04-20wifi: iwlwifi: mei: make mei filtered scan more aggressiveAvraham Stern
When mei filtered scan is performed, it must find the AP on the first scan, otherwise CSME will take the ownership of the NIC. Make this scan more aggressive by scanning the channel the AP is supposed to be on (as reported by CSME) several times. Signed-off-by: Avraham Stern <avraham.stern@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230418122405.47e383b10b18.I14340a118acdb19ecb7214e7ff413054c77bd99c@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-04-20wifi: iwlwifi: modify scan request and results when in link protectionAvraham Stern
When CSME is connected and has link protection set, the driver must connect to the same AP CSME is connected to. When in link protection, modify scan request parameters to include only the channel of the AP CSME is connected to and scan for the same SSID. In addition, filter the scan results to include only results from the same AP. This will make sure the driver will connect to the same AP and will do it fast enough to keep the session alive. Signed-off-by: Avraham Stern <avraham.stern@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230418122405.c1b55de3d704.I3895eebe18b3b672607695c887d728e113fc85ec@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-04-20wifi: iwlwifi: mvm: enable support for MLO APIsGregory Greenman
Enable driver's support for MLO APIs to unlock this functionality. Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Link: https://lore.kernel.org/r/20230418122405.0ae0dd6f0481.Iec993cf0f28eacb2483fb9d1e755b0b2fd62e163@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-04-20wifi: iwlwifi: mvm: prefer RCU_INIT_POINTER()Johannes Berg
For constant values we don't need rcu_assign_pointer(), use RCU_INIT_POINTER() instead. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230418122405.7b400d21a27f.Iccdef9d777677390a9881c88b06c0ed13a83d978@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-04-20wifi: iwlwifi: mvm: fix potential memory leakJohannes Berg
If we do get multiple notifications from firmware, then we might have allocated 'notif', but don't free it. Fix that by checking for duplicates before allocation. Fixes: 4da46a06d443 ("wifi: iwlwifi: mvm: Add support for wowlan info notification") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230418122405.116758321cc4.I8bdbcbb38c89ac637eaa20dda58fa9165b25893a@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-04-20wifi: iwlwifi: fw: fix argument to efi.get_variableAlon Giladi
We should pass the newly allocated data to fill. Signed-off-by: Alon Giladi <alon.giladi@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230418122405.aaa6d8874442.I734841c71aad9564cb22c50f2737aaff489fadaf@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-04-20wifi: iwlwifi: mvm: fix MIC removal confusionJohannes Berg
The RADA/firmware collaborate on MIC stripping in the following way: - the firmware fills the IWL_RX_MPDU_MFLG1_MIC_CRC_LEN_MASK value for how many words need to be removed at the end of the frame, CRC and, if decryption was done, MIC - if the RADA is active, it will - remove that much from the end of the frame - zero the value in IWL_RX_MPDU_MFLG1_MIC_CRC_LEN_MASK As a consequence, the only thing the driver should need to do is to - unconditionally tell mac80211 that the MIC was removed if decryption was already done - remove as much as IWL_RX_MPDU_MFLG1_MIC_CRC_LEN_MASK says at the end of the frame, since either RADA did it and then the value is 0, or RADA was disabled and then the value is whatever should be removed to strip both CRC & MIC However, all this code was historically grown and getting a bit confused. Originally, we were indicating that the MIC was not stripped, which is the version of the code upstreamed in commit 780e87c29e77 ("iwlwifi: mvm: add 9000 series RX processing") which indicated RX_FLAG_DECRYPTED in iwl_mvm_rx_crypto(). We later had a commit to change that to also indicate that the MIC was stripped, adding RX_FLAG_MIC_STRIPPED. However, this was then "fixed" later to only do that conditionally on RADA being enabled, since otherwise RADA didn't strip the MIC bytes yet. At the time, we were also always including the FCS if the RADA was not enabled, so that was still broken wrt. the FCS if the RADA isn't enabled - but that's a pretty rare case. Notably though, it does happen for management frames, where we do need to remove the MIC and CRC but the RADA is disabled. Later, in commit 40a0b38d7a7f ("iwlwifi: mvm: Fix calculation of frame length"), we changed this again, upstream this was just a single commit, but internally it was split into first the correct commit and then an additional fix that reduced the number of bytes that are removed by crypt_len. Note that this is clearly wrong since crypt_len indicates the length of the PN header (always 8), not the length of the MIC (8 or 16 depending on algorithm). However, this additional fix mostly canceled the other bugs, apart from the confusion about the size of the MIC. To fix this correctly, remove all those additional workarounds. We really should always indicate to mac80211 the MIC was stripped (it cannot use it anyway if decryption was already done), and also always actually remove it and the CRC regardless of the RADA being enabled or not. That's simple though, the value indicated in the metadata is zeroed by the RADA if it's enabled and used the value, so there's no need to check if it's enabled or not. Notably then, this fixes the MIC size confusion, letting us receive GCMP-256 encrypted management frames correctly that would otherwise be reported to mac80211 8 bytes too short since the RADA is turned off for them, crypt_len is 8, but the MIC size is 16, so when we do the adjustment based on IWL_RX_MPDU_MFLG1_MIC_CRC_LEN_MASK (which indicates 20 bytes to remove) we remove 12 bytes but indicate then to mac80211 the MIC is still present, so mac80211 again removes the MIC of 16 bytes, for an overall removal of 28 rather than 20 bytes. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230418122405.81345b6ab0cd.Ibe0348defb6cce11c99929a1f049e60b5cfc150c@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-04-20wifi: iwlwifi: fw: fix memory leak in debugfsJohannes Berg
Fix a memory leak that occurs when reading the fw_info file all the way, since we return NULL indicating no more data, but don't free the status tracking object. Fixes: 36dfe9ac6e8b ("iwlwifi: dump api version in yaml format") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230418122405.239e501b3b8d.I4268f87809ef91209cbcd748eee0863195e70fa2@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-04-20wifi: iwlwifi: Update support for b0 versionMukesh Sisodiya
Add support for B0 version of MAC of MR device Signed-off-by: Mukesh Sisodiya <mukesh.sisodiya@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230418122405.5dca1ea7a0cf.I87932e1e216a1940eeae8824071ecb777f4c034f@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-04-20net: bridge: switchdev: don't notify FDB entries with "master dynamic"Vladimir Oltean
There is a structural problem in switchdev, where the flag bits in struct switchdev_notifier_fdb_info (added_by_user, is_local etc) only represent a simplified / denatured view of what's in struct net_bridge_fdb_entry :: flags (BR_FDB_ADDED_BY_USER, BR_FDB_LOCAL etc). Each time we want to pass more information about struct net_bridge_fdb_entry :: flags to struct switchdev_notifier_fdb_info (here, BR_FDB_STATIC), we find that FDB entries were already notified to switchdev with no regard to this flag, and thus, switchdev drivers had no indication whether the notified entries were static or not. For example, this command: ip link add br0 type bridge && ip link set swp0 master br0 bridge fdb add dev swp0 00:01:02:03:04:05 master dynamic has never worked as intended with switchdev. It causes a struct net_bridge_fdb_entry to be passed to br_switchdev_fdb_notify() which has a single flag set: BR_FDB_ADDED_BY_USER. This is further passed to the switchdev notifier chain, where interested drivers have no choice but to assume this is a static (does not age) and sticky (does not migrate) FDB entry. So currently, all drivers offload it to hardware as such, as can be seen below ("offload" is set). bridge fdb get 00:01:02:03:04:05 dev swp0 master 00:01:02:03:04:05 dev swp0 offload master br0 The software FDB entry expires $ageing_time centiseconds after the kernel last sees a packet with this MAC SA, and the bridge notifies its deletion as well, so it eventually disappears from hardware too. This is a problem, because it is actually desirable to start offloading "master dynamic" FDB entries correctly - they should expire $ageing_time centiseconds after the *hardware* port last sees a packet with this MAC SA - and this is how the current incorrect behavior was discovered. With an offloaded data plane, it can be expected that software only sees exception path packets, so an otherwise active dynamic FDB entry would be aged out by software sooner than it should. With the change in place, these FDB entries are no longer offloaded: bridge fdb get 00:01:02:03:04:05 dev swp0 master 00:01:02:03:04:05 dev swp0 master br0 and this also constitutes a better way (assuming a backport to stable kernels) for user space to determine whether the kernel has the capability of doing something sane with these or not. As opposed to "master dynamic" FDB entries, on the current behavior of which no one currently depends on (which can be deduced from the lack of kselftests), Ido Schimmel explains that entries with the "extern_learn" flag (BR_FDB_ADDED_BY_EXT_LEARN) should still be notified to switchdev, since the spectrum driver listens to them (and this is kind of okay, because although they are treated identically to "static", they are expected to not age, and to roam). Fixes: 6b26b51b1d13 ("net: bridge: Add support for notifying devices about FDB add/del") Link: https://lore.kernel.org/netdev/20230327115206.jk5q5l753aoelwus@skbuf/ Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Tested-by: Ido Schimmel <idosch@nvidia.com> Link: https://lore.kernel.org/r/20230418155902.898627-1-vladimir.oltean@nxp.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-04-19Merge branch 'Access variable length array relaxed for integer type'Alexei Starovoitov
Feng zhou says: ==================== From: Feng Zhou <zhoufeng.zf@bytedance.com> Add support for integer type of accessing variable length array. Add a selftest to check it. ==================== Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2023-04-19selftests/bpf: Add test to access integer type of variable arrayFeng Zhou
Add prog test for accessing integer type of variable array in tracing program. In addition, hook load_balance function to access sd->span[0], only to confirm whether the load is successful. Because there is no direct way to trigger load_balance call. Co-developed-by: Chengming Zhou <zhouchengming@bytedance.com> Signed-off-by: Chengming Zhou <zhouchengming@bytedance.com> Signed-off-by: Feng Zhou <zhoufeng.zf@bytedance.com> Link: https://lore.kernel.org/r/20230420032735.27760-3-zhoufeng.zf@bytedance.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2023-04-19bpf: support access variable length array of integer typeFeng Zhou
After this commit: bpf: Support variable length array in tracing programs (9c5f8a1008a1) Trace programs can access variable length array, but for structure type. This patch adds support for integer type. Example: Hook load_balance struct sched_domain { ... unsigned long span[]; } The access: sd->span[0]. Co-developed-by: Chengming Zhou <zhouchengming@bytedance.com> Signed-off-by: Chengming Zhou <zhouchengming@bytedance.com> Signed-off-by: Feng Zhou <zhoufeng.zf@bytedance.com> Link: https://lore.kernel.org/r/20230420032735.27760-2-zhoufeng.zf@bytedance.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2023-04-19Revert "net/mlx5: Enable management PF initialization"Jakub Kicinski
This reverts commit fe998a3c77b9f989a30a2a01fb00d3729a6d53a4. Paul reports that it causes a regression with IB on CX4 and FW 12.18.1000. In addition I think that the concept of "management PF" is not fully accepted and requires a discussion. Fixes: fe998a3c77b9 ("net/mlx5: Enable management PF initialization") Reported-by: Paul Moore <paul@paul-moore.com> Link: https://lore.kernel.org/all/CAHC9VhQ7A4+msL38WpbOMYjAqLp0EtOjeLh4Dc6SQtD6OUvCQg@mail.gmail.com/ Link: https://lore.kernel.org/r/20230413222547.56901-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-04-19Merge branch 'another-crack-at-a-handshake-upcall-mechanism'Jakub Kicinski
Chuck Lever says: ==================== Another crack at a handshake upcall mechanism Here is v10 of a series to add generic support for transport layer security handshake on behalf of kernel socket consumers (user space consumers use a security library directly, of course). A summary of the purpose of these patches is archived here: https://lore.kernel.org/netdev/1DE06BB1-6BA9-4DB4-B2AA-07DE532963D6@oracle.com/ The first patch in the series applies to the top-level .gitignore file to address the build warnings reported a few days ago. I intend to submit that separately. I'd like you to consider taking the rest of this series for v6.4. The full patch set to support SunRPC with TLSv1.3 is available in the topic-rpc-with-tls-upcall branch here, based on net-next/main: https://git.kernel.org/pub/scm/linux/kernel/git/cel/linux.git This patch set includes support for in-transit confidentiality and peer authentication for both the Linux NFS client and server. A user space handshake agent for TLSv1.3 to go along with the kernel patches is available in the "main" branch here: https://github.com/oracle/ktls-utils ==================== Link: https://lore.kernel.org/r/168174169259.9520.1911007910797225963.stgit@91.116.238.104.host.secureserver.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-04-19net/handshake: Add Kunit tests for the handshake consumer APIChuck Lever
These verify the API contracts and help exercise lifetime rules for consumer sockets and handshake_req structures. One way to run these tests: ./tools/testing/kunit/kunit.py run --kunitconfig ./net/handshake/.kunitconfig Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-04-19net/handshake: Add a kernel API for requesting a TLSv1.3 handshakeChuck Lever
To enable kernel consumers of TLS to request a TLS handshake, add support to net/handshake/ to request a handshake upcall. This patch also acts as a template for adding handshake upcall support for other kernel transport layer security providers. Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-04-19net/handshake: Create a NETLINK service for handling handshake requestsChuck Lever
When a kernel consumer needs a transport layer security session, it first needs a handshake to negotiate and establish a session. This negotiation can be done in user space via one of the several existing library implementations, or it can be done in the kernel. No in-kernel handshake implementations yet exist. In their absence, we add a netlink service that can: a. Notify a user space daemon that a handshake is needed. b. Once notified, the daemon calls the kernel back via this netlink service to get the handshake parameters, including an open socket on which to establish the session. c. Once the handshake is complete, the daemon reports the session status and other information via a second netlink operation. This operation marks that it is safe for the kernel to use the open socket and the security session established there. The notification service uses a multicast group. Each handshake mechanism (eg, tlshd) adopts its own group number so that the handshake services are completely independent of one another. The kernel can then tell via netlink_has_listeners() whether a handshake service is active and prepared to handle a handshake request. A new netlink operation, ACCEPT, acts like accept(2) in that it instantiates a file descriptor in the user space daemon's fd table. If this operation is successful, the reply carries the fd number, which can be treated as an open and ready file descriptor. While user space is performing the handshake, the kernel keeps its muddy paws off the open socket. A second new netlink operation, DONE, indicates that the user space daemon is finished with the socket and it is safe for the kernel to use again. The operation also indicates whether a session was established successfully. Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-04-19.gitignore: Do not ignore .kunitconfig filesChuck Lever
Circumvent the .gitignore wildcard to avoid warnings about ignored .kunitconfig files. As far as I can tell, the warnings are harmless and these files are not actually ignored. Reported-by: kernel test robot <lkp@intel.com> Link: https://lore.kernel.org/oe-kbuild-all/202304142337.jc4oUrov-lkp@intel.com/ Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-04-19Merge tag 'ipsec-next-2023-04-19' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next Steffen Klassert says: ==================== ipsec-next 2023-04-19 1) Remove inner/outer modes from input/output path. These are not needed anymore. From Herbert Xu. * tag 'ipsec-next-2023-04-19' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next: xfrm: Remove inner/outer modes from output path xfrm: Remove inner/outer modes from input path ==================== Link: https://lore.kernel.org/r/20230419075300.452227-1-steffen.klassert@secunet.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-04-19dt-bindings: net: ethernet: Fix JSON pointer referencesRob Herring
A JSON pointer reference (the part after the "#") must start with a "/". Conversely, references to the entire document must not have a trailing "/" and should be just a "#". The existing jsonschema package allows these, but coming changes make allowed "$ref" URIs stricter and throw errors on these references. Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20230418150628.1528480-1-robh@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-04-19net: micrel: Update the list of supported physHoratiu Vultur
At the beginning of the file micrel.c there is list of supported PHYs. Extend this list with the following PHYs lan8841, lan8814 and lan8804, as these PHYs were added but the list was not updated. Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20230418124713.2221451-1-horatiu.vultur@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-04-19net: stmmac: dwmac-meson8b: Avoid cast to incompatible function typeSimon Horman
Rather than casting clk_disable_unprepare to an incompatible function type provide a trivial wrapper with the correct signature for the use-case. Reported by clang-16 with W=1: drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c:276:6: error: cast from 'void (*)(struct clk *)' to 'void (*)(void *)' converts to incompatible function type [-Werror,-Wcast-function-type-strict] (void(*)(void *))clk_disable_unprepare, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ No functional change intended. Compile tested only. Signed-off-by: Simon Horman <horms@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Link: https://lore.kernel.org/r/20230418-dwmac-meson8b-clk-cb-cast-v1-1-e892b670cbbb@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-04-19Merge tag 'for-netdev' of ↵Jakub Kicinski
https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf Daniel Borkmann says: ==================== bpf 2023-04-19 We've added 3 non-merge commits during the last 6 day(s) which contain a total of 3 files changed, 34 insertions(+), 9 deletions(-). The main changes are: 1) Fix a crash on s390's bpf_arch_text_poke() under a NULL new_addr, from Ilya Leoshkevich. 2) Fix a bug in BPF verifier's precision tracker, from Daniel Borkmann and Andrii Nakryiko. 3) Fix a regression in veth's xdp_features which led to a broken BPF CI selftest, from Lorenzo Bianconi. * tag 'for-netdev' of https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf: bpf: Fix incorrect verifier pruning due to missing register precision taints veth: take into account peer device for NETDEV_XDP_ACT_NDO_XMIT xdp_features flag s390/bpf: Fix bpf_arch_text_poke() with new_addr == NULL ==================== Link: https://lore.kernel.org/r/20230419195847.27060-1-daniel@iogearbox.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-04-19MAINTAINERS: Resume MPTCP co-maintainer roleMat Martineau
I'm returning to the MPTCP maintainer role I held for most of the subsytem's history. This time I'm using my kernel.org email address. Acked-by: Matthieu Baerts <matthieu.baerts@tessares.net> Link: https://lore.kernel.org/mptcp/af85e467-8d0a-4eba-b5f8-e2f2c5d24984@tessares.net/ Signed-off-by: Mat Martineau <martineau@kernel.org> Link: https://lore.kernel.org/r/20230418231318.115331-1-martineau@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-04-19mailmap: add entries for Mat MartineauMatthieu Baerts
Map Mat's old corporate addresses to his kernel.org one. Reviewed-by: Mat Martineau <martineau@kernel.org> Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net> Link: https://lore.kernel.org/r/20230418-upstream-net-20230418-mailmap-mat-v1-1-13ca5dc83037@tessares.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-04-19Merge branch '40GbE' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue Tony Nguyen says: ==================== Intel Wired LAN Driver Updates 2023-04-17 (i40e) This series contains updates to i40e only. Alex moves setting of active filters to occur under lock and checks/takes error path in rebuild if re-initializing the misc interrupt vector failed. * '40GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue: i40e: fix i40e_setup_misc_vector() error handling i40e: fix accessing vsi->active_filters without holding lock ==================== Reviewed-by: Simon Horman <simon.horman@corigine.com> Link: https://lore.kernel.org/r/20230417205245.1030733-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-04-19Merge tag 'mm-hotfixes-stable-2023-04-19-16-36' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Pull misc fixes from Andrew Morton: "22 hotfixes. 19 are cc:stable and the remainder address issues which were introduced during this merge cycle, or aren't considered suitable for -stable backporting. 19 are for MM and the remainder are for other subsystems" * tag 'mm-hotfixes-stable-2023-04-19-16-36' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: (22 commits) nilfs2: initialize unused bytes in segment summary blocks mm: page_alloc: skip regions with hugetlbfs pages when allocating 1G pages mm/mmap: regression fix for unmapped_area{_topdown} maple_tree: fix mas_empty_area() search maple_tree: make maple state reusable after mas_empty_area_rev() mm: kmsan: handle alloc failures in kmsan_ioremap_page_range() mm: kmsan: handle alloc failures in kmsan_vmap_pages_range_noflush() tools/Makefile: do missed s/vm/mm/ mm: fix memory leak on mm_init error handling mm/page_alloc: fix potential deadlock on zonelist_update_seq seqlock kernel/sys.c: fix and improve control flow in __sys_setres[ug]id() Revert "userfaultfd: don't fail on unrecognized features" writeback, cgroup: fix null-ptr-deref write in bdi_split_work_to_wbs maple_tree: fix a potential memory leak, OOB access, or other unpredictable bug tools/mm/page_owner_sort.c: fix TGID output when cull=tg is used mailmap: update jtoppins' entry to reference correct email mm/mempolicy: fix use-after-free of VMA iterator mm/huge_memory.c: warn with pr_warn_ratelimited instead of VM_WARN_ON_ONCE_FOLIO mm/mprotect: fix do_mprotect_pkey() return on error mm/khugepaged: check again on anon uffd-wp during isolation ...
generated by cgit (git 2.34.1) at 2025-09-11 15:01:00 +0000