are
set.
Fixes: bd1e82bb420a ("brcmfmac: Set board_type from DMI on x86 based ...")
Cc: Peter Robinson
Tested-and-reported-by: Peter Robinson
Signed-off-by: Hans de Goede
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletio
Hi,
On 05-11-18 16:05, Kalle Valo wrote:
Arend van Spriel writes:
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
Hi,
On 05-11-18 12:41, Arend van Spriel wrote:
On 10/9/2018 2:47 PM, Hans de Goede wrote:
For x86 based machines, set the board_type used for nvram file selection
based on the DMI sys-vendor and product-name strings.
Since on some models these strings are too generic, this commit also adds
Hi,
On 05-11-18 12:42, Arend van Spriel wrote:
On 10/9/2018 2:47 PM, Hans de Goede wrote:
The "cur" variable is now only used for a debug print and we already
print the same info from brcmf_fw_complete_request(), so the debug print
does not provide any extra info and we can remo
Hi,
Thank you for the reviews.
On 05-11-18 12:41, Arend van Spriel wrote:
On 10/9/2018 2:47 PM, Hans de Goede wrote:
The nvram files which some brcmfmac chips need are board-specific. To be
able to distribute these as part of linux-firmware, so that devices with
such a wifi chip will work
Hi,
On 10-10-18 10:15, Arend van Spriel wrote:
On 10/10/2018 9:59 AM, Hans de Goede wrote:
Any chance you could do a patch-review of this series?
Yup and test for regressions with some of the chipsets I have here.
Have you gotten around to review and testing this series yet?
it would
Specifically using ccode=XV + regrev=1 on brcmfmac43241b4 leads to:
12-14 no-ir, U-NII-1 no-ir, U-NII-2 no-ir/radar, U-NII-3 no-ir
But only on the brcmfmac43241b4 and not on e.g. the brcmfmac43340
Tested-by: Hans de Goede
Signed-off-by: Hans de Goede
---
Changes in v4:
-Rebase for changes to
on these devices instead of
requiring manual setup.
This has been tested on the following models: Acer Iconia Tab8 w1-810,
Acer One 10, Asus T100CHI, Asus T100HA, Asus T100TA, Asus T200TA and a
Lenovo Mixx 2 8.
Tested-by: Hans de Goede
Signed-off-by: Hans de Goede
---
Changes in v4:
-Drop unused path argument
with
a board-specific name so that we can ship files for each supported board
in linux-firmware.
Signed-off-by: Hans de Goede
---
.../net/wireless/broadcom/brcm80211/brcmfmac/common.h | 1 +
drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c | 11 ++-
.../net/wireless/broadcom/brcm80211
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.
Signed-off-by: Hans de Goede
---
.../broadcom/brcm80211/brcmfmac
of the brcmfmac/firmware.c code to
pass in a board_type parameter through the request structure.
If that parameter is set then the code will first try to load
chipmodel.board_type.txt before falling back to the old chipmodel.txt name.
Signed-off-by: Hans de Goede
---
.../broadcom/brcm80211/brcmfmac
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
Signed-off-by: Hans de Goede
---
.../broadcom/brcm80211/brcmfmac/firmware.c| 65
The "cur" variable is now only used for a debug print and we already
print the same info from brcmf_fw_complete_request(), so the debug print
does not provide any extra info and we can remove it.
Signed-off-by: Hans de Goede
---
.../net/wireless/broadcom/brcm80211/brcmfmac/firmwa
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.
Signed-off-by: Hans de Goede
---
Changes in v2:
-Use full ISC text for now instead of SPDX tag, because the ISC is not
yet listed under LICENSES
Specifically using ccode=XV + regrev=1 on brcmfmac43241b4 leads to:
12-14 no-ir, U-NII-1 no-ir, U-NII-2 no-ir/radar, U-NII-3 no-ir
But only on the brcmfmac43241b4 and not on e.g. the brcmfmac43340
Tested-by: Hans de Goede
Signed-off-by: Hans de Goede
---
.../broadcom/brcm80211/brcmfmac/firmwa
Hi,
On 10-10-18 09:57, Kalle Valo wrote:
Arend van Spriel writes:
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
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?
This is not entirely true as far as I know. I assume you
Hi,
On 10-10-18 09:09, Kalle Valo wrote:
Hans de Goede writes:
For x86 based machines, set the board_type used for nvram file selection
based on the DMI sys-vendor and product-name strings.
Since on some models these strings are too generic, this commit also adds
a quirk table overriding
on these devices instead of
requiring manual setup.
This has been tested on the following models: Acer Iconia Tab8 w1-810,
Acer One 10, Asus T100CHI, Asus T100HA, Asus T100TA, Asus T200TA and a
Lenovo Mixx 2 8.
Tested-by: Hans de Goede
Signed-off-by: Hans de Goede
---
Changes in v3:
-Drop ccode fixup code
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.
Signed-off-by: Hans de Goede
---
.../broadcom/brcm80211/brcmfmac
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
Signed-off-by: Hans de Goede
---
.../broadcom/brcm80211/brcmfmac/firmware.c| 65
of the brcmfmac/firmware.c code to
pass in a board_type parameter through the request structure.
If that parameter is set then the code will first try to load
chipmodel.board_type.txt before falling back to the old chipmodel.txt name.
Signed-off-by: Hans de Goede
---
.../broadcom/brcm80211/brcmfmac
The "cur" variable is now only used for a debug print and we already
print the same info from brcmf_fw_complete_request(), so the debug print
does not provide any extra info and we can remove it.
Signed-off-by: Hans de Goede
---
.../net/wireless/broadcom/brcm80211/brcmfmac/firmwa
with
a board-specific name so that we can ship files for each supported board
in linux-firmware.
Signed-off-by: Hans de Goede
---
.../net/wireless/broadcom/brcm80211/brcmfmac/common.h | 1 +
drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c | 11 ++-
.../net/wireless/broadcom/brcm80211
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.
Signed-off-by: Hans de Goede
---
.../broadcom/brcm80211/brcmfmac/Makefile | 2 +
.../broadcom/brcm80211/brcmfmac/common.c | 3 +-
.../broadcom
Hi Greg,
While running some ASOC tests on a VIOS LTH17 laptop I noticed that
wifi was broken and often the machine would hard freeze shortly after
bringing up the wifi connection.
One of the oopses pointed to the commit which this patch reverts and
that fixes both the wifi being broken and the
o all lead to scenario 2. Until
I reverted the commit again.
Revert the commit fixes both issues making the laptop usable again.
Cc: sta...@vger.kernel.org
Cc: Ivan Safonov
Signed-off-by: Hans de Goede
---
drivers/staging/rtl8188eu/Kconfig | 1 -
drivers/staging/rtl8188eu/core/
Hi,
On 30-05-18 09:28, Chi-Hsien Lin wrote:
On 05/27/2018 10:37, Hans de Goede wrote:
Hi,
On 18-05-18 09:04, Hans de Goede wrote:
Hi,
On 15-05-18 10:43, Arend van Spriel wrote:
On 5/14/2018 2:05 PM, Josh Boyer wrote:
n Mon, May 14, 2018 at 6:11 AM Arend van Spriel <
arend.van
Hi,
On 18-05-18 09:04, Hans de Goede wrote:
Hi,
On 15-05-18 10:43, Arend van Spriel wrote:
On 5/14/2018 2:05 PM, Josh Boyer wrote:
n Mon, May 14, 2018 at 6:11 AM Arend van Spriel <
arend.vanspr...@broadcom.com> wrote:
On 3/16/2018 3:08 PM, Chi-Hsien Lin wrote:
Update brcm firmware
Hi,
On 18-05-18 11:00, Arend van Spriel wrote:
On 5/18/2018 9:04 AM, Hans de Goede wrote:
Hi,
On 15-05-18 10:43, Arend van Spriel wrote:
On 5/14/2018 2:05 PM, Josh Boyer wrote:
n Mon, May 14, 2018 at 6:11 AM Arend van Spriel <
arend.vanspr...@broadcom.com> wrote:
On 3/16/2018 3:08 P
Hi,
On 15-05-18 10:43, Arend van Spriel wrote:
On 5/14/2018 2:05 PM, Josh Boyer wrote:
n Mon, May 14, 2018 at 6:11 AM Arend van Spriel <
arend.vanspr...@broadcom.com> wrote:
On 3/16/2018 3:08 PM, Chi-Hsien Lin wrote:
Update brcm firmware files and WHENCE accordingly.
Hi
Samuel,
Can I get an ack for these please?
Anything I need to do to get these picked up / merged?
Regards,
Hans
On 19-03-18 17:40, Hans de Goede wrote:
Commit 8b55d7581fc5 ("NFC: pn533: use constant off-stack buffer for sending
acks"), fixed the ack case of using on
hat.com/show_bug.cgi?id=1514134
Fixes: 8b55d7581fc5 ("NFC: pn533: use constant off-stack buffer ...")
Cc: Michał Mirosław <mirq-li...@rere.qmqm.pl>
Signed-off-by: Hans de Goede <hdego...@redhat.com>
---
drivers/nfc/pn533/usb.c | 22 +++---
1 file changed, 15
=1514134
Fixes: 9815c7cf22da ("NFC: pn533: Separate physical layer from ...")
Cc: Michael Thalmeier <michael.thalme...@hale.at>
Signed-off-by: Hans de Goede <hdego...@redhat.com>
---
drivers/nfc/pn533/usb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --g
is never correct) or ccode=XV we fix it
up to the right value (XV or X2) for the firmware, assuming the firmware
from linux-firmware is used.
This has been tested on the following models: Asus T100CHI, Asus T100HA,
Asus T100TA and Asus T200TA
Tested-by: Hans de Goede <hdego...@redhat.com>
Hi,
On 16-03-18 21:41, Arend van Spriel wrote:
On 3/14/2018 9:43 AM, Hans de Goede wrote:
Hi,
On 13-03-18 21:19, Arend van Spriel wrote:
On 3/12/2018 10:45 AM, Hans de Goede wrote:
Actually had a Sony device with nvram in EFI. Why not just drop this
optimization.
Ok, do you know
Hi,
On 13-03-18 21:19, Arend van Spriel wrote:
On 3/12/2018 10:45 AM, Hans de Goede wrote:
Actually had a Sony device with nvram in EFI. Why not just drop this
optimization.
Ok, do you know if that variable had the same name and guid though ?
Because
if it doesn't then this code
Hi,
On 12-03-18 09:55, Arend van Spriel wrote:
On 3/11/2018 10:47 PM, Hans de Goede wrote:
Various models Asus laptops with a SDIO attached brcmfmac wifi chip, store
the nvram contents in a special EFI variable. This commit adds support for
getting nvram directly from this EFI variable
h is the correct way to specify the worldwide broadcast
regime.
This has been tested on the following models: Asus T100CHI, Asus T100HA,
Asus T100TA and Asus T200TA
Tested-by: Hans de Goede <hdego...@redhat.com>
Signed-off-by: Hans de Goede <hdego...@redhat.com>
---
.../broadcom/brcm80211/
Hi,
On 01-03-18 20:54, Arend van Spriel wrote:
On 3/1/2018 9:35 AM, Hans de Goede wrote:
HI,
On 28-02-18 20:43, Arend van Spriel wrote:
On 2/28/2018 3:52 PM, Hans de Goede wrote:
Hi,
On 27-02-18 00:04, Arend van Spriel wrote:
On 2/26/2018 12:22 PM, Hans de Goede wrote:
Hi,
On 26-02-18
HI,
On 28-02-18 20:43, Arend van Spriel wrote:
On 2/28/2018 3:52 PM, Hans de Goede wrote:
Hi,
On 27-02-18 00:04, Arend van Spriel wrote:
On 2/26/2018 12:22 PM, Hans de Goede wrote:
Hi,
On 26-02-18 12:01, Arend van Spriel wrote:
On 2/26/2018 11:29 AM, Hans de Goede wrote:
Hi,
On 26-02-18
Hi,
On 27-02-18 00:04, Arend van Spriel wrote:
On 2/26/2018 12:22 PM, Hans de Goede wrote:
Hi,
On 26-02-18 12:01, Arend van Spriel wrote:
On 2/26/2018 11:29 AM, Hans de Goede wrote:
Hi,
On 26-02-18 11:22, Arend van Spriel wrote:
On 2/25/2018 3:52 PM, Hans de Goede wrote:
Hi,
On 26-05-17
Hi,
On 26-02-18 12:01, Arend van Spriel wrote:
On 2/26/2018 11:29 AM, Hans de Goede wrote:
Hi,
On 26-02-18 11:22, Arend van Spriel wrote:
On 2/25/2018 3:52 PM, Hans de Goede wrote:
Hi,
On 26-05-17 12:57, Hans de Goede wrote:
The firmware responding with -EBUSY when trying to add an extra
Hi,
On 26-02-18 11:22, Arend van Spriel wrote:
On 2/25/2018 3:52 PM, Hans de Goede wrote:
Hi,
On 26-05-17 12:57, 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.
Signed-off-by: Hans de Goede
Hi,
On 26-05-17 12:57, 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.
Signed-off-by: Hans de Goede <hdego...@redhat.com>
I'm now seeing this on another device too, but this time the
Hi,
On 02/20/2018 03:36 PM, Carlo Caione wrote:
On Tue, Feb 20, 2018 at 2:01 PM, Hans de Goede <hdego...@redhat.com> wrote:
Hi Carlo,
Hi Hans,
Is this for devices with a RTL8723BS chip? If so then they
still will not work after this since there also no longer is
a /dev/ttyS4 c
Hi Carlo,
Is this for devices with a RTL8723BS chip? If so then they
still will not work after this since there also no longer is
a /dev/ttyS4 created for the UART for the bluetooth, instead
you probably want:
rypt() 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 <insafo...@gmail.com>
Signed-off-by: H
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 <juliana.o...@gmail.com>
Signed-off-by: Ha
Cc: Kees Cook <keesc...@chromium.org>
Signed-off-by: Hans de Goede <hdego...@redhat.com>
---
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/r
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
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 <hdego...@redhat.com>
---
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/wi
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" <hdego...@redhat.com
<mailto:hdego...@redhat.com>>:
>
> Hi,
>
> I
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 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 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
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 14-08-17 17:46, Kalle Valo wrote:
Hans de Goede <hdego...@redhat.com> 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/brc
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,
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
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 28-06-17 14:35, Arend Van Spriel wrote:
Op 28 jun. 2017 12:07 schreef "Hans de Goede" <hdego...@redhat.com
<mailto:hdego...@redhat.com>>:
>
> Hi,
>
> I noticed today that my GPD Win (x86 clamshell mini laptop)
> which uses a brcmfmac43
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
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 <hdego...@redhat.com>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/wi
chips is not changed, ideally those
would load brcmfmac43430a1-sdio.bin, but that will break existing setups.
Signed-off-by: Hans de Goede <hdego...@redhat.com>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff
Hi,
On 26-05-17 13:15, Kalle Valo wrote:
Hans de Goede <hdego...@redhat.com> writes:
From: Arend Van Spriel <arend.vanspr...@broadcom.com>
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.
rxglom: sublen 1492 not multiple of 8
Fixes: 6e84ab604bde ("properly align buffers ... with 64 bit DMA")
Suggested-by: Arend van Spriel <arend.vanspr...@broadcom.com>
Signed-off-by: Hans de Goede <hdego...@redhat.com>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio
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 <hdego...@redhat.com>
---
.../net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c| 14 ++
drivers/net/wireless/br
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
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,
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 will soon be 4.12-rc1
and I'm getting my dmesg log filled with the following errors:
[ 32.528271
Hi,
On 13-05-17 14:19, Hans de Goede wrote:
Hi,
I've just rebased my personal kernel tree to what will soon be 4.12-rc1
and I'm getting my dmesg log filled with the following errors:
[ 32.528271] brcmfmac: brcmf_sdio_rxglom: sublen 524 not multiple of 8
[ 32.528296] brcmfmac
Hi,
On 13-05-17 14:19, Hans de Goede wrote:
Hi,
I've just rebased my personal kernel tree to what will soon be 4.12-rc1
and I'm getting my dmesg log filled with the following errors:
[ 32.528271] brcmfmac: brcmf_sdio_rxglom: sublen 524 not multiple of 8
[ 32.528296] brcmfmac
Hi,
I've just rebased my personal kernel tree to what will soon be 4.12-rc1
and I'm getting my dmesg log filled with the following errors:
[ 32.528271] brcmfmac: brcmf_sdio_rxglom: sublen 524 not multiple of 8
[ 32.528296] brcmfmac: brcmf_sdio_rxglom: sublen 84 not multiple of 8
[
to me:
Reviewed-by: Hans de Goede <hdego...@redhat.com>
Regards,
Hans
---
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
index f17f4fb..2e
Hi,
On 27-04-17 02:36, Luis R. Rodriguez wrote:
On Tue, Apr 11, 2017 at 10:53:57AM +0200, Hans de Goede wrote:
Right, sorry. For the pcie device I'm looking at the
name is brcmfmac4356-pcie.txt and I would like to propose
to first check for "brcmfmac4356--.txt"
So who is going
The rtl8188eu driver defines a ton of global symbols which tend to
conflict with other realtek wifi drivers, force it to be built as
a module.
Signed-off-by: Hans de Goede <hdego...@redhat.com>
---
drivers/staging/rtl8188eu/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/d
As reported by Stephen Rothwell when merging staging-next,
drivers/staging/rtl8723bs/core/rtw_ieee80211.c does not compile due
to of_get_property not being declared.
Explicitly include to fix this compile error.
Cc: Stephen Rothwell <s...@canb.auug.org.au>
Signed-off-by: Hans de Goede
Hi,
On 09-04-17 10:01, Marcel Holtmann wrote:
Hi Hans,
The OBDA8723 ACPI HID is used on quite a few Bay Trail based tablets
for bluetooth rfkill functionality.
Tested-by: russianneuroman...@ya.ru <russianneuroman...@ya.ru>
Signed-off-by: Hans de Goede <hdego...@redhat.com>
--
The OBDA8723 ACPI HID is used on quite a few Bay Trail based tablets
for bluetooth rfkill functionality.
Tested-by: russianneuroman...@ya.ru <russianneuroman...@ya.ru>
Signed-off-by: Hans de Goede <hdego...@redhat.com>
---
net/rfkill/rfkill-gpio.c | 1 +
1 file changed, 1 insert
Hi,
On 07-04-17 23:43, Arend Van Spriel wrote:
On 6-4-2017 14:14, Hans de Goede wrote:
Hi,
I noticed your patch-series on the lwn.net kernel page,
and I took a peek :)
I don't think that this patch:
https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux-next.git/commit/?h=20170329
Hi,
I noticed your patch-series on the lwn.net kernel page,
and I took a peek :)
I don't think that this patch:
https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux-next.git/commit/?h=20170329-driver-data-v2-try3=3968dd3031d1ff7e7be4acfb810948c70c2d4490
Is a good idea, specifically
Hi,
On 06-04-17 11:04, Bastien Nocera wrote:
On Thu, 2017-04-06 at 08:55 +0200, Hans de Goede wrote:
Good thank you. So what is the plan with the github version ?
Note that my submission contains a few small fixes on top of
the github version, for which I intended to submit a pull-req
Hi,
On 05-04-17 18:32, Larry Finger wrote:
On 04/05/2017 04:36 AM, Hans de Goede wrote:
Hi,
On 05-04-17 01:41, Larry Finger wrote:
On 04/04/2017 04:53 PM, Hans de Goede wrote:
Hi,
On 04/04/2017 11:38 PM, Arend Van Spriel wrote:
On 4-4-2017 20:53, Hans de Goede wrote:
Hi,
On 04/04/2017
Hi,
On 05-04-17 01:41, Larry Finger wrote:
On 04/04/2017 04:53 PM, Hans de Goede wrote:
Hi,
On 04/04/2017 11:38 PM, Arend Van Spriel wrote:
On 4-4-2017 20:53, Hans de Goede wrote:
Hi,
On 04/04/2017 08:31 PM, Larry Finger wrote:
On 03/29/2017 12:47 PM, Hans de Goede wrote:
The rtl8723bs
Hi,
On 04/04/2017 11:38 PM, Arend Van Spriel wrote:
On 4-4-2017 20:53, Hans de Goede wrote:
Hi,
On 04/04/2017 08:31 PM, Larry Finger wrote:
On 03/29/2017 12:47 PM, Hans de Goede wrote:
The rtl8723bs is found on quite a few systems used by Linux users,
such as on Atom systems (Intel
Hi,
On 04/04/2017 08:31 PM, Larry Finger wrote:
On 03/29/2017 12:47 PM, Hans de Goede wrote:
The rtl8723bs is found on quite a few systems used by Linux users,
such as on Atom systems (Intel Computestick and various other
Atom based devices) and on many (budget) ARM boards such as
the CHIP
Hi All,
I forgot to add --compose so I could add the cover letter I had
already written, so here it goes:
Hi Greg, all,
I'm hereby submitting the rtl8723bs driver which
Bastien Nocera and Larry Finger have been maintaining at:
https://github.com/hadess/rtl8723bs
For inclusion into staging,
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
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 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
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 <hdego...@redhat.com>
Acked-by: Arend van Spriel <arend.vanspr...@broadcom.com>
---
Changes in v3:
-Add Arend's Acked-by
---
drivers
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 <hdego...@redhat.com>
Acked-by: Arend v
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
HI,
On 08-03-17 10:57, Kalle Valo wrote:
Arend Van Spriel <arend.vanspr...@broadcom.com> 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 ide
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
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 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
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 <hdego...@redhat.com>
---
drivers/net
1 - 100 of 122 matches
Mail list logo