- 05 Oct, 2021 3 commits
-
-
Hans de Goede authored
The Cyberbook T116 tablet contains quite generic names in the sys_vendor and product_name DMI strings, without this patch brcmfmac will try to load: "brcmfmac43455-sdio.Default string-Default string.txt" as nvram file which is way too generic. The nvram file shipped on the factory Android image contains the exact same settings as those used on the AcePC T8 mini PC, so point the new DMI nvram filename quirk to the acepc-t8 nvram file. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210928160633.96928-1-hdegoede@redhat.com
-
Zong-Zhe Yang authored
The usage of fw_crash debugfs is to write 1 to it to trigger fw crash simulation and to read from it to check the state. When zero is read, it is supposed to mean fw crash/restart process is done. Then, some test plans can be designed for crash/restart. e.g. step 1. trigger fw crash simulation step 2. poll the state until zero is read step 3. check connection by ping test However, in certain connection cases, triggering fw crash simulation will take a while. If the state is queried too early before restart begins processing, it may mistakenly think restart process has been done. If some tests are started at this time, something unexpected might happen due to the follow-up restart process. To avoid that, let fw_crash also show non-zero when a simulation is still triggering. Signed-off-by:
Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by:
Ping-Ke Shih <pkshih@realtek.com> Signed-off-by:
-
Zong-Zhe Yang authored
When fw fifo dumps, RX clock gating should be disabled to avoid something unexpected. However, the register operation ran into a mistake. So, we fix it. Signed-off-by:
-
- 28 Sep, 2021 1 commit
-
-
Cai Huoqing authored
Use dma_alloc_coherent() instead of pci_alloc_consistent(), because only dma_alloc_coherent() is called here. Signed-off-by:
Cai Huoqing <caihuoqing@baidu.com> Signed-off-by:
-
- 24 Sep, 2021 3 commits
-
-
Guo-Feng Fan authored
NIC card saves calibrated TX power index in the efuse(ROM). Driver loads TX power idex when interface is up. The problem is type2/4 NICs loads 2.4G TX power index from wrong position. This patch corrects the offsets. So, driver loads real 2.4G TX power index for type 2/4 NICs. 2.4G performance increased when using correct TX power index. Signed-off-by:
Guo-Feng Fan <vincent_fann@realtek.com> Signed-off-by:
-
Guo-Feng Fan authored
RFE type4 is a new NIC which has one RF antenna shares with BT. RFE type4 HW is the same as RFE type2 but attaching antenna to aux antenna connector. RFE type2 attach antenna to main antenna connector. Load the same parameter as RFE type2 when initializing NIC. Signed-off-by:
-
Len Baker authored
There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use "flexible array members"[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. Also, make use of the struct_size() helper in devm_kzalloc(). [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.14/process/deprecated.html#zero-length-and-one-element-arraysSigned-off-by:
Len Baker <len.baker@gmx.com> Reviewed-by:
Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by:
-
- 21 Sep, 2021 32 commits
-
-
Krzysztof Kozlowski authored
The device 0x043e,0x7a32 is already on the list under CONFIG_RT2800USB_RT55XX. Since it is the sole Arcadyan entry in RT55xx, assume the proper chip is RT55xx, not RT53xx, although this was not confirmed by testing or 3rd party sources. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by:
-
Krzysztof Kozlowski authored
The device 0x157e,0x3006 is already on the list. Signed-off-by:
-
Krzysztof Kozlowski authored
The device 0x07b8,0x6001 is already on the list as zd1211 chip. Wiki https://wireless.wiki.kernel.org/en/users/Drivers/zd1211rw/devices confirms it is also zd1211, not the zd1211b. Signed-off-by:
-
Ajay Singh authored
Increase the WID config packet response timeout to have extra wait time for host to receive the response message from firmware. Sometimes the WID config response was timed out because of host interrupt latency. Signed-off-by:
Ajay Singh <ajay.kathat@microchip.com> Signed-off-by:
-
Ajay Singh authored
Instead of using double read for the same register, use the write register command after the read command. The correct sequence is to use the read value in write command instead of reading the same register again. Signed-off-by:
-
Ajay Singh authored
Add 'initialized' variable check before adding net/mgmt packet to TX queue as safety check before passing the commands to the firmware. Signed-off-by:
-
Ajay Singh authored
Add the chip reset command to initialize the WILC chip before downloading the firmware. Also, put the chip in wake-up mode so it is ready to receive the firmware binary from the host. Signed-off-by:
-
Ajay Singh authored
During WILC chip wake-up sequence, the clockless status register sometimes reports failure even when the actual status is successful. So, for the clockless register, remove the incorrect error status reporting during the read and write command API's. Signed-off-by:
-
Ajay Singh authored
For SPI bus, the register read fails after read/write to the clockless register during chip wakeup sequence. Add workaround to send CMD_RESET command during chip wake-up sequence to overcome the issue. Signed-off-by:
-
Ajay Singh authored
Add reset/terminate/repeat command for SPI module. In case of SPI commands failure, the host should issue a RESET command to WILC chip to recover from any temporary bus error. For now, the new command support is added and later the SPI read/write API's would be modified to make use of these commands for retry mechanism Signed-off-by:
-
Ajay Singh authored
Use the correct sequence to configure clockless registers for chip wake-up. The following sequence is expected from WILC chip for wakeup: - set wakeup bit in wakeup_reg register - after setting the wakeup bit, read back the clock status bit for wakeup complete. For SDIO/SPI modules, the wakeup sequence is the same except uses different register values so refactored the code to use common function for both SDIO/SPI bus. Signed-off-by:
-
Ajay Singh authored
Add new WID(WID_WOWLAN_TRIGGER) to send wake_enable information to firmware. In 'set_wakeup' cfg80211_ops callback, the enable information was not passed to firmware which is required to handle WOWLan trigger notification from firmware. Signed-off-by:
-
Ajay Singh authored
When the BSS reference holds a valid reference, it is not freed. The 'if' condition is wrong. Instead of the 'if (bss)' check, the 'if (!bss)' check is used. The issue is solved by removing the unnecessary 'if' check because cfg80211_put_bss() already performs the NULL validation. Fixes: 6cd4fa5a ("staging: wilc1000: make use of cfg80211_inform_bss_frame()") Signed-off-by:
-
Ajay Singh authored
Move initialization & deinitialization of 'deinit_lock' mutex lock inside wlan_init_locks() & wlan_deinit_locks() API's respectively alongside other locks. After the movement, the client count variable(client_count) which is used for lock init/deinit is removed. Signed-off-by:
-
Marek Vasut authored
The module parameters are missing dev_oper_mode 12, BT classic alone, add it. Moreover, the parameters encode newlines, which ends up being printed malformed e.g. by modinfo, so fix that too. However, the module parameter string is duplicated in both USB and SDIO modules and the dev_oper_mode mode enumeration in those module parameters is a duplicate of macros used by the driver. Furthermore, the enumeration is confusing. So, deduplicate the module parameter string and use __stringify() to encode the correct mode enumeration values into the module parameter string. Finally, replace 'Wi-Fi' with 'Wi-Fi alone' and 'BT' with 'BT classic alone' to clarify what those modes really mean. Fixes: 898b2553 ("rsi: add module parameter operating mode") Signed-off-by:
Marek Vasut <marex@denx.de> Cc: Amitkumar Karwar <amit.karwar@redpinesignals.com> Cc: Angus Ainslie <angus@akkea.ca> Cc: David S. Miller <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Kalle Valo <kvalo@codeaurora.org> Cc: Karun Eagalapati <karun256@gmail.com> Cc: Martin Fuzzey <martin.fuzzey@flowbird.group> Cc: Martin Kepplinger <martink@posteo.de> Cc: Prameela Rani Garnepudi <prameela.j04cs@gmail.com> Cc: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm> Cc: Siva Rebbagondla <siva8118@gmail.com> Cc: netdev@vger.kernel.org Cc: <stable@vger.kernel.org> # 4.17+ Signed-off-by:
-
Jonas Dreßler authored
The BSS priority here for a new P2P_CLIENT device was accidentally set to an enum that's certainly not meant for this. Since MWIFIEX_BSS_ROLE_STA is 0 anyway, we can just set the bss_priority to 0 instead here. Signed-off-by:
Jonas Dreßler <verdre@v0yd.nl> Signed-off-by:
-
Jonas Dreßler authored
When creating a new virtual interface in mwifiex_add_virtual_intf(), we update our internal driver states like bss_type, bss_priority, bss_role and bss_mode to reflect the mode the firmware will be set to. When switching virtual interface mode using mwifiex_init_new_priv_params() though, we currently only update bss_mode and bss_role. In order for the interface mode switch to actually work, we also need to update bss_type to its proper value, so do that. This fixes a crash of the firmware (because the driver tries to execute commands that are invalid in AP mode) when switching from station mode to AP mode. Signed-off-by:
-
Jonas Dreßler authored
Looks like this case was simply overseen, so handle it, too. Signed-off-by:
-
Jonas Dreßler authored
It's possible to change virtual interface type between P2P_CLIENT and P2P_GO, the card supports that just fine, and it happens for example when using miracast with the miraclecast software. So allow type changes between P2P_CLIENT and P2P_GO and simply call into mwifiex_change_vif_to_p2p(), which handles this just fine. We have to call mwifiex_cfg80211_deinit_p2p() before though to make sure the old p2p mode is properly uninitialized. Signed-off-by:
-
Jonas Dreßler authored
In mwifiex_init_new_priv_params() we update our private driver state to reflect the currently selected virtual interface type. Most notably we set the bss_mode to the mode we're going to put the firmware in. Now after we updated the driver state we actually start talking to the firmware and instruct it to set up the new mode. Those commands can and will sometimes fail, in which case we return with an error from mwifiex_change_vif_to_*. We currently update our virtual interface type counters after this return, which means the code is never reached when a firmware error happens and we never update the counters. Since we have updated our bss_mode earlier though, the counters now no longer reflect the actual state of the driver. This will break things on the next virtual interface change, because the virtual interface type we're switching away from didn't get its counter incremented, and we end up decrementing a 0-counter. To fix this, simply update the virtual interface type counters right after updating our driver structures, so that they are always in sync. Signed-off-by:
-
Jonas Dreßler authored
Use a small helper function to increment and decrement the counter of the interface types we currently manage. This makes the code that actually changes and sets up the interface type a bit less messy and also helps avoiding mistakes in case someone increments/decrements a counter wrongly. Signed-off-by:
-
Jonas Dreßler authored
We currently handle changing from the P2P to the STATION virtual interface type slightly different than changing from P2P to ADHOC: When changing to STATION, we don't send the SET_BSS_MODE command. We do send that command on all other type-changes though, and it probably makes sense to send the command since after all we just changed our BSS_MODE. Looking at prior changes to this part of the code, it seems that this is simply a leftover from old refactorings. Since sending the SET_BSS_MODE command is the only difference between mwifiex_change_vif_to_sta_adhoc() and the current code, we can now use mwifiex_change_vif_to_sta_adhoc() for both switching to ADHOC and STATION interface type. This does not fix any particular bug and just "looked right", so there's a small chance it might be a regression. Signed-off-by:
-
Jonas Dreßler authored
Instead of bailing out in the function which is supposed to do the type change, detect invalid changes beforehand using a generic function and return an error if the change is not allowed. Signed-off-by:
-
Jonas Dreßler authored
Handle the obvious invalid virtual interface type changes with a general check instead of looking at the individual change. For type changes from P2P_CLIENT to P2P_GO and the other way round, this changes the behavior slightly: We now still do nothing, but return -EOPNOTSUPP instead of 0. Now that behavior was incorrect before and still is, because type changes between these two types are actually possible and supported, which we'll fix in a following commit. Signed-off-by:
-
Chin-Yen Lee authored
Current adaptivity mechanism is achieved in driver, by periodically referencing the IGI value and then updating related registers. But we find that this way may halt TX activity too long if huge and temporary energy is detected frequently. So we move the mechanism to firmware for immediately reacting this case to recover TX rapidly. Signed-off-by:
Chin-Yen Lee <timlee@realtek.com> Signed-off-by:
-
Zong-Zhe Yang authored
Add Energy Detected CCA (EDCCA) mechanism to detect energy on the channel. And EDCCA support adaptivity mode now. From MIC Ordinance Regulating Radio Equipment article 49.20, ETSI EN-300-328 and EN-301-893, the device should be able to dynamically pause TX activity when energy detected on the air. According to ETSI/JP DFS region, driver will set corresponding threshold and stop TX activity if the detected energy exceeds the threshold. For now, we support it on 8822b and 8822c first. By default, EDCCA mechanism is turned on. For ETSI/JP DFS region, it will turn to adaptivity mode. However, with adaptivity, if environment is too noisy, TX may often be halted. So, a debugfs for EDCCA is added. It can show what EDCCA mode is used currently. And EDCCA mechanism can be turned on/off through the debugfs while debugging. Signed-off-by:
-
Zong-Zhe Yang authored
Realtek chips can program a specific country domain on efuse to indicate what is the expected rtw_regulatory. For chips with a programmed country domain, we set REGULATORY_STRICT_REG to tell stack to consider follow-up regulatory_hint() as the superset of our regulatory rule. Besides, on driver side, only the request via NL80211_REGDOM_SET_BY_DRIVER, which matches programmed country domain, will be handled to keep rtw_regulatory unchanged. For worldwide roaming chips, i.e. ones without a specific programmed country domain, system of distro can set expected regulatory via NL80211_REGDOM_SET_BY_USER. With setting from it, rtw_regulatory will handle the requests only via NL80211_REGDOM_SET_BY_USER to follow setting from system of distro. REGULATORY_COUNTRY_IE_IGNORE will then be set to tell stack to ignore country IE for us. The restrictions mentioned above will remain until 00, i.e. worldwide, is set via NL80211_REGDOM_SET_BY_USER. On the other hand, for worldwide roamin chips, if there is no specific regulatory set via NL80211_REGDOM_SET_BY_USER, requests from all regulatory notifications will be handled by rtw_regulatory. And REGULATORY_COUNTRY_IE_IGNORE won't be set. Signed-off-by:
-
Zong-Zhe Yang authored
Mapping table from country code to rtw_regulatory, which manages tx power limit according to countries, is updated. And mapping architecture is also upgraded. For more precise control on tx power limit, it allows different rtw_regulatory for different bands logically. Besides, a helper function to query rtw_regulatory for current band under current country is provided. For older chips, some newly added rtw_regulatory may not be configured. To avoid that those chips have no limit on some countries mapping to a newer rtw_regulatory after table update, a backward selection mechanism of rtw_regulatory is introduced. It can help chips use a rtw_regulatory which has been configured as an alternative of a newer one which is not configured. In addition, rtw88 actually doesn't manage channel plans by itself. Instead, it follows them from stack. So, correct some naming about chplan with regd, and remove the unnecessary channel control for now. Signed-off-by:
-
James Prestwood authored
An unsupported AKM would end up printing "invalid cipher group". Instead print "invalid akm suite" with the offending AKM. Signed-off-by:
James Prestwood <prestwoj@gmail.com> Signed-off-by:
-
Martin Fuzzey authored
P2P client mode was only working the first time. On subsequent connection attempts the group was successfully created but no data was sent (no transmitted data packets were seen with a sniffer). The reason for this was that the hardware was being configured in fixed rate mode with rate RSI_RATE_1 (1Mbps) which is not valid in the 5GHz band. In P2P mode wpa_supplicant uses NL80211_CMD_SET_TX_BITRATE_MASK to disallow the 11b rates in the 2.4GHz band which updated common->fixedrate_mask. rsi_set_min_rate() then used the fixedrate_mask to calculate the minimum allowed rate, or 0xffff = auto if none was found. However that calculation did not account for the different rate sets allowed in the different bands leading to the error. Fixing set_min_rate() would result in 6Mb/s being used all the time which is not what we want either. The reason the problem did not occur on the first connection is that rsi_mac80211_set_rate_mask() only updated the fixedrate_mask for the *current* band. When it was called that was still 2.4GHz as the switch is done later. So the when set_min_rate() was subsequently called after the switch to 5GHz it still had a mask of zero, leading to defaulting to auto mode. Fix this by differentiating the case of a single rate being requested, in which case the hardware will be used in fixed rate mode with just that rate, and multiple rates being requested, in which case we remain in auto mode but the firmware rate selection algorithm is configured with a restricted set of rates. Fixes: dad0d04f ("rsi: Add RS9113 wireless driver") Signed-off-by:
Martin Fuzzey <martin.fuzzey@flowbird.group> CC: stable@vger.kernel.org Signed-off-by:
-
Martin Fuzzey authored
My previous patch checked if encryption should be enabled by directly checking info->control.hw_key (like the downstream driver). However that missed that the control and driver_info members of struct ieee80211_tx_info are union fields. Due to this when rsi_core_xmit() updates fields in "tx_params" (driver_info) it can overwrite the control.hw_key, causing the result of the later test to be incorrect. With the current structure layout the first byte of control.hw_key is overlayed with the vap_id so, since we only test if control.hw_key is NULL / non NULL, a non zero vap_id will incorrectly enable encryption. In basic STA and AP modes the vap_id is always zero so it works but in P2P client mode a second VIF is created causing vap_id to be non zero and hence encryption to be enabled before keys have been set. Fix this by extracting the key presence flag to a new field in the driver private tx_params structure and populating it first. Fixes: 31453804 ("rsi: fix AP mode with WPA failure due to encrypted EAPOL") Signed-off-by:
-
Martin Fuzzey authored
When BT coexistence is enabled (eg oper mode 13, which is the default) the initialisation on startup sometimes silently fails. In a normal initialisation we see usb 1-1.3: Product: Wireless USB Network Module usb 1-1.3: Manufacturer: Redpine Signals, Inc. usb 1-1.3: SerialNumber: 000000000001 rsi_91x: rsi_probe: Initialized os intf ops rsi_91x: rsi_load_9116_firmware: Loading chunk 0 rsi_91x: rsi_load_9116_firmware: Loading chunk 1 rsi_91x: rsi_load_9116_firmware: Loading chunk 2 rsi_91x: Max Stations Allowed = 1 But sometimes the last log is missing and the wlan net device is not created. Running a userspace loop that resets the hardware via a GPIO shows the problem occurring ~5/100 resets. The problem does not occur in oper mode 1 (wifi only). Adding logs shows that the initialisation state machine requests a MAC reset via rsi_send_reset_mac() but the firmware does not reply, leading to the initialisation sequence being incomplete. Fix this by delaying attaching the BT adapter until the wifi initialisation has completed. With this applied I have done > 300 reset loops with no errors. Fixes: 716b840c ("rsi: handle BT traffic in driver") Signed-off-by:
-
- 12 Sep, 2021 1 commit
-
-
Linus Torvalds authored
-
