...@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
tek comes: are there plans to actually
fix this?
Yes, I am working on this. My only question is "if you are such an expert on the
problem, why do you not fix it?"
The example in rx200 is not particularly useful, and I have not found any other
examples.
Larry
0,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 */
/*FW clock change */
Acked-by: Larry Finger
Thanks,
Larry
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
hould add it:
https://patchwork.kernel.org/project/linux-wireless/patch/20210202055012.8296-4-pks...@realtek.com/
New firmware (rtw8821c_fw.bin) is also needed. That is available at
https://github.com/lwfinger/rtw88.git.
Larry
or a given driver in case something goes
wrong.Note: The driver for ps is rtl_pci, and that for rtl8192c is
rtl8192c-common. The other driver names match their directory.
Larry
es for these drivers, the subject should be
"rtlwifi: : Fix description of usage of own bit in descriptor"
For all drivers, that comment should be written as:
/* By default, a beacon packet will only use the first
* descriptor and the own bit may not be cleared by the hardware
*/
Larry
anges, but
it is also possible to provide a diffstat of the changes as the above file shows.
Larry
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c
b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c
index b9775eec4c54..c948dafa0c80 100644
--- a/drivers/net/wireless/realte
quot;David S. Miller"
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/wire
Welcome to 24Hour Loan Service
Have you tried to obtain loans from banks without success? Urgently need money
to get out of debt? Need money for expansion or establishment of your own
business? Get a loan from one of the UK's leading loan companies. 24Hour Loan
Service is one of the largest se
this
error is not likely to appear and it does not make much difference!
In any case, the commit message is wrong. NACK.
Larry
(-)
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
: 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
: 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
: 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
cation turns the warning statements into BUGS.
The problem was bisected to commit a5c3b9ffb0f4 ("mm/debug_vm_pgtable: add tests
validating advanced arch page table helpers") by Anshuman Khandual
Thanks,
Larry
-
.../wireless/realtek/rtlwifi/rtl8723be/trx.c | 13 +-
.../wireless/realtek/rtlwifi/rtl8821ae/hw.c | 9 +-
.../wireless/realtek/rtlwifi/rtl8821ae/trx.c | 13 +-
12 files changed, 115 insertions(+), 132 deletions(-)
Tested-by: Larry Finger for rtl8821ae.
Larry
;PATCH v2 00/15] rtlwifi:
Change RT_TRACE into rtl_dbg for all drivers".
Larry
n the variable type and
the name, but that is probably the subject of separate patches.
Larry
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 that
}
}
In fixing one checkpatch.pl condition, you introduced another - the resulting
line is too long. You should fix only one such condition, but you should fix any
others that are introduced. You do need to document it.
Patch subjects for this driver should be written as "staging: rtl8188eu: .".
Larry
. Thus your statement "Then authmode may
contain a garbage value and influence the execution flow of this function." is
false.
Larry
I have 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
makes? It looks like source churn
rather than a substantive change. The symbol is defined in pci.h and is used in
many architures. Certainly, PCIBIOS_SUCCESSFUL indicates success even more
clearly than 0 does.
Why is your name inside quotes in your s-o-b?
Larry
the driver failed. Apparently, the alignment
of some other quantity was affected. I do not think that this change would have
that affect; however, you should be testing whenever the changes are more than
cosmetic.
Larry
wireless-drivers-next. Where did you intend it to go? Staging is the correct tree.
Larry
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 was
ore
time to fix it before release of 5.7, but every other problem I have found
happened at boot, not when the machine had to swap.
Thanks,
Larry
This is a "family 0x15" AMD CPU, thus MSR saving is needed during suspending. I
believe this to be a false positive.
The indicated memory allocation has been in the kernel since v4.5.0. Should a
patch be sent to clear this false memory leak indication for systems with AMD
processors?
Larry
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
~~
I think the internal macros in the Oracle code are correct - at least they
worked before the patch in question was applied.
I would appreciate any suggestions.
Thanks,
Larry
< RTL88E_MESSAGE_BOX_SIZE; cmd_idx++)
+ usb_write8(adapt, msgbox_addr + cmd_idx, *((u8 *)(&h2c_cmd) +
cmd_idx));
- } while ((!bcmd_down) && (retry_cnts--));
+ adapt->HalData->LastHMEBoxNum =
+ (h2c_box_num + 1) % RTL88E_MAX_H2C_BOX_NUMS;
ret = _SUCCESS;
Acked-by: Larry Finger
Thanks,
Larry
d 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 --
r->addr3, get_bssid(pmlmepriv), ETH_ALEN);
- if (psta->qos_option)
+ 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
mepriv), ETH_ALEN);
- if (psta->qos_option)
+ 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)));
This change is a good one, but why not get the same fix at line 779?
Larry
lways be executed once,
thus you could remove the loop and the loop variable bcmd_down.
@greg: If you would prefer a two-step process, then this one is OK.
Larry
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_memory_
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 Molnar
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
7eb5 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
ust above this section, I
agree that this is likely an error, but that error happened in an earlier
commit. Thus 2be25cac8402 did not introduce the error, merely copied it.
Has this change been tested?
Larry
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 *
on
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/rt
struct sk_buff_head *list)
Because you merely shift the warning to a different tool,
NACK.
Larry
ons(+), 38 deletions(-)
If they apply, all six of these are OK.
Acked-by: Larry Finger
Larry
WARN(), otherwise the logs
will be flooded once this condition triggers.
Larry
are happy with Chris's two patches
here on a code review level, we'll reach out to other driver
contributors plus people who previously complained about these types
of problems, and see if we can get some wider testing.
Larry, do you have these devices, can you help with testing too?
I
nce to b43-legacy.
Using b43 on my macmini g4 never showed those symptoms (using
5.2.0-rc2+)
According to Wikipedia Mac mini G4 is limited to 1 GB RAM, so that's
why you don't see the issue.
He wouldn't see it with b43. Those cards have 32-bit DMA.
Larry
.
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
.
Do you have any ideas on what should trigger the change in ARCH_ZONE_BITS?
Should it be CONFIG_PPC32 defined, or perhaps CONFIG_G4_CPU defined?
Larry
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 are
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
e new enough to use b43 rather than b43legacy work with
new kernels; however, they have and use 32-bit DMA.
Larry
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&#x
der bit of dev->dma_mask.
Suggestions are welcome.
These tests have all been with your patch that sets ARCH_ZONE_DMA_BITS to 30.
Larry
This is based on (but somewhat different from) what hugetlbfs
does to share/unshare page tables.
Signed-off-by: Larry Bassel
---
include/linux/hugetlb.h | 4 ++
mm/huge_memory.c| 37 +
mm/hugetlb.c| 8 ++--
mm/memory.c | 108
Signed-off-by: Larry Bassel
---
arch/arm64/Kconfig | 2 +-
arch/arm64/mm/hugetlbpage.c | 2 +-
arch/x86/Kconfig| 2 +-
mm/hugetlb.c| 6 +++---
4 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 697ea05
ntation of sharing and unsharing is based
on, but somewhat different than that in mm/hugetlb.c,
though some of the code from this file could be reused and
thus was made non-static.
Larry Bassel (2):
Rename CONFIG_ARCH_WANT_HUGE_PMD_SHARE to
CONFIG_ARCH_HAS_HUGE_PMD_SHARE
Implement sharing/un
tual allocation fail?
I agree that that patch should not be sent upstream. I posted it only so that
anyone running into the problem would have a work around.
I will try to see why your patch failed.
Larry
zky
Signed-off-by: Michael Ellerman
Aaro,
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.
Larry
>From 25e2f50273e785598b6bd9a8aee28cf825d3fe9f Mon Sep 17 00:00:0
e_pfns[ZONE_DMA] = min(max_low_pfn,
+ ((1UL << ARCH_ZONE_DMA_BITS) - 1) >> PAGE_SHIFT);
#endif
max_zone_pfns[ZONE_NORMAL] = max_low_pfn;
#ifdef CONFIG_HIGHMEM
This trial patch failed.
Larry
d
be better. I still need to understand why the same setup works in b43 and fails
in b43legacy. :(
Larry
turns.
I am trying to find a patch.
Larry
potential
unterminated "while" loop, and that this condition is extremely unlikely to happen.
Larry
-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..37ab582a8afb 10
fix this. Thanks.
Signed-off-by: Chris Chiu
I have not tested this patch, but I plan to soon.
Larry
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
ed. Finally, a null-pointer
dereference occurs due to the same reason of the above bug.
To fix this bug, the initialization of lists in rtl_init_core() are
performed before the call to rtl_regd_init().
These bugs are found by a runtime fuzzing tool named FIZZER written by
us.
Signed-off-by: Jia-Ju B
On 14 May 19 16:01, Kirill A. Shutemov wrote:
> On Thu, May 09, 2019 at 09:05:33AM -0700, Larry Bassel wrote:
[trim]
> > --- a/mm/huge_memory.c
> > +++ b/mm/huge_memory.c
> > @@ -1747,6 +1747,33 @@ static inline void zap_deposited_table(struct
> > mm_struct *mm, pmd_t *
t a wifi driver should require 200K lines of code!
Larry
On 14 May 19 15:28, Kirill A. Shutemov wrote:
> On Thu, May 09, 2019 at 09:05:31AM -0700, Larry Bassel wrote:
> > This patchset implements sharing of page table entries pointing
> > to 2MiB pages (PMDs) for FS/DAX on x86.
>
> -EPARSE.
>
> How do you share entries? En
your Kconfig may be 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 fil
t that 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 storin
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.
The
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
1, 30);
else
- 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 i
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
I will be
backporting to kernels at least as old as 4.0.
I would appreciate your comments and bug reports.
Larry
, we/RedHat have quite a bit of experience running on several
large system
(32TB/128nodes/1024CPUs). Some of these systems have NVRAM and can operated
in memory mode as well as storage mode.
Larry
> So am I. We may want to rethink the whole NUMA API and the way we handle
> different types
[adding linux-mm]
On 21 Feb 19 15:41, Jerome Glisse wrote:
> On Wed, Feb 20, 2019 at 03:06:22PM -0800, Larry Bassel wrote:
> > I'm working on sharing page tables in the DAX/XFS/PMEM/PMD case.
> >
> > If multiple processes would use the identical page of PMDs correspond
inted to?) so that
I could do the right thing here.
I understand that I may have missed something obvious here.
Thanks.
Larry
re my copied
page is persistent)?
Thanks.
Larry
-...@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
1 - 100 of 978 matches
Mail list logo
