- 11 Sep, 2023 7 commits
-
-
Johannes Berg authored
To change aggregation status may call into the driver, lock the wiphy for this. Signed-off-by:Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
It's no longer really needed to ensure that the debugfs file isn't going away, debugfs handles that. So there's no point in holding dev_base_lock or RTNL here, but we should instead hold the wiphy lock since drivers will be allowed to depend on that. Do that, which requires splitting the sdata and link macros a bit. Signed-off-by: -
Johannes Berg authored
Since we no longer really use the RTNL, there's no point in locking it here. Most drivers don't really need to have any locks here anyway, and the rest are probably completely broken, but it's a debugfs-only callback so it really doesn't matter much. Signed-off-by: -
Johannes Berg authored
The current SMPS status handling isn't per link, so we only ever change the deflink, which is obviously wrong, it's not even used for multi-link connections, but the request API actually includes the link ID. Use the new status_data changes to move the handling to the right link, this also saves parsing the frame again on the status report, instead we can now check only if it was an SMPS frame. Of course, move the worker to be a wiphy work so that we're able to cancel it safely for the link. Signed-off-by: -
Ilan Peer authored
When the connection is a MLO connection, a SMPS request should be sent on a specific link, as SMPS is BSS specific, and the DA and BSSID used for the action frame transmission should be the AP MLD address, as the underlying driver is expected to perform the address translation (based on the link ID). Fix the SMPS request handling to use the AP MLD address and provide the link ID for the request processing during Tx. Signed-off-by:
Ilan Peer <ilan.peer@intel.com> Signed-off-by:
-
Johannes Berg authored
Take one more free bit to indicate it's IDR vs. internal usage, to be able to carve out some bits here for other internal usage, other than IDR handling with a full ACK SKB, that is. Reviewed-by:
Benjamin Berg <benjamin.berg@intel.com> Reviewed-by:
-
Johannes Berg authored
This really just reformats the statement, but makes it more readable. Signed-off-by:
-
- 07 Sep, 2023 15 commits
-
-
Rand Deeb authored
In ssb_calc_clock_rate(), there is a potential issue where the value of m1 could be zero due to initialization using clkfactor_f6_resolv(). This situation raised concerns about the possibility of a division by zero error. We fixed it by following the suggestions provided by Larry Finger <Larry.Finger@lwfinger.net> and Michael Büsch <m@bues.ch>. The fix involves returning a value of 1 instead of 0 in clkfactor_f6_resolv(). This modification ensures the proper functioning of the code and eliminates the risk of division by zero errors. Signed-off-by:
Rand Deeb <rand.sec96@gmail.com> Acked-by:
Larry Finger <Larry.Finger@lwfinger.net> Acked-by:
Michael Büsch <m@bues.ch> Signed-off-by:
Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230904232346.34991-1-rand.sec96@gmail.com
-
Ping-Ke Shih authored
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:
-
Ping-Ke Shih authored
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 authored
Before downloading firmware for BB MCU, call this ops to enable baseband hardware. Signed-off-by:
-
Ping-Ke Shih authored
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 authored
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 authored
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 authored
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 authored
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:
-
Zong-Zhe Yang authored
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:
-
Zong-Zhe Yang authored
Fix a typo where `bitamp` should be `bitmap`. Don't change functionality at all. Signed-off-by:
-
Zong-Zhe Yang authored
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 authored
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 authored
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 authored
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:
-
- 04 Sep, 2023 5 commits
-
-
Kuan-Chung Chen authored
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:
-
Kuan-Chung Chen authored
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:
-
Dmitry Antipov authored
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:
-
Zenm Chen authored
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:
-
Po-Hao Huang authored
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:
-
- 26 Aug, 2023 13 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queueJakub Kicinski authored
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.comSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Donald Hunter authored
Add del operation to the spec to help with testing. Signed-off-by:
Donald Hunter <donald.hunter@gmail.com> Link: https://lore.kernel.org/r/20230824142221.71339-1-donald.hunter@gmail.comSigned-off-by:
-
Jakub Kicinski authored
We use a tempfile for code generation, to avoid wiping the target file out if the code generator crashes. File contents are copied from tempfile to actual destination at the end of main(). uAPI generation is relatively simple so when generating the uAPI header we return from main() early, and never reach the "copy code over" stage. Since commit under Fixes uAPI headers are not updated by ynl-gen. Move the copy/commit of the code into CodeWriter, to make it easier to call at any point in time. Hook it into the destructor to make sure we don't miss calling it. Fixes: f65f305a ("tools: ynl-gen: use temporary file for rendering") Link: https://lore.kernel.org/r/20230824212431.1683612-1-kuba@kernel.orgSigned-off-by:
-
Jakub Kicinski authored
Russell King says: ==================== stmmac cleanups One of the comments I had on Feiyang Chen's series was concerning the initialisation of phylink... and so I've decided to do something about it, cleaning it up a bit. This series: 1) adds a new phylink function to limit the MAC capabilities according to a maximum speed. This allows us to greatly simplify stmmac's initialisation of phylink's mac capabilities. 2) everywhere that uses priv->plat->phylink_node first converts this to a fwnode before doing anything with it. This is silly. Let's instead store it as a fwnode to eliminate these conversions in multiple places. 3) clean up passing the fwnode to phylink - it might as well happen at the phylink_create() callsite, rather than being scattered throughout the entire function. 4) same for mdio_bus_data 5) use phylink_limit_mac_speed() to handle the priv->plat->max_speed restriction. 6) add a method to get the MAC-specific capabilities from the code dealing with the MACs, and arrange to call it at an appropriate time. 7) convert the gmac4 users to use the MAC specific method. 8) same for xgmac. 9) group all the simple phylink_config initialisations together. 10) convert half-duplex logic to being positive logic. While looking into all of this, this raised eyebrows: if (priv->plat->tx_queues_to_use > 1) priv->phylink_config.mac_capabilities &= ~(MAC_10HD | MAC_100HD | MAC_1000HD); priv->plat->tx_queues_to_use is initialised by platforms to either 1, 4 or 8, and can be controlled from userspace via the --set-channels ethtool op. The implementation of this op in this driver limits the number of channels to priv->dma_cap.number_tx_queues, which is derived from the DMA hwcap. So, the obvious questions are: 1) what guarantees that the static initialisation of tx_queues_to_use will always be less than or equal to number_tx_queues from the DMA hw cap? 2) tx_queues_to_use starts off as 1, but number_tx_queues is larger, we will leave the half-duplex capabilities in place, but userspace can increase tx_queues_to_use above 1. Does that mean half-duplex is then not supported? 3) Should we be basing the decision whether half-duplex is supported off the DMA capabilities? 4) What about priv->dma_cap.half_duplex? Doesn't that get a say in whether half-duplex is supported or not? Why isn't this used? Why is it only reported via debugfs? If it's not being used by the driver, what's the point of reporting it via debugfs? ==================== Link: https://lore.kernel.org/r/ZOddFH22PWmOmbT5@shell.armlinux.org.ukSigned-off-by: -
Russell King (Oracle) authored
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.ukSigned-off-by:
-
Russell King (Oracle) authored
Move priv->phylink_config.mac_managed_pm to be along side the other phylink initialisations. Signed-off-by:
-
Russell King (Oracle) authored
Move the xgmac specific phylink capabilities to the dwxgmac2 support core. Signed-off-by:
-
Russell King (Oracle) authored
Move the setup of gmac4 speicifc phylink capabilities into gmac4 code. Signed-off-by:
-
Russell King (Oracle) authored
Allow MACs to provide their own capabilities via the MAC operations struct. Signed-off-by:
-
Russell King (Oracle) authored
Use phylink_limit_mac_speed() to limit the MAC capabilities rather than coding this for each speed. Signed-off-by:
-
Russell King (Oracle) authored
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) authored
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) authored
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:
-
