Re: [PATCH 4/8] staging: wilc1000: avoid line over 80 chars in wilc_parse_network_info()

On 11/5/2018 9:27 PM, Joe Perches wrote: > On Mon, 2018-11-05 at 12:18 +, ajay.kat...@microchip.com wrote: >> Hi Joe, >> >> On 11/5/2018 4:27 PM, Joe Perches wrote: >>> On Thu, 2018-11-01 at 16:45 +, ajay.kat...@microchip.com wrote: From: Ajay Singh Use shorter name for

Re: [PATCH] staging: wilc1000: update wilc1000 driver maintainer ids

Hi Greg, On 11/5/2018 7:46 PM, Greg KH wrote: > On Tue, Oct 30, 2018 at 05:53:40AM +, ajay.kat...@microchip.com wrote: >> From: Ajay Singh >> >> We would like to update the maintainer email id's for wilc1000 driver. >> >> Signed-off-by: Ajay Singh >> Signed-off-by: Adham Abozaeid > It

[PATCH 03/11] brcmfmac: set SDIO F1 MesBusyCtrl for CYW4373

From: Madhan Mohan R Along with F2 watermark (existing) configuration, F1 MesBusyCtrl should be enabled & configured to avoid overflow errors. Signed-off-by: Madhan Mohan R Signed-off-by: Chi-Hsien Lin --- drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 3 +++

[PATCH 01/11] brcmfmac: add 4354 raw pcie device id

From: Winnie Chang Add the raw 4354 PCIe device ID. Signed-off-by: Winnie Chang Signed-off-by: Chi-Hsien Lin --- drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 1 + drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h | 1 + 2 files changed, 2 insertions(+) diff

[PATCH 00/11] chip related changes

This patch series includes various chip-related changes: * 43012 support * 4373 saverestore support * SDIO bus settings * 4354 raw chipid Chi-Hsien Lin (3): brcmfmac: add support for CYW43012 SDIO chipset brcmfmac: allow GCI core enumuration brcmfmac: 4373 save-restore support Double Lo

[PATCH 11/11] brcmfmac: disable command decode in sdio_aos for 4373

From: Madhan Mohan R By disabling command decode, sdiod_aos module supports the detection of sdio command line toggle only and generates a wakeup request to PMU and to sdiod core. It does not decode any sdio command and generates no response to any command. Signed-off-by: Madhan Mohan R

[PATCH 06/11] brcmfmac: saverestore support changes for 43012

From: Praveen Babu C Add saverestore register settings for 43012. Signed-off-by: Praveen Babu C Signed-off-by: Chi-Hsien Lin --- .../wireless/broadcom/brcm80211/brcmfmac/chip.c| 5 + .../wireless/broadcom/brcm80211/brcmfmac/sdio.c| 22 +- 2 files changed, 22

[PATCH 05/11] brcmfmac: allow GCI core enumuration

GCI core is needed for ULP operation. Allow GCI core enumuration with below changes: - Allow GCI to be added to core list even when it doesn't have a wrapper. - Allow 8K address space size. - Don't overwrite the address value when an additional size descriptor is in place. Signed-off-by:

[PATCH 09/11] brcmfmac: disable command decode in sdio_aos for 43012/4339/4345

From: Wright Feng Transaction between AOS and SDIOD is not protected, and if cmd 52 received in AOS and in the middle of response state changed from AOS to SDIOD, response is corrupted and it causes to SDIO Host controller to hang. Signed-off-by: Wright Feng Signed-off-by: Chi-Hsien Lin ---

[PATCH 04/11] brcmfmac: add support for CYW43012 SDIO chipset

CYW43012 is a 1x1 802.11a/b/g/n Dual-Band HT20, 256-QAM/Turbo QAM. It is an Ultra Low Power WLAN+BT combo chip. Signed-off-by: Chi-Hsien Lin --- .../wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 1 + .../wireless/broadcom/brcm80211/brcmfmac/chip.c| 9 -

[PATCH 10/11] brcmfmac: disable command decode in sdio_aos for 4354

From: Double Lo Transaction between AOS and SDIOD is not protected, and if cmd 52 received in AOS and in the middle of response state changed from AOS to SDIOD, response is corrupted and it causes to SDIO Host controller to hang. Signed-off-by: Double Lo Signed-off-by: Chi-Hsien Lin ---

[PATCH 02/11] brcmfmac: set F2 watermark to 256 for 4373

From: Wright Feng We got SDIO_CRC_ERROR with 4373 on SDR104 when doing bi-directional throughput test. Enable watermark to 256 to guarantee the operation stability. Signed-off-by: Wright Feng Signed-off-by: Chi-Hsien Lin --- .../wireless/broadcom/brcm80211/brcmfmac/sdio.c| 25

[PATCH 08/11] brcmfmac: 4373 save-restore support

Use sr_eng_en bit to check 4373 sr support. Signed-off-by: Chi-Hsien Lin --- drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c

[PATCH 07/11] brcmfmac: update 43012 F2 watermark setting to fix DMA Error during UDP RX Traffic

From: Naveen Gupta The number of words that the read FIFO has to contain except the end of frame before sends data back to the host. Max watermark = (512B - 2* (BurstLength))/4 = (512 - 128)/4 = 384/4 = 0x60 so if burst length (i.e. BurstLength = 64) is increased, watermark has to be reduced.

Re: RTL8188EUS support

On 11/5/18 5:37 AM, Menion wrote: Hi all I have a question about the support of RTL8188EUS chipset (which I have in a TpLink 0bda:8179 usb dongle) This dongle works with the wext staging driver r8188eu driver. Is it meant to be supported in the rtl2xxx driver? Assuming that you mean rtl8xxxu,

Re: [PATCH] rtlwifi: rtl8192de: Fix misleading REG_MCUFWDL information

On Mon, 2018-11-05 at 19:25 +0800, Shaokun Zhang wrote: > RT_TRACE shows REG_MCUFWDL value as a decimal value with a '0x' > prefix, which is somewhat misleading. > > Fix it to print hexadecimal, as was intended. > > Cc: Ping-Ke Shih > Cc: Kalle Valo > Signed-off-by: Shaokun Zhang > --- >  

[PATCH v3 1/4] staging: wilc1000: remove unused flags in handle_cfg_param()

From: Adham Abozaeid handle_cfg_param() receives a bit map that describes what to be changed. Some of these bits flags aren't referred to from elsewhere and can be removed. Signed-off-by: Adham Abozaeid --- drivers/staging/wilc1000/host_interface.c | 216 --

[PATCH v3 4/4] staging: wilc1000: Remove unused mutex cfg_values_lock

From: Adham Abozaeid After removing cfg_values member, cfg_values_lock that was used to protect it can also be removed. Signed-off-by: Adham Abozaeid --- drivers/staging/wilc1000/host_interface.c | 9 - drivers/staging/wilc1000/host_interface.h | 2 -- 2 files changed, 11 deletions(-)

[PATCH v3 3/4] staging: wilc1000: Don't keep a copy of wiphy parameters in the driver

From: Adham Abozaeid host_if_drv.cfg_values is a write only member, and can be removed Signed-off-by: Adham Abozaeid --- drivers/staging/wilc1000/host_interface.c | 13 - drivers/staging/wilc1000/host_interface.h | 1 - 2 files changed, 14 deletions(-) diff --git

[PATCH v3 2/4] staging: wilc1000: validate cfg parameters before scheduling the work

From: Adham Abozaeid Validate cfg parameters after being called by cfg80211 in set_wiphy_params before scheduling the work executed in handle_cfg_param Signed-off-by: Adham Abozaeid --- drivers/staging/wilc1000/host_interface.c | 61 ++-

[PATCH v3 0/4] staging: wilc1000: validate input to set_wiphy_param and return proper errors

From: Adham Abozaeid Validate input parameters to set_wiphy_param before scheduling handle_cfg_param() to validate them. This way proper errors can be returned to caller. Also cleaned up unused code in handle_cfg_param. Changes since v1: - Correction spelling in subject of patch#2 - Added From:

Re: [RFC 0/3] cfg80211/nl80211/iw: add basic AMPDU/AMSDU controls

On 11/05/2018 02:49 PM, Igor Mitsyanko wrote: On 11/05/2018 12:45 PM, Ben Greear wrote: I see you don't implement it this way in the driver, but wouldn't it make more sense to have this as a per-STA (RA) setting? That's really the granularity it can be done on, I think? Arguably even

Re: [RFC 0/3] cfg80211/nl80211/iw: add basic AMPDU/AMSDU controls

On 11/05/2018 12:45 PM, Ben Greear wrote: >> >> I see you don't implement it this way in the driver, but wouldn't it >> make more sense to have this as a per-STA (RA) setting? That's really >> the granularity it can be done on, I think? >> >> Arguably even per-RA/TID, though that seems a little

Re: [RFC 0/3] cfg80211/nl80211/iw: add basic AMPDU/AMSDU controls

On 11/05/2018 12:45 PM, Ben Greear wrote: >> >> I see you don't implement it this way in the driver, but wouldn't it >> make more sense to have this as a per-STA (RA) setting? That's really >> the granularity it can be done on, I think? >> >> Arguably even per-RA/TID, though that seems a little

Re: [RFC 0/3] cfg80211/nl80211/iw: add basic AMPDU/AMSDU controls

On 11/05/2018 12:32 PM, Johannes Berg wrote: Hi, Here are several RFC patches providing simple high-level controls of AMSDU/AMPDU aggregation. The primary purpose of this functionality is an attempt to fill missing gaps in nl80211 interface for basic WFA certification tests. I see you don't

Re: [RFC 0/3] cfg80211/nl80211/iw: add basic AMPDU/AMSDU controls

Hi, > Here are several RFC patches providing simple high-level controls of > AMSDU/AMPDU > aggregation. The primary purpose of this functionality is an attempt to fill > missing gaps in nl80211 interface for basic WFA certification tests. I see you don't implement it this way in the driver, but

rtl8814au

We are planning on spinning up a 4x4 mimo mini pcie card using the Realtek chip similar to rtl8814au except not usb.  I didn't see anything in rtlwifi_new showing support for this chip.  Is this chip going to be supported in rtlwifi_new?  Can we provide any help in the development?  We are

Re: [PATCH v3 1/2] mt76x02: run calibration after scanning

On 2018-11-01 16:35, Stanislaw Gruszka wrote: > If we are associated and scanning is performed, sw_scan_complete callback > is done after we get back to operating channel, so we do not perform > queue cal work. Fix this queue cal work from sw_scan_complete(). > > On mt76x0 we have to restore gain

Re: [PATCH] mt76x0: use band parameter for LC calibration

On 2018-10-25 18:18, Stanislaw Gruszka wrote: > We use always 1 as band parameter for MCU_CAL_LC, this break 2GHz, > we should use 0 for this band instead. > > Patch fixes problems happened sometimes when try to associate with 2GHz > AP and manifest by errors like below: > > [14680.920823]

Re: [PATCH] mt76x0: dfs: fix IBI_R11 configuration on non-radar channels

On 2018-11-05 00:18, Lorenzo Bianconi wrote: > Fix IBI_R11 configuration on non-radar channels for mt76x0e > driver. This patch improve system stability under heavy load. > Moreover use IBI_R11 name and remove magic numbers for > 0x212c register > > Fixes: 0c3b3abc9251 ("mt76x0: pci: add DFS

Re: [PATCH 0/3] mt76x0: add tssi calibration support

On 2018-10-29 22:31, Lorenzo Bianconi wrote: > Introduce tssi calibration support in mt76x0 driver. > Configure tx power gain according to tssi calibrated value > if available Applied, thanks. - Felix

Re: [PATCH] mt76x2u: init: use common routines for wcid/key initialization

On 2018-10-29 22:16, Lorenzo Bianconi wrote: > Use mt76x02_mac_wcid_setup and mt76x02_mac_shared_key_setup for > shared keys and wcid table initialization and remove duplicated > code > > Signed-off-by: Lorenzo Bianconi Applied, thanks. - Felix

Re: [PATCH] mt76x2u: init: remove not useful configuration

On 2018-10-29 15:12, Lorenzo Bianconi wrote: > Remove MT_TSO_CTRL and MT_HEADER_TRANS_CTRL_REG initialization since > it is already done in mt76_write_mac_initvals routine > > Signed-off-by: Lorenzo Bianconi Applied, thanks. - Felix

Re: [PATCH] mt76x0: init: use mt76x02_mac_shared_key_setup in mt76x0_init_hardware

On 2018-10-28 23:54, Lorenzo Bianconi wrote: > Use mt76x02_mac_shared_key_setup utility routine for shared key > initialization and remove duplicated code > > Signed-off-by: Lorenzo Bianconi Applied, thanks. - Felix

Re: [PATCH 0/2] mt76x0: fix hw key table initialization

On 2018-10-29 01:36, Lorenzo Bianconi wrote: > Fix wrong mt76x0 hw key table initialization in AP mode. > Remove duplicated code. > > This patchset is based on top of 'mt76x0: init: use > mt76x02_mac_shared_key_setup in mt76x0_init_hardware' > https://patchwork.kernel.org/patch/10658721/ Applied,

Re: [PATCH 0/4] mt76: mcu api clenups

On 2018-10-26 14:00, Stanislaw Gruszka wrote: > Simplify mcu api and wait for response for mcu commands the same > as vendor driver. > > This is on top of: > [PATCH] mt76x0: use band parameter for LC calibration > > Stanislaw Gruszka (4): > mt76: remove mcu_msg_alloc > mt76: remove wait

Re: [PATCH] mt76x0: phy: use mt76_poll_msec in mt76x0_phy_temp_sensor

On 2018-10-27 21:06, Lorenzo Bianconi wrote: > Use mt76_poll_msec utility routine for CORE_R34 register polling > instead of mt76_poll in order to allow the hw to complete requested > calibration since on slow devices (e.g. mt7620 based boards) calibration > takes longer than 2ms > > Fixes:

Re: [PATCH 4/8] staging: wilc1000: avoid line over 80 chars in wilc_parse_network_info()

On Mon, 2018-11-05 at 12:18 +, ajay.kat...@microchip.com wrote: > Hi Joe, > > On 11/5/2018 4:27 PM, Joe Perches wrote: > > On Thu, 2018-11-01 at 16:45 +, ajay.kat...@microchip.com wrote: > > > From: Ajay Singh > > > > > > Use shorter name for 'network_info' variable to avoid line over

[PATCH v2] mt76: fix building without CONFIG_LEDS_CLASS

From: Arnd Bergmann When CONFIG_LEDS_CLASS is disabled, or it is a loadable module while mt76 is built-in, we run into a link error: drivers/net/wireless/mediatek/mt76/mac80211.o: In function `mt76_register_device': mac80211.c:(.text+0xb78): relocation truncated to fit: R_AARCH64_CALL26

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

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 1/6] brcmfmac: Remove firmware-loading code duplication

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 helper removing this code >>

Re: [PATCH] mt76x0: use band parameter for LC calibration

On 2018-11-05 15:58, Kalle Valo wrote: > Stanislaw Gruszka writes: > >> On Thu, Oct 25, 2018 at 06:18:33PM +0200, Stanislaw Gruszka wrote: >>> We use always 1 as band parameter for MCU_CAL_LC, this break 2GHz, >>> we should use 0 for this band instead. >>> >>> Patch fixes problems happened

Re: [PATCH] mt76x0: use band parameter for LC calibration

Stanislaw Gruszka writes: > On Thu, Oct 25, 2018 at 06:18:33PM +0200, Stanislaw Gruszka wrote: >> We use always 1 as band parameter for MCU_CAL_LC, this break 2GHz, >> we should use 0 for this band instead. >> >> Patch fixes problems happened sometimes when try to associate with 2GHz >> AP and

Re: [PATCH] mt76: fix building without CONFIG_LEDS_CLASS

Lorenzo Bianconi writes: >> Lorenzo Bianconi writes: >> >> > From: Arnd Bergmann >> > >> > When CONFIG_LEDS_CLASS is disabled, or it is a loadable module while >> > mt76 is built-in, we run into a link error: >> > >> > drivers/net/wireless/mediatek/mt76/mac80211.o: In function >> >

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

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 a

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

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 remove it. I

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

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

[RFC 2/3] iw: add phy subcommands to configure aggregation

Add phy subcommands to enable/disable AMPDU/AMSDU aggregation. Signed-off-by: Sergey Matyukevich --- nl80211.h | 6 ++ phy.c | 60 2 files changed, 66 insertions(+) diff --git a/nl80211.h b/nl80211.h index 1766a12..41eec4a

[RFC 3/3] qtnfmac: add support for basic aggregation control

Add support for basic AMPDU/AMSDU aggregation control: - report initial aggregation configuration to cfg80211 core - pass AMPDU/AMSDU aggregation changes to wireless card using set_wiphy_params cfg80211 callback Signed-off-by: Sergey Matyukevich ---

[RFC 0/3] cfg80211/nl80211/iw: add basic AMPDU/AMSDU controls

Hello Johannes and all, Here are several RFC patches providing simple high-level controls of AMSDU/AMPDU aggregation. The primary purpose of this functionality is an attempt to fill missing gaps in nl80211 interface for basic WFA certification tests. We experimented with QCA sigma-dut tool:

[RFC 1/3] cfg80211/nl80211: add wiphy flags to control aggregation

Add two top-level switches to wiphy structure to control AMSDU and AMPDU aggregation. Enable read/update of AMSDU and AMPDU aggregation from the userspace using set_wiphy/get_wiphy commands. Signed-off-by: Sergey Matyukevich --- include/net/cfg80211.h | 7 +++

Re: [PATCH v2 1/4] staging: wilc1000: remove unused flags in handle_cfg_param()

On Tue, Oct 30, 2018 at 04:22:55AM +, adham.aboza...@microchip.com wrote: > From: Adham Abozaeid > > handle_cfg_param() receives a bit map that describes what to be changed. > Some of these bits flags aren't referred to from elsewhere and can be > removed. > > Signed-off-by: Adham Abozaeid

Re: [PATCH] staging: wilc1000: update wilc1000 driver maintainer ids

On Tue, Oct 30, 2018 at 05:53:40AM +, ajay.kat...@microchip.com wrote: > From: Ajay Singh > > We would like to update the maintainer email id's for wilc1000 driver. > > Signed-off-by: Ajay Singh > Signed-off-by: Adham Abozaeid It would be good to get the current maintainer's signed off

Re: [PATCH 4/8] staging: wilc1000: avoid line over 80 chars in wilc_parse_network_info()

Hi Joe, On 11/5/2018 4:27 PM, Joe Perches wrote: > On Thu, 2018-11-01 at 16:45 +, ajay.kat...@microchip.com wrote: >> From: Ajay Singh >> >> Use shorter name for 'network_info' variable to avoid line over 80 chars >> issue. > > I suppose this is OK, though perhaps unnecessary. > > As well,

Re: [PATCH 0/5] rt2800mmio txdone/interrupts/flush rework

On 05/11/2018, Craig Matsuura wrote: > Tom, > > > I see my name and email in some urls but could not see what you are > referring too? > > > Craig > > > Craig Matsuura • Technical Director, Embedded Software Architecture > > cmatsu...@vivint.com • P: 801.229.6005 > >

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

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 remove it. I guess this could have been collapsed in the first

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

On 10/9/2018 2:47 PM, Hans de Goede wrote: For of/devicetree using machines, set the board_type used for nvram file selection to the first string listed in the top-level's node compatible string, aka the machine-compatible as used by of_machine_is_compatible(). The board_type setting is used to

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

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 a quirk table overriding the strings for models

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

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 OOTB, multiple (one per board) versions must co-exist under /lib/firmware. This

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

On 10/9/2018 2:47 PM, Hans de Goede wrote: Before this commit brcmf_fw_request_done would call brcmf_fw_request_next_item to load the next item, which on an error would call brcmf_fw_request_done, which if the error is recoverable (*) will then continue calling brcmf_fw_request_next_item for the

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

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 helper removing this code duplication. Reviewed-by: Arend van Spriel

RTL8188EUS support

Hi all I have a question about the support of RTL8188EUS chipset (which I have in a TpLink 0bda:8179 usb dongle) This dongle works with the wext staging driver r8188eu driver. Is it meant to be supported in the rtl2xxx driver? Bye

[PATCH] rtlwifi: rtl8192de: Fix misleading REG_MCUFWDL information

RT_TRACE shows REG_MCUFWDL value as a decimal value with a '0x' prefix, which is somewhat misleading. Fix it to print hexadecimal, as was intended. Cc: Ping-Ke Shih Cc: Kalle Valo Signed-off-by: Shaokun Zhang --- drivers/net/wireless/realtek/rtlwifi/rtl8192de/fw.c | 2 +- 1 file changed, 1

Re: [PATCH 4/8] staging: wilc1000: avoid line over 80 chars in wilc_parse_network_info()

On Thu, 2018-11-01 at 16:45 +, ajay.kat...@microchip.com wrote: > From: Ajay Singh > > Use shorter name for 'network_info' variable to avoid line over 80 chars > issue. I suppose this is OK, though perhaps unnecessary. As well, perhaps there are defects in the original code in a couple

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

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 be

Re: 7f9a3e150ec7d breaks brcmfmac with modparam roamoff=1

On 11/4/2018 8:04 PM, Stijn Tintel wrote: [ 259.240131] WARNING: CPU: 0 PID: 50 at /home/build/lede/build_dir/target-arm_arm1176jzf-s+vfp_musl_eabi/linux-brcm2708_bcm2708/backports-4.19-rc5-1/net/wireless/core.c:736 wiphy_register+0x280/0xa58 [cfg80211] [ 259.274067] Modules linked in: