summaryrefslogtreecommitdiffstats
path: root/drivers/net (follow)
Commit message (Collapse)AuthorAgeFilesLines
* wifi: mac80211_hwsim: fix clang-specific fortify warningDmitry Antipov2023-09-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When compiling with clang 16.0.6 and CONFIG_FORTIFY_SOURCE=y, I've noticed the following (somewhat confusing due to absence of an actual source code location): In file included from drivers/net/wireless/virtual/mac80211_hwsim.c:18: In file included from ./include/linux/slab.h:16: In file included from ./include/linux/gfp.h:7: In file included from ./include/linux/mmzone.h:8: In file included from ./include/linux/spinlock.h:56: In file included from ./include/linux/preempt.h:79: In file included from ./arch/x86/include/asm/preempt.h:9: In file included from ./include/linux/thread_info.h:60: In file included from ./arch/x86/include/asm/thread_info.h:53: In file included from ./arch/x86/include/asm/cpufeature.h:5: In file included from ./arch/x86/include/asm/processor.h:23: In file included from ./arch/x86/include/asm/msr.h:11: In file included from ./arch/x86/include/asm/cpumask.h:5: In file included from ./include/linux/cpumask.h:12: In file included from ./include/linux/bitmap.h:11: In file included from ./include/linux/string.h:254: ./include/linux/fortify-string.h:592:4: warning: call to '__read_overflow2_field' declared with 'warning' attribute: detected read beyond size of field (2nd parameter); maybe use struct_group()? [-Wattribute-warning] __read_overflow2_field(q_size_field, size); The compiler actually complains on 'mac80211_hwsim_get_et_strings()' where fortification logic inteprets call to 'memcpy()' as an attempt to copy the whole 'mac80211_hwsim_gstrings_stats' array from its first member and so issues an overread warning. This warning may be silenced by passing an address of the whole array and not the first member to 'memcpy()'. Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Link: https://lore.kernel.org/r/20230829094140.234636-1-dmantipov@yandex.ru Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* wifi: cfg80211: remove wdev mutexJohannes Berg2023-09-113-6/+6
| | | | | | | | | Since we're now protecting everything with the wiphy mutex (and were really using it for almost everything before), there's no longer any real reason to have a separate wdev mutex. It may feel better, but really has no value. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* wifi: rtw89: 8922a: set memory heap address for secure firmwarePing-Ke Shih2023-09-072-0/+6
| | | | | | | | | | Secure firmware is protected by public/private key cryptography. To help firmware self verify integrity, configure a heap address for these data before downloading firmware. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230901073956.54203-9-pkshih@realtek.com
* wifi: rtw89: fw: refine download flow to support variant firmware suitsPing-Ke Shih2023-09-071-19/+65
| | | | | | | | | | | | | | | To support download more than one firmware, adjust flow to download firmware by unit of firmware suit. Then, flow becomes 1. initial setup - disable/enable_wcpu 2. for all firmware suits 2.1. download WiFi CPU, and check ready 2.2. download BB MCU, and check ready 3. check status code to make sure all ready Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230901073956.54203-8-pkshih@realtek.com
* wifi: rtw89: 8922a: add chip_ops::bb_preinit to enable BB before downloading ↵Ping-Ke Shih2023-09-076-0/+20
| | | | | | | | | | | firmware Before downloading firmware for BB MCU, call this ops to enable baseband hardware. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230901073956.54203-7-pkshih@realtek.com
* wifi: rtw89: fw: propagate an argument include_bb for BB MCU firmwarePing-Ke Shih2023-09-0712-14/+31
| | | | | | | | | | | Though WiFi 7 chips need BB MCU firmware, we don't download it in probe stage. Instead, only bring interface up under normal operation or WoWLAN mode. So, add an argument to assist download flow to setup download settings properly. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230901073956.54203-6-pkshih@realtek.com
* wifi: rtw89: fw: add checking type for variant type of firmwarePing-Ke Shih2023-09-076-15/+45
| | | | | | | | | | | | | | For WiFi 6 chips, there is only single one firmware i.e. WiFi CPU firmware, so no need an argument to discriminate them. For WiFi 7 chips, BB MCU firmware is introduced, and we need to check it ready after downloading. For each type of firmware, we need to check corresponding hardware ready bit. After downloading all firmware, check status code to determine if all things are ready. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230901073956.54203-5-pkshih@realtek.com
* wifi: rtw89: fw: implement supported functions of download firmware for WiFi ↵Ping-Ke Shih2023-09-072-0/+238
| | | | | | | | | | | | 7 chips To work with generalized flow of download firmware, implement WiFi 7 specific functions to support it. These functions include disable/enable WiFi CPU, status of path ready, and status of firmware. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230901073956.54203-4-pkshih@realtek.com
* wifi: rtw89: fw: generalize download firmware flow by mac_gen pointersPing-Ke Shih2023-09-073-18/+29
| | | | | | | | | | In order to reuse the flow to download firmware, define some mac_gen::ops to implement them for WiFi 6 and 7 chips individually. This 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://lore.kernel.org/r/20230901073956.54203-3-pkshih@realtek.com
* wifi: rtw89: fw: move polling function of firmware path ready to an ↵Ping-Ke Shih2023-09-074-9/+17
| | | | | | | | | | | | | | | individual function To download firmware, we need to check path is ready. There are two kinds of path -- one is to download firmware header, and the other is to download firmware body. Since the polling method is different from WiFi 7 chips, make it to be an individual function, and then we can reuse the download flow. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230901073956.54203-2-pkshih@realtek.com
* wifi: rtw89: mcc: trigger FW to start/stop MCCZong-Zhe Yang2023-09-071-0/+173
| | | | | | | | | | | | According to Wi-Fi/BT roles' settings, we fill corresponding H2Cs (host to chip packets). Then, following MCC (multi-channel concurrency) pattern, we send these H2Cs as planned. Eventually, the trigger H2Cs will be sent to tell FW to really start/stop MCC. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230831053133.24015-7-pkshih@realtek.com
* wifi: rtw89: fix typo of rtw89_fw_h2c_mcc_macid_bitmap()Zong-Zhe Yang2023-09-072-2/+2
| | | | | | | | | | Fix a typo where `bitamp` should be `bitmap`. Don't change functionality at all. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230831053133.24015-6-pkshih@realtek.com
* wifi: rtw89: mcc: decide pattern and calculate parametersZong-Zhe Yang2023-09-072-0/+235
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After the previous works, we can now expand and display the MCC pattern in more detail, as shown below. |< MCC interval >| |< duration ref >| (if mid bt) |< duration aux >| (if tail bt) | |<tob ref >|< toa ref>| ... |<tob aux >|< toa aux>| ... | V V tbtt ref tbtt aux |< beacon offset >| (where tob means `time offset behind` and toa means `time offset ahead`) There are two key points. 1. decide position of BT slot if MCC pattern needs to handle BT duration. 2. calculate all parameters related to tob and toa in MCC pattern. For point (1), when BT duration needs to be handled, BT position will rely on beacon offset, either middle or tail. For point (2), to ensure durations of the Wi-Fi roles cover their beacons, we have to calculate tob and toa for them according to their TBTT. And, there are two strategies to calculate parameters, strict and loose. In strict pattern, all parameters take HW time into account as limitation. But, the strict calculation are not always successful. In loose pattern, it only tries to give positive parameters to reference role and doesn't care much about auxiliary role. If unfortunately auxiliary role gets negative parameters in loose pattern, FW will be notified and then deal with it. So, the loose calculation won't fail. In general, we always try strict pattern cases before using a loose pattern. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230831053133.24015-5-pkshih@realtek.com
* wifi: rtw89: mcc: consider and determine BT durationZong-Zhe Yang2023-09-071-0/+169
| | | | | | | | | | | | | | | | | | | | Before calculating MCC pattern, we have to determine whether to handle BT duration in it or not. The decision will depend on the channels that Wi-Fi roles use. And, we have three cases shown below. 1. non-2GHz + non-2GHz 2. non-2GHz + 2GHz (different band) 3. 2GHz + 2GHz (dual 2GHz) For case (1), we don't care BT duration in MCC pattern. For case (2), we still don't care BT duration in MCC pattern. Instead, we try to satisfy it by modifying duration of Wi-Fi role on non-2GHz channel. For case (3), we need to modify Wi-Fi durations and also need to handle BT duration in MCC pattern. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230831053133.24015-4-pkshih@realtek.com
* wifi: rtw89: mcc: fill fundamental configurationsZong-Zhe Yang2023-09-073-0/+187
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We determine the fundamental settings shown below. |< MCC interval >| |< duration ref >|< duration aux >| | | | | |< beacon offset >| | | V V (tbtt ref) (tbtt aux) (where `ref` (reference) and `aux` (auxiliary) mean the two MCC roles) Based on MCC mode (GO+STA or GC+STA), we fill configurations of MCC interval and beacon offset. And, we make sure each MCC role have a basically required duration in the MCC interval. The beacon offset mentioned above is a parameter for further MCC pattern calculation. If MCC is in GC+STA mode, we will calculate the real beacon offset through TSFs shown in beacons of both MCC roles. Otherwise, we will use a default beacon offset, and make GO sync STA's TSF timer with this offset. MCC pattern calculation will break down each MCC role's duration in more detail. We will implement it in the following. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230831053133.24015-3-pkshih@realtek.com
* wifi: rtw89: mcc: initialize start flowZong-Zhe Yang2023-09-074-0/+502
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We prepare to support TDMA-based MCC (multi-channel concurrency) which allows two kinds of modes below. * P2P GO + normal STA * P2P GC + normal STA Each mode has two vif and two chanctx. Then, each vif binds one separate chanctx and becomes one MCC role. We name the two MCC roles as follows. * MCC role - reference (ref) We calculate the baseline of our TDMA things accodring to its info, e.g. TBTT. In normal case, it will be put at the first slot of TDMA. * MCC role - auxiliary (aux) MCC state machine will be running in FW eventually, but before that, we have to fill and calculate things that are needed by FW. We fill the information of MCC role according to its vif and its chanctx. Then, we calculate the start time for MCC. Note that the parameters used in the calculation now is assigned by default rules. The precise parameters for better MCC behavior will be derived in the following. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230831053133.24015-2-pkshih@realtek.com
* wifi: rtw89: 8852c: Fix TSSI causes transmit power inaccuracyKuan-Chung Chen2023-09-043-23/+46
| | | | | | | | | | Modify TSSI ADC FIFO Clock follow RX ADC Clock can avoid transmit power inaccuracy. Signed-off-by: Kuan-Chung Chen <damon.chen@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/20230830092849.153251-3-pkshih@realtek.com
* wifi: rtw89: 8852c: Update bandedge parameters for better performanceKuan-Chung Chen2023-09-043-3/+15
| | | | | | | | | | | TSSI configures bandedge to TX proper waveform, these new bandedge parameters improve the accuracy of transmit power compensation. This helps to avoid throughput degradation. Signed-off-by: Kuan-Chung Chen <damon.chen@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/20230830092849.153251-2-pkshih@realtek.com
* wifi: plfxlc: fix clang-specific fortify warningDmitry Antipov2023-09-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When compiling with clang 16.0.6 and CONFIG_FORTIFY_SOURCE=y, I've noticed the following (somewhat confusing due to absence of an actual source code location): In file included from drivers/net/wireless/purelifi/plfxlc/mac.c:6: In file included from ./include/linux/netdevice.h:24: In file included from ./include/linux/timer.h:6: In file included from ./include/linux/ktime.h:24: In file included from ./include/linux/time.h:60: In file included from ./include/linux/time32.h:13: In file included from ./include/linux/timex.h:67: In file included from ./arch/x86/include/asm/timex.h:5: In file included from ./arch/x86/include/asm/processor.h:23: In file included from ./arch/x86/include/asm/msr.h:11: In file included from ./arch/x86/include/asm/cpumask.h:5: In file included from ./include/linux/cpumask.h:12: In file included from ./include/linux/bitmap.h:11: In file included from ./include/linux/string.h:254: ./include/linux/fortify-string.h:592:4: warning: call to '__read_overflow2_field' declared with 'warning' attribute: detected read beyond size of field (2nd parameter); maybe use struct_group()? [-Wattribute-warning] __read_overflow2_field(q_size_field, size); The compiler actually complains on 'plfxlc_get_et_strings()' where fortification logic inteprets call to 'memcpy()' as an attempt to copy the whole 'et_strings' array from its first member and so issues an overread warning. This warning may be silenced by passing an address of the whole array and not the first member to 'memcpy()'. Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230829094541.234751-1-dmantipov@yandex.ru
* wifi: rtl8xxxu: mark TOTOLINK N150UA V5/N150UA-B as testedZenm Chen2023-09-041-0/+1
| | | | | | | | | TOTOLINK N150UA V5/N150UA-B (VID=0x0bda, PID=0x2005) works fine with the rtl8xxxu driver, so mark as tested. Signed-off-by: Zenm Chen <zenmchen@gmail.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230829074358.14795-1-zenmchen@gmail.com
* wifi: rtw88: fix typo rtw8822cu_probePo-Hao Huang2023-09-041-2/+2
| | | | | | | | | | The probe function of 8822cu is misplaced to 8822bu, so we fix it. Just cosmetics, no changes in functionality. 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/20230825062404.50813-1-pkshih@realtek.com
* Merge branch '1GbE' of ↵Jakub Kicinski2023-08-2611-64/+210
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue Tony Nguyen says: ==================== Intel Wired LAN Driver Updates 2023-08-24 (igc, e1000e) This series contains updates to igc and e1000e drivers. Vinicius adds support for utilizing multiple PTP registers on igc. Sasha reduces interval time for PTM on igc and adds new device support on e1000e. * '1GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue: e1000e: Add support for the next LOM generation igc: Decrease PTM short interval from 10 us to 1 us igc: Add support for multiple in-flight TX timestamps ==================== Link: https://lore.kernel.org/r/20230824204418.1551093-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * e1000e: Add support for the next LOM generationSasha Neftin2023-08-245-0/+17
| | | | | | | | | | | | | | | | | | | | Add devices IDs for the next LOM generations that will be available on the next Intel Client platforms. This patch provides the initial support for these devices. Signed-off-by: Sasha Neftin <sasha.neftin@intel.com> Tested-by: Naama Meir <naamax.meir@linux.intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
| * igc: Decrease PTM short interval from 10 us to 1 usSasha Neftin2023-08-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | With the 10us interval, we were seeing PTM transactions take around 12us. Hardware team suggested this interval could be lowered to 1us which was confirmed with PCIe sniffer. With the 1us interval, PTM dialogs took around 2us. Suggested-by: Vinicius Costa Gomes <vinicius.gomes@intel.com> Signed-off-by: Sasha Neftin <sasha.neftin@intel.com> Tested-by: Muhammad Husaini Zulkifli <muhammad.husaini.zulkifli@intel.com> Reviewed-by: Muhammad Husaini Zulkifli <muhammad.husaini.zulkifli@intel.com> Tested-by: Naama Meir <naamax.meir@linux.intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
| * igc: Add support for multiple in-flight TX timestampsVinicius Costa Gomes2023-08-246-63/+192
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for using the four sets of timestamping registers that i225/i226 have available for TX. In some workloads, where multiple applications request hardware transmission timestamps, it was possible that some of those requests were denied because the only in use register was already occupied. This is also in preparation to future support for hardware timestamping with multiple PTP domains. With multiple domains chances of multiple TX timestamps being requested at the same time increase. Before: $ sudo ./ntpperf -i enp3s0 -m 10:22:22:22:22:21 -d 192.168.1.3 -s 172.18.0.0/16 -I -H -o 37 | responses | TX timestamp offset (ns) rate clients | lost invalid basic xleave | min mean max stddev 1000 100 0.00% 0.00% 0.00% 100.00% +1 +41 +73 13 1500 150 0.00% 0.00% 0.00% 100.00% +9 +49 +87 15 2250 225 0.00% 0.00% 0.00% 100.00% +9 +42 +79 13 3375 337 0.00% 0.00% 0.00% 100.00% +11 +46 +81 13 5062 506 0.00% 0.00% 0.00% 100.00% +7 +44 +80 13 7593 759 0.00% 0.00% 0.00% 100.00% +9 +44 +79 12 11389 1138 0.00% 0.00% 0.00% 100.00% +14 +51 +87 13 17083 1708 0.00% 0.00% 0.00% 100.00% +1 +41 +80 14 25624 2562 0.00% 0.00% 0.00% 100.00% +11 +50 +5107 51 38436 3843 0.00% 0.00% 0.00% 100.00% -2 +36 +7843 38 57654 5765 0.00% 0.00% 0.00% 100.00% +4 +42 +10503 69 86481 8648 0.00% 0.00% 0.00% 100.00% +11 +54 +5492 65 129721 12972 0.00% 0.00% 0.00% 100.00% +31 +2680 +6942 2606 194581 16384 16.79% 0.00% 0.87% 82.34% +73 +4444 +15879 3116 291871 16384 35.05% 0.00% 1.53% 63.42% +188 +5381 +17019 3035 437806 16384 54.95% 0.00% 2.55% 42.50% +233 +6302 +13885 2846 After: $ sudo ./ntpperf -i enp3s0 -m 10:22:22:22:22:21 -d 192.168.1.3 -s 172.18.0.0/16 -I -H -o 37 | responses | TX timestamp offset (ns) rate clients | lost invalid basic xleave | min mean max stddev 1000 100 0.00% 0.00% 0.00% 100.00% -20 +12 +43 13 1500 150 0.00% 0.00% 0.00% 100.00% -23 +18 +57 14 2250 225 0.00% 0.00% 0.00% 100.00% -2 +33 +67 13 3375 337 0.00% 0.00% 0.00% 100.00% +1 +38 +76 13 5062 506 0.00% 0.00% 0.00% 100.00% +9 +52 +93 14 7593 759 0.00% 0.00% 0.00% 100.00% +11 +47 +82 13 11389 1138 0.00% 0.00% 0.00% 100.00% -9 +27 +74 13 17083 1708 0.00% 0.00% 0.00% 100.00% -13 +25 +66 14 25624 2562 0.00% 0.00% 0.00% 100.00% -8 +28 +65 13 38436 3843 0.00% 0.00% 0.00% 100.00% -13 +28 +69 13 57654 5765 0.00% 0.00% 0.00% 100.00% -11 +32 +71 14 86481 8648 0.00% 0.00% 0.00% 100.00% +2 +44 +83 14 129721 12972 15.36% 0.00% 0.35% 84.29% -2 +2248 +22907 4252 194581 16384 42.98% 0.00% 1.98% 55.04% -4 +5278 +65039 5856 291871 16384 54.33% 0.00% 2.21% 43.46% -3 +6306 +22608 5665 We can see that with 4 registers, as expected, we are able to handle a increasing number of requests more consistently, but as soon as all registers are in use, the decrease in quality of service happens in a sharp step. Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Muhammad Husaini Zulkifli <muhammad.husaini.zulkifli@intel.com> Reviewed-by: Kurt Kanzenbach <kurt@linutronix.de> Tested-by: Naama Meir <naamax.meir@linux.intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
* | net: stmmac: convert half-duplex support to positive logicRussell King (Oracle)2023-08-261-6/+7
| | | | | | | | | | | | | | | | | | | | Rather than detecting when half-duplex is not supported, and clearing the MAC capabilities, reverse the if() condition and use it to set the capabilities instead. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://lore.kernel.org/r/E1qZAXn-005pUb-SP@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | net: stmmac: move priv->phylink_config.mac_managed_pmRussell King (Oracle)2023-08-261-1/+1
| | | | | | | | | | | | | | | | | | Move priv->phylink_config.mac_managed_pm to be along side the other phylink initialisations. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://lore.kernel.org/r/E1qZAXi-005pUV-Nq@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | net: stmmac: move xgmac specific phylink caps to dwxgmac2 coreRussell King (Oracle)2023-08-262-10/+10
| | | | | | | | | | | | | | | | | | Move the xgmac specific phylink capabilities to the dwxgmac2 support core. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://lore.kernel.org/r/E1qZAXd-005pUP-JL@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | net: stmmac: move gmac4 specific phylink capabilities to gmac4Russell King (Oracle)2023-08-262-3/+9
| | | | | | | | | | | | | | | | Move the setup of gmac4 speicifc phylink capabilities into gmac4 code. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://lore.kernel.org/r/E1qZAXY-005pUJ-Ez@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | net: stmmac: provide stmmac_mac_phylink_get_caps()Russell King (Oracle)2023-08-262-0/+7
| | | | | | | | | | | | | | | | | | Allow MACs to provide their own capabilities via the MAC operations struct. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://lore.kernel.org/r/E1qZAXT-005pUD-Aj@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | net: stmmac: use phylink_limit_mac_speed()Russell King (Oracle)2023-08-261-21/+14
| | | | | | | | | | | | | | | | | | Use phylink_limit_mac_speed() to limit the MAC capabilities rather than coding this for each speed. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://lore.kernel.org/r/E1qZAXO-005pU7-61@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | net: stmmac: use "mdio_bus_data" local variableRussell King (Oracle)2023-08-261-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | We have a local variable for priv->plat->mdio_bus_data, which we use later in the conditional if() block, but we evaluate the above within the conditional expression. Use mdio_bus_data instead. Since these will be the only two users of this local variable, move its assignment just before the if(). Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://lore.kernel.org/r/E1qZAXJ-005pU1-1z@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | net: stmmac: clean up passing fwnode to phylinkRussell King (Oracle)2023-08-261-4/+5
| | | | | | | | | | | | | | | | | | Move the initialisation of the fwnode variable closer to its use site, rather than scattered throughout stmmac_phy_setup(). Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://lore.kernel.org/r/E1qZAXD-005pTv-TN@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | net: stmmac: convert plat->phylink_node to fwnodeRussell King (Oracle)2023-08-263-4/+5
| | | | | | | | | | | | | | | | | | | | | | All users of plat->phylink_node first convert it to a fwnode. Rather than repeatedly convert to a fwnode, store it as a fwnode. To reflect this change, call it plat->port_node instead - it is used for more than just phylink. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://lore.kernel.org/r/E1qZAX8-005pTo-OT@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | net: phylink: add phylink_limit_mac_speed()Russell King (Oracle)2023-08-261-0/+18
| | | | | | | | | | | | | | | | | | Add a function which can be used to limit the phylink MAC capabilities to an upper speed limit. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://lore.kernel.org/r/E1qZAX3-005pTi-K1@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | veth: Avoid NAPI scheduling on failed SKB forwardingLiang Chen2023-08-261-3/+2
| | | | | | | | | | | | | | | | | | | | | | When an skb fails to be forwarded to the peer(e.g., skb data buffer length exceeds MTU), it will not be added to the peer's receive queue. Therefore, we should schedule the peer's NAPI poll function only when skb forwarding is successful to avoid unnecessary overhead. Signed-off-by: Liang Chen <liangchen.linux@gmail.com> Link: https://lore.kernel.org/r/20230824123131.7673-1-liangchen.linux@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | Merge tag 'wireless-next-2023-08-25' of ↵Jakub Kicinski2023-08-26130-1021/+1967
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Kalle Valo says: ==================== wireless-next patches for v6.6 The second pull request for v6.6, this time with both stack and driver changes. Unusually we have only one major new feature but lots of small cleanup all over, I guess this is due to people have been on vacation the last month. Major changes: rtw89 - Introduce Time Averaged SAR (TAS) support * tag 'wireless-next-2023-08-25' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (114 commits) wifi: rtlwifi: rtl8723: Remove unused function rtl8723_cmd_send_packet() wifi: rtw88: usb: kill and free rx urbs on probe failure wifi: rtw89: Fix clang -Wimplicit-fallthrough in rtw89_query_sar() wifi: rtw89: phy: modify register setting of ENV_MNTR, PHYSTS and DIG wifi: rtw89: phy: add phy_gen_def::cr_base to support WiFi 7 chips wifi: rtw89: mac: define register address of rx_filter to generalize code wifi: rtw89: mac: define internal memory address for WiFi 7 chip wifi: rtw89: mac: generalize code to indirectly access WiFi internal memory wifi: rtw89: mac: add mac_gen_def::band1_offset to map MAC band1 register address wifi: wlcore: sdio: Use module_sdio_driver macro to simplify the code wifi: rtw89: initialize multi-channel handling wifi: rtw89: provide functions to configure NoA for beacon update wifi: rtw89: call rtw89_chan_get() by vif chanctx if aware of vif wifi: rtw89: sar: let caller decide the center frequency to query wifi: rtw89: refine rtw89_correct_cck_chan() by rtw89_hw_to_nl80211_band() wifi: rtw89: add function prototype for coex request duration Fix nomenclature for USB and PCI wireless devices wifi: ath: Use is_multicast_ether_addr() to check multicast Ether address wifi: ath12k: Remove unused declarations wifi: ath12k: add check max message length while scanning with extraie ... ==================== Link: https://lore.kernel.org/r/20230825132230.A0833C433C8@smtp.kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * \ Merge ath-next from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.gitKalle Valo2023-08-2540-268/+195
| |\ \ | | | | | | | | | | | | | | | | ath.git patches for v6.6. No major changes, only smaller fixes and cleanups this time.
| | * | wifi: ath: Use is_multicast_ether_addr() to check multicast Ether addressRuan Jinjie2023-08-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use is_multicast_ether_addr() to perform the Checking. Signed-off-by: Ruan Jinjie <ruanjinjie@huawei.com> Reviewed-by: Jeff Johnson <quic_jjohnson@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20230814124212.302738-2-ruanjinjie@huawei.com
| | * | wifi: ath12k: Remove unused declarationsYue Haibing2023-08-254-8/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") declared but never implemented these, remove it. Signed-off-by: Yue Haibing <yuehaibing@huawei.com> Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20230816130550.50896-1-yuehaibing@huawei.com
| | * | wifi: ath12k: add check max message length while scanning with extraieWen Gong2023-08-251-7/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently the extraie length is directly used to allocate skb buffer. When the length of skb is greater than the max message length which firmware supports, error will happen in firmware side. Hence add check for the skb length and drop extraie when overflow and print a message. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0-03427-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.15378.4 Signed-off-by: Wen Gong <quic_wgong@quicinc.com> Reviewed-by: Jeff Johnson <quic_jjohnson@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20230809081657.13858-1-quic_wgong@quicinc.com
| | * | wifi: ath9k: use IS_ERR() with debugfs_create_dir()Wang Ming2023-08-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The debugfs_create_dir() function returns error pointers, it never returns NULL. Most incorrect error checks were fixed, but the one in ath9k_htc_init_debug() was forgotten. Fix the remaining error check. Fixes: e5facc75fa91 ("ath9k_htc: Cleanup HTC debugfs") Signed-off-by: Wang Ming <machel@vivo.com> Acked-by: Toke Høiland-Jørgensen <toke@toke.dk> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20230713030358.12379-1-machel@vivo.com
| | * | wifi: ath12k: Fix memory leak in rx_desc and tx_descRajat Soni2023-08-232-1/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently when ath12k_dp_cc_desc_init() is called we allocate memory to rx_descs and tx_descs. In ath12k_dp_cc_cleanup(), during descriptor cleanup rx_descs and tx_descs memory is not freed. This is cause of memory leak. These allocated memory should be freed in ath12k_dp_cc_cleanup. In ath12k_dp_cc_desc_init(), we can save base address of rx_descs and tx_descs. In ath12k_dp_cc_cleanup(), we can free rx_descs and tx_descs memory using their base address. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 Signed-off-by: Rajat Soni <quic_rajson@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20230718053510.30894-1-quic_rajson@quicinc.com
| | * | wifi: ath5k: ath5k_hw_get_median_noise_floor(): use swap()Mahmoud Maatuq2023-08-231-16/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | coccinielle reported the following: ./drivers/net/wireless/ath/ath5k/phy.c:1573:25-26: WARNING opportunity for swap() while trying to fix the above warning, it reveals that ath5k_hw_get_median_noise_floor() had open-coded sort() functionality. Since ath5k_hw_get_median_noise_floor() only executes once every 10 seconds, any extra overhead due to sort() calling its "compare" and "swap" functions can be ignored, so replace the existing logic with a call to sort(). Signed-off-by: Mahmoud Maatuq <mahmoudmatook.mm@gmail.com> Suggested-by: Jiri Slaby <jirislaby@kernel.org> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20230815040819.649455-1-mahmoudmatook.mm@gmail.com
| | * | wifi: ath: remove unused-but-set parameterArnd Bergmann2023-08-234-6/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This has never been used since the driver was merged, but it now causes a W=1 warning in recent clang versions drivers/net/wireless/ath/ath9k/main.c:1566:21: error: parameter 'changed_flags' set but not used [-Werror,-Wunused-but-set-parameter] drivers/net/wireless/ath/ath9k/htc_drv_main.c:1258:25: error: parameter 'changed_flags' set but not used [-Werror,-Wunused-but-set-parameter] drivers/net/wireless/ath/ath5k/mac80211-ops.c:367:62: error: parameter 'changed_flags' set but not used [-Werror,-Wunused-but-set-parameter] Remove the bit manipulation on the otherwise unused parameter. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Jeff Johnson <quic_jjohnson@quicinc.com> Acked-by: Toke Høiland-Jørgensen <toke@toke.dk> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20230814073255.1065242-1-arnd@kernel.org
| | * | wifi: ath11k: Remove unused declarationsYue Haibing2023-08-232-5/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 2c3960c2253d ("ath11k: setup ce tasklet for control path") declared but never implemented ath11k_ce_map_service_to_pipe(). Commit e3396b8bddd2 ("ath11k: ce: support different CE configurations") declared but never implemented ath11k_ce_attr_attach(). Commit d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") declared but never implemented ath11k_qmi_event_work()/ath11k_qmi_msg_recv_work(). Signed-off-by: Yue Haibing <yuehaibing@huawei.com> Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20230811104413.33668-1-yuehaibing@huawei.com
| | * | wifi: ath10k: fix Wvoid-pointer-to-enum-cast warningKrzysztof Kozlowski2023-08-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 'hw_rev' is an enum, thus cast of pointer on 64-bit compile test with W=1 causes: ath10k/ahb.c:736:11: error: cast to smaller integer type 'enum ath10k_hw_rev' from 'const void *' [-Werror,-Wvoid-pointer-to-enum-cast] Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20230810091224.70088-2-krzysztof.kozlowski@linaro.org
| | * | wifi: ath11k: fix Wvoid-pointer-to-enum-cast warningKrzysztof Kozlowski2023-08-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 'hw_rev' is an enum, thus cast of pointer on 64-bit compile test with W=1 causes: h11k/ahb.c:1124:11: error: cast to smaller integer type 'enum ath11k_hw_rev' from 'const void *' [-Werror,-Wvoid-pointer-to-enum-cast] Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20230810091224.70088-1-krzysztof.kozlowski@linaro.org
| | * | wifi: ath11k: simplify the code with module_platform_driverYang Yingliang2023-08-231-11/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The init/exit() of driver only calls platform_driver_register/unregister, it can be simpilfied with module_platform_driver. Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20230804091255.1347178-1-yangyingliang@huawei.com
| | * | wifi: ath12k: Fix a few spelling errorsJeff Johnson2023-08-235-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix a few issues flagged by 'codespell'. Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20230822-ath_spelling-v1-3-8e2698759564@quicinc.com
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-23 19:29:13 +0100