On Tue, 3 Sep 2019 at 20:59, Arend Van Spriel
wrote:
> On 9/3/2019 6:29 AM, Rafał Miłecki wrote:
> > From: Rafał Miłecki
> >
> > This moves "ops" pointer from "struct brcmf_cfg80211_info" to the
> > "struct brcmf_pub". This movement
On Tue, 3 Sep 2019 at 20:51, Arend Van Spriel
wrote:
> On 9/3/2019 6:29 AM, Rafał Miłecki wrote:
> > From: Rafał Miłecki
> >
> > Driver's main init/attach function brcmf_attach() was handling both:
> > wiphy allocation and driver initialization. It meant getti
From: Rafał Miłecki
Providing a new wiphy on every PCIe reset was confusing and was causing
configuration problems for some users (supplicant and authenticators).
Sticking to the existing wiphy should make error recovery much simpler
and more reliable.
Signed-off-by: Rafał Miłecki
---
drivers
From: Rafał Miłecki
This moves "ops" pointer from "struct brcmf_cfg80211_info" to the
"struct brcmf_pub". This movement makes it possible to allocate wiphy
without attaching cfg80211 (brcmf_cfg80211_attach()). It's required for
later separation of wiphy a
From: Rafał Miłecki
Move code allocating/freeing wiphy out of above functions. This will
allow reinitializing the driver (e.g. on some error) without allocating
a new wiphy.
Signed-off-by: Rafał Miłecki
---
.../broadcom/brcm80211/brcmfmac/bus.h | 4 ++-
.../broadcom/brcm80211
From: Rafał Miłecki
Driver's main init/attach function brcmf_attach() was handling both:
wiphy allocation and driver initialization. It meant getting a new wiphy
on every init (initial, resume, error recovery).
For supplicants/authenticators and Linux users it's move convenient to
hav
From: Rafał Miłecki
In case of compiling driver without DEBUG expose a stub function to make
writing debug code much simpler (no extra conditions). This will allow
e.g. using debugfs_create_file() without any magic if or #ifdef.
Signed-off-by: Rafał Miłecki
---
drivers/net/wireless/broadcom
From: Rafał Miłecki
This is a trivial debugfs entry for triggering reset just like in case
of firmware crash. It works by writing 1 to it:
echo 1 > reset
Signed-off-by: Rafał Miłecki
---
.../broadcom/brcm80211/brcmfmac/core.c| 25 +++
1 file changed, 25 inserti
On 28.08.2019 17:47, Rafał Miłecki wrote:
From: Rafał Miłecki
This is a trivial debugfs entry for triggering reset just like in case
of firmware crash. It works by writing 1 to it:
echo 1 > reset
Signed-off-by: Rafał Miłecki
Please drop this patch
drivers/net/wireless/broadcom/brcm80
From: Rafał Miłecki
Getting RAM info just once per driver's lifetime (during chip
recognition) is not enough as it may get adjusted later (depending on
the used firmware). Subsequent inits may load different firmwares so a
full RAM recognition is required on every PCIe setup. This is espec
From: Rafał Miłecki
This is a trivial debugfs entry for triggering reset just like in case
of firmware crash. It works by writing 1 to it:
echo 1 > reset
Signed-off-by: Rafał Miłecki
---
.../broadcom/brcm80211/brcmfmac/core.c| 25 +++
1 file changed, 25 inserti
From: Rafał Miłecki
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 imp
reported in the:
brcmfmac: NULL pointer dereference during brcmf_detach() after firmware crash
https://www.spinics.net/lists/linux-wireless/msg182913.html
Tested-by: Rafał Miłecki
.
Reported-by: Rafał Miłecki
Reviewed-by: Hante Meuleman
Reviewed-by: Pieter-Paul Giesberts
Reviewed-by: Franky Lin
Signed-off-by: Arend van Spriel
---
Hi Piotr,
While working on an issue with msgbuf protocol (used for PCIe devices)
your change 5cdb0ef6144f ("brcmfmac: fix NULL pointer dere
On Fri, 17 May 2019 at 01:25, Arend Van Spriel
wrote:
> On 5/16/2019 10:01 PM, Greg Kroah-Hartman wrote:
> > On Thu, May 16, 2019 at 09:45:19PM +0200, Arend Van Spriel wrote:
> >> On 5/16/2019 7:31 PM, Greg Kroah-Hartman wrote:
> >>> On Thu, May 16, 2019 at 02:04:07PM +0200, Arend van Spriel wrote
On 2019-04-28 23:06, Arend Van Spriel wrote:
On 4/27/2019 8:30 PM, Rafał Miłecki wrote:
From: Rafał Miłecki
Normally firmware messages are printed with debugging enabled only.
It's
a good idea as firmware may print a lot of messages that normal users
don't need to care about.
H
From: Rafał Miłecki
Normally firmware messages are printed with debugging enabled only. It's
a good idea as firmware may print a lot of messages that normal users
don't need to care about.
However, on firmware crash, it may be very helpful to log all recent
messages. There is almos
From: Rafał Miłecki
Normally firmware messages are printed with debugging enabled only. It's
a good idea as firmware may print a lot of messages that normal users
don't need to care about.
However, on firmware crash, it may be very helpful to log all recent
messages. There is almos
On Fri, 15 Feb 2019 at 07:15, Rafał Miłecki wrote:
> On Thu, 14 Feb 2019 at 23:37, Arend Van Spriel
> wrote:
> > On 2/14/2019 11:30 PM, Rafał Miłecki wrote:
> > > I've just found a well reproducible brcmfmac crash (NULL pointer
> > > dereference).
> > &g
On Sun, 3 Mar 2019 at 20:06, Krzysiek Rosinski wrote:
> On Sun, Mar 3, 2019 at 10:22 AM Krzysiek Rosinski
> wrote:
> > I'm working on a custom board with cyw4343 connected to osd3358-sm (TI
> > am3358), when I load the brcmfmac driver I get 'HT Avail timeout'
> > error. The same combination of d
From: Rafał Miłecki
During a normal brcmfmac lifetime brcmf_fw_alloc_request() is called
once only during the probe. It's safe to assume provided array is clear.
Further brcmfmac improvements may require calling it multiple times
though. This patch allows it by fixing invalid firmware
From: Rafał Miłecki
It's important as brcmf_chip_get_raminfo() also makes sure that memory
is properly setup. Without it the firmware could report invalid RAM
address like 0x0401.
During a normal brcmfmac lifetime brcmf_chip_get_raminfo() is called on
probe by the brcmf_chip_recogn
From: Rafał Miłecki
So far PCIe firmware halts / crashes were resulting in massive timeouts
and running out of resources (e.g. slots). There wasn't even a clear
message indicating the problem source.
This patches improves it by:
1) Printing an error
2) Reloading a firmware
After that use
From: Rafał Miłecki
This improves handling PCIe firmware halts by printing a clear error
message and replaces a similar code in the SDIO bus support.
It will also allow further improvements like trying to recover from a
firmware crash.
Signed-off-by: Rafał Miłecki
---
drivers/net/wireless
From: Rafał Miłecki
This includes bus reset & reloading a firmware. It should be sufficient
for a user space to (setup and) use a wireless device again.
Support for reset on USB & SDIO can be added later.
Signed-off-by: Rafał Miłecki
---
.../broadcom/brcm80211/brcmfmac/bus.h
From: Rafał Miłecki
FullMAC firmware may happen to crash due to some potential bugs exposed
by e.g. a specific traffic or host-requested setup. It usually results
in various timeouts & running our of resources (e.g. ring slots).
Monitoring firmware state allows handling such a situation
On 2019-02-21 11:45, Arend Van Spriel wrote:
On 2/21/2019 11:33 AM, Rafał Miłecki wrote:
From: Rafał Miłecki
Firmware may report general errors using a special message type. Add
basic support for it by simply decoding & printing an error number.
A sample situation in which firmware repor
From: Rafał Miłecki
This updates host struct to match the in-firmawre definition. It's a
cosmetic change as it only applies to the reserved struct space.
Fixes: c988b78244df ("brcmfmac: print firmware reported ring status errors")
Signed-off-by: Rafał Miłecki
---
drivers/net/wi
From: Rafał Miłecki
Firmware may report general errors using a special message type. Add
basic support for it by simply decoding & printing an error number.
A sample situation in which firmware reports a buf error:
CONSOLE: 027084.733 no host response IOCTL buffer available..so fail the req
On Thu, 21 Feb 2019 at 09:59, Arend Van Spriel
wrote:
> On 2/21/2019 9:01 AM, Rafał Miłecki wrote:
> > On Wed, 20 Feb 2019 at 11:31, Rafał Miłecki wrote:
> >> From: Rafał Miłecki
> >>
> >> While experimenting with firmware loading I ended up in a state o
On Wed, 20 Feb 2019 at 11:31, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> While experimenting with firmware loading I ended up in a state of
> firmware reporting shared RAM address 0x0401. It was causing:
> [ 94.448015] Unable to handle kernel paging request at
From: Rafał Miłecki
While experimenting with firmware loading I ended up in a state of
firmware reporting shared RAM address 0x0401. It was causing:
[ 94.448015] Unable to handle kernel paging request at virtual address
cd680001
due to reading out of the mapped memory.
This patch adds
From: Rafał Miłecki
This recently added macro provides more meaningful error messages thanks
to identifying a specific wiphy. It's especially important on systems
with few cards supported by the same (brcmfmac) driver.
Signed-off-by: Rafał Miłecki
Acked-by: Arend van Spriel
---
V2: Fi
From: Rafał Miłecki
This macro will be used in more places not just the cfg80211.c. It makes
sense to pass some common struct to it as "struct wiphy" is mostly
referenced in cfg80211 code only.
A very common one (used above the bus abstraction layer) is struct
brcmf_pub. Many functio
On Fri, 15 Feb 2019 at 07:43, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> This recently added macro provides more meaningful error messages thanks
> to identifying a specific wiphy. It's especially important on systems
> with few cards supported by the same (brcmfmac) dr
On Fri, 15 Feb 2019 at 11:04, Kalle Valo wrote:
> Dan Carpenter writes:
>
> > Hi Rafał,
> >
> > url:
> > https://github.com/0day-ci/linux/commits/Rafa-Mi-ecki/brcmfmac-use-bphy_err-in-all-wiphy-related-code/20190214-140004
> > base:
> > https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wirele
On Fri, 15 Feb 2019 at 10:40, Arend Van Spriel
wrote:
> On 2/15/2019 9:37 AM, Rafał Miłecki wrote:
> > On Fri, 15 Feb 2019 at 07:43, Rafał Miłecki wrote:
> >> From: Rafał Miłecki
> >>
> >> This recently added macro provides more meaningful error messages t
On Fri, 15 Feb 2019 at 07:43, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> This recently added macro provides more meaningful error messages thanks
> to identifying a specific wiphy. It's especially important on systems
> with few cards supported by the same (brcmfmac) dr
From: Rafał Miłecki
This recently added macro provides more meaningful error messages thanks
to identifying a specific wiphy. It's especially important on systems
with few cards supported by the same (brcmfmac) driver.
Signed-off-by: Rafał Miłecki
Acked-by: Arend van Spriel
---
V2: Fi
On Thu, 14 Feb 2019 at 23:37, Arend Van Spriel
wrote:
> On 2/14/2019 11:30 PM, Rafał Miłecki wrote:
> > I've just found a well reproducible brcmfmac crash (NULL pointer
> > dereference).
> >
> > Steps:
> > 1. Wait for or trigger a FullMAC firmware crash
>
Hi,
I've just found a well reproducible brcmfmac crash (NULL pointer dereference).
Steps:
1. Wait for or trigger a FullMAC firmware crash
2. Wait for some skb to get queued on a flowring
3. Call rmmod brcmfmac
Problem:
There is a NULL pointer dereference in one of the brcmf_detach() calls.
Exp
From: Rafał Miłecki
This recently added macro provides more meaningful error messages thanks
to identifying a specific wiphy. It's especially important on systems
with few cards supported by the same (brcmfmac) driver.
Signed-off-by: Rafał Miłecki
Acked-by: Arend van Spriel
---
V2: Fi
On Thu, 14 Feb 2019 at 13:38, Arend Van Spriel
wrote:
> On 2/13/2019 12:26 PM, Rafał Miłecki wrote:
> > From: Rafał Miłecki
> >
> > This recently added macro provides more meaningful error messages thanks
> > to identifying a specific wiphy. It's especially i
On 12.02.2019 06:57, Aaron Blair wrote:
[18990.872335] brcmfmac: brcmf_cfg80211_get_station: GET STA INFO failed, -12
[18990.872433] brcmfmac: brcmf_msgbuf_tx_ioctl: Failed to reserve space in
commonring
[18990.872439] brcmfmac: brcmf_cfg80211_get_tx_power: error (-12)
FullMAC firmware (the on
From: Rafał Miłecki
This recently added macro provides more meaningful error messages thanks
to identifying a specific wiphy. It's especially important on systems
with few cards supported by the same (brcmfmac) driver.
Signed-off-by: Rafał Miłecki
---
I obviously couldn't hit &
From: Rafał Miłecki
1) Use switch to simplify/improve the code & avoid some duplication
2) Add warning for unsupported values
Signed-off-by: Rafał Miłecki
---
.../wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --g
From: Rafał Miłecki
So far 160 MHz channels were treated as 20 MHz ones which was breaking
support for 40/80 MHz due to the brcmf_construct_chaninfo() logic and
its assumptions.
Signed-off-by: Rafał Miłecki
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 3 +++
1 file
Hi,
During debugging some potential problems I hit a race bug in the
brcmfmac. It calls wiphy_register() before it's ready to handle all the
cfg80211 callbacks correctly.
In brcmf_cfg80211_attach() there is a wiphy_register() call performed
before setting "config" in the struct brcmf_pub. So if:
From: Rafał Miłecki
Firmware is capable of reporting ring status. It's used e.g. to signal
some problem with a specific ring setup. This patch adds support for
printing ring & error number which may be useful for debugging setup
issues.
Signed-off-by: Rafał Miłecki
---
.../broadcom/
From: Rafał Miłecki
So far there were two monitor frame formats:
1) 802.11 frames (with frame (sub)type & all addresses)
2) 802.11 frames with the radiotap header
Testing the latest FullMAC firmwares for 4366b1/4366c0 resulted in
discovering a new format being used. It seems (almost?) ident
On Thu, 7 Feb 2019 at 17:36, Kalle Valo wrote:
> Rafał Miłecki wrote:
>
> > From: Rafał Miłecki
> >
> > The new FullMAC firmwares for 4366b1/4366c0 were supposed to provide
> > monitor frames with radiotap header but it doesn't seem to be the case.
> &g
From: Rafał Miłecki
This enables dev_err() usage (instead of pr_err()) in the __brcmf_err().
It makes error messages more meaningful and is important for debugging
errors/bugs on systems with multiple brcmfmac supported devices.
All bus files should follow & get updated similarly (
From: Rafał Miłecki
So far __brcmf_err() was using pr_err() which didn't allow identifying
device that was affected by an error. It's crucial for systems with more
than 1 device supported by brcmfmac (a common case for home routers).
This change allows passing struct brcmf_
On 01.02.2019 13:14, Kalle Valo wrote:
Rafał Miłecki wrote:
From: Rafał Miłecki
So far __brcmf_err() was using pr_err() which didn't allow identifying
device that was affected by an error. It's crucial for systems with more
than 1 device supported by brcmfmac (a common case for ho
On 2019-01-25 09:51, Arend Van Spriel wrote:
On 1/22/2019 12:08 PM, Rafał Miłecki wrote:
From: Rafał Miłecki
The new FullMAC firmwares for 4366b1/4366c0 were supposed to provide
monitor frames with radiotap header but it doesn't seem to be the
case.
I was not aware that this was sup
On Mon, 21 Jan 2019 at 15:46, Christoph Hellwig wrote:
> On Mon, Jan 21, 2019 at 11:11:21AM +0100, Rafał Miłecki wrote:
> > From: Rafał Miłecki
> >
> > For bus devices to be fully usable it's required to set their DMA
> > parameters.
> >
> > For year
From: Rafał Miłecki
The new FullMAC firmwares for 4366b1/4366c0 were supposed to provide
monitor frames with radiotap header but it doesn't seem to be the case.
Testing the latest release resulted in discovering a new format being
used. It seems (almost?) identical to the one known from
From: Rafał Miłecki
For bus devices to be fully usable it's required to set their DMA
parameters.
For years it has been missing and remained unnoticed because of
mips_dma_alloc_coherent() silently handling the empty coherent_dma_mask.
Kernel 4.19 came with a lot of DMA changes and cau
From: Rafał Miłecki
This new macro uses wiphy_err() which:
1) Should be the best choice with wiphy already created
2) Uses dev_err() which allows identifying error-affected device
Signed-off-by: Rafał Miłecki
---
This is based on Arend's feedback from
[PATCH 2/2] brcmfmac: pass bus t
From: Rafał Miłecki
So far __brcmf_err() was using pr_err() which didn't allow identifying
device that was affected by an error. It's crucial for systems with more
than 1 device supported by brcmfmac (a common case for home routers).
This change allows passing struct brcmf_
From: Rafał Miłecki
This enables dev_err() usage (instead of pr_err()) in the __brcmf_err().
It makes error messages more meaningful and is important for debugging
errors/bugs on systems with multiple brcmfmac supported devices.
All bus files should follow & get updated similarly (
On Tue, 15 Jan 2019 at 09:48, Arend Van Spriel
wrote:
> On 1/15/2019 7:19 AM, Rafał Miłecki wrote:
> > From: Rafał Miłecki
> >
> > So far __brcmf_err() was using pr_err() which didn't allow identifying
> > device that was affected by an error. It's crucial fo
From: Rafał Miłecki
This enables dev_err() usage (instead of pr_err()) in the __brcmf_err().
It makes error messages more meaningful and is important for debugging
errors/bugs on systems with multiple brcmfmac supported devices.
All other files should follow & get updated similarly (
From: Rafał Miłecki
So far __brcmf_err() was using pr_err() which didn't allow identifying
device that was affected by an error. It's crucial for systems with more
than 1 device supported by brcmfmac (a common case for home routers).
This change allows passing struct brcmf_
On 2019-01-02 16:50, Hauke Mehrtens wrote:
On 1/2/19 1:51 PM, Rafał Miłecki wrote:
From: Rafał Miłecki
So far we never had any device registered for the SoC. This resulted
in
some small issues that we kept ignoring like:
1) Not working GPIOLIB_IRQCHIP (gpiochip_irqchip_add_key() failing)
2
From: Rafał Miłecki
So far we never had any device registered for the SoC. This resulted in
some small issues that we kept ignoring like:
1) Not working GPIOLIB_IRQCHIP (gpiochip_irqchip_add_key() failing)
2) Lack of proper tree in the /sys/devices/
3) mips_dma_alloc_coherent() silently handling
From: Rafał Miłecki
So far we never had any device registered for the SoC. This resulted in
some small issues that we kept ignoring like:
1) Not working GPIOLIB_IRQCHIP (gpiochip_irqchip_add_key() failing)
2) Lack of proper tree in the /sys/devices/
3) mips_dma_alloc_coherent() silently handling
From: Rafał Miłecki
Accessing struct device is pretty useful/common so having a direct
pointer:
1) Simplifies some code
2) Makes bcma_bus_get_host_dev() unneeded
3) Allows further improvements like using dev_* printing helpers
Signed-off-by: Rafał Miłecki
---
drivers/bcma/bcma_private.h | 1
From: Rafał Miłecki
It provides more meaningful messages.
Signed-off-by: Rafał Miłecki
---
drivers/bcma/bcma_private.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/bcma/bcma_private.h b/drivers/bcma/bcma_private.h
index 1f0e66310b23..6eded32d1aac 100644
On Sat, 15 Dec 2018 at 12:03, Arend Van Spriel
wrote:
> On 12/14/2018 2:02 PM, Josh Boyer wrote:
> > On Wed, Nov 7, 2018 at 3:45 PM Arend van Spriel
> > wrote:
> >>
> >> These firmwares are for the BCM4366 3x3 802.11 ac chipsets, which also
> >> comprise of BCM4366E or BCM43664 devices. Signed-o
On Mon, 10 Dec 2018 at 10:32, Arend van Spriel
wrote:
> This series includes the firmwares for the BCM4366 3x3 802.11ac chipset.
> The firmware for the bcm4366c0 has been long overdue.
>
> I did submit the firmware files early November in a single patch, but
> probably hit the majordomo limit of 1
apabilities:
commit f4830bed661f4adff51f50a0d37c64ceb748e780
Author: Rafał Miłecki
Date: Mon Apr 25 17:10:47 2016 +0200
nl80211: Try running without mgmt frame subscription (driver AP SME)
So your problem is the ancient hostapd that can't run with drivers that:
1) Report NL80211_ATTR_DEVICE_AP_SME
2) Don&
On Wed, 8 Feb 2017 at 08:55, David Lin wrote:
> > From: Rafał Miłecki [mailto:zaj...@gmail.com] worte:
> > On 8 February 2017 at 08:28, David Lin wrote:
> > >> From: Rafał Miłecki [mailto:zaj...@gmail.com] worte:
> > >> Sent: Wednesday, February 08, 2017 3:2
On 2018-11-16 09:46, Kalle Valo wrote:
(changing subject for better visibility and trimming Cc)
Rafał Miłecki writes:
On 2018-11-09 15:05, Kalle Valo wrote:
Rafał Miłecki writes:
From: Rafał Miłecki
Driver can report IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ so it's
important to pr
On 2018-11-09 15:05, Kalle Valo wrote:
Rafał Miłecki writes:
From: Rafał Miłecki
Driver can report IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ so it's
important to provide valid & complete info about supported bands for
each channel. By default no support for 160 MHz should be assume
From: Rafał Miłecki
Driver can report IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ so it's
important to provide valid & complete info about supported bands for
each channel. By default no support for 160 MHz should be assumed unless
firmware reports it for a given channel later.
This f
I just wanted to share my opinion /
ping due to patch being marked as "Deferred".
Reviewed-by: Rafał Miłecki
From: Rafał Miłecki
On one of my devices I got WARNINGs when brcmfmac tried to decode
chanspec. I couldn't tell if it was some unsupported format or just a
malformed value passed by a firmware.
Print chanspec value so it's possible to debug a possible problem.
Signed-off-by: Raf
From: Rafał Miłecki
Previous commit /adding/ support for 160 MHz chanspecs was incomplete.
It didn't set bandwidth info and didn't extract control channel info. As
the result it was also using uninitialized "sb" var.
This change has been tested for two chanspecs found to
On Wed, 5 Sep 2018 at 13:06, Arend van Spriel
wrote:
> 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 Ju
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
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 event handler
but it wasn't e
From: Rafał Miłecki
NVRAM is designed to work with Broadcom's SDK Linux kernel which fakes
PCI domain 0 for all internal MMIO devices. Since official Linux kernel
uses platform devices for that purpose there is a mismatch in numbering
PCI domains.
There used to be a fix for that problem b
From: Rafał Miłecki
Some features supported by firmware aren't advertised and there is no
way for a driver to query them. This includes e.g. monitor mode details.
Most firmwares support monitor interface but only the latest ones
/announce/ it with a "monitor" flag in the &qu
From: Rafał Miłecki
Some features supported by firmware aren't advertised and there is no
way for a driver to query them. This includes e.g. monitor mode details.
Most firmwares support monitor interface but only the latest ones
/announce/ it with a "monitor" flag in the &qu
On 2018-06-30 20:48, Arend van Spriel wrote:
On 6/28/2018 12:36 PM, Rafał Miłecki wrote:
From: Rafał Miłecki
That struct is used when querying firmware for the STA. It seem is has
been changing during the time. Luckily its format seems to be backward
compatible starting with v2 (the only
On 2018-06-29 09:03, Kalle Valo wrote:
Rafał Miłecki writes:
From: Rafał Miłecki
Depending on used build-time options some firmwares may already
include
radiotap header in passed monitor frames. Add a new feature flag to
store info about it. It's needed for proper handling of rec
From: Rafał Miłecki
That struct is used when querying firmware for the STA. It seem is has
been changing during the time. Luckily its format seems to be backward
compatible starting with v2 (the only breakage was v1 -> v2).
The version that was supported by brcmfmac so far was v4. It was w
From: Rafał Miłecki
That struct is passed by a firmware when querying for STA info. Flags
are used to indicate what info could be obtained.
These new defines may allow passing more info to the cfg80211 in the
future. They had been obtained from Broadcom's SDK file wlioctl_defs.h
used by D
On 2018-06-25 10:28, Arend van Spriel wrote:
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ł
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 Mon, 25 Jun 2018 at 10:18, Arend van Spriel
wrote:
> 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 queryi
On 15.05.2018 14:29, Rafał Miłecki wrote:
I was hoping that maybe looking at fw-reported capabilities will give me
any hint regarding that but I'm afraid I'm out of luck. Below is a list
of firmwares I tested and summary of each of them.
Note: as every firmware reports following ca
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 the
From: Rafał Miłecki
Many/most of firmwares support creating monitor interface but only the
most recent ones explicitly /announce/ it using a "monitor" entry in the
list of capabilities.
Check for that entry and store internally info about monitor mode
support using a new feature fla
From: Rafał Miłecki
New Broadcom firmwares mark monitor mode packets using a newly defined
bit in the flags field. Use it to filter them out and pass to the
monitor interface. These defines were found in bcmmsgbuf.h from SDK.
As not every firmware generates radiotap header this commit
From: Rafał Miłecki
Depending on used build-time options some firmwares may already include
radiotap header in passed monitor frames. Add a new feature flag to
store info about it. It's needed for proper handling of received frames
before passing them up.
Signed-off-by: Rafał Miłecki
S
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
> >>>
> >>> Afte
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, this iovar will fail with BCME_NOTUP; Otherwise
> it fails with BCME_
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 in the driver
> so there is a patch for tha
1 - 100 of 774 matches
Mail list logo
