From: Rafał Miłecki
So far we got only one function for loading firmware asynchronously:
request_firmware_nowait. It didn't allow much customization of firmware
loading process - there is only one bool uevent argument. Moreover this
bool also controls user helper in an unclear way.
Resolve
From: Rafał Miłecki
Failing to load NVRAM file isn't critical if we manage to get platform
one in the fallback path. It means warnings like:
[ 10.801506] brcmfmac :01:00.0: Direct firmware load for
brcm/brcmfmac43602-pcie.txt failed with error -2
are unnecessary & disturbing f
Hi guys,
On 12 September 2016 at 07:22, Rafał Miłecki wrote:
> Few months ago Hante added support for 4366c0 to the brcmfmac. There
> are already few devices with this chipset on the market. We even have
> some related bug report at kernel:
> https://bugzilla.kernel.org/show_bug.c
On 8 February 2017 at 10:54, Arend Van Spriel
wrote:
> On 2-2-2017 22:33, Rafał Miłecki wrote:
>> From: Rafał Miłecki
>>
>> This will allow getting struct device reference from the passed
>> brcmf_pub for the needs of dev_err. More detailed messages are really
>>
Hey Arend,
On 8 February 2017 at 10:54, Arend Van Spriel
wrote:
> On 2-2-2017 22:33, Rafał Miłecki wrote:
>> From: Rafał Miłecki
>>
>> This will allow getting struct device reference from the passed
>> brcmf_pub for the needs of dev_err. More detailed messages are r
From: Rafał Miłecki
43602a0 uses chip revision 0 compared to 43602a1 with revision 1. In
brcmfmac there is support for 43602a1 and from what I know supporting
43602a0 would require loading a different firmware.
Signed-off-by: Rafał Miłecki
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac
From: Rafał Miłecki
Many chips have few variants/versions, e.g. BCM4366 can be 4366b1 or
4366c0. Cutting name at the letter isn't a good idea as sometimes we may
have e.g. a0 and a1.
This is just a cosmetic change, a trivial cleanup. It obviously doesn't
change fw filenames as we don
From: Rafał Miłecki
It avoids some unnecessary work. Most likely there wasn't much sense in
doing this before bus reset anyway, as reset is supposed to put chip
into default state. In PCIe code (only bus implementing reset) we e.g.
use watchdog to perform a chip "reboot".
Signe
On 2017-02-24 14:31, Arend Van Spriel wrote:
On 24-2-2017 14:10, Rafał Miłecki wrote:
From: Rafał Miłecki
It avoids some unnecessary work. Most likely there wasn't much sense
in
doing this before bus reset anyway, as reset is supposed to put chip
into default state. In PCIe code (onl
On 2017-02-24 14:21, Arend Van Spriel wrote:
On 24-2-2017 13:27, Rafał Miłecki wrote:
From: Rafał Miłecki
43602a0 uses chip revision 0 compared to 43602a1 with revision 1. In
brcmfmac there is support for 43602a1 and from what I know supporting
43602a0 would require loading a different
From: Rafał Miłecki
So far we were attaching BRCMF_E_PSM_WATCHDOG event listener in
brcmf_debug_attach which gets compiled only with CONFIG_BRCMDBG. This
event means something went wrong and firmware / hardware usually can't
be expected to work (reliably).
Such a problem is significant for
From: Rafał Miłecki
When PSM's watchdog fires hardware / firmware is not operational. It
seems there isn't a way to restart firmware & reapply all settings so
instead shut all interfaces down. This is at least some signal for the
user things went wrong and allows reacting to it.
From: Rafał Miłecki
This helper function is pretty trivial and we can easily do without it.
What's important though it's one of FWS (Firmware Signalling)
dependencies in core.c. The plan is to make FWS required by BCDC only so
we don't have to use/compile it when using msgbuf.
From: Rafał Miłecki
This function is called by USB and SDIO only, both using BCDC & FW
Signalling. Move it out of core.c to make this file more generic and
allow making fwsignal optional in the future.
Signed-off-by: Rafał Miłecki
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/b
Why you didn't cc linux-wireless?!?!
On 27 February 2017 at 21:28, Alban wrote:
> @@ -513,6 +515,43 @@ static void ath9k_eeprom_release(struct ath_softc *sc)
> release_firmware(sc->sc_ah->eeprom_blob);
> }
>
> +#ifdef CONFIG_OF
> +static int ath9k_init_of(struct ath_softc *sc)
> +{
> +
On 27 February 2017 at 23:48, Alban wrote:
> On Mon, 27 Feb 2017 22:13:21 +0100
> Rafał Miłecki wrote:
>
>> Why you didn't cc linux-wireless?!?!
>
> I first wanted to be sure that the devdata part was generally
> acceptable, this patch was just included as an exam
On 28 February 2017 at 10:50, Arend Van Spriel
wrote:
> On 27-2-2017 13:06, Rafał Miłecki wrote:
>> From: Rafał Miłecki
>>
>> This helper function is pretty trivial and we can easily do without it.
>> What's important though it's one of FWS (Firmware Signa
From: Rafał Miłecki
This function is called by USB and SDIO only, both using BCDC & FW
Signalling. Move it out of core.c to make this file more generic and
allow making fwsignal optional in the future.
Signed-off-by: Rafał Miłecki
---
V2: Make code with this patch compile when not based on
From: Rafał Miłecki
PCI devices can be described in DT as well so we should always execute
relevant code. This will make bcma e.g. set of_node for cores described
in DT.
Signed-off-by: Rafał Miłecki
---
drivers/bcma/main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
From: Rafał Miłecki
A tiny code deduplication thanks to the bcma_bus_get_host_dev.
Signed-off-by: Rafał Miłecki
---
drivers/bcma/main.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/bcma/main.c b/drivers/bcma/main.c
index 12da68ec48ba..4f88821c1b2a 100644
--- a
From: Rafał Miłecki
We already have the same check in bcma_of_get_irq which really calls
symbols available with CONFIG_OF_IRQ only. It appears this duplicated
check was accidentally added in commit c58d900cc96a ("bcma: fix building
without OF_IRQ"). The rest of code in bcma_of_fill_dev
On 01/09/2017 10:07 AM, igor.mitsyanko...@quantenna.com wrote:
From: Igor Mitsyanko
This patch adds support for new FullMAC WiFi driver for Quantenna
QSR10G chipsets.
QSR10G (aka Pearl) is Quantenna's 8x8, 160M, 11ac offering.
QSR10G supports 2 simultaneous WMACs - one 5G and one 2G.
5G WMAC s
Two more comments. Please note I don't find these things critical, this would be
fine to fix them in incremental patch for me.
On 01/09/2017 10:07 AM, igor.mitsyanko...@quantenna.com wrote:
> +static int qtnf_core_mac_init(struct qtnf_bus *bus, int macid)
> +{
> + struct qtnf_wmac *mac;
> + str
On 7 March 2017 at 11:07, Igor Mitsyanko
wrote:
> On 03/07/2017 12:19 AM, Rafał Miłecki wrote:
>> On 01/09/2017 10:07 AM, igor.mitsyanko...@quantenna.com wrote:
>>>
>>> From: Igor Mitsyanko
>>>
>>> This patch adds support for new FullMAC
On 7 March 2017 at 14:32, Kalle Valo wrote:
> Rafał Miłecki writes:
>
>> From: Rafał Miłecki
>>
>> When PSM's watchdog fires hardware / firmware is not operational. It
>> seems there isn't a way to restart firmware & reapply all settings so
>>
On 03/13/2017 10:05 PM, Alban wrote:
@@ -654,6 +656,25 @@ static int ath9k_init_softc(u16 devid, struct ath_softc
*sc,
if (ret)
return ret;
+ /* If the EEPROM hasn't been retrieved via firmware request
+* use the nvmem API insted.
+*/
+ if (!a
On 03/13/2017 10:05 PM, Alban wrote:
@@ -573,6 +575,12 @@ static int ath9k_of_init(struct ath_softc *sc)
ath_dbg(common, CONFIG, "parsing configuration from OF node\n");
+ clk = clk_get(sc->dev, "ref");
+ if (!IS_ERR(clk)) {
+ ah->is_clk_25mhz = (clk_get_rate(c
On 23 February 2017 at 19:30, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> So far we got only one function for loading firmware asynchronously:
> request_firmware_nowait. It didn't allow much customization of firmware
> loading process - there is only one bool uevent arg
On 02/23/2017 07:30 PM, Rafał Miłecki wrote:
From: Rafał Miłecki
So far we got only one function for loading firmware asynchronously:
request_firmware_nowait. It didn't allow much customization of firmware
loading process - there is only one bool uevent argument. Moreover this
bool
From: Rafał Miłecki
fwsignal is only used by bcdc. Create new protocol interface functions
for core code to perform proto specific (de)initialization. This makes
core agnostic to the protocol which will allow further optimizations.
We will be able to avoid compiling unused protocols or
From: Rafał Miłecki
For quite some time now brcmfmac supports 802.11ac chipsets and it's
not limited to embedded devices only. There are even standalone PCIe
cards based on BCM43602 or BCM4366.
Signed-off-by: Rafał Miłecki
---
drivers/net/wireless/broadcom/brcm80211/Kconfig | 10 +---
From: Rafał Miłecki
Right now whole brcmfmac is a single module. Enabling one bus support
increases brcmfmac.ko size which may be unwanted for some embedded
devices like home routers. With this change brcmfmac gets modularized.
It's possible to build brcmfmac without PCIe support and
On 2017-03-22 20:38, Arend Van Spriel wrote:
On 21-3-2017 15:43, Rafał Miłecki wrote:
From: Rafał Miłecki
For quite some time now brcmfmac supports 802.11ac chipsets and it's
not limited to embedded devices only. There are even standalone PCIe
cards based on BCM43602 or BCM4366.
From: Rafał Miłecki
For quite some time now brcmfmac supports 802.11ac chipsets and it's
not limited to embedded devices only. There are even standalone PCIe
cards based on BCM43602 or BCM4366.
Signed-off-by: Rafał Miłecki
Reviewed-by: Arend van Spriel
---
V2: Drop "IEEE802.11n&quo
On 03/28/2017 12:43 PM, Arend van Spriel wrote:
This series intended for 4.12 includes:
- support for network namespace
- rework fwsignal module
- small fix for suspend error code path
Arend van Spriel (3):
brcmfmac: add support to move wiphy instance into network namespace
brcmfmac: restore
On 03/28/2017 12:43 PM, Arend van Spriel wrote:
From: Franky Lin
Create a new protocol layer interface brcmf_proto_init_cb for protocol
layer to finish initialzation after core module components(fweh and
etc.) are initialized.
Signed-off-by: Franky Lin
Change-Id: I560d2478a7c09766cf07b20d74b3
On 03/28/2017 12:43 PM, Arend van Spriel wrote:
From: Franky Lin
Move brcmf_fws_deinit into brcmf_proto_bcdc_detach since it is a bcdc
exclusive feature.
Signed-off-by: Franky Lin
Change-Id: Iefa5db632b92185a49d538b1cd25b7d8be618ce0
Reviewed-on: http://hnd-swgit.sj.broadcom.com:8080/8157
Revi
On 03/22/2017 08:43 PM, Arend Van Spriel wrote:
On 21-3-2017 14:44, Rafał Miłecki wrote:
From: Rafał Miłecki
fwsignal is only used by bcdc. Create new protocol interface functions
for core code to perform proto specific (de)initialization. This makes
core agnostic to the protocol which will
Sending with a fixed linux-wireless ML address. Please kindly send your
replies using linux-wireless@
On 02/27/2018 11:08 AM, Rafał Miłecki wrote:
I've problem when using OpenWrt/LEDE on a home router with Broadcom's
FullMAC WiFi chipset.
First of all OpenWrt/LEDE uses bridge int
On 26 February 2018 at 09:44, wrote:
> From: Sebastian Gottschall
>
> Adds LED and GPIO Control support for 988x, 9887, 9888, 99x0, 9984 based
> chipsets with on chipset connected led's
> using WMI Firmware API.
> The LED device will get available named as "ath10k-phyX" at sysfs and can be
> c
On 14 December 2017 at 14:21, Kalle Valo wrote:
> Christian Lamparter writes:
>
>> On Monday, November 20, 2017 11:57:21 AM CET Kalle Valo wrote:
>>> Christian Lamparter writes:
>>>
>>> > On Wednesday, November 1, 2017 9:37:53 PM CET Sebastian Gottschall wrote:
>>> >> a additional array bounds c
On 2 March 2018 at 10:22, Sebastian Gottschall wrote:
>>> leds-gpio is crap and limited. you can just register one platform data at
>>> kernel runtime since its identified by its object name "led-gpio" but the
>>> kernel forbidds to register 2 platform datas with the same name
>>> consider the ar7
On 11 March 2018 at 08:12, Kalle Valo wrote:
> Rafał Miłecki writes:
>
>> On 14 December 2017 at 14:21, Kalle Valo wrote:
>>> Christian Lamparter writes:
>>>
>>>> On Monday, November 20, 2017 11:57:21 AM CET Kalle Valo wrote:
>>>>>
On 27 February 2018 at 18:05, Stephen Hemminger
wrote:
> On Tue, 27 Feb 2018 11:08:20 +0100
> Rafał Miłecki wrote:
>
>> I've problem when using OpenWrt/LEDE on a home router with Broadcom's
>> FullMAC WiFi chipset.
>>
>>
>> First of all OpenWr
On 28 February 2018 at 12:31, Arend van Spriel
wrote:
> On 2/27/2018 11:14 AM, Rafał Miłecki wrote:
>>
>> Sending with a fixed linux-wireless ML address. Please kindly send your
>> replies using linux-wireless@
>>
>> On 02/27/2018 11:08 AM, Rafał Miłecki wrote
On 12 March 2018 at 12:08, Linus Lüssing wrote:
> On Tue, Feb 27, 2018 at 11:08:20AM +0100, Rafał Miłecki wrote:
>> I've problem when using OpenWrt/LEDE on a home router with Broadcom's
>> FullMAC WiFi chipset.
>
> Hi Rafał,
>
> Thanks for reporting this iss
On 12 March 2018 at 12:48, Linus Lüssing wrote:
> On Mon, Mar 12, 2018 at 12:08:56PM +0100, Linus Lüssing wrote:
>> On Tue, Feb 27, 2018 at 11:08:20AM +0100, Rafał Miłecki wrote:
>> > I've problem when using OpenWrt/LEDE on a home router with Broadcom's
>> >
On 02/27/2018 11:08 AM, Rafał Miłecki wrote:
I've problem when using OpenWrt/LEDE on a home router with Broadcom's
FullMAC WiFi chipset.
First of all OpenWrt/LEDE uses bridge interface for LAN network with:
1) IFLA_BRPORT_MCAST_TO_UCAST
2) Clients isolation in hostapd
3) Hairpin mo
On 03/13/2018 12:01 AM, Stephen Hemminger wrote:
On Mon, 12 Mar 2018 23:42:48 +0100
Rafał Miłecki wrote:
2) Blame bridge + mcast-to-ucast + hairpin for 802.11f incompatibility
If we agree that 802.11f support in FullMAC firmware is acceptable, then
we have to make sure Linux's bridge do
From: Rafał Miłecki
Testing brcmfmac with more recent firmwares resulted in AP interfaces
not working in some specific setups. Debugging resulted in discovering
support for IAPP in Broadcom's firmwares. This is an obsoleted standard
and its implementation is something that:
1) Most people
On 2018-03-14 16:08, Kalle Valo wrote:
Arend van Spriel writes:
On 3/14/2018 3:24 PM, Kalle Valo wrote:
+config BRCMFMAC_IAPP
>+ bool "Partial support for obsoleted Inter-Access Point Protocol"
>+ depends on BRCMFMAC
>+ ---help---
>+ Most of Broadcom's firmwares can send 802.11f ADD
On 2018-03-14 16:39, Rafał Miłecki wrote:
On 2018-03-14 13:58, Arend van Spriel wrote:
On 3/14/2018 12:01 PM, Rafał Miłecki wrote:
From: Rafał Miłecki
Testing brcmfmac with more recent firmwares resulted in AP interfaces
not working in some specific setups. Debugging resulted in
discovering
On 2018-03-14 16:39, Rafał Miłecki wrote:
On 2018-03-14 13:58, Arend van Spriel wrote:
On 3/14/2018 12:01 PM, Rafał Miłecki wrote:
From: Rafał Miłecki
Testing brcmfmac with more recent firmwares resulted in AP interfaces
not working in some specific setups. Debugging resulted in
discovering
On 2018-03-14 15:24, Kalle Valo wrote:
Rafał Miłecki writes:
From: Rafał Miłecki
Testing brcmfmac with more recent firmwares resulted in AP interfaces
not working in some specific setups. Debugging resulted in discovering
support for IAPP in Broadcom's firmwares. This is an obso
On 2018-03-14 13:58, Arend van Spriel wrote:
On 3/14/2018 12:01 PM, Rafał Miłecki wrote:
From: Rafał Miłecki
Testing brcmfmac with more recent firmwares resulted in AP interfaces
not working in some specific setups. Debugging resulted in discovering
support for IAPP in Broadcom's firm
On 14 March 2018 at 20:02, Stefan Wahren wrote:
> The commit "regulatory: add NUL to request alpha2" increases the length of
> alpha2 to 3. This causes a regression on brcmfmac, because
> brcmf_cfg80211_reg_notifier() expect valid ISO3166 codes in the complete
> array. So fix this accordingly.
>
>
From: Rafał Miłecki
Testing brcmfmac with more recent firmwares resulted in AP interfaces
not working in some specific setups. Debugging resulted in discovering
support for IAPP in Broadcom's firmwares.
Older firmwares were only generating 802.11f frames. Newer ones like:
1) 10.10
On 15 March 2018 at 08:29, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> Testing brcmfmac with more recent firmwares resulted in AP interfaces
> not working in some specific setups. Debugging resulted in discovering
> support for IAPP in Broadcom's firmwares.
>
>
On 19 March 2018 at 09:11, Martin Blumenstingl
wrote:
> - some ship with a broken EEPROM that enables the 5GHz band on a
> 2.4GHz-only card, which is why we need "qca,disable-5ghz"
No. You just need to use ieee80211-freq-limit.
--
Rafał
Hi,
On 23 March 2018 at 10:47, Juri Lelli wrote:
> I've got a Dell XPS 13 9343/0TM99H (BIOS A15 01/23/2018) mounting a
> BCM4352 802.11ac (rev 03) wireless card and so far I've been using it on
> Fedora with broadcom-wl package (which I believe installs Broadcom's STA
> driver?). It works good ap
On 23 March 2018 at 15:09, Juri Lelli wrote:
> On 23/03/18 14:43, Rafał Miłecki wrote:
>> Hi,
>>
>> On 23 March 2018 at 10:47, Juri Lelli wrote:
>> > I've got a Dell XPS 13 9343/0TM99H (BIOS A15 01/23/2018) mounting a
>> > BCM4352 802.11ac (rev 03) wi
On 03/29/2018 08:20 AM, Ramon Fried wrote:
wcn3610 can only operate on 2.4GHz band due to RF limitation.
If wcn36xx digital block is associated with an external IRIS
RF module, retrieve the id and disable 5GHz band in case of
wcn3610 id.
Signed-off-by: Ramon Fried
---
drivers/net/wireless/ath/
On 23 March 2018 at 10:31, Arend van Spriel
wrote:
> On 3/22/2018 4:58 PM, Dan Haab wrote:
>>
>> From: Dan Haab
>>
>> BCM4366E is a wireless chipset with a BCM43664 ChipCommon. It's
>> supported by the same firmware as 4366c0.
>
>
> Thanks, Dan
>
> I have a patch for that queued up already. So le
On 3 April 2018 at 10:22, Arend van Spriel wrote:
> On 3/30/2018 9:26 AM, Rafał Miłecki wrote:
>>
>> On 23 March 2018 at 10:31, Arend van Spriel
>> wrote:
>>>
>>> On 3/22/2018 4:58 PM, Dan Haab wrote:
>>>>
>>>>
>>>&g
On 3 April 2018 at 13:24, Arend van Spriel wrote:
> On 4/3/2018 12:17 PM, Rafał Miłecki wrote:
>>
>> On 3 April 2018 at 10:22, Arend van Spriel
>> wrote:
>
>
> [...]
>
>>>
>>>
>>> My first reaction to this email needed to some cooldown
On 17 March 2016 at 10:39, Arnd Bergmann wrote:
> While fixing another bug, I noticed that bcma manually sets up
> a dma_mask pointer for its child devices. We have a generic
> helper for that now, which should be able to cope better with
> any variations that might be needed to deal with cache co
Hi,
Few months ago Hante added support for 4366c0 to the brcmfmac. There
are already few devices with this chipset on the market. We even have
some related bug report at kernel:
https://bugzilla.kernel.org/show_bug.cgi?id=135321
Unfortunately the firmware for this chipset is still missing. Can yo
Hi,
Even with the most recent brcmfmac code ppl keep seeing WARNINGs from
brcmf_netdev_wait_pend8021x [0].
Hante suggested using CONSOLE for debugging some firmware crash so I
decided to see I it could also help understanding WARNINGs. I believe it
did.
First of all, I can't reproduce these prob
On 09/14/2016 07:45 AM, Rafał Miłecki wrote:
Even with the most recent brcmfmac code ppl keep seeing WARNINGs from
brcmf_netdev_wait_pend8021x [0].
Hante suggested using CONSOLE for debugging some firmware crash so I
decided to see I it could also help understanding WARNINGs. I believe it
did
On 09/14/2016 07:45 AM, Rafał Miłecki wrote:
First of all, I can't reproduce these problems reliably. One evening I
got WARNINGs one by one and I could work on my debugging patch easily.
Yesterday when I got my patch complete, it took me 10+ hours to get a
single WARNING.
I think I found
Hi,
Yesterday I explained on OpenWrt forum [0] that there are 2 problems
leading to WARNINGs triggered by brcmf_netdev_wait_pend8021x.
The first one is firmware problem with A-MPDU implementation. I already
reported this in "AMPDU stalls with brcmfmac4366b-pcie.bin triggering
WARNINGs" e-mail thr
On 15 September 2016 at 11:20, Hante Meuleman
wrote:
> Thank you for the extensive debugging. We are looking into this. Arend wrote
> yesterday to ask for detailed timing on wen eapol is inserted. We want this
> so we can increase the timeout. This is not a "nice" way to solve the
> problem, and
On 09/14/2016 08:28 PM, Arend Van Spriel wrote:
> On 14-9-2016 7:45, Rafał Miłecki wrote:
>> Even with the most recent brcmfmac code ppl keep seeing WARNINGs from
>> brcmf_netdev_wait_pend8021x [0].
>>
>> Hante suggested using CONSOLE for debugging some firmware crash
On 09/15/2016 01:48 PM, Rafał Miłecki wrote:
On 09/14/2016 08:28 PM, Arend Van Spriel wrote:
It would be great to have a timestamp for these skb when they arrive in
brcmfmac or transferred to firmware (or both).
You ask and you have it :) I saved kernel's local time and printed it the
Hi Hante,
I hit this problem again and I'm afraid it's getting even more complex. Last
time you were suspecting flowring deletion but it didn't make much sense to me.
It was because I didn't see brcmf_flowring_delete anywhere in my log.
Well, today it was different. I saw brcmf_flowring_delete wh
From: Rafał Miłecki
Sending a new key to the firmware should be done without any 802.1x
packets pending. Currently brcmfmac has very trivial code waiting for
that condition and it doesn't seem to be enough.
We should stop netif from sending any extra packets in order to:
1) Make sure new 8
From: Rafał Miłecki
This function is called from get_station callback which means that every
time user space was getting/dumping station(s) we were leaking 2 KiB.
Signed-off-by: Rafał Miłecki
Fixes: 1f0dc59a6de ("brcmfmac: rework .get_station() callback")
Cc: sta...@vger.kernel
And again...
I decided to focus on brcmf_flowring_delete a bit more.
As I can see flowrings are created and removed from time to time, in most cases
they are empty when being deleted. When they are not, things go wrong. In below
log you can see brcmfmac removing flowring that got 8 skb packets.
On 09/22/2016 01:59 PM, Rafał Miłecki wrote:
And again...
I decided to focus on brcmf_flowring_delete a bit more.
As I can see flowrings are created and removed from time to time, in most cases
they are empty when being deleted. When they are not, things go wrong. In below
log you can see
On 22 September 2016 at 14:24, Rafał Miłecki wrote:
> On 09/22/2016 01:59 PM, Rafał Miłecki wrote:
>>
>> And again...
>>
>> I decided to focus on brcmf_flowring_delete a bit more.
>>
>> As I can see flowrings are created and removed from time to time, in mos
On 23 September 2016 at 04:43, David Petrizze wrote:
> I'm having issues with broadcom's latest firmware / driver, version
> 6.30.163.46. Wireless is solid for about a minute, and then drops
> completely. My research has led me to believe my chip (BCM4331) is no
> longer supported under 6.30.X.X,
On 22 September 2016 at 16:09, Rafał Miłecki wrote:
> On 22 September 2016 at 14:24, Rafał Miłecki wrote:
>> I got the same problem again, but this time there was only 1 skb in my
>> flowring.
>> That resulted in less serial console messages and no reboot.
>&
From: Rafał Miłecki
They seem to be there from the first day. We calculate these values but
never use them.
Signed-off-by: Rafał Miłecki
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c | 3 ---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h | 4
drivers/net
From: Rafał Miłecki
There are two protocols used by Broadcom FullMAC devices: BCDC and
msgbuf. They use different ways for (some part of) communication with
the firmware. Firmware Signaling is required for the first one only
(BCDC).
So far we were always initializing fws and always calling it&#
From: Rafał Miłecki
It's not needed by the other (msgbuf) protocol, so let's save some size
and compile it conditionally.
Signed-off-by: Rafał Miłecki
---
.../wireless/broadcom/brcm80211/brcmfmac/Makefile | 4 +-
.../broadcom/brcm80211/brcmfmac/fwsignal.h
From: Rafał Miłecki
We need to track 802.1x packets to know if there are any pending ones
for transmission. This is required for performing key update in the
firmware.
Unfortunately our old tracking code wasn't very accurate. It was
treating skb as pending as soon as it was passed by the
On 26 September 2016 at 13:46, Arend Van Spriel
wrote:
> On 26-9-2016 12:23, Rafał Miłecki wrote:
>> From: Rafał Miłecki
>>
>> We need to track 802.1x packets to know if there are any pending ones
>> for transmission. This is required for performing key update in the
&
On 26 September 2016 at 14:13, Rafał Miłecki wrote:
> On 26 September 2016 at 13:46, Arend Van Spriel
> wrote:
>> On 26-9-2016 12:23, Rafał Miłecki wrote:
>>> From: Rafał Miłecki
>>>
>>> We need to track 802.1x packets to know if there are any pending ones
From: Rafał Miłecki
So far our core code was calling brcmf_fws_process_skb which wasn't
a proper thing to do. If case of devices using msgbuf protocol fwsignal
shouldn't be used. It was an unnecessary extra layer simply calling
a protocol specifix txdata function.
Please note we al
From: Rafał Miłecki
Flowrings contain skbs waiting for transmission that were passed to us
by netif. It means we checked every one of them looking for 802.1x
Ethernet type. When deleting flowring we have to use freeing function
that will check for 802.1x type as well.
Freeing skbs without a
From: Rafał Miłecki
Even with timeout increased to 950 ms we get WARNINGs from time to time.
It mostly happens on A-MPDU stalls (e.g. when station goes out of
range). It may take up to 5-10 secods for the firmware to recover and
for that time it doesn't process packets.
It's still
On 27 September 2016 at 13:27, Kalle Valo wrote:
> Arend Van Spriel writes:
>
>> On 27-9-2016 11:14, Rafał Miłecki wrote:
>>> From: Rafał Miłecki
>>>
>>> Flowrings contain skbs waiting for transmission that were passed to us
>>> by netif. It means
On 27 September 2016 at 13:44, Rafał Miłecki wrote:
> On 27 September 2016 at 13:27, Kalle Valo wrote:
>> Arend Van Spriel writes:
>>
>>> On 27-9-2016 11:14, Rafał Miłecki wrote:
>>>> From: Rafał Miłecki
>>>>
>>>> Flowrings contain
On 27 September 2016 at 14:04, Arend Van Spriel
wrote:
> On 27-9-2016 13:58, Rafał Miłecki wrote:
>> On 27 September 2016 at 13:44, Rafał Miłecki wrote:
>>> On 27 September 2016 at 13:27, Kalle Valo wrote:
>>>> Arend Van Spriel writes:
>>>>
>
From: Rafał Miłecki
Flowrings contain skbs waiting for transmission that were passed to us
by netif. It means we checked every one of them looking for 802.1x
Ethernet type. When deleting flowring we have to use freeing function
that will check for 802.1x type as well.
Freeing skbs without a
On 27 September 2016 at 11:24, Arend Van Spriel
wrote:
> On 26-9-2016 14:38, Rafał Miłecki wrote:
>> On 26 September 2016 at 14:13, Rafał Miłecki wrote:
>>> On 26 September 2016 at 13:46, Arend Van Spriel
>>> wrote:
>>>> On 26-9-2016 12:23, Rafał M
On 09/28/2015 11:00 AM, Rafał Miłecki wrote:
I'm using recent brcmfmac and brcmfmac43602-pcie.ap.bin that currently
sits in linux-firmware.git.
In OpenWrt we have hostapd with a feature of banning STAs. It works in
a quite simple way. Whenever hostapd gets NL80211_CMD_NEW_STATION for
STA
On 10/05/2016 11:08 AM, Arend Van Spriel wrote:
On 4-10-2016 20:15, Rafał Miłecki wrote:
On 09/28/2015 11:00 AM, Rafał Miłecki wrote:
I'm using recent brcmfmac and brcmfmac43602-pcie.ap.bin that currently
sits in linux-firmware.git.
In OpenWrt we have hostapd with a feature of banning
From: Rafał Miłecki
This simplifies debugging. Format %s (%u) comes from similar debugging
message in brcmf_fweh_event_worker.
Signed-off-by: Rafał Miłecki
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 3 ++-
drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c | 4
On 14 October 2016 at 12:13, Arend Van Spriel
wrote:
> Ok. Did you also try the firmware I sent you?
It gets more complex there, I'm still working on this. Will provide
more info later today.
1 - 100 of 774 matches
Mail list logo
