...@codeaurora.org; Larry Finger
Subject: Re: rtlwifi/rtl8192cu AP mode broken with PS STA
On 08.04.2021 21:04, Maciej S. Szmigiero wrote:
On 08.04.2021 06:42, Pkshih wrote:
-Original Message-
From: Maciej S. Szmigiero [mailto:m...@maciej.szmigiero.name]
Sent: Thursday, April 08, 2021 4:53
On 4/6/21 9:48 PM, Pkshih wrote:
On Tue, 2021-04-06 at 11:25 -0500, Larry Finger wrote:
On 4/6/21 7:06 AM, Maciej S. Szmigiero wrote:
On 06.04.2021 12:00, Kalle Valo wrote:
"Maciej S. Szmigiero" writes:
On 29.03.2021 00:54, Maciej S. Szmigiero wrote:
Hi,
It looks like rtlwifi
On 4/6/21 7:06 AM, Maciej S. Szmigiero wrote:
On 06.04.2021 12:00, Kalle Valo wrote:
"Maciej S. Szmigiero" writes:
On 29.03.2021 00:54, Maciej S. Szmigiero wrote:
Hi,
It looks like rtlwifi/rtl8192cu AP mode is broken when a STA is using PS,
since the driver does not update its beacon to
wifi/wifi.h
+++ b/drivers/net/wireless/realtek/rtlwifi/wifi.h
@@ -2450,7 +2450,6 @@ struct rtl_locks {
spinlock_t waitq_lock;
spinlock_t entry_list_lock;
spinlock_t usb_lock;
- spinlock_t c2hcmd_lock;
spinlock_t scan_list_lock; /* lock for the scan list */
table[i] = coef[i];
+ coef[i] = table[i];
else
coef[i] = 0;
}
Acked-by: Larry Finger
Good catch, thanks.
Larry
*/
{} /* Terminating entry */
};
Acked-by: Larry Finger
Larry
On 2/2/21 12:29 AM, Kalle Valo wrote:
Kai-Heng Feng writes:
On Wed, Aug 5, 2020 at 7:24 PM Kai-Heng Feng
wrote:
Hi Tony,
On Aug 5, 2020, at 19:18, Tony Chuang wrote:
8821CE with RFE 2 isn't supported:
[ 12.404834] rtw_8821ce :02:00.0: rfe 2 isn't supported
[ 12.404937]
On 1/8/21 9:32 AM, Aditya Srivastava wrote:
There are certain conditional expressions in rtlwifi, where a boolean
variable is compared with true/false, in forms such as (foo == true) or
(false != bar), which does not comply with checkpatch.pl (CHECK:
BOOL_COMPARISON), according to which boolean
On 1/5/21 5:55 AM, Joe Perches wrote:
On Tue, 2021-01-05 at 17:11 +0530, Bhaskar Chowdhury wrote:
On 22:24 Tue 05 Jan 2021, Julian Calaby wrote:
Hi Bhaskar,
[]
and your change is just making this comment worse.
really??? Not sure about it.
I agree with Julian. I'm fairly sure it's worse.
On 11/17/20 7:53 PM, Jia-Ju Bai wrote:
In rtl88ee_tx_fill_cmddesc(), skb->data is mapped to streaming DMA on
line 677:
dma_addr_t mapping = dma_map_single(..., skb->data, ...);
On line 680, skb->data is assigned to hdr after cast:
struct ieee80211_hdr *hdr = (struct ieee80211_hdr
"
Cc: Jakub Kicinski
Cc: Larry Finger
Cc: linux-wirel...@vger.kernel.org
Cc: net...@vger.kernel.org
Signed-off-by: Lee Jones
---
drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi
On 10/21/20 2:33 AM, Jing Xiangfeng wrote:
Fix to return error code -EINVAL from the error handling case instead
of 0.
Signed-off-by: Jing Xiangfeng
---
drivers/ssb/scan.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/ssb/scan.c b/drivers/ssb/scan.c
index
(-)
Acked-by: Larry Finger
Larry
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c
b/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c
index 3c7ba8214daf..0748aedce2ad 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi
-by: Larry Finger
Larry
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192de/hw.c
b/drivers/net/wireless/realtek/rtlwifi/rtl8192de/hw.c
index 2deadc7339ce..f849291cc587 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192de/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192de/hw.c
-by: Larry Finger
Larry
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c
b/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c
index d4cd186036fd..bb5a0c4aec93 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c
/phy.c:1839:5-13: WARNING:
Comparison to bool
Signed-off-by: Zheng Bin
---
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Acked-by: Larry Finger
Larry
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c
b
(-)
Acked-by: Larry Finger
Larry
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c
b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c
index 3061bd81f39e..6312fddd9c00 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi
(-)
Acked-by: Larry Finger
Larry
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c
b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c
index b2e5b9fda669..33ffc24d3675 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi
-by: Larry Finger
Larry
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/mac.c
b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/mac.c
index d7afb6a186df..2890a495a23e 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/mac.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu
(+), 1 deletion(-)
Acked-by: Larry Finger
Larry
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192c/phy_common.c
b/drivers/net/wireless/realtek/rtlwifi/rtl8192c/phy_common.c
index fc6c81291cf5..6a3deca404b9 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192c/phy_common.c
+++ b
On 8/31/20 5:46 AM, Anshuman Khandual wrote:
On 08/29/2020 06:40 AM, Larry Finger wrote:
In kernel 5.9.0-rc1 on a PowerBook G4 (ppc32), several warnings of the
following type are logged:
[ cut here ]
WARNING: CPU: 0 PID: 1 at arch/powerpc/mm/pgtable.c:185
In kernel 5.9.0-rc1 on a PowerBook G4 (ppc32), several warnings of the following
type are logged:
[ cut here ]
WARNING: CPU: 0 PID: 1 at arch/powerpc/mm/pgtable.c:185 set_pte_at+0x20/0x100
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 5.9.0-rc2 #2
NIP:
13 +-
12 files changed, 115 insertions(+), 132 deletions(-)
Tested-by: Larry Finger for rtl8821ae.
Larry
On 7/27/20 9:52 AM, Joe Perches wrote:
On Mon, 2020-07-27 at 09:04 +, Pkshih wrote:
So, I think you would like to have parenthesis intentionally.
If so,
test1 ? : (test2 ? :)
would be better.
If not,
test1 ? : test2 ? :
may be what you want (without any parenthesis).
Use whatever style
On 7/26/20 3:40 AM, Aditya Jain wrote:
On Sun, Jul 26, 2020 at 1:56 PM Greg KH wrote:
On Sun, Jul 26, 2020 at 01:32:15PM +0530, Aditya Jain wrote:
Fixing ERROR: "foo * bar" should be "foo *bar" in hal_phy_cfg.h
as reported by checkpatch.pl
Signed-off-by: Aditya Jain
---
On 7/25/20 1:39 PM, Joe Perches wrote:
On Sat, 2020-07-25 at 12:47 -0500, Larry Finger wrote:
On 7/25/20 7:20 AM, Anant Thazhemadam wrote:
Running the checkpatch.pl script on the file for which patch was created, the
following error was found to exist.
ERROR: space required after
On 7/25/20 7:20 AM, Anant Thazhemadam wrote:
Running the checkpatch.pl script on the file for which patch was created, the
following error was found to exist.
ERROR: space required after that ',' (ctx:VxV)
Fixed the above error which was found on line #721 by inserting a blank
space at the
On 7/24/20 8:28 AM, Dinghao Liu wrote:
The variable authmode will keep uninitialized if neither if
statements used to initialize this variable are not triggered.
Besides Greg's comment, you need to re-parse this sentence. I realize that
English is probably not your first language, but this
ave already fixed 4 places with unnecessary alignment, but, alas, there is no
great desire to test them on real hardware.
I have now tested on real hardware and it works fine.
Acked-by: Larry Finger
Larry
On 7/13/20 2:13 PM, Saheed Bolarinwa wrote:
Hello Larry,
On 7/13/20 7:16 PM, Larry Finger wrote:
On 7/13/20 7:22 AM, Saheed O. Bolarinwa wrote:
In reference to the PCI spec (Chapter 2), PCIBIOS* is an x86 concept.
Their scope should be limited within arch/x86.
Change all PCIBIOS_SUCCESSFUL
On 7/13/20 7:22 AM, Saheed O. Bolarinwa wrote:
In reference to the PCI spec (Chapter 2), PCIBIOS* is an x86 concept.
Their scope should be limited within arch/x86.
Change all PCIBIOS_SUCCESSFUL to 0
Signed-off-by: "Saheed O. Bolarinwa"
Could you please tell me what difference this makes? It
On 7/12/20 7:38 AM, Ivan Safonov wrote:
Remove unused members of struct xmit_buf: alloc_sz, ff_hwaddr,
dma_transfer_addr, bpending and last.
Signed-off-by: Ivan Safonov
---
Have you tested this change? Previously with this driver, an unused quantity was
removed from one of the structs and
On 6/1/20 3:24 PM, Pascal Terjan wrote:
This patch switches to and and
deletes a lot of duplicate definitions plus many unused ones.
Non obvious changes:
- struct ieee80211_ht_cap is different enough that I preferred to keep
(and rename) it for now.
- mcs_rate in translate_scan was not
On 5/23/20 12:30 PM, Christophe Leroy wrote:
Hi Larry,
Le 23/05/2020 à 19:24, Larry Finger a écrit :
Hi Christophe,
Although kernel 5.7.0-rc2 appeared to boot cleanly, it failed on my G4 when I
tried to generate a new kernel. The following BUG message is logged:
[...]
This problem
Hi Christophe,
Although kernel 5.7.0-rc2 appeared to boot cleanly, it failed on my G4 when I
tried to generate a new kernel. The following BUG message is logged:
[ 336.148935] [ cut here ]
[ 336.148950] kernel BUG at ./include/linux/swapops.h:195!
[ 336.148971]
On a system with an AMD FX-8320E Eight-Core Processor running kernel 5.7.0-rc5,
I am seeing the following memory leak:
localhost:~ # cat /sys/kernel/debug/kmemleak
unreferenced object 0x88840ca02540 (size 64):
comm "swapper/0", pid 1, jiffies 4294892775 (age 138786.084s)
hex dump (first
is OK, but the subject is wrong. It should be "[PATCH-next] rtl8187:
Remove "
With that change, ACKed-by: Larry Finger
Larry
On 10/15/19 2:32 PM, Joe Perches wrote:
Hey Larry.
Looks like this should be:
#define FALL_THROUGH __attribute__((__fallthrough__))
and there appear to be many of these #defines that
use __attribute__((foo)) where foo does not use the
double underscored prefix and suffix form
I also
Joe,
Since commit 294f69e662d1("compiler_attributes.h: Add 'fallthrough' pseudo
keyword for switch/case use"), builds of VirtualBox are failing with the
following errors:
1954s] In file included from
/usr/src/linux-5.4.0-rc3-1.g2309d7d/include/linux/compiler_types.h:59,
[ 1954s]
bcmd_down) && (retry_cnts--));
+ adapt->HalData->LastHMEBoxNum =
+ (h2c_box_num + 1) % RTL88E_MAX_H2C_BOX_NUMS;
ret = _SUCCESS;
Acked-by: Larry Finger
Thanks,
Larry
uld be
with 0x03 according to the max_rate_idx in ODM_RAInfo_Init().
Cc: Larry Finger
Cc: Greg Kroah-Hartman
Cc: Michael Straube
Cc: sta...@vger.kernel.org
Signed-off-by: Denis Efremov
---
drivers/staging/rtl8188eu/hal/hal8188e_rate_adaptive.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a
if (psta && psta->qos_option)
qos_option = true;
} else {
RT_TRACE(_module_rtl871x_xmit_c_, _drv_err_, ("fw_state:%x
is not allowed to xmit frame\n", get_fwstate(pmlmepriv)));
Acked-by: Larry Finger
Thanks,
Larry
RT_IN_PS_LEVEL(ppsc, RT_PS_LEVEL_ASPM) &&
- rtlhal->interface == INTF_PCI) {
+ RT_IN_PS_LEVEL(ppsc, RT_PS_LEVEL_ASPM)) {
rtlpriv->intf_ops->disable_aspm(hw);
RT_CLEAR_PS_LEVEL(ppsc, RT_PS_LEVEL_ASPM);
}
Acked-by: Larry Finger
Thanks,
Larry
On 9/25/19 4:32 PM, Connor Kuehl wrote:
Inside a nested 'else' block at the beginning of this function is a
call that assigns 'psta' to the return value of 'rtw_get_stainfo()'.
If 'rtw_get_stainfo()' returns NULL and the flow of control reaches
the 'else if' where 'psta' is dereferenced, then we
On 9/23/19 2:48 PM, Connor Kuehl wrote:
The local variable 'bcmd_down' is always set to true almost immediately
before the do-while's condition is checked. As a result, !bcmd_down
evaluates to false which short circuits the logical AND operator meaning
that the second operand is never reached
On 9/18/19 12:53 PM, Linus Torvalds wrote:
On Wed, Sep 18, 2019 at 10:50 AM Larry Finger wrote:
Is there approved way for pages to be set to be executable by an external module
that would not be a security issue?
Point to what external module and why.
Honestly, the likely answer is simply
On 9/18/19 11:45 AM, Christoph Hellwig wrote:
On Wed, Sep 18, 2019 at 11:41:21AM -0500, Larry Finger wrote:
In commit 185be15143aa ("x86/mm: Remove set_pages_x() and set_pages_nx()"),
the wrappers were removed as they did not provide a real benefit over
set_memory_x() and set
s a
result, external modules that used the wrappers would need to recreate
a significant part of memory management.
Signed-off-by: Larry Finger
Cc: Christoph Hellwig
Cc: Peter Zijlstra (Intel)
Fixes: 185be15143aa ("x86/mm: Remove set_pages_x() and set_pages_nx()")
Cc: Ingo Moln
s a
result, external modules that used the wrappers would need to recreate
a significant part of memory management.
Signed-off-by: Larry Finger
Cc: Christoph Hellwig
Cc: Peter Zijlstra (Intel)
Fixes: 185be15143aa ("x86/mm: Remove set_pages_x() and set_pages_nx()")
Cc: Ingo Moln
rtl8188eu/core/rtw_ieee80211.o
After:
text data bss dec hex filename
26612 5776 0 323887e84 rtl8188eu/core/rtw_ieee80211.o
(gcc version 9.2.1, amd64)
Signed-off-by: Colin Ian King
---
Acked-by: Larry Finger
Thanks,
Larry
On 8/22/19 11:11 AM, Colin Ian King wrote:
On 22/08/2019 17:03, Larry Finger wrote:
On 8/22/19 8:35 AM, Colin King wrote:
From: Colin Ian King
An earlier commit re-worked the setting of the bitmask and is now
assigning v with some bit flags rather than bitwise or-ing them
into v
On 8/22/19 8:35 AM, Colin King wrote:
From: Colin Ian King
An earlier commit re-worked the setting of the bitmask and is now
assigning v with some bit flags rather than bitwise or-ing them
into v, consequently the earlier bit-settings of v are being lost.
Fix this by replacing an assignment
On 8/8/19 2:10 AM, Kalle Valo wrote:
Larry Finger writes:
On 8/7/19 8:51 PM, Valdis Klētnieks wrote:
Fix spurious warning message when building with W=1:
CC [M] drivers/net/wireless/realtek/rtlwifi/usb.o
drivers/net/wireless/realtek/rtlwifi/usb.c:243: warning: Cannot understand
v1: Larry Finger pointed out the patch wasn't checkpatch-clean.
diff --git a/drivers/net/wireless/realtek/rtlwifi/usb.c
b/drivers/net/wireless/realtek/rtlwifi/usb.c
index 34d68dbf4b4c..4b59f3b46b28 100644
--- a/drivers/net/wireless/realtek/rtlwifi/usb.c
+++ b/drivers/net/wireless/realtek/rtlwifi
On 8/7/19 5:39 PM, Valdis Klētnieks wrote:
When this driver was originally entered, a line with "/*" was flagged by
checkpatch.pl. In fact, when I make your change, I get
WARNING: networking block comments don't use an empty /* line, use /* Comment...
#243: FILE:
deletions(-)
If they apply, all six of these are OK.
Acked-by: Larry Finger
Larry
On 7/8/19 1:32 AM, Jian-Hong Pan wrote:
diff --git a/drivers/net/wireless/realtek/rtw88/pci.c
b/drivers/net/wireless/realtek/rtw88/pci.c
index cfe05ba7280d..1bfc99ae6b84 100644
--- a/drivers/net/wireless/realtek/rtw88/pci.c
+++ b/drivers/net/wireless/realtek/rtw88/pci.c
@@ -786,6 +786,15 @@
On 7/4/19 10:44 PM, Daniel Drake wrote:
On Wed, Jul 3, 2019 at 8:59 PM Jes Sorensen wrote:
My point is this seems to be very dongle dependent :( We have to be
careful not breaking it for some users while fixing it for others.
Do you still have your device?
Once we get to the point when you
On 6/14/19 2:15 PM, Aaro Koskinen wrote:
Hi,
On Fri, Jun 14, 2019 at 09:24:16AM +0200, Mathieu Malaterre wrote:
On Thu, Jun 13, 2019 at 10:27 AM Christoph Hellwig wrote:
With the strict dma mask checking introduced with the switch to
the generic DMA direct code common wifi chips on 32-bit
.
Fixes: 65a21b71f948 ("powerpc/dma: remove dma_nommu_dma_supported")
Reported-by: Aaro Koskinen
Signed-off-by: Christoph Hellwig
As expected, it works. The patch needs
Cc: Stable # v5.1+
Tested-by: Larry Finger
Acked-by: Larry Finger
Thanks for the help, and the patience with my
On 6/12/19 1:55 AM, Christoph Hellwig wrote:
Ooops, yes. But I think we could just enable ZONE_DMA on 32-bit
powerpc. Crude enablement hack below:
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 8c1c636308c8..1dd71a98b70c 100644
--- a/arch/powerpc/Kconfig
+++
On 6/11/19 5:46 PM, Aaro Koskinen wrote:
Hi,
On Tue, Jun 11, 2019 at 05:20:12PM -0500, Larry Finger wrote:
It is obvious that the case of a mask smaller than min_mask should be
handled by the IOMMU. In my system, CONFIG_IOMMU_SUPPORT is selected. All
other CONFIG variables containing IOMMU
On 6/11/19 5:46 PM, Benjamin Herrenschmidt wrote:
On Tue, 2019-06-11 at 17:20 -0500, Larry Finger wrote:
b43-pci-bridge 0001:11:00.0: dma_direct_supported: failed (mask =
0x3fff,
min_mask = 0x5000/0x5000, dma bits = 0x1f
Ugh ? A mask with holes in it ? That's very wrong
On 6/11/19 1:05 AM, Christoph Hellwig wrote:
On Mon, Jun 10, 2019 at 11:09:47AM -0500, Larry Finger wrote:
What might be confusing in your output is that dev->dma_mask is a pointer,
and we are setting it in dma_set_mask. That is before we only check
if the pointer is set, and later we overr
On 6/7/19 11:21 PM, Benjamin Herrenschmidt wrote:
Please try the attached patch. I'm not really pleased with it and I will
continue to determine why the fallback to a 30-bit mask fails, but at least this
one works for me.
Your patch only makes sense if the device is indeed capable of
On 6/10/19 3:18 AM, Christoph Hellwig wrote:
On Sat, Jun 08, 2019 at 04:52:24PM -0500, Larry Finger wrote:
On 6/7/19 12:29 PM, Christoph Hellwig wrote:
I don't think we should work around this in the driver, we need to fix
it in the core. I'm curious why my previous patch didn't work. Can
On 6/7/19 12:29 PM, Christoph Hellwig wrote:
I don't think we should work around this in the driver, we need to fix
it in the core. I'm curious why my previous patch didn't work. Can
you throw in a few printks what failed? I.e. did dma_direct_supported
return false? Did the actual allocation
On 6/7/19 12:29 PM, Christoph Hellwig wrote:
I don't think we should work around this in the driver, we need to fix
it in the core. I'm curious why my previous patch didn't work. Can
you throw in a few printks what failed? I.e. did dma_direct_supported
return false? Did the actual allocation
1
From: Larry Finger
Date: Fri, 7 Jun 2019 12:04:16 -0500
Subject: [PATCH] b43legacy: Fix DMA breakage from commit commit 65a21b71f948
To: kv...@codeaurora.org
Cc: linux-wirel...@vger.kernel.org,
pks...@realtek.com
Following commit 65a21b71f948 ("powerpc/dma: remove dma_nommu_dm
On 6/6/19 6:43 AM, Christoph Hellwig wrote:
On Thu, Jun 06, 2019 at 08:57:49PM +1000, Benjamin Herrenschmidt wrote:
Wow... that's an odd amount. One thing we could possibly do is add code
to limit the amount of RAM when we detect that device
Sent too quickly... I mean that *or* force
On 6/6/19 6:43 AM, Christoph Hellwig wrote:
On Thu, Jun 06, 2019 at 08:57:49PM +1000, Benjamin Herrenschmidt wrote:
Wow... that's an odd amount. One thing we could possibly do is add code
to limit the amount of RAM when we detect that device
Sent too quickly... I mean that *or* force
On 6/5/19 5:50 PM, Aaro Koskinen wrote:
Hi,
When upgrading from v5.0 -> v5.1 on G4 PowerBook, I noticed WLAN does
not work anymore:
[ 42.004303] b43legacy-phy0: Loading firmware version 0x127, patch level 14
(2005-04-18 02:36:27)
[ 42.184837] b43legacy-phy0 debug: Chip initialized
[
On 5/31/19 9:14 AM, Colin King wrote:
From: Colin Ian King
The assignment of 0 to variable k is never read once we break out of
the loop, so the assignment is redundant and can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King
---
-by: Colin Ian King
---
Acked-by: Larry Finger
Thanks,
Larry
drivers/net/wireless/realtek/rtlwifi/efuse.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/efuse.c
b/drivers/net/wireless/realtek/rtlwifi/efuse.c
index e68340dfd980..37ab582a8
On 5/29/19 12:03 AM, Chris Chiu wrote:
We have 3 laptops which connect the wifi by the same RTL8723BU.
The PCI VID/PID of the wifi chip is 10EC:B720 which is supported.
They have the same problem with the in-kernel rtl8xxxu driver, the
iperf (as a client to an ethernet-connected server) gets
On 5/29/19 5:30 AM, Jia-Ju Bai wrote:
On 2019/5/28 21:00, Larry Finger wrote:
On 5/28/19 6:55 AM, Kalle Valo wrote:
Jia-Ju Bai wrote:
*BUG 1:
In rtl_pci_probe(), when rtlpriv->cfg->ops->init_sw_vars() fails,
rtl_deinit_core() in the error handling code is executed.
rtl_deinit_cor
On 5/28/19 6:55 AM, Kalle Valo wrote:
Jia-Ju Bai wrote:
*BUG 1:
In rtl_pci_probe(), when rtlpriv->cfg->ops->init_sw_vars() fails,
rtl_deinit_core() in the error handling code is executed.
rtl_deinit_core() calls rtl_free_entries_from_scan_list(), which uses
rtlpriv->scan_list.list in
On 5/15/19 8:06 AM, Kai-Heng Feng wrote:
at 20:33, Greg KH wrote:
On Wed, May 15, 2019 at 07:54:58PM +0800, Kai-Heng Feng wrote:
at 19:40, Greg KH wrote:
On Wed, May 15, 2019 at 07:24:01PM +0800, Kai-Heng Feng wrote:
The rtl8821ce can be found on many HP and Lenovo laptops.
Users have
newer than mine. In any
case, the changes are harmless.
Acked-by: Larry Finger
---
drivers/staging/rtl8188eu/Kconfig | 4 ++--
drivers/staging/rtl8192e/Kconfig | 8
drivers/staging/rtl8712/Kconfig | 4 ++--
drivers/staging/rtl8723bs/Kconfig | 2 +-
4 files changed, 9 insert
time.
So the virtual address of the field should be used instead, but in
the meantime, thread struct has already been zeroised and initialised
so we can just drop this initialisation.
Reported-by: Larry Finger
Fixes: 0df977eafc79 ("powerpc/6xx: Don't use SPRN_SPRG2 for storing stack pointer
On 3/25/19 3:46 AM, Christophe Leroy wrote:
Le 25/03/2019 à 01:49, Larry Finger a écrit :
A build of kernel 5.1.0-rc2 resulted in a failure to boot on my PowerBook G4
Aluminum. The bootstrap loads the initial kernel and issues the appropriate
start, but the machine hangs at that point
On 3/25/19 1:53 AM, Christophe Leroy wrote:
Le 25/03/2019 à 01:49, Larry Finger a écrit :
A build of kernel 5.1.0-rc2 resulted in a failure to boot on my PowerBook G4
Aluminum. The bootstrap loads the initial kernel and issues the appropriate
start, but the machine hangs at that point.
Can
lpphy_papd_cal(dev, gains, 0, 1, 65);
+ lpphy_papd_cal(dev, oldgains, 0, 1, 65);
if (old_afe_ovr)
lpphy_set_tx_gains(dev, oldgains);
Acked-by: Larry Finger
Thanks. I will submit a patch that removes lpphy_papd_cal(). You are correct
that it is unlikely ever to be implemented.
Larry
On 3/2/19 12:09 PM, David R. Bergstein wrote:
Larry,
I tried using iw but it gives the same reading for bit rate. In regard
to the firmware, it was not installed via "make install" so I did it
manually.
David,
There was a typo in the Makefile. 'make install' now installs the firmware
On 3/1/19 9:52 PM, David R. Bergstein wrote:
Larry,
Sorry about all these extra replies. Shortly after I sent my last
message my access point started recognizing the connection as 802.11ac
with PHY Rate / Modulation Rate of 866.6 Mbps. What is somewhat
misleading is the information reported
On 3/1/19 4:26 PM, David R. Bergstein wrote:
Larry,
Thanks for the response and detailed instructions, which allowed me to
build and install the rtw88 kernel module. I cannot however seem to get
my system to actually use the module. Just to recap this is an HP Omen
laptop with secure boot
On 2/28/19 8:32 PM, David R. Bergstein wrote:
Tony,
Thanks for your response. Can you advise as to the availability of the
new rtw88 driver? As it appears to be under development, I could not
locate a copy of the code for local compilation.
David,
Use the command 'git clone
-...@lists.infradead.org
Signed-off-by: Greg Kroah-Hartman
Acked-by: Larry Finger
Thanks,
Larry
On 1/22/19 9:21 AM, Greg Kroah-Hartman wrote:
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.
Cc: Larry Finger
Cc: Kalle Valo
Cc: linux-wirel
...@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman
Greg,
Please change the subject to read "rtlwifi: ...". Otherwise the patch is
correct.
Acked-by: Larry Finger
Thanks,
Larry
between
calls to this routine. Your fix is correct.
Acked-by: Larry Finger
Thanks,
Larry
On 1/17/19 1:29 PM, Joe Perches wrote:
On Thu, 2019-01-17 at 15:28 +, Colin King wrote:
From: Colin Ian King
There is a statement that is indented too deeply. Fix this.
Thanks.
diff --git a/drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c
On 1/8/19 4:49 PM, Bernd Edlinger wrote:
Currently the rtl8723ae driver is broken (since v4.7).
Connection to AP is lost very often, especially when
the signal level is not very good.
The main issue is the power save mode is basically
not working, and seems to trigger a firmware bug.
So I had
On 1/7/19 11:28 AM, Michael Straube wrote:
This device was added to the stand-alone driver on github.
Add it to the staging driver as well.
Link: https://github.com/lwfinger/rtl8188eu/commit/a0619a07cd1e
Signed-off-by: Michael Straube
Acked-by: Larry Finger
Thanks,
Larry
On 1/5/19 12:38 PM, Bernd Edlinger wrote:
Currently the rtl8723ae driver is broken (since v4.7).
Connection to AP is lost very often, especially when
the signal level is not very good.
The main issue is the power save mode is basically
not working, and seems to trigger a firmware bug.
So I had
On 1/5/19 10:30 AM, Bernd Edlinger wrote:
On 1/5/19 5:13 PM, Larry Finger wrote:
but this works:
modprobe rtl8723ae debug_mask=0x debug_level=5 swlps=1 fwlps=0
Yes, I think that is a better thing to do now. If and when Realtek finds a
firmware bug, and when the new firmware
On 1/5/19 5:31 AM, Bernd Edlinger wrote:
On 1/5/19 3:44 AM, Larry Finger wrote:
On 1/4/19 6:48 AM, Bernd Edlinger wrote:
This appears to trigger a firmware bug and causes severe
problems with rtl8723ae PCI devices.
When the power save mode is activated for longer periods
of time the firmware
On 1/5/19 3:10 AM, Július Milan wrote:
Fixes the following sparse warnings:
drivers/staging/wilc1000/host_interface.c:2360:30: warning:
incorrect type in assignment (different base types)
expected restricted __le32 [addressable] [assigned] [usertype] frame_type
got restricted __le16
On 1/4/19 6:48 AM, Bernd Edlinger wrote:
This appears to trigger a firmware bug and causes severe
problems with rtl8723ae PCI devices.
When the power save mode is activated for longer periods
of time the firmware stops to receive any packets.
This problem was exposed by commit 873ffe154ae0
On 1/1/19 1:31 PM, Michael Straube wrote:
I've tested your patch and it solved the issue. No freezes and dmesg looks good.
I noticed that try_then_request_module() is also used in rtw_wep_encrypt() and
rtw_wep_decrypt(). I guess that also could cause problems?
Yes, I believe it would if
1 - 100 of 1407 matches
Mail list logo
