On 11/28/2018 7:08 PM, Fabio Estevam wrote:
Hi Arend,
On Wed, Nov 28, 2018 at 2:23 PM Fabio Estevam wrote:
I am not sure if I can access this signal via scope.
Good news!
I managed to make mx7d to generate the 32kHz clock and now Wifi works
with the default nvram file value: boardflags3
On 11/25/2018 2:14 PM, Stefan Wahren wrote:
Hi Rafał,
Rafał Miłecki hat am 24. November 2018 um 22:23 geschrieben:
Possibly you can just update hostapd to anything more recent? I'm afraid
the version you're using may suffer from a lot of security issues anyway
thanks for your quick reply.
On 11/20/2018 9:50 AM, Madhan Mohan R wrote:
On Mon, Nov 12, 2018 at 10:13:07AM +0100, Arend van Spriel wrote:
On 11/12/2018 8:29 AM, Chi-Hsien Lin wrote:
From: Madhan Mohan R
Along with F2 watermark (existing) configuration, F1 MesBusyCtrl
should be enabled & configured to avoid over
+ Cameron
On 3/26/2018 3:34 PM, Vanessa Maegima wrote:
On Seg, 2018-03-26 at 09:24 -0300, Vanessa Maegima wrote:
Hi Arend,
Here's the hexdump: http://code.bulix.org/trv3o7-306254
The link above provides the hexdump from the html nvram, which makes
wifi work on pico-imx7d.
I also got the
On 11/12/2018 8:30 AM, Chi-Hsien Lin wrote:
From: Wright Feng
AOS is a part of the SDIOD core that becomes active when the rest of
SDIOD is sleeping to keep SDIO bus alive responding to reduced set of
commands.
Transaction between AOS and SDIOD is not protected, and if cmd 52 is
received in
van Spriel
Signed-off-by: Wright Feng
Signed-off-by: Double Lo
Signed-off-by: Madhan Mohan R
Signed-off-by: Chi-Hsien Lin
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
On 11/12/2018 8:29 AM, Chi-Hsien Lin wrote:
Use sr_eng_en bit to check 4373 sr support.
Reviewed-by: Arend van Spriel
Signed-off-by: Chi-Hsien Lin
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/net/wireless
On 11/12/2018 11:24 AM, Chi-Hsien Lin wrote:
On 11/12/2018 6:16, Arend van Spriel wrote:
On 11/12/2018 8:29 AM, Chi-Hsien Lin wrote:
GCI core is needed for ULP operation. Allow GCI core enumuration with
below changes:
- Allow GCI to be added to core list even when it doesn't have a
wrapper
descriptor
is in place.
One question. This only assures the GCI core is listed. So does the
driver need to access it for ULP operation?
Regards,
Arend
Reviewed-by: Arend van Spriel
Signed-off-by: Chi-Hsien Lin
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c | 14
with this change.
Regards,
Arend
Reviewed-by: Arend van Spriel
Signed-off-by: Wright Feng
Signed-off-by: Chi-Hsien Lin
---
.../wireless/broadcom/brcm80211/brcmfmac/sdio.c| 26 --
1 file changed, 24 insertions(+), 2 deletions(-)
On 11/12/2018 8:29 AM, Chi-Hsien Lin wrote:
From: Winnie Chang
Add the raw 4354 PCIe device ID for unprogrammed Cypress boards.
Already have my review tag so this is fine as is.
Reviewed-by: Arend Van Spriel
Signed-off-by: Winnie Chang
Signed-off-by: Chi-Hsien Lin
---
drivers/net
) is increased,
watermark has to be reduced. This is the optimal setting for this chip.
Reviewed-by: Arend van Spriel
Signed-off-by: Naveen Gupta
Signed-off-by: Chi-Hsien Lin
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 12
1 file changed, 12 insertions(+)
diff
On 11/12/2018 8:29 AM, Chi-Hsien Lin wrote:
From: Madhan Mohan R
Along with F2 watermark (existing) configuration, F1 MesBusyCtrl
should be enabled & configured to avoid overflow errors.
I am a bit confused. Why is it necessary to program the watermark in
both SBSDIO_WATERMARK (0x10008) and
will
fallback to the very limited v3 instead of something in between such as
v4.
I would expect a changelog, but looking at the patch is addresses my
comments nicely so
Reviewed-by: Arend van Spriel
Signed-off-by: Dan Haab
Reviewed-by: Rafał Miłecki
---
.../broadcom/brcm80211/brcmfmac
+ Jouni
On 11/8/2018 4:48 AM, Chi-Hsien Lin wrote:
From: Madhan Mohan R
Send p2p presence response from the p2p interface address instead
of the p2p device address. This is needed for p2p cert 6.1.9 to pass.
I am not really into the P2P spec, but if this is indeed a requirement
(@Jouni:
Session with a
Reference Source
Reviewed-by: Arend van Spriel
Signed-off-by: Ryohei Kondo
Signed-off-by: Chi-Hsien Lin
---
.../net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c| 14 ++
.../net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h| 4
2 files changed, 18
, the
locally administered bit cannot be set again. Generate a random locally
administered address for this case.
We discussed this on the linux-wireless list a while ago. I have no
problem with the approach in this patch.
Reviewed-by: Arend van Spriel
Signed-off-by: Chi-Hsien Lin
---
drivers/net
On 11/8/2018 4:48 AM, Chi-Hsien Lin wrote:
From: Wright Feng
APSTA can work on two band concurrently with using VSDB(Virtual
Simultaneous Dual-Band) or RSDB(Real Simultaneous Dual-Band) features.
In this case, we have to keep apsta is 1 in firmware side. However, if
we start wpa_supplicant on
On 11/9/2018 8:34 AM, Chi-Hsien Lin wrote:
On 11/08/2018 7:53, Arend van Spriel wrote:
On 11/6/2018 4:50 AM, Chi-Hsien Lin wrote:
From: Madhan Mohan R
Along with F2 watermark (existing) configuration, F1 MesBusyCtrl
should be enabled & configured to avoid overflow errors.
Revi
On 11/6/2018 4:50 AM, Chi-Hsien Lin wrote:
From: Double Lo
Transaction between AOS and SDIOD is not protected, and if cmd 52
received in AOS and in the middle of response state changed from AOS to
SDIOD, response is corrupted and it causes to SDIO Host controller to
hang.
See comment in
On 11/6/2018 4:50 AM, Chi-Hsien Lin wrote:
From: Madhan Mohan R
By disabling command decode, sdiod_aos module supports
the detection of sdio command line toggle only and
generates a wakeup request to PMU and to sdiod core.
It does not decode any sdio command and generates no
response to any
be good to elaborate on what AOS stands for. It is a
part of the SDIOD core that becomes active when the rest of SDIOD is
sleeping to keep SDIO bus alive responding to reduced set of commands.
I would actually suggest to collapse patch 10 and 11 in this one.
Reviewed-by: Arend van Spriel
On 11/6/2018 4:50 AM, Chi-Hsien Lin wrote:
Use sr_eng_en bit to check 4373 sr support.
Reviewed-by: Arend van Spriel
Signed-off-by: Chi-Hsien Lin
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers
) is increased,
watermark has to be reduced. This is the optimal setting for this chip.
Nice formula. So could the BurstLength be retrieved from firmware so the
driver can determine and update the F2 watermark in
brcmf_sdio_bus_preinit().
Reviewed-by: Arend van Spriel
Signed-off-by: Naveen
descriptor
is in place.
Reviewed-by: Arend van Spriel
Signed-off-by: Chi-Hsien Lin
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
On 11/6/2018 4:50 AM, Chi-Hsien Lin wrote:
From: Praveen Babu C
Add saverestore register settings for 43012.
I would collapse this commit with PATCH 04/11.
Reviewed-by: Arend van Spriel
Signed-off-by: Praveen Babu C
Signed-off-by: Chi-Hsien Lin
---
.../wireless/broadcom/brcm80211
On 11/6/2018 4:50 AM, Chi-Hsien Lin wrote:
CYW43012 is a 1x1 802.11a/b/g/n Dual-Band HT20, 256-QAM/Turbo QAM. It
is an Ultra Low Power WLAN+BT combo chip.
comments below
Reviewed-by: Arend van Spriel
Signed-off-by: Chi-Hsien Lin
---
.../wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
On 11/6/2018 4:50 AM, Chi-Hsien Lin wrote:
From: Winnie Chang
Add the raw 4354 PCIe device ID.
What is the motivation for adding this. I can do an educated guess, but
I would like to see it in the commit message. Why only for 4354?
Regards,
Arend
Signed-off-by: Winnie Chang
On 11/6/2018 4:50 AM, Chi-Hsien Lin wrote:
From: Madhan Mohan R
Along with F2 watermark (existing) configuration, F1 MesBusyCtrl
should be enabled & configured to avoid overflow errors.
Reviewed-by: Arend van Spriel
Signed-off-by: Madhan Mohan R
Signed-off-by: Chi-Hsien Lin
---
dri
, but in the register it needs number of words (word being 4
bytes). So is this really only applicable to 4373? I have had question
about SDIO crc errors before for other chips. Other than that
Reviewed-by: Arend van Spriel
Signed-off-by: Wright Feng
Signed-off-by: Chi-Hsien Lin
On 10/11/2018 10:19 PM, Dan Haab wrote:
The newest firmwares provide STA info using v7 of the struct. As v7
isn't backward compatible, a union is needed.
Even though brcmfmac does not use any of the new info it's important to
provide the proper struct buffer. Without this change new firmwares
On 11/7/2018 11:02 AM, Kalle Valo wrote:
Rafał Miłecki writes:
On Thu, 11 Oct 2018 at 22:21, Dan Haab wrote:
The newest firmwares provide STA info using v7 of the struct. As v7
isn't backward compatible, a union is needed.
Even though brcmfmac does not use any of the new info it's
the first patch introducing
brcmf_fw_complete_request(). All-in-all a nice cleanup. Thanks.
Reviewed-by: Arend van Spriel
Signed-off-by: Hans de Goede
---
.../net/wireless/broadcom/brcm80211/brcmfmac/firmware.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
to load the board-specific nvram file with
a board-specific name so that we can ship files for each supported board
in linux-firmware.
Reviewed-by: Arend van Spriel
Signed-off-by: Hans de Goede
---
.../net/wireless/broadcom/brcm80211/brcmfmac/common.h | 1 +
drivers/net/wireless/broadcom
listed in that table.
The board_type setting is used to load the board-specific nvram file with
a board-specific name so that we can ship files for each supported board
in linux-firmware.
some comments below
Reviewed-by: Arend van Spriel
Signed-off-by: Hans de Goede
---
.../broadcom
...
Reviewed-by: Arend van Spriel
Signed-off-by: Hans de Goede
---
.../broadcom/brcm80211/brcmfmac/firmware.c| 27 ++-
.../broadcom/brcm80211/brcmfmac/firmware.h| 1 +
2 files changed, 27 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac
this by removing brcmf_fw_request_next_item and by
making brcmf_fw_get_firmwares and brcmf_fw_request_done directly call
firmware_request_nowait resp. firmware_request themselves.
*) brcmf_fw_request_nvram_done fallback path succeeds or
BRCMF_FW_REQF_OPTIONAL is set
Reviewed-by: Arend van Spriel
Signed
On 10/9/2018 2:47 PM, Hans de Goede wrote:
brcmf_fw_request_next_item and brcmf_fw_request_done both have identical
code to complete the fw-request depending on the item-type.
This commit adds a new brcmf_fw_complete_request helper removing this code
duplication.
Reviewed-by: Arend van Spriel
On 11/4/2018 8:04 PM, Stijn Tintel wrote:
[ 259.240131] WARNING: CPU: 0 PID: 50 at
/home/build/lede/build_dir/target-arm_arm1176jzf-s+vfp_musl_eabi/linux-brcm2708_bcm2708/backports-4.19-rc5-1/net/wireless/core.c:736
wiphy_register+0x280/0xa58 [cfg80211]
[ 259.274067] Modules linked in:
On 11/2/2018 9:24 AM, Wright Feng wrote:
The patches are for throughput enhancement with flow control mode enabled
and introduce a new module parameter to enhance TX throughput as well.
Changes since v1:
Remove the patch "calling skb_orphan before sending skb to SDIO bus"
Revise the patch
On 11/2/2018 9:24 AM, Wright Feng wrote:
This patch is for adding a new module parameter "frameburst".
With setting "frameburst=1" in module parameters, firmware frameburst mode
will be enabled. The feature can enable per-packet framebursting in
firmware side and get higher TX throughput in High
On 10/29/2018 11:27 AM, Wright Feng wrote:
This patch is for adding a new module parameter "frameburst".
With setting "frameburst=1" in module parameters, firmware frameburst mode
will be enabled. The feature can enable per-packet framebursting in
firmware side and get higher TX throughput in
interface up.
The purpose of this patch is making host driver has ability of updating
the credit numbers when receiving the BRCMF_E_FIFO_CREDIT_MAP event.
Reviewed-by: Arend van Spriel
Signed-off-by: Wright Feng
---
.../broadcom/brcm80211/brcmfmac/fwsignal.c | 23 ++
1
On 10/22/2018 10:37 AM, Johannes Berg wrote:
On Mon, 2018-10-22 at 10:35 +0200, Johannes Stezenbach wrote:
commit 848e616e66d4592fe9afc40743d3504deb7632b4
Author: Stefan Seyfried
Date: Sun Sep 30 12:53:00 2018 +0200
cfg80211: fix wext-compat memory leak
Hopefully that'll eventually
On 10/18/2018 10:35 AM, Johannes Berg wrote:
From: Johannes Berg
In some cases, like in the rsi driver hardware scan offload, there
may be scenarios in which hardware scan might not be available or
desirable.
Allow drivers to cope with this by letting them fall back to software
scan by
On 10/12/2018 10:59 AM, Christoph Müllner wrote:
On 10/12/18 10:00 AM, Arend van Spriel wrote:
On 10/11/2018 6:04 PM, Christoph Müllner wrote:
Hi Franky and Arend,
today I could get a SDIO Wifi module, which includes a BCM43455.
I was able to get this up and running without any issues
On 10/12/2018 12:41 PM, Johannes Berg wrote:
+ NL80211_ATTR_TIMEOUT,
+
Guess you consider reuse of the TIMEOUT attribute?
Yes, I was actually surprised we don't have one already :-)
Dito.
Arend
On 10/12/2018 12:08 PM, Johannes Berg wrote:
From: Johannes Berg
Add a new "peer measurement" API, that can be used to measure
certain things related to a peer. Right now, only implement
FTM (flight time measurement) over it, but the idea is that
it'll be extensible to also support measuring
On 10/12/2018 10:59 AM, Christoph Müllner wrote:
On 10/12/18 10:00 AM, Arend van Spriel wrote:
On 10/11/2018 6:04 PM, Christoph Müllner wrote:
Hi Franky and Arend,
today I could get a SDIO Wifi module, which includes a BCM43455.
I was able to get this up and running without any issues
On 10/11/2018 10:19 PM, Dan Haab wrote:
The newest firmwares provide STA info using v7 of the struct. As v7
isn't backward compatible, a union is needed.
Even though brcmfmac does not use any of the new info it's important to
provide the proper struct buffer. Without this change new firmwares
On 10/11/2018 6:04 PM, Christoph Müllner wrote:
Hi Franky and Arend,
today I could get a SDIO Wifi module, which includes a BCM43455.
I was able to get this up and running without any issues with the brcmfmac
driver and a 4.19 kernel. For me that's enough evidence to say that the SDIO
driver
On 10/10/2018 9:59 AM, Hans de Goede wrote:
Hi Arend,
On 10-10-18 09:52, Arend van Spriel wrote:
On 10/10/2018 9:28 AM, Hans de Goede wrote:
So how do you want to proceed with this, do you want me to just
put the full ISC text in the header for now as the rest of brcmfmac
does
On 10/10/2018 9:28 AM, Hans de Goede wrote:
So how do you want to proceed with this, do you want me to just
put the full ISC text in the header for now as the rest of brcmfmac
does?
This is not entirely true as far as I know. I assume you are referring
to this:
/*
* Copyright (c) 2010
On 10/9/2018 8:10 PM, Christoph Müllner wrote:
Hi Arend,
recently I got an SDIO module, which includes a BCM4359.
I tried to get it up and running via the SD card interface
on a RK3399 SoC and succeeded in doing so with
bcmdhd.1.579.77.41.x and a vendor kernel (based on Linux 4.4).
All that was
On 9/25/2018 11:48 AM, Stanislaw Gruszka wrote:
On Tue, Sep 25, 2018 at 11:07:47AM +0200, Lorenzo Bianconi wrote:
On Sep 25, Felix Fietkau wrote:
On 2018-09-25 09:54, Lorenzo Bianconi wrote:
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/usb.c
On 9/25/2018 11:28 AM, Enrique Giraldo wrote:
The main reason is to be able to stop the CAC when you want to make a
channel switch and the CAC is ongoing. It's true that the radio would
not pass to the next phase, the behavior is the same as when during
the CAC a radar event is detected. In the
On 9/25/2018 10:19 AM, Enrique Giraldo wrote:
Add NL80211_CMD_ABORT_CAC to the nl80211 interface.
This one really needs a good motivation. The CAC duration is a hard
requirement so aborting it means that the radio can not proceed to the
next phase. You really need to describe your reasoning
On 9/23/2018 11:54 AM, Ali MJ Al-Nasrawy wrote:
Beacons are not updated to reflect TIM changes. This is not compliant with
power-saving client stations as the beacons do not have valid TIM and can cause
the network to stall at random occasions with highly variable latencies.
Fix it by updating
=20180911163534.21312d08%20()%20manjaro
A few remarks below but here is my
Reviewed-by: Arend van Spriel
Signed-off-by: Ali MJ Al-Nasrawy
---
.../broadcom/brcm80211/brcmsmac/mac80211_if.c | 23 +++
.../broadcom/brcm80211/brcmsmac/main.h| 2 ++
2 files changed, 25 insertions
On 8/29/2018 10:17 PM, Rafał Miłecki wrote:
Hi Arend,
On Mon, 25 Jun 2018 at 10:31, Arend van Spriel
wrote:
On 6/25/2018 6:40 AM, Rafał Miłecki wrote:
On Sun, 24 Jun 2018 at 13:48, Rafał Miłecki wrote:
On Fri, 22 Jun 2018 at 20:45, Arend van Spriel
wrote:
Here a couple of patches
On 9/5/2018 10:00 AM, Johannes Berg wrote:
From: Johannes Berg
Some frames may have a non-zero skb->priority assigned by
mac80211 internally, e.g. TDLS setup frames, regardless of
support for QoS.
Currently, we set skb->priority to 0 for all data frames.
Note that there's a comment that this
viewed-by: Pieter-Paul Giesberts
Reviewed-by: Franky Lin
Signed-off-by: Arend van Spriel
---
.../net/wireless/broadcom/brcm80211/brcmutil/d11.c | 34 +-
.../broadcom/brcm80211/include/brcmu_wifi.h| 2 ++
2 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/drive
Resending two patches which apply to the master branch of the
wireless-drivers-next repository.
Arend van Spriel (2):
brcmfmac: fix for proper support of 160MHz bandwidth
brcmfmac: increase buffer for obtaining firmware capabilities
.../wireless/broadcom/brcm80211/brcmfmac/feature.c | 2
Reviewed-by: Pieter-Paul Giesberts
Reviewed-by: Franky Lin
Signed-off-by: Arend van Spriel
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
b/drivers/net
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
On 8/17/2018 9:49 AM, Kalle Valo wrote:
Ajay Singh writes:
On Thu, 16 Aug 2018 13:53:50 +0300
Kalle Valo wrote:
Kalle Valo writes:
Ajay Singh writes:
Hi Greg,
We all are working on submitting and reviewing patches for
wilc1000 in staging driver for quite some time.
We would like to
On 8/15/2018 8:01 PM, Rafał Miłecki wrote:
From: Rafał Miłecki
It may happen for FullMAC firmware to crash. It should be detected and
ideally somehow handled by a driver.
Since commit ff4445a8502c ("brcmfmac: expose device memory to
devcoredump subsystem") brcmfmac has BRCMF_E_PSM_WATCHDOG
O, and add "brcmfmac:" prefix in the subject.
Regards,
Arend
On 8/15/2018 11:06 AM, Chi-Hsien Lin wrote:
From: Jia-Shyr Chuang
CYW89342 is a 2x2 MIMO, 802.11a/b/g/n/ac, SDIO 3.0 and PCIe 3.0 for
WLAN. It is a member of 4355/4359 family.
So the device support SDIO, but this patch only adds the PCIe variant.
The subject mentions that already, but
On 8/14/2018 12:56 PM, Dan Carpenter wrote:
On Sun, Aug 12, 2018 at 05:48:52PM +0530, Ajay Singh wrote:
Yes, currently only code to read and writing for "wilc_debug_level"
exists.
The main purpose for this file was to configure(enable/disable)
specific level debug logs to print.
The
On 8/13/2018 2:16 PM, Toke Høiland-Jørgensen wrote:
The TXQ teardown code can reference the vif data structures that are
stored in the netdev private memory area if there are still packets on
the queue when it is being freed. Since the TXQ teardown code is run
after the netdevs are freed, this
On 8/8/2018 7:58 PM, Randy Oostdyk wrote:
Good day all,
Hi Randy
I'm writing to report an issue with the linux kernel, and I'm hoping
this is the right place to report it. (short aside: I tried to ask in
the #linux-wireless IRC channel, but wasn't permitted to speak!)
uhm. why?
I'm aware
On 8/7/2018 3:38 PM, Chi-Hsien Lin wrote:
From: Winnie Chang
The kernel BUG happens when wowl is enabled from firmware. In
brcmf_wiphy_wowl_params(), cfg is a NULL pointer because it is
drvr->config returned from wiphy_to_cfg(), and drvr->config is not set
yet. To fix it, set drvr->config
+ linux-wireless
On 8/5/2018 4:59 AM, Dan Kosek wrote:
Arend,
Thank you for getting back to me. Adding the “flush” variable to the command
fixes the issue on both systems. Wow is the single channel scan fast with the
flush. Is appears the full scan (all channels) is faster with the flush
On 8/5/2018 5:22 PM, Sergey Matyukevich wrote:
Implement support for PTA (Packet Traffic Arbitration) configuration.
The PTA mechanism is used to coordinate sharing of the medium between
WiFi and other 2.4 wireless networks, e.g. Bluetooth or ZigBee.
This patch implements core infrastructure
On 8/1/2018 10:23 AM, Sergey Matyukevich wrote:
Implement support for PTA (Packet Traffic Arbitration) configuration.
The PTA mechanism is used to coordinate sharing of the medium between
WiFi and other 2.4 wireless networks, e.g. Bluetooth or ZigBee.
This patch implements core infrastructure
On 8/4/2018 3:08 PM, Dan Kosek wrote:
If you enter the following command, you should get a single channel scan:
sudo iw wlan0 scan freq 2412
You do not. Instead you get a full (all) channels scan, which takes 3-5
seconds.
Do you have any logs to support that claim. Please note that the
On 7/30/2018 4:06 PM, Kalle Valo wrote:
Sergey Matyukevich writes:
From: Andrey Shevchenko
Implement support for PTA (Packet Traffic Arbitration) configuration.
The PTA mechanism is used to coordinate sharing of the medium between
WiFi and other 2.4 wireless networks, e.g. Bluetooth or
mfmac: introduce brcmf_fw_alloc_request() function")
Cc: sta...@vger.kernel.org # v4.17+
oops. my bad.
Acked-by: Arend van Spriel
Signed-off-by: Rafał Miłecki
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/d
uilding radiotap
headers can't be reliably detected for all firmwares.
This commit adds table that allows mapping features to firmware version.
It adds mappings for 43602a1 and 4366b1 firmwares from
linux-firmware.git. Both were confirmed to be passing monitor frames.
Reviewed-by: Arend van Spriel
Hi Denis,
I prefer the subject summarizes the issue, eg. "allow non-linear skb
data passed to cfg80211_rx_control_port".
On 7/3/2018 8:26 PM, Denis Kenzior wrote:
The current implementation of cfg80211_rx_control_port assumed that the
caller could provide a contiguous region of memory for
see a comment that version 5 is obsoleted and in recent
branch we are at version 7. Just curious what the actual version is. If
you do not explicitly need version 5 I would prefer to skip it and move
to version 6 struct. Otherwise it is...
Acked-by: Arend van Spriel
Signed-off-by: Rafał Miłe
On 6/25/2018 6:40 AM, Rafał Miłecki wrote:
On Sun, 24 Jun 2018 at 13:48, Rafał Miłecki wrote:
On Fri, 22 Jun 2018 at 20:45, Arend van Spriel
wrote:
Here a couple of patches in preparation of monitor mode support. It
is mostly about querying firmware for support. While at it I stumbled
upon
On 6/24/2018 4:20 PM, Rafał Miłecki wrote:
On Fri, 22 Jun 2018 at 20:59, Arend van Spriel
wrote:
On 6/19/2018 10:25 PM, Rafał Miłecki wrote:
On 2018-06-19 22:01, Arend van Spriel wrote:
On 6/19/2018 5:48 PM, Rafał Miłecki wrote:
From: Rafał Miłecki
After a bit long discussions in various
On 6/24/2018 4:08 PM, Rafał Miłecki wrote:
On Fri, 22 Jun 2018 at 20:45, Arend van Spriel
wrote:
Firmwares may not provide all monitor mode features in the "cap" iovar.
For those this fallback mechanism uses "sta_monitor" iovar. If firmware
is compiled with stamon,
On 6/24/2018 1:48 PM, Rafał Miłecki wrote:
On Fri, 22 Jun 2018 at 20:45, Arend van Spriel
wrote:
Here a couple of patches in preparation of monitor mode support. It
is mostly about querying firmware for support. While at it I stumbled
upon the fact that 160MHz was not completely implemented
On 6/19/2018 10:25 PM, Rafał Miłecki wrote:
On 2018-06-19 22:01, Arend van Spriel wrote:
On 6/19/2018 5:48 PM, Rafał Miłecki wrote:
From: Rafał Miłecki
After a bit long discussions in various e-mail threads I'm coming with
this simple & small patchset. It isn't complete support for mon
viewed-by: Pieter-Paul Giesberts
Reviewed-by: Franky Lin
Signed-off-by: Arend van Spriel
---
.../net/wireless/broadcom/brcm80211/brcmutil/d11.c | 34 +-
.../broadcom/brcm80211/include/brcmu_wifi.h| 2 ++
2 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/drive
Reviewed-by: Pieter-Paul Giesberts
Reviewed-by: Franky Lin
Signed-off-by: Arend van Spriel
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
b/drivers/net
Just a bit of bike-shedding so nothing functionally changed.
Signed-off-by: Arend van Spriel
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c| 2 +-
drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.h | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git
Reviewed-by: Pieter-Paul Giesberts
Reviewed-by: Franky Lin
Signed-off-by: Arend van Spriel
---
.../wireless/broadcom/brcm80211/brcmfmac/feature.c | 15 +++
.../broadcom/brcm80211/brcmfmac/fwil_types.h| 21 +
2 files changed, 36 insertions(+)
diff
to the patches that
Rafal submitted. So this series depend on:
[V3,2/2] brcmfmac: handle monitor mode marked msgbuf packets [1]
These apply to the master branch of the wireless-drivers-next repository.
[1] https://patchwork.kernel.org/patch/10474799/
Arend van Spriel (6):
brcmfmac: remove
ot whether
it is supported in full-dongle mode, ie. firmware has means to transfer
the monitor packets to the host. Firmwares that return the "monitor"
flag in the "cap" iovar are able to send the packets to the host.
Signed-off-by: Arend van Spriel
---
.../wireless/broadcom/brc
On 6/19/2018 5:39 PM, Denis Kenzior wrote:
On pre-emption enabled kernels the following oops was being seen due
to missing local_bh_disable/local_bh_enable calls. mac80211 assumes
that pre-emption is disabled in the data path.
No sure if "assumes" is the right term here. It seems like it is
On 6/20/2018 9:53 AM, Johannes Berg wrote:
On Wed, 2018-06-20 at 09:51 +0200, Arend van Spriel wrote:
On 6/19/2018 5:39 PM, Denis Kenzior wrote:
On pre-emption enabled kernels the following oops was being seen due
to missing local_bh_disable/local_bh_enable calls. mac80211 assumes
that pre
On 6/19/2018 5:48 PM, Rafał Miłecki wrote:
From: Rafał Miłecki
After a bit long discussions in various e-mail threads I'm coming with
this simple & small patchset. It isn't complete support for monitor mode
but just a pair of preparing patches that should be clear & well
discussed by now to
to the msgbuf protocol at this point. Adding
support for SDIO/USB devices will require some extra work (possibly a
new firmware release).
Acked-by: Arend van Spriel
Signed-off-by: Rafał Miłecki
---
V2: Use cpu_to_le16 when setting it_len
V3: Update TODO comments
Rename flag (after adding MONITOR
ew feature flag. Once we sort out all details of handling monitor
interface it will be used when reporting available interfaces to the
cfg80211.
Acked-by: Arend van Spriel
Signed-off-by: Rafał Miłecki
---
V3: Patch added to the series
---
.../wireless/broadcom/brcm80211/brcmfmac/feat
On 6/19/2018 10:32 AM, Rafał Miłecki wrote:
On 19.06.2018 09:53, Arend van Spriel wrote:
On 6/19/2018 9:27 AM, Rafał Miłecki wrote:
On Mon, 11 Jun 2018 at 12:48, Arend van Spriel
wrote:
On 5/30/2018 1:52 PM, Rafał Miłecki wrote:
I'm providing extra version info of tested firmware images
On 6/19/2018 9:27 AM, Rafał Miłecki wrote:
On Mon, 11 Jun 2018 at 12:48, Arend van Spriel
wrote:
On 5/30/2018 1:52 PM, Rafał Miłecki wrote:
I'm providing extra version info of tested firmware images as requested
by Arend in another e-mail thread.
Looking into our firmware repo
1 - 100 of 2045 matches
Mail list logo
