An error occurred fetching the project authors.
- 06 Aug, 2019 13 commits
-
-
Ganapathi Kondraju authored
Issue: While removing and inserting the driver module, observed driver loading is not successful. Root cause: Card is not resetted completely without issuing cmd5. Fix: Issued cmd5 properly. Signed-off-by:
Ganapathi Kondraju <ganapathirajukondraju@gmail.com> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org>
-
Dan Williams authored
The lbs_process_rxed_packet() frees the skb. It didn't originally, but we fixed it in commit f54930f3 ("libertas: don't leak skb on receive error"). Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Dan Williams <dcbw@redhat.com> Signed-off-by:
-
Navid Emamdoost authored
devm_kzalloc may fail and return NULL. So the null check is needed. Signed-off-by:
Navid Emamdoost <navid.emamdoost@gmail.com> Acked-by:
Jakub Kicinski <kubakici@wp.pl> Signed-off-by:
-
YueHaibing authored
Fixes gcc '-Wunused-but-set-variable' warning: drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c: In function brcmf_update_bss_info: drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:2962:5: warning: variable dtim_period set but not used [-Wunused-but-set-variable] drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c: In function brcmf_update_bss_info: drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:2961:6: warning: variable beacon_interval set but not used [-Wunused-but-set-variable] They are never used so can be removed. Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Signed-off-by:
-
YueHaibing authored
Now _rtl_dump_channel_map() does not do any actual thing using the channel. So remove it. Signed-off-by:
Ping-Ke Shih <pkshih@realtek.com> Signed-off-by:
-
Chuhong Yuan authored
Instead of using to_pci_dev + pci_get_drvdata, use dev_get_drvdata to make code simpler. Signed-off-by:
Chuhong Yuan <hslester96@gmail.com> Signed-off-by:
-
Chuhong Yuan authored
Instead of using to_pci_dev + pci_get_drvdata, use dev_get_drvdata to make code simpler. Signed-off-by:
-
Chuhong Yuan authored
Instead of using to_pci_dev + pci_get_drvdata, use dev_get_drvdata to make code simpler. Signed-off-by:
-
Chuhong Yuan authored
Instead of using to_pci_dev + pci_get_drvdata, use dev_get_drvdata to make code simpler. Signed-off-by:
-
Ganapathi Kondraju authored
Issue: RS-9116 Card is not responding after firmware got loaded. Root cause: After firmware got loaded, we need to reset the program counter and few device specific registers. Those registers were not resetted properly. Fix: Properly resetting those registers. Signed-off-by:
-
Pavel Machek authored
Surrounding code uses -ERRNO as a result, so don't pass plain -1. Signed-off-by:
Pavel Machek <pavel@denx.de> Signed-off-by:
-
Chuhong Yuan authored
Instead of using to_pci_dev + pci_get_drvdata, use dev_get_drvdata to make code simpler. Signed-off-by:
-
Brian Norris authored
We're just trusting that these tables are of the right dimensions, when we could do better by just using the struct directly. Let's expose the struct txpwr_lmt_cfg_pair instead. The table changes were made by using some Vim macros, so that should help prevent any translation mistakes along the way. Remaining work: get the 'void *data' out of the generic struct rtw_table; all of these tables really deserve to be their own data structure, with proper type fields. Signed-off-by:
Brian Norris <briannorris@chromium.org> Signed-off-by:
-
- 24 Jul, 2019 27 commits
-
-
Mao Wenan authored
This patch is to use eth_broadcast_addr() to assign broadcast address insetad of memcpy(). Signed-off-by:
Mao Wenan <maowenan@huawei.com> Signed-off-by:
-
Ping-Ke Shih authored
Module parameters of 'sw_crypto' and 'disable_watchdog' are false by default. If new value is desired, we can do it during inserting module, assignment existing in source code is not reasonable. Reported-by:
David Binderman <dcb314@hotmail.com> CC: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
-
Rafał Miłecki authored
Firmware crash is a pretty rare event and can't happen too frequently as it has to be followed by a hardware reinitialization and config reload. It should be safe to don't use net_ratelimit() when it happens. For reporting & debugging purposes it's important to provide a complete log as the last lines are actually the most important. This change modifies brcmfmac to print all messages in an unlimited way in that specific case. With this change there should be finally a backtrace of firmware finally visible after a crash. Signed-off-by:
Rafał Miłecki <rafal@milecki.pl> Acked-by:
Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by:
-
YueHaibing authored
It seems we should use 'range' instead of 'priv->range' in lbtf_geo_init(), because 'range' is the corret one related to current regioncode. Reported-by:
-
Zong-Zhe Yang authored
Add a read entry in debugfs to dump current tx power indexes in use for each path and each rate section. The corresponding power bases, power by rate, and power limit are also included. Also this patch fixes unused function warning. Fixes: b7414222 ("rtw88: refine flow to get tx power index") Signed-off-by:
Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by:
Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by:
-
Hariprasad Kelam authored
fix below issue reported by coccicheck drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c:514:1-3: WARNING: possible condition with no effect (if == else) Signed-off-by:
Hariprasad Kelam <hariprasad.kelam@gmail.com> Acked-by:
-
Stanislaw Gruszka authored
There is no point to use pointer to params->ssn. Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Acked-by:
-
Arend van Spriel authored
Recently a strcpy() was replaced by strlcpy(). However, the strcpy() was not needed in the first place. So removing that line of code. Reviewed-by:
Hante Meuleman <hante.meuleman@broadcom.com> Reviewed-by:
Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com> Reviewed-by:
Franky Lin <franky.lin@broadcom.com> Signed-off-by:
-
Arend van Spriel authored
When the bus is down, eg. due to rmmod, there is no need to attempt to inform firmware about it. Reviewed-by:
-
Arend van Spriel authored
Upon rmmod a few attempts are made to inform firmware, but there is no point as the bus is down and these will fail. Avoid them to keep the logs clean. Reported-by:
Stefan Wahren <stefan.wahren@i2se.com> Reviewed-by:
-
Arend van Spriel authored
Clearing firmware events in brcmf_fweh_detach() is always failing because it is called only upon driver remove and communication with firmware is no longer possible. Reviewed-by:
-
Arend van Spriel authored
No point in sending a firmware command when bus is down so make it conditional checking the state. Reviewed-by:
-
Arend van Spriel authored
When brcmf_detach() from the bus layer upon rmmod we can no longer communicate. Hence we will set the bus state to DOWN and cleanup the event and protocol layer. The network interfaces need to be deleted before brcmf_cfg80211_detach() because the latter does the wiphy_unregister() which issues a warning if there are still network devices linked to the wiphy instance. Reviewed-by:
-
Arend van Spriel authored
This reverts commit 5cdb0ef6. Subsequent changes make rework the driver code fixing the issue differently. Signed-off-by:
-
Arend van Spriel authored
The driver has custom regulatory rules which had maximum bandwidth for 5GHz channels set to 80MHz. As a consequence the driver can not use 160MHz in AP mode even when the device supports it. So relax the rules allowing 160MHz. After wiphy_register() the channel flags are updated according what the device actually supports. Reviewed-by:
-
Arend van Spriel authored
If the firmware supports 802.11h and the device can operate in 5GHz band we can enable DFS_OFFLOAD extended feature. Reviewed-by:
-
Arend van Spriel authored
The function chandef_to_chanspec() was not handling 160MHz bandwidth resulting in wrong encoding of the channel. That resulting in firmware rejecting the provided channel specification. Reviewed-by:
-
Jian-Hong Pan authored
Since each skb in RX ring is reused instead of new allocation, we can treat the DMA in a more efficient way by DMA synchronization. Signed-off-by:
Jian-Hong Pan <jian-hong@endlessm.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Jian-Hong Pan authored
Testing with RTL8822BE hardware, when available memory is low, we frequently see a kernel panic and system freeze. First, rtw_pci_rx_isr encounters a memory allocation failure (trimmed): rx routine starvation WARNING: CPU: 7 PID: 9871 at drivers/net/wireless/realtek/rtw88/pci.c:822 rtw_pci_rx_isr.constprop.25+0x35a/0x370 [rtwpci] [ 2356.580313] RIP: 0010:rtw_pci_rx_isr.constprop.25+0x35a/0x370 [rtwpci] Then we see a variety of different error conditions and kernel panics, such as this one (trimmed): rtw_pci 0000:02:00.0: pci bus timeout, check dma status skbuff: skb_over_panic: text:00000000091b6e66 len:415 put:415 head:00000000d2880c6f data:000000007a02b1ea tail:0x1df end:0xc0 dev:<NULL> ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:105! invalid opcode: 0000 [#1] SMP NOPTI RIP: 0010:skb_panic+0x43/0x45 When skb allocation fails and the "rx routine starvation" is hit, the function returns immediately without updating the RX ring. At this point, the RX ring may continue referencing an old skb which was already handed off to ieee80211_rx_irqsafe(). When it comes to be used again, bad things happen. This patch allocates a new, data-sized skb first in RX ISR. After copying the data in, we pass it to the upper layers. However, if skb allocation fails, we effectively drop the frame. In both cases, the original, full size ring skb is reused. In addition, to fixing the kernel crash, the RX routine should now generally behave better under low memory conditions. Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=204053Signed-off-by:
-
Kevin Easton authored
This sentinel tells the firmware loading process when to stop. Reported-and-tested-by: syzbot+98156c174c5a2cad9f8f@syzkaller.appspotmail.com Signed-off-by:
Kevin Easton <kevin@guarana.org> Signed-off-by:
-
Joe Perches authored
Arguments are supposed to be ordered high then low. Signed-off-by:
Joe Perches <joe@perches.com> Acked-by:
-
Colin Ian King authored
The variable rc is being initialized with a value that is never read and it is being updated later with a new value that is returned. The variable is redundant and can be replaced with a return 0 as there are no other return points in this function. Addresses-Coverity: ("Unused value") Signed-off-by:Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Colin Ian King authored
The variable ret is being initialized with a value that is never read and it is being updated later with a new value. The initialization is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by: -
Chris Chiu authored
The WiFi tx power of RTL8723BU is extremely low after booting. So the WiFi scan gives very limited AP list and it always fails to connect to the selected AP. This module only supports 1x1 antenna and the antenna is switched to bluetooth due to some incorrect register settings. Compare with the vendor driver https://github.com/lwfinger/rtl8723bu, we realized that the 8723bu's enable_rf() does the same thing as rtw_btcoex_HAL_Initialize() in vendor driver. And it by default sets the antenna path to BTC_ANT_PATH_BT which we verified it's the cause of the wifi weak tx power. The vendor driver will set the antenna path to BTC_ANT_PATH_PTA in the consequent btcoexist mechanism, by the function halbtc8723b1ant_PsTdma. This commit hand over the antenna control to PTA(Packet Traffic Arbitration), which compares the weight of bluetooth/wifi traffic then determine whether to continue current wifi traffic or not. After PTA take control, The wifi signal will be back to normal and the bluetooth scan can also work at the same time. However, the btcoexist still needs to be handled under different circumstances. If there's a BT connection established, the wifi still fails to connect until BT disconnected. Signed-off-by:
Chris Chiu <chiu@endlessm.com> Signed-off-by:
-
Greg Kroah-Hartman authored
When calling debugfs functions, there is no need to ever check the return value. The function can work or not, but the code logic should never do something different based on this. Because we don't need to save the individual debugfs files and directories, remove the local storage of them and just remove the entire debugfs directory in a single call, making things a lot simpler. Cc: Stanislaw Gruszka <sgruszka@redhat.com> Cc: Helmut Schaa <helmut.schaa@googlemail.com> Cc: Kalle Valo <kvalo@codeaurora.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: linux-wireless@vger.kernel.org Cc: netdev@vger.kernel.org Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by:
-
Soeren Moch authored
In contrast to the TX path, there is no need to separately read the transfer status from the device after receiving RX data. Consequently, there is no real STATUS_PENDING RX processing queue entry state. Remove the unnecessary ENTRY_DATA_STATUS_PENDING flag checks from the RX path. Also remove the misleading comment about reading RX status from device. Suggested-by:
Soeren Moch <smoch@web.de> Acked-by:
-
Enrico Weigelt authored
Explicitly return constants instead of variable (and rely on it to be explicitly initialized), if the value is supposed to be fixed anyways. Align it with the rest of the driver, which does it the same way. Signed-off-by:
Enrico Weigelt <info@metux.net> Signed-off-by:
-
