[PATCH] brcmfmac: Call brcmf_dmi_probe before brcmf_of_probe

2018-11-23 Thread Hans de Goede
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

Re: [PATCH 1/6] brcmfmac: Remove firmware-loading code duplication

2018-11-05 Thread Hans de Goede
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

Re: [PATCH 5/6] brcmfmac: Set board_type from DMI on x86 based machines

2018-11-05 Thread Hans de Goede
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

Re: [PATCH 6/6] brcmfmac: Cleanup brcmf_fw_request_done()

2018-11-05 Thread Hans de Goede
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

Re: [PATCH 3/6] brcmfmac: Add support for first trying to get a board specific nvram file

2018-11-05 Thread Hans de Goede
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

Re: [PATCH 5/6] brcmfmac: Set board_type from DMI on x86 based machines

2018-11-05 Thread Hans de Goede
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

[PATCH v4 2/2] brcmfmac: Fix ccode from EFI nvram when necessary

2018-10-11 Thread Hans de Goede
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

[PATCH v4 1/2] brcmfmac: Add support for getting nvram contents from EFI variables

2018-10-11 Thread Hans de Goede
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

[PATCH v2 4/6] brcmfmac: Set board_type used for nvram file selection to machine-compatible

2018-10-10 Thread Hans de Goede
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

[PATCH v2 1/6] brcmfmac: Remove firmware-loading code duplication

2018-10-10 Thread Hans de Goede
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

[PATCH v2 3/6] brcmfmac: Add support for first trying to get a board specific nvram file

2018-10-10 Thread Hans de Goede
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

[PATCH v2 2/6] brcmfmac: Remove recursion from firmware load error handling

2018-10-10 Thread Hans de Goede
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

[PATCH v2 6/6] brcmfmac: Cleanup brcmf_fw_request_done()

2018-10-10 Thread Hans de Goede
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

[PATCH v2 5/6] brcmfmac: Set board_type from DMI on x86 based machines

2018-10-10 Thread Hans de Goede
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

[PATCH] brcmfmac: Fix ccode from EFI nvram when necessary

2018-10-10 Thread Hans de Goede
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

Re: [PATCH 5/6] brcmfmac: Set board_type from DMI on x86 based machines

2018-10-10 Thread Hans de Goede
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

Re: [PATCH 5/6] brcmfmac: Set board_type from DMI on x86 based machines

2018-10-10 Thread Hans de Goede
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

Re: [PATCH 5/6] brcmfmac: Set board_type from DMI on x86 based machines

2018-10-10 Thread Hans de Goede
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

[PATCH v3] brcmfmac: Add support for getting nvram contents from EFI variables

2018-10-10 Thread Hans de Goede
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

[PATCH 1/6] brcmfmac: Remove firmware-loading code duplication

2018-10-09 Thread Hans de Goede
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

[PATCH 2/6] brcmfmac: Remove recursion from firmware load error handling

2018-10-09 Thread Hans de Goede
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

[PATCH 3/6] brcmfmac: Add support for first trying to get a board specific nvram file

2018-10-09 Thread Hans de Goede
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

[PATCH 6/6] brcmfmac: Cleanup brcmf_fw_request_done()

2018-10-09 Thread Hans de Goede
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

[PATCH 4/6] brcmfmac: Set board_type used for nvram file selection to machine-compatible

2018-10-09 Thread Hans de Goede
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

[PATCH 5/6] brcmfmac: Set board_type from DMI on x86 based machines

2018-10-09 Thread Hans de Goede
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

[PATCH 4.17 REGRESSION fix 0/1] Revert "staging:r8188eu: Use lib80211 to support TKIP"

2018-07-14 Thread Hans de Goede
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

[PATCH 4.17 REGRESSION fix] Revert "staging:r8188eu: Use lib80211 to support TKIP"

2018-07-14 Thread Hans de Goede
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/

Re: [PATCH V3 0/5] Update brcm firmware files

2018-05-30 Thread Hans de Goede
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

Re: [PATCH V3 0/5] Update brcm firmware files

2018-05-27 Thread Hans de Goede
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

Re: [PATCH V3 0/5] Update brcm firmware files

2018-05-18 Thread Hans de Goede
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

Re: [PATCH V3 0/5] Update brcm firmware files

2018-05-18 Thread Hans de Goede
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

Re: [PATCH 1/2] NFC: pn533: Use kmalloc-ed memory for USB transfer buffers

2018-03-29 Thread Hans de Goede
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

[PATCH 1/2] NFC: pn533: Use kmalloc-ed memory for USB transfer buffers

2018-03-19 Thread Hans de Goede
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

[PATCH 2/2] NFC: pn533: Fix wrong GFP flag usage

2018-03-19 Thread Hans de Goede
=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

[PATCH v2] brcmfmac: Add support for getting nvram contents from EFI variables

2018-03-18 Thread Hans de Goede
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>

Re: [PATCH] brcmfmac: Add support for getting nvram contents from EFI variables

2018-03-18 Thread Hans de Goede
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

Re: [PATCH] brcmfmac: Add support for getting nvram contents from EFI variables

2018-03-14 Thread Hans de Goede
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

Re: [PATCH] brcmfmac: Add support for getting nvram contents from EFI variables

2018-03-12 Thread Hans de Goede
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

[PATCH] brcmfmac: Add support for getting nvram contents from EFI variables

2018-03-11 Thread Hans de Goede
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/

Re: [PATCH resend] brcmfmac: p2p and normal ap access are not always possible at the same time

2018-03-01 Thread Hans de Goede
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

Re: [PATCH resend] brcmfmac: p2p and normal ap access are not always possible at the same time

2018-03-01 Thread Hans de Goede
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

Re: [PATCH resend] brcmfmac: p2p and normal ap access are not always possible at the same time

2018-02-28 Thread Hans de Goede
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

Re: [PATCH resend] brcmfmac: p2p and normal ap access are not always possible at the same time

2018-02-26 Thread Hans de Goede
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

Re: [PATCH resend] brcmfmac: p2p and normal ap access are not always possible at the same time

2018-02-26 Thread Hans de Goede
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

Re: [PATCH resend] brcmfmac: p2p and normal ap access are not always possible at the same time

2018-02-25 Thread 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

Re: [RFC PATCH 0/2] net: rfkill: gpio: Fix and support SerDev

2018-02-20 Thread Hans de Goede
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

Re: [RFC PATCH 0/2] net: rfkill: gpio: Fix and support SerDev

2018-02-20 Thread Hans de Goede
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:

[PATCH 3/3] staging: r8188eu: Revert 4 commits breaking ARP

2017-11-02 Thread Hans de Goede
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

[PATCH 1/3] staging: rtl8188eu: Revert part of "staging: rtl8188eu: fix comments with lines over 80 characters"

2017-11-02 Thread Hans de Goede
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

[PATCH 2/3] staging: rtl8188eu: Fix bug introduced by convert timers to use timer_setup()

2017-11-02 Thread Hans de Goede
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

Re: [PATCH resend] brcmfmac: p2p and normal ap access are not always possible at the same time

2017-10-19 Thread Hans de Goede
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

[PATCH v2] brcmfmac: Log chip id and revision

2017-08-30 Thread Hans de Goede
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

Re: brcmfmac4356-pci device not seeing 2.4Ghz channel 12 and 13

2017-08-30 Thread Hans de Goede
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

Re: [PATCH resend] brcmfmac: p2p and normal ap access are not always possible at the same time

2017-08-30 Thread Hans de Goede
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

Re: [PATCH resend] brcmfmac: p2p and normal ap access are not always possible at the same time

2017-08-30 Thread Hans de Goede
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

Re: [PATCH 2/2] brcmfmac: Use separate firmware for revision 0 of the brcm43430 chip

2017-08-25 Thread Hans de Goede
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

Re: [PATCH 2/2] brcmfmac: Use separate firmware for revision 0 of the brcm43430 chip

2017-08-25 Thread Hans de Goede
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

Re: [4.13 REGRESSION] Re: brcm43430 sdio wifi regression with 4.13-rc1

2017-08-14 Thread Hans de Goede
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

[4.13 REGRESSION] Re: brcm43430 sdio wifi regression with 4.13-rc1

2017-08-14 Thread Hans de Goede
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

brcmfmac4356-pcie 4.13 regression (frequent kernel panics) not fixed by recent 4.13 regression fix

2017-07-26 Thread Hans de Goede
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

brcm43430 sdio wifi regression with 4.13-rc1

2017-07-22 Thread Hans de Goede
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

Re: brcmfmac4356-pci device not seeing 2.4Ghz channel 12 and 13

2017-07-06 Thread Hans de Goede
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

brcmfmac4356-pci device not seeing 2.4Ghz channel 12 and 13

2017-06-28 Thread Hans de Goede
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

[PATCH 1/2] brcmfmac: Log chip id and revision

2017-06-16 Thread Hans de Goede
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

[PATCH 2/2] brcmfmac: Use separate firmware for revision 0 of the brcm43430 chip

2017-06-16 Thread Hans de Goede
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

Re: [PATCH 4.12 REGRESSION fix] brcmfmac: Use ALIGNMENT rather then hardcoded "4" for bus:txglomalign

2017-05-26 Thread Hans de Goede
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.

[PATCH 4.12 REGRESSION fix] brcmfmac: Use ALIGNMENT rather then hardcoded "4" for bus:txglomalign

2017-05-26 Thread Hans de Goede
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

[PATCH resend] brcmfmac: p2p and normal ap access are not always possible at the same time

2017-05-26 Thread Hans de Goede
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

[PATCH resend 0/1] brcmfmac: p2p and normal ap access are not always possible at the same time

2017-05-26 Thread Hans de Goede
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

Re: New brcmfmac errors in 4.12: brcmf_sdio_rxglom: sublen ... not multiple of 8

2017-05-14 Thread Hans de Goede
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

Re: New brcmfmac errors in 4.12: brcmf_sdio_rxglom: sublen ... not multiple of 8

2017-05-13 Thread Hans de Goede
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

Re: New brcmfmac errors in 4.12: brcmf_sdio_rxglom: sublen ... not multiple of 8

2017-05-13 Thread 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] brcmfmac: brcmf_sdio_rxglom: sublen 524 not multiple of 8 [ 32.528296] brcmfmac

Re: New brcmfmac errors in 4.12: brcmf_sdio_rxglom: sublen ... not multiple of 8

2017-05-13 Thread 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] brcmfmac: brcmf_sdio_rxglom: sublen 524 not multiple of 8 [ 32.528296] brcmfmac

New brcmfmac errors in 4.12: brcmf_sdio_rxglom: sublen ... not multiple of 8

2017-05-13 Thread Hans de Goede
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 [

Re: [PATCH v2] staging: rtl8723bs: remove re-positioned call to kfree in os_dep/ioctl_cfg80211.c

2017-04-30 Thread Hans de Goede
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

Re: brcmfmac: don't warn user if requested nvram fails

2017-04-30 Thread Hans de Goede
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

[PATCH] staging: rtl8188eu: force driver to be built as a module

2017-04-11 Thread Hans de Goede
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

[PATCH] staging: rtl8723bs: Add missing include to fix compile error

2017-04-10 Thread Hans de Goede
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

Re: [PATCH] net: rfkill: gpio: Add OBDA8723 ACPI HID

2017-04-09 Thread 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> --

[PATCH] net: rfkill: gpio: Add OBDA8723 ACPI HID

2017-04-08 Thread Hans de Goede
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

Re: brcmfmac: don't warn user if requested nvram fails

2017-04-08 Thread Hans de Goede
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

Re: brcmfmac: don't warn user if requested nvram fails

2017-04-06 Thread Hans de Goede
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

Re: [PATCH] staging: Add rtl8723bs sdio wifi driver

2017-04-06 Thread Hans de Goede
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

Re: [PATCH] staging: Add rtl8723bs sdio wifi driver

2017-04-06 Thread Hans de Goede
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

Re: [PATCH] staging: Add rtl8723bs sdio wifi driver

2017-04-05 Thread Hans de Goede
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

Re: [PATCH] staging: Add rtl8723bs sdio wifi driver

2017-04-04 Thread Hans de Goede
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

Re: [PATCH] staging: Add rtl8723bs sdio wifi driver

2017-04-04 Thread Hans de Goede
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

Re: [PATCH] staging: Add rtl8723bs sdio wifi driver

2017-03-29 Thread Hans de Goede
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,

Re: [PATCH v3] brcmfmac: Do not print the firmware version as an error

2017-03-09 Thread Hans de Goede
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

Re: [PATCH v3] brcmfmac: Do not print the firmware version as an error

2017-03-09 Thread Hans de Goede
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

Re: [PATCH v3] brcmfmac: Do not print the firmware version as an error

2017-03-08 Thread Hans de Goede
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

[PATCH v3 1/3] brcmfmac: Do not print the firmware version as an error

2017-03-08 Thread Hans de Goede
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

[PATCH v3 2/3] brcmfmac: Do not complain about country code "00"

2017-03-08 Thread Hans de Goede
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

[PATCH v3 3/3] brcmfmac: Handle status == BRCMF_E_STATUS_ABORT in cfg80211_escan_handler

2017-03-08 Thread Hans de Goede
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

Re: [PATCH v2 2/4] brcmfmac: p2p and normal ap access are not always possible at the same time

2017-03-08 Thread Hans de Goede
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

Re: [PATCH v2 1/4] brcmfmac: Do not print the firmware version as an error

2017-03-08 Thread Hans de Goede
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

Re: [PATCH v2 2/4] brcmfmac: p2p and normal ap access are not always possible at the same time

2017-03-08 Thread Hans de Goede
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

[PATCH v3] brcmfmac: Do not print the firmware version as an error

2017-03-08 Thread Hans de Goede
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

Re: [PATCH v2 1/4] brcmfmac: Do not print the firmware version as an error

2017-03-08 Thread Hans de Goede
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

[PATCH v2 4/4] brcmfmac: Handle status == BRCMF_E_STATUS_ABORT in cfg80211_escan_handler

2017-02-27 Thread Hans de Goede
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   2   >