gree...@candelatech.com wrote:
> The vdev-start-response message should cause the
> completion to fire, even in the error case. Otherwise,
> the user still gets no useful information and everything
> is blocked until the timeout period.
>
> Add some warning text to print out the invalid status
From: Johannes Berg
Date: Mon, 3 Sep 2018 14:15:45 +0200
> This time around for mac80211 I have a larger than usual number of
> fixes, in part because Luca dumped our (Intel's) patches out after
> quite a while - we'll try to make sure this doesn't happen again.
>
> Shortlog below, as usual,
Govind Singh wrote:
> WCN3990 target uses separate htc service for pktlog.
> Add pktlog service request and support for pktlog
> rx path handling.
>
> Testing:
> Tested on WCN3990 and QCA6174 HW.
> Tested FW: WLAN.HL.2.0-01192-QCAHLSWMTPLZ-1,
>
Sathishkumar Muruganandam wrote:
> To support dual-band variant of QCA9984, new extended board data (eBDF)
> is introduced since existing board data ran out of space.
>
> Below is the brief implementation & design detail,
>
>
> 1. New OTP
Kalle Valo writes:
> Tomislav Požega writes:
>
>> Move ack debug code to common-debug and adjust
>> ath9k/ath9k_htc debug for common ack output.
>
> Why? I guess to be able to get ack timeout with ath9k_htc, but please
> write the reason clearly in the commit log.
>
> Also the title prefix
Tomislav Požega writes:
> Increase driver limit for various interface combinations.
> I was able to start 8 virtual APs and connect 5 clients to
> these. Frimware support is required too, see:
> https://github.com/qca/open-ath9k-htc-firmware/pull/149
So what is the exact firmware version which
Tomislav Požega writes:
> Move ack debug code to common-debug and adjust
> ath9k/ath9k_htc debug for common ack output.
Why? I guess to be able to get ack timeout with ath9k_htc, but please
write the reason clearly in the commit log.
Also the title prefix should be "ath9k:".
--
Kalle Valo
Tomislav Požega wrote:
> Move ack debug code to common-debug and adjust
> ath9k/ath9k_htc debug for common ack output.
>
> Signed-off-by: Tomislav Požega
Failed to build:
drivers/net/wireless/ath/ath9k/debug.c: In function 'ath9k_init_debug':
drivers/net/wireless/ath/ath9k/debug.c:1431:2:
On Mon, 2018-09-03 at 22:57 +0800, Kevin Lo wrote:
> Remove set but unused variables from _rtl88ee_hw_configure() and
> _rtl8723e_hw_configure().
>
> Signed-off-by: Kevin Lo
Acked-by: Ping-Ke Shih
Hi Wen Gong,
Do you also have throughput and latency data for different
sk_pacing_shift setting when the ath10k client is at some distance
away from AP? Just curious about its impact on latency with less than
ideal PHY rate.
Thanks,
Kan
Increase driver limit for various interface combinations.
I was able to start 8 virtual APs and connect 5 clients to
these. Frimware support is required too, see:
https://github.com/qca/open-ath9k-htc-firmware/pull/149
Signed-off-by: Tomislav Požega
---
drivers/net/wireless/ath/ath9k/htc.h
Move ack debug code to common-debug and adjust
ath9k/ath9k_htc debug for common ack output.
Signed-off-by: Tomislav Požega
---
drivers/net/wireless/ath/ath9k/common-debug.c | 29
drivers/net/wireless/ath/ath9k/common-debug.h |7 +
Enable ANI output in debug file similar to how it's done on ath9k.
Disabling the entire feature is also working. Tested with ALFA
AWUS036NHA device.
Signed-off-by: Tomislav Požega
---
drivers/net/wireless/ath/ath9k/htc.h |1 +
drivers/net/wireless/ath/ath9k/htc_drv_debug.c | 98
Best I can say is that it seemed to happen after a failed connection.
It would connect and disconnect a few times and work fine, but if it
failed to connect for any reason (mostly mismatched settings between
AP and wpa_supplicant.conf) then the bug would occur. So,
wpa_supplicant would up the
Remove set but unused variables from _rtl88ee_hw_configure() and
_rtl8723e_hw_configure().
Signed-off-by: Kevin Lo
---
v2: Correct my email address.
---
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/hw.c
b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/hw.c
index
Hi Steve,
We are building with ptxdist, we have a compiler for arm
(arm-linux-gnueabihf-gcc), I am not a total novice in this, and have already
written some ptxdist rules, but haven't done it with non-autoconfizzed
packages, basically the problem is that if I use the default iw.make from the
Remove unused variables from _rtl88ee_hw_configure() and
_rtl8723e_hw_configure().
Signed-off-by: Kevin Lo
---
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/hw.c
b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/hw.c
index 988d5ac57d02..cfc8762c55f4 100644
---
Stanislaw Gruszka writes:
> We wrongly use wcid_mask instead of vif_mask
>
> Fixes: 95e444098a7b ("mt76x0: main file")
> Reported-and-tested-by: Sid Hayn
> Signed-off-by: Stanislaw Gruszka
For bug fixes please always try to describe the bug and symptoms. I can
add it this time. From the other
We wrongly use wcid_mask instead of vif_mask
Fixes: 95e444098a7b ("mt76x0: main file")
Reported-and-tested-by: Sid Hayn
Signed-off-by: Stanislaw Gruszka
---
drivers/net/wireless/mediatek/mt76/mt76x0/main.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git
On Fri, 2018-08-31 at 15:00 +0200, Alexander Wetzel wrote:
>
> Version history:
> V8
> - Minor code cleanup
> - some minor clarifications in commit messages
>
Ok, enough :-)
Applied this now.
johannes
Hi,
In addition or as an alternative to what Steve said, make sure your
LDFLAGS also contains -m32.
johannes
>
> On Mon, 2018-09-03 at 09:28 +, Grumbach, Emmanuel wrote:
> > >
> > For managed mode, the driver will need to check the HE cap along with
> > the extended capabilities to determine whether AP supports TWT or not.
>
> Do you have any idea why it's there twice? Sounds like we should resolve
On Mon, 2018-09-03 at 09:28 +, Grumbach, Emmanuel wrote:
> >
> For managed mode, the driver will need to check the HE cap along with the
> extended capabilities to determine whether AP supports TWT or not.
Do you have any idea why it's there twice? Sounds like we should resolve
that in
>
> > Since those bits are present in the HE Cap as well, we can set the
> > capability bits in the Extended Capabilities IE based on what is
> > advertised in the HE Cap IE.
>
> It's not clear to me what this is trying to say, you don't seem to do anything
> with the HE capabilities in the
Applied 2, 4, 8, 10, 11 as fixes.
Applied 1, 3, 5, 6, 7,
As Kalle pointed out, 20-28 are corrupted, so you need to resend; 22 was
already in the tree, no need to resend that one.
Please respin patch 20 ("mac80211: fix saving a few HE values") to use
FIELD_GET() to avoid such problems in the
On Fri, 2018-08-31 at 11:31 +0300, Luca Coelho wrote:
>
> + cap = cfg80211_find_ext_ie(WLAN_EID_EXT_HE_CAPABILITY, ies, ies_len);
> + if (cap && cap[1] >= sizeof(*params->he_cap) + 1)
> + params->he_cap = (void *)(cap + 3);
I think this should validate that the element is
On Fri, 2018-08-31 at 11:31 +0300, Luca Coelho wrote:
> Since those bits are present in the HE Cap as well,
> we can set the capability bits in the Extended
> Capabilities IE based on what is advertised in the HE Cap IE.
It's not clear to me what this is trying to say, you don't seem to do
On 8/31/2018 11:56 AM, Luca Coelho wrote:
From: Shaul Triebitz
In order to receive TB (Trigger Based) PPDU in monitor mode,
the Driver must send the HE_AIR_SNIFFER_CONFIG_CMD host command.
Enable that via debugfs.
Signed-off-by: Liad Kaufman
Signed-off-by: Ido Yariv
Signed-off-by: Shaul
28 matches
Mail list logo
