- 20 Apr, 2023 19 commits
-
-
Po-Hao Huang authored
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
-
Po-Hao Huang authored
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
-
Po-Hao Huang authored
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
-
Po-Hao Huang authored
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
-
Po-Hao Huang authored
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
-
Po-Hao Huang authored
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
-
Ping-Ke Shih authored
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
-
Yingsha Xu authored
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.cnSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Avraham Stern authored
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@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Avraham Stern authored
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@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Avraham Stern authored
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@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Avraham Stern authored
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@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Gregory Greenman authored
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@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
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@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
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: 4da46a06 ("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@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Alon Giladi authored
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@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
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 780e87c2 ("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 40a0b38d ("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@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
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: 36dfe9ac ("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@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Mukesh Sisodiya authored
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@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
- 19 Apr, 2023 1 commit
-
-
Hans de Goede authored
A received TKIP key may be up to 32 bytes because it may contain MIC rx/tx keys too. These are not used by iwl and copying these over overflows the iwl_keyinfo.key field. Add a check to not copy more data to iwl_keyinfo.key then will fit. This fixes backtraces like this one: memcpy: detected field-spanning write (size 32) of single field "sta_cmd.key.key" at drivers/net/wireless/intel/iwlwifi/dvm/sta.c:1103 (size 16) WARNING: CPU: 1 PID: 946 at drivers/net/wireless/intel/iwlwifi/dvm/sta.c:1103 iwlagn_send_sta_key+0x375/0x390 [iwldvm] <snip> Hardware name: Dell Inc. Latitude E6430/0H3MT5, BIOS A21 05/08/2017 RIP: 0010:iwlagn_send_sta_key+0x375/0x390 [iwldvm] <snip> Call Trace: <TASK> iwl_set_dynamic_key+0x1f0/0x220 [iwldvm] iwlagn_mac_set_key+0x1e4/0x280 [iwldvm] drv_set_key+0xa4/0x1b0 [mac80211] ieee80211_key_enable_hw_accel+0xa8/0x2d0 [mac80211] ieee80211_key_replace+0x22d/0x8e0 [mac80211] <snip> Link: https://www.alionet.org/index.php?topic=1469.0 Link: https://lore.kernel.org/linux-wireless/20230218191056.never.374-kees@kernel.org/ Link: https://lore.kernel.org/linux-wireless/68760035-7f75-1b23-e355-bfb758a87d83@redhat.com/ Cc: Kees Cook <keescook@chromium.org> Suggested-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
- 18 Apr, 2023 16 commits
-
-
Felix Fietkau authored
It is unused and should not be used. In order to avoid limitations in 4-address mode, the driver should always use ieee80211_tx_status_ext for 802.3 frames with a valid sta pointer. Signed-off-by: Felix Fietkau <nbd@nbd.name> Link: https://lore.kernel.org/r/20230417133751.79160-1-nbd@nbd.nameSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Gregory Greenman authored
Start supporting API version 78 for AX devices. Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230417113648.5a4dcbf5a2c1.I125808566fe892ee0865e392bf1b1872daafe8ad@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
Check the firmware response size for responses to the memory read/write command in debugfs before using it. Fixes: 2b55f43f ("iwlwifi: mvm: Add mem debugfs entry") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230417113648.0d56fcaf68ee.I70e9571f3ed7263929b04f8fabad23c9b999e4ea@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
For MLO support, use the pointer to the peer MLD instead of the default link station id, since the default link is only used for non-MLO cases. Using the default link sta id is meaningless for MLO. Also remove the rcu protected section since we now avoid the lookup based on sta id. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230417113648.40cef48c0592.I8dd666d603d6e1854033e5369c70e78d9303d236@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
If the AP station already exists on link activation (which means we're during link switch), configure the TLC in FW so we can immediately transmit once the link is activated. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230417113648.1a93de9b7c1f.I42022f24bbe3572f5a082da8c99794ae14281875@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
For MLO, we cannot use vif->bss_conf.chandef.chan->band, since that will lead to a NULL-ptr dereference as bss_conf isn't used. However, in case of real MLO, we also need to take both LMACs into account if they exist, since the station might be active on both LMACs at the same time. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230417113648.3588afc85d79.I11592893bbc191b9548518b8bd782de568a9f848@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
Track instead whether or not the station was authorized, that's clearer than trying to indicate in the code whether or not the full bandwidth should be used via an 'update' argument. While at it, give rs_fw_rate_init() the iwl_mvm_ prefix. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230417113648.92bd8d36e311.I1877a109104d5ffeaaad6a623e89f0c44decc38e@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
When allocating a new link station, initialize the ratescaling data for it. To do that, refactor the initialization code out into a new iwl_mvm_rs_add_sta_link() function. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230417113648.441b6a8c60fd.I34f1b3555c25aaa22cc34d1112fc3b6393a20b7c@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
We need to look up the correct version of this struct depending on the interface type, rather than just checking if the pointer is non-NULL. Fix that. Fixes: befebbb3 ("iwlwifi: rs: consider LDPC capability in case of HE") Fixes: b009cf71 ("iwlwifi: mvm: only enable HE DCM if we also support TX") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230417113648.1fd54368a02c.Ie4db5e8ae224d9a4a63b528da5d63e1b957b9cef@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
Since only clients to an AP can be 20MHz-only STAs, adjust the code to not make the use of EHT capabilities depend on only the bandwidth, but also the type of interface. Fixes: 701404f1 ("wifi: iwlwifi: rs: add support for parsing max MCS per NSS/BW in 11be") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230417113648.a3a4c931e4a3.I693a07f4d88044c889eee04793883a83bc5ee362@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
When this is called it might crash due to the use of deflink's phy context, update all links instead. It really shouldn't be called right now though, but it's better to have safer code until we update this to be with a link parameter. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230417113648.fd47d0de8319.I87c5e5bcb2fadd70acc32021eed394fc1eea12a4@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
When we first add the STA before sending an authentication frame this is false. However, in some cases such as FT or certainly in MLO link switch scenarios, it will be true. If it happens to be true, it causes a firmware assert (in LMAC, 0x2528), because the same bit is used by the firmware for tracking this setting as well as for tracking if the management key has been installed, and then we get this assert from the firmware when installing the MFP key as it thinks it has already been installed. Remove the setting for now, until the firmware disentangles the two. We should be able to set it, in fact we should be setting it speculatively before authentication/association, to avoid processing management frames that should have been protected/encrypted before the key is set. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230417113648.adbeb0e0bfed.I400d0ee3721dc4f294313be992d277ba4d9c88d9@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
We can allow NL80211_EXT_FEATURE_SCAN_MIN_PREQ_CONTENT since we just use the elements from mac80211. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230417113648.88b1a70365fd.If5030437707ab67e2146291c1517a9b0e31d01ab@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
A long time, ago in commit 818965d3 ("cfg80211: Allow a scan request for a specific BSSID"), the stack started passing the BSSID that should be scanned for. Use it in iwlwifi for the intended optimisation, and to also allow the use of this for an implementation sending multi-link probe requests. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230417113648.0be90360cad7.If279c28079a1db34280a824cee7c3f6545fd8b9e@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Gregory Greenman authored
The restriction where MAC ID 0 could be used only for the managed/IBSS vif is not required when using the new MLO FW API. Update the driver. Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230417113648.e4355615da92.Iba934ccf8589c3c27a25a390dc5e938312889b45@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Emmanuel Grumbach authored
The firmware no longer wants the beacon template inside the MAC command. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230417113648.92aed4180a06.I277efa343c88081cb3fc890dcbeae3161cdffe16@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
- 17 Apr, 2023 4 commits
-
-
Po-Hao Huang authored
Add iface_combination declaration to enable concurrent mode. Only two interfaces under same frequency is supported currently. We limit the role combination to be STA + P2P or STA + AP only for now until new feature is 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/20230415035016.15788-2-pkshih@realtek.com
-
Po-Hao Huang authored
Power saving for more than one station is not supported currently. Disallow entering PS mode when we have more than one associated stations. 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/20230415035016.15788-1-pkshih@realtek.com
-
Po-Hao Huang authored
Since firmware can't have proper statistics, driver update the statistics periodically to firmware to assist in tuning performance. 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/20230415034900.15679-5-pkshih@realtek.com
-
Ping-Ke Shih authored
Remove macros that set H2C data. Instead, use struct and le32_encode_bits() with mask definition to make it clean. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230415034900.15679-4-pkshih@realtek.com
-