Hi,
On 14-05-17 10:21, Arend Van Spriel wrote:
On 13-5-2017 16:55, Hans de Goede wrote:
Hi,
On 13-05-17 15:39, Heiner Kallweit wrote:
Am 13.05.2017 um 14:35 schrieb Hans de Goede:
Hi,
On 13-05-17 14:19, Hans de Goede wrote:
Hi,
I've just rebased my personal kernel tree to what
Hi,
This is a resend of a patch which I send a while ago, back then there
was some discussion to come up with a better fix, but that has not lead
to anything and the driver is still periodically spamming the logs.
As such I would like to move forward with this patch for now, which
makes no functi
The firmware responding with -EBUSY when trying to add an extra virtual-if
is a normal thing, do not print an error for this.
Signed-off-by: Hans de Goede
---
.../net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c| 14 ++
drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c
Fixes: 6e84ab604bde ("properly align buffers ... with 64 bit DMA")
Suggested-by: Arend van Spriel
Signed-off-by: Hans de Goede
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/broadcom
Hi,
On 26-05-17 13:15, Kalle Valo wrote:
Hans de Goede writes:
From: Arend Van Spriel
Ah I see I set the Author to Arend when I added this to my
tree a while back, that is fine as he did all the work
for this one. I was under the impression Arend would submit
this himself, but since I did
Hi Arend,
Sorry I was a bit slow to respond to this.
On 04-08-17 14:35, Arend van Spriel wrote:
On 5/26/2017 12:57 PM, Hans de Goede wrote:
The firmware responding with -EBUSY when trying to add an extra virtual-if
is a normal thing, do not print an error for this.
Hi Hans,
First of all
Hi,
On 30-08-17 12:24, Hans de Goede wrote:
Hi Arend,
Sorry I was a bit slow to respond to this.
On 04-08-17 14:35, Arend van Spriel wrote:
On 5/26/2017 12:57 PM, Hans de Goede wrote:
The firmware responding with -EBUSY when trying to add an extra virtual-if
is a normal thing, do not print
Hi,
On 06-07-17 21:43, Arend van Spriel wrote:
On 06-07-17 21:23, Hans de Goede wrote:
Hi,
On 28-06-17 14:35, Arend Van Spriel wrote:
Op 28 jun. 2017 12:07 schreef "Hans de Goede" mailto:hdego...@redhat.com>>:
>
> Hi,
>
> I noticed today that my GPD Wi
For debugging some problems, it is useful to know the chip revision
add a brcmf_info message logging this.
Signed-off-by: Hans de Goede
---
Changes in v2:
-Put the brcmf_info in brcmf_fw_map_chip_to_name() so that it works for
e.g. pcie devices too
---
drivers/net/wireless/broadcom/brcm80211
Hi,
On 30-08-17 12:30, Hans de Goede wrote:
Hi,
On 30-08-17 12:24, Hans de Goede wrote:
Hi Arend,
Sorry I was a bit slow to respond to this.
On 04-08-17 14:35, Arend van Spriel wrote:
On 5/26/2017 12:57 PM, Hans de Goede wrote:
The firmware responding with -EBUSY when trying to add an
int and can have values such
as -2 and -3.
Note for the next time, please only make one type of changes in a single
clean-up commit.
Fixes: 74e1e498e84e ("staging: rtl8188eu: fix comments with lines over 80 ...")
Cc: Juliana Rodrigues
Signed-off-by: Hans de Goede
---
drivers/staging/r
c: Kees Cook
Signed-off-by: Hans de Goede
---
drivers/staging/rtl8188eu/core/rtw_mlme_ext.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
b/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
index d717046a6c2f..d73e9bdc80cc 100644
-
decrypt() and also place it after rtl88eu_mon_recv_hook()")
This is the commit actually breaking ARP.
Note this commit is a straight-forward squash of the revert of these
4 commits, without any changes.
Cc: sta...@vger.kernel.org
Cc: Ivan Safonov
Signed-off-by: Hans de Goede
---
drivers/st
Using pr_err for things which are not errors is a bad idea. E.g. it
will cause the plymouth bootsplash screen to drop back to the text
console so that the user can see the error, which is not what we
normally want to happen.
Instead add a new brcmf_info macro and use that.
Signed-off-by: Hans de
The country code gets set to "00" by default at boot, ignore this
rather then logging an error about it.
Signed-off-by: Hans de Goede
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/net/wireless/broadcom
The firmware responding with -EBUSY when trying to add an extra virtual-if
is a normal thing, do not print an error for this.
Signed-off-by: Hans de Goede
---
.../net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c| 14 ++
drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c
Hi All,
Here is a small series to stop brcmfmac from spamming dmesg with errors
which are not really errors at all.
Note the 4th patch actually contains a small behavior change rather then
just changing logging, so it needs a bit of extra review attention.
Regards,
Hans
ORT and in this case simply
cleanly exit the cfg80211_escan_handler. This also avoids a
BRCMF_E_STATUS_ABORT event arriving after a new scan has been started
causing the new scan to complete prematurely without any data.
Signed-off-by: Hans de Goede
---
drivers/net/wireless/broadcom/brcm80211/brcmf
The country code gets set to "00" by default at boot, ignore this
rather then logging an error about it.
Signed-off-by: Hans de Goede
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/net/wireless/broadcom
The firmware responding with -EBUSY when trying to add an extra virtual-if
is a normal thing, do not print an error for this.
Signed-off-by: Hans de Goede
---
.../net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c| 14 ++
drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c
Using pr_err for things which are not errors is a bad idea. E.g. it
will cause the plymouth bootsplash screen to drop back to the text
console so that the user can see the error, which is not what we
normally want to happen.
Instead add a new brcmf_info macro and use that.
Signed-off-by: Hans de
ORT and in this case simply
cleanly exit the cfg80211_escan_handler. This also avoids a
BRCMF_E_STATUS_ABORT event arriving after a new scan has been started
causing the new scan to complete prematurely without any data.
Signed-off-by: Hans de Goede
---
drivers/net/wireless/broadcom/brcm80211/brcmf
Hi,
On 07-03-17 10:59, Arend Van Spriel wrote:
On 27-2-2017 22:45, Hans de Goede wrote:
Using pr_err for things which are not errors is a bad idea. E.g. it
will cause the plymouth bootsplash screen to drop back to the text
console so that the user can see the error, which is not what we
Using pr_err for things which are not errors is a bad idea. E.g. it
will cause the plymouth bootsplash screen to drop back to the text
console so that the user can see the error, which is not what we
normally want to happen.
Instead add a new brcmf_info macro and use that.
Signed-off-by: Hans de
Hi,
On 07-03-17 11:03, Arend Van Spriel wrote:
On 27-2-2017 22:45, Hans de Goede wrote:
The firmware responding with -EBUSY when trying to add an extra virtual-if
is a normal thing, do not print an error for this.
This may be something we need to look into. It seems to me the interface
HI,
On 08-03-17 10:57, Kalle Valo wrote:
Arend Van Spriel writes:
On 8-3-2017 9:23, Hans de Goede wrote:
Hi,
On 07-03-17 10:59, Arend Van Spriel wrote:
On 27-2-2017 22:45, Hans de Goede wrote:
Using pr_err for things which are not errors is a bad idea. E.g. it
will cause the plymouth
Hi,
On 08-03-17 11:15, Arend Van Spriel wrote:
On 8-3-2017 10:26, Arend Van Spriel wrote:
On 8-3-2017 9:24, Hans de Goede wrote:
Hi,
On 07-03-17 11:03, Arend Van Spriel wrote:
On 27-2-2017 22:45, Hans de Goede wrote:
The firmware responding with -EBUSY when trying to add an extra
virtual
The country code gets set to "00" by default at boot, ignore this
rather then logging an error about it.
Signed-off-by: Hans de Goede
Acked-by: Arend van Spriel
---
Changes in v3:
-Add Arend's Acked-by
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 4
1
ORT and in this case simply
cleanly exit the cfg80211_escan_handler. This also avoids a
BRCMF_E_STATUS_ABORT event arriving after a new scan has been started
causing the new scan to complete prematurely without any data.
Signed-off-by: Hans de Goede
Acked-by: Arend van Spriel
---
Changes in v3:
-
Using pr_err for things which are not errors is a bad idea. E.g. it
will cause the plymouth bootsplash screen to drop back to the text
console so that the user can see the error, which is not what we
normally want to happen.
Instead add a new brcmf_info macro and use that.
Signed-off-by: Hans de
Hi,
On 08-03-17 17:34, Joe Perches wrote:
On Wed, 2017-03-08 at 09:23 +0100, Hans de Goede wrote:
Using pr_err for things which are not errors is a bad idea. E.g. it
will cause the plymouth bootsplash screen to drop back to the text
console so that the user can see the error, which is not what
Hi all,
On 08-03-17 21:44, Arend Van Spriel wrote:
On 8-3-2017 18:53, Joe Perches wrote:
On Wed, 2017-03-08 at 17:57 +0100, Hans de Goede wrote:
Hi,
And hello back to you.
Also hello.
On 08-03-17 17:34, Joe Perches wrote:
On Wed, 2017-03-08 at 09:23 +0100, Hans de Goede wrote:
Using
Hi,
On 09-03-17 09:17, Arend Van Spriel wrote:
On 9-3-2017 9:09, Hans de Goede wrote:
Hi all,
On 08-03-17 21:44, Arend Van Spriel wrote:
On 8-3-2017 18:53, Joe Perches wrote:
On Wed, 2017-03-08 at 17:57 +0100, Hans de Goede wrote:
Hi,
And hello back to you.
Also hello.
On 08-03-17
For debugging some problems, it is useful to know the chip revision
add a brcmf_info message logging this.
Signed-off-by: Hans de Goede
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/wireless/broadcom/brcm80211
chips is not changed, ideally those
would load brcmfmac43430a1-sdio.bin, but that will break existing setups.
Signed-off-by: Hans de Goede
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless
Hi,
I noticed today that my GPD Win (x86 clamshell mini laptop)
which uses a brcmfmac4356-pci wifi does not see an APs which
is using channel 13.
I've tried updating brcmfmac4356-pci.txt changing "ccode=US"
to "ccode=EU" and then rebooted, but that does not help.
I believe that the Linux wifi s
Hi,
On 28-06-17 14:35, Arend Van Spriel wrote:
Op 28 jun. 2017 12:07 schreef "Hans de Goede" mailto:hdego...@redhat.com>>:
>
> Hi,
>
> I noticed today that my GPD Win (x86 clamshell mini laptop)
> which uses a brcmfmac4356-pci wifi does not see an A
Hi,
When upgrading my devel environment to 4.13-rc1+ I noticed that
the brcm43430 sdio wifi on a Chuwi Hi8 plus stopped working:
jul 22 14:13:23 localhost.localdomain kernel: brcmfmac: brcmf_sdio_probe:
Loading firmware brcm/brcmfmac43430-sdio.bin for chip a9a6 rev 0001
jul 22 14:13:23
Hi,
On 22-07-17 21:53, Arend van Spriel wrote:
On 22-07-17 21:19, Ian Molton wrote:
On 22/07/17 20:18, Ian Molton wrote:
On 22/07/17 19:43, Hans de Goede wrote:
Hi,
When upgrading my devel environment to 4.13-rc1+ I noticed that
the brcm43430 sdio wifi on a Chuwi Hi8 plus stopped working
Hi,
I've been seeing frequent kernel panics on wifi activity
(scp-ing a lot of files) with 4.13 on 2 different systems
which both use a brcmfmac4356-pcie wifi chip.
This is with this fix:
https://www.spinics.net/lists/linux-wireless/msg164178.html
already applied.
Here is a picture of the panic
Hi,
On 26-07-17 23:08, Arend van Spriel wrote:
+ ref
On 26-07-17 23:08, Arend van Spriel wrote:
On 26-07-17 23:03, Hans de Goede wrote:
Hi,
I've been seeing frequent kernel panics on wifi activity
(scp-ing a lot of files) with 4.13 on 2 different systems
which both use a brcmfmac4356
on to one line.
v4: Use max_t rather than max.
I can confirm that this fixes a brcmfmac kernel panic for me:
Tested-by: Hans de Goede
Regards,
Hans
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
index 21
Hi,
On 23-07-17 09:08, Hans de Goede wrote:
Hi,
On 22-07-17 21:53, Arend van Spriel wrote:
On 22-07-17 21:19, Ian Molton wrote:
On 22/07/17 20:18, Ian Molton wrote:
On 22/07/17 19:43, Hans de Goede wrote:
Hi,
When upgrading my devel environment to 4.13-rc1+ I noticed that
the brcm43430
Hi,
On 14-08-17 17:46, Kalle Valo wrote:
Hans de Goede writes:
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
index d21258d..def120c 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
Hi,
On 25-08-17 15:55, Jörg Krause wrote:
Hi,
On Fri, 2017-06-16 at 15:14 +0200, Hans de Goede wrote:
The brcm43430 chip needs different firmware files for chip revision 0
and 1. The file currently in linux-firmware is for revision 1 only.
This commit makes brcmfmac request brcmfmac43430a0
Hi,
On 25-08-17 16:49, Jörg Krause wrote:
Thanks for the files!
I've tested with brcmfmac43430a0-sdio.bin.7.10.1.244.ucode940.1020 and
brcmfmac is happy:
brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Jul 1 2016
18:02:40 version 7.10.1 (A0 Station/P2P feature) FWID 01-bae8afee
W
101 - 146 of 146 matches
Mail list logo
