Re: [PATCH 21/30] brcmfmac: Remove {r,w}_sdreg32

On 22-08-17 13:25, Ian Molton wrote: Remove yet another IO function from the code and replace with one that already exists. Reviewed-by: Arend van Spriel <arend.vanspr...@broadcom.com> Signed-off-by: Ian Molton <i...@mnementh.co.uk> --- .../wireless/broadcom/brcm80211/brc

Re: [PATCH 28/30] brcmfmac: Clean up interrupt macros

On 22-08-17 13:25, Ian Molton wrote: Make it more obvious that this code acually enables interrupts, and provide nice definitions for the bits in the register. Acked-by: Arend van Spriel <arend.vanspr...@broadcom.com> Signed-off-by: Ian Molton <i...@mnementh.co.uk> --- drivers/

Re: [PATCH v5] brcmfmac: add CLM download support

viewed-by: Arend van Spriel <arend.vanspr...@broadcom.com> Signed-off-by: Chung-Hsien Hsu <stanley@cypress.com> --- v2: Revise commit message to describe in more detail v3: Add error handling in brcmf_c_get_clm_name function v4: Correct the length of dload_buf in brcmf_c_download f

Re: [PATCH v5] brcmfmac: add CLM download support

On 04-09-17 13:33, Chung-Hsien Hsu wrote: On Tue, Aug 29, 2017 at 02:23:41PM +0800, Wright Feng wrote: From: Chung-Hsien Hsu The firmware for brcmfmac devices includes information regarding regulatory constraints. For certain devices this information is kept

Re: [PATCH v2] brcmfmac: Correctly fail to suspend when SDIO does not support power on suspend

On 04-09-17 21:33, Steve deRosier wrote: On Fri, Sep 1, 2017 at 1:02 PM, Arend van Spriel <arend.vanspr...@broadcom.com> wrote: Also note that the wifi chip (the term "radio" does not quite cover it) has not really lost power. It is quite common that it is not powered thro

Re: [PATCH] Documentation: dt-binding: net: wireless: add bcm43430-fmac

On 04-09-17 16:42, Antony Antony wrote: Hi Arend, On Fri, Sep 01, 2017 at 11:30:59PM +0200, Arend van Spriel wrote: Hi Rob, Actually the Broadcom wifi chips themselves are discoverable. So once the driver has access to the register space of the device it can determine the actual chip, its

Re: [PATCH] Documentation: dt-binding: net: wireless: add bcm43430-fmac

On 01-09-17 23:38, Rob Herring wrote: On Fri, Sep 1, 2017 at 2:10 PM, Arend van Spriel <arend.vanspr...@broadcom.com> wrote: On 01-09-17 18:49, Rob Herring wrote: On Wed, Aug 30, 2017 at 02:02:18PM +0200, Antony Antony wrote: hi, On Wed, Aug 30, 2017 at 10:28:20AM +0800, Chen-Y

Re: [PATCH] Documentation: dt-binding: net: wireless: add bcm43430-fmac

On 01-09-17 22:40, Antony Antony wrote: On Fri, Sep 01, 2017 at 09:10:41PM +0200, Arend van Spriel wrote: On 01-09-17 18:49, Rob Herring wrote: On Wed, Aug 30, 2017 at 02:02:18PM +0200, Antony Antony wrote: hi, On Wed, Aug 30, 2017 at 10:28:20AM +0800, Chen-Yu Tsai wrote: On Wed, Aug 30

Re: [PATCH v2] brcmfmac: feature check for multi-scheduled scan fails on bcm4345 devices

fix. Thanks. This is one of the few devices that I actually do not have on my desk. Acked-by: Arend van Spriel <arend.vanspr...@broadcom.com> Fixes: 9fe929aaace6 ("brcmfmac: add firmware feature detection for gscan feature") Signed-off-by: Ian W MORRISON <ianwmorri..

Re: [PATCH v2] brcmfmac: Correctly fail to suspend when SDIO does not support power on suspend

Maybe you can incorporate some of this in the commit message, but you should at least add: Fixes: 330b4e4be937 ("brcmfmac: Add wowl support for SDIO devices.") Fixes: bdf1340cf20f ("brcmfmac: fix sdio suspend and resume") Reviewed-by: Arend van Spriel <arend.vanspr...@bro

Re: [PATCH] Documentation: dt-binding: net: wireless: add bcm43430-fmac

On 01-09-17 18:49, Rob Herring wrote: On Wed, Aug 30, 2017 at 02:02:18PM +0200, Antony Antony wrote: hi, On Wed, Aug 30, 2017 at 10:28:20AM +0800, Chen-Yu Tsai wrote: On Wed, Aug 30, 2017 at 5:43 AM, Antony Antony wrote:

Re: [PATCH 20/30] brcmfmac: Remove repeated calls to brcmf_chip_get_core()

of the cores anyway, and even so, this will allow for easier refcounting in future. Reviewed-by: Arend van Spriel <arend.vanspr...@broadcom.com> Signed-off-by: Ian Molton <i...@mnementh.co.uk> --- .../wireless/broadcom/brcm80211/brcmfmac/sdio.c| 25 +- 1

Re: [PATCH 19/30] brcmfmac: Remove unused macro.

On 22-08-17 13:25, Ian Molton wrote: This macro is used exactly nowhere in the code. Delete it. this removal could have been done in previous patch making that one a rename/change of the macro. Anyway Reviewed-by: Arend van Spriel <arend.vanspr...@broadcom.com> Signed-off-b

Re: [PATCH 18/30] brcmfmac: Cleanup offsetof()

On 22-08-17 13:25, Ian Molton wrote: Create a macro to make the code a bit more readable, whilst we're stuck with using struct element offsets as register offsets. Reviewed-by: Arend van Spriel <arend.vanspr...@broadcom.com> Signed-off-by: Ian Molton <i...@mnementh.co.uk> ---

Re: [PATCH 07/34] brcmfmac: Remove brcmf_sdiod_request_data()

On 19-08-17 22:02, Ian Molton wrote: On 07/08/17 18:51, Ian Molton wrote: On 07/08/17 12:25, Arend van Spriel wrote: Handling of -ENOMEDIUM is altered, but as that's pretty much broken anyway we can ignore that. Please explain why you think it is broken. Not got the code to hand right now

Re: [PATCH 15/30] brcmfmac: Tidy register definitions a little

On 22-08-17 13:25, Ian Molton wrote: Trivial tidy of register definitions. Thought I already did, but Acked-by: Arend van Spriel <arend.vanspr...@broadcom.com> Signed-off-by: Ian Molton <i...@mnementh.co.uk> --- .../net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 4 ++

Re: [PATCH 13/30] brcmfmac: Clarify if using braces.

On 22-08-17 13:25, Ian Molton wrote: Whilst this if () statement is technically correct, it lacks clarity. I don't see the unclarity here. In my opinion people reading the code should have a good level in C language and a decent level of curiosity when they come across a function/macro like

Re: [PATCH 12/30] brcmfmac: Whitespace fixes.

On 22-08-17 13:25, Ian Molton wrote: Maybe mention the function you are making whitespace changes in as it involves only one here. Reviewed-by: Arend van Spriel <arend.vanspr...@broadcom.com> Signed-off-by: Ian Molton <i...@mnementh.co.uk> --- drivers/net/wireless/broadc

Re: [PATCH 03/30] brcmfmac: Split brcmf_sdiod_regrw_helper() up.

with the rw flag in the process. Signed-off-by: Ian Molton <i...@mnementh.co.uk> Reviewed-by: Arend van Spriel <arend.vanspr...@broadcom.com> --- .../wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 94 +- 1 file changed, 73 insertions(+), 21 deletions(-) diff --git a

Re: [PATCH 01/30] brcmfmac: Fix parameter order in brcmf_sdiod_f0_writeb()

On 22-08-17 13:25, Ian Molton wrote: All the other IO functions are the other way round in this driver. Make this one match. Sorry for being a nit, but not sure why the commit message starts with a tab. Other than that... Acked-by: Arend van Spriel <arend.vanspr...@broadcom.

Re: [PATCH v2] brcmfmac: Log chip id and revision

On 30-08-17 15:54, Hans de Goede wrote: For debugging some problems, it is useful to know the chip revision add a brcmf_info message logging this. Acked-by: Arend van Spriel <arend.vanspr...@broadcom.com> Signed-off-by: Hans de Goede <hdego...@redhat.com> --- Changes

Re: [PATCH v4] brcmfmac: add CLM download support

On 28-08-17 16:52, Steve deRosier wrote: On Mon, Aug 28, 2017 at 2:25 AM, Wright Feng wrote: From: Chung-Hsien Hsu The firmware for brcmfmac devices includes information regarding regulatory constraints. For certain devices this information

Re: [PATCH v4] brcmfmac: add CLM download support

On 8/28/2017 11:25 AM, Wright Feng wrote: From: Chung-Hsien Hsu The firmware for brcmfmac devices includes information regarding regulatory constraints. For certain devices this information is kept separately in a binary form that needs to be downloaded to the device.

Re: CVE-2017-9417 and brcmfmac

On 27-08-17 17:14, Ben Hutchings wrote: The CVE-2017-9417 aka "Broadpwn" vulnerability is said to affect the firmware for various Broadcom BCM43xx wifi chips, some of which are supported by the in-tree brcmfmac driver and firmware in linux- firmware.git. The bcmdhd driver for Android was

Re: [PATCH 17/30] brcmfamc: remove unnecessary call to brcmf_sdiod_set_backplane_window()

On 22-08-17 21:38, Arend van Spriel wrote: On 22-08-17 14:50, Julian Calaby wrote: Hi Ian, On Tue, Aug 22, 2017 at 9:25 PM, Ian Molton <i...@mnementh.co.uk> wrote: All functions that might require the window address changing call brcmf_sdiod_set_backplane_window() prior to access

Re: [PATCH v5] brcmfmac cleanup

On 22-08-17 13:25, Ian Molton wrote: Hi folks, Arend, as requested - a respin to take account of your comments. Unfortunately, although I've only included the patches you requested from v4, breaking out some of the simpler changes (whitespace, macos, etc.) has grown the set back up to 30

Re: [PATCH 17/30] brcmfamc: remove unnecessary call to brcmf_sdiod_set_backplane_window()

On 22-08-17 14:50, Julian Calaby wrote: Hi Ian, On Tue, Aug 22, 2017 at 9:25 PM, Ian Molton wrote: All functions that might require the window address changing call brcmf_sdiod_set_backplane_window() prior to access. Thus resetting the window is not required. Wouldn't

Re: AP mode with Broadcom 4330

On 15-08-17 10:22, Russell King - ARM Linux wrote: On Mon, Aug 14, 2017 at 11:25:03PM -0700, ros...@gmail.com wrote: If using rtlwifi, you could try using rtl8xxxu and see if you get similar results. ¯\_(ツ)_/¯ I'm using rtl8xxxu. I don't think rtlwifi supports the 8192eu - it certainly does

Re: [PATCH] nl80211: add an option to allow MFP without requiring it

On 14-08-17 15:49, Emmanuel Grumbach wrote: User space can now allow the kernel to associate to an AP that requires MFP or that doesn't have MFP enabled in the same NL80211_CMD_CONNECT command. The driver / firmware will decide whether to use it or not. Signed-off-by: Emmanuel Grumbach

Re: [PATCH 05/11] rsi: handle station connection in AP mode

On 14-08-17 08:53, Prameela Rani Garnepudi wrote: Hi Kalle, I will change the debug level and send the updated patches again. Thanks, Prameela Please do not top-post. On Mon, Aug 14, 2017 at 10:24 AM, Kalle Valo wrote: Amitkumar Karwar writes:

Re: [PATCH v2 09/10] rtlwifi: use debugfs to debug.

On 14-08-17 20:56, Joe Perches wrote: On Sun, 2017-06-25 at 10:43 -0500, Larry Finger wrote: From: Ping-Ke Shih Also the subject line is kinda generic. At least it made me smile ;-p Use debugfs to dump register and btcoex status. [] diff --git

[PATCH for-4.13] brcmfmac: feature check for multi-scheduled scan fails on bcm4343x devices

Wahren <stefan.wah...@i2se.com> Reported-by: Ian Molton <i...@mnementh.co.uk> Fixes: 9fe929aaace6 ("brcmfmac: add firmware feature detection for gscan feature") Signed-off-by: Arend van Spriel <arend.vanspr...@broadcom.com> --- drivers/net/wireless/broadcom/brcm

Re: brcmfmac: BCM43431 won't get probed on Raspberry Pi Zero W

On 8/11/2017 7:55 AM, Stefan Wahren wrote: Hi Arend, Am 26.07.2017 um 10:50 schrieb Arend van Spriel: On 7/26/2017 8:19 AM, Stefan Wahren wrote: Hi, what are the plans to fix this regression? I am a bit in doubt about this one. We can avoid the firmware config above for bcm4343x devices

Re: Regression: Bug 196547 - Since 4.12 - bonding module not working with wireless drivers

On 10-08-17 07:39, Kalle Valo wrote: Hi Mahesh and Andy, James Feeney reported that there's a serious regression in bonding module since v4.12, it doesn't work with wireless drivers anymore as wireless drivers don't report the link speed via ethtool:

Re: Problem with the wifi

On 09-08-17 18:40, Larry Finger wrote: On 08/08/2017 04:10 AM, Arend van Spriel wrote: + linux-wireless + Larry please keep linux-wireless in this thread. On 08-08-17 08:21, Paolo Bettini wrote: Arend van Spriel ha scritto: + linux-wireless On 07-08-17 21:38, Paolo Bettini wrote: Hi , i am

Re: wireless drivers fail to report link speed?

On 8/9/2017 2:36 AM, James Feeney wrote: Hey [...] On 08/08/2017 05:43 PM, Dan Williams wrote: It's very relevant to the question. Because if the speed is actually not useful for the requested purpose, there is no real point in having it reported it via ethtool. Same for duplex. Wifi

Re: [PATCH v4 01/10] wil6210: protect against invalid length of tx management frame

On 8/3/2017 9:08 PM, Maya Erez wrote: From: Hamad Kadmany Validate buffer length has the minimum needed size when sending management frame to protect against possible buffer overrun. I noticed this is already applied, but I saw this subject text which has

Re: [PATCH 30/34] brcmfmac: Correctly handle accesses to SDIO func0

On 26-07-17 22:25, Ian Molton wrote: > Rather than workaround the restrictions on func0 addressing in the > driver, set MMC_QUIRK_LENIENT_FN0 A quirk sounds like a workaround to me, but as it is provided by the mmc stack it trumps a driver solution. Acked-by: Arend van Spriel <are

Re: [PATCH 31/34] brcmfmac: Remove func0 from function array

On 08-08-17 13:27, Ian Molton wrote: > On 08/08/17 12:19, Arend van Spriel wrote: > >>> #define brcmf_sdiod_func0_rb(sdiodev, addr, r) \ >>> - sdio_f0_readb((sdiodev)->func[0], (addr), (r)) >>> + sdio_f0_readb((sdiodev)->func[1], (addr), (r)) >

Re: [PATCH 34/34] brcmfmac: Reduce the noise from repeatedly dereferencing common pointers

probe routine 89e5bb5 brcmfmac: Rename axi functions for clarity. a6352d7 brcmfmac: HUGE cleanup of IO access functions. ee7ea4f brcmfmac: Rename chip.ctx -> chip.bus_priv Reviewed-by: Arend van Spriel <arend.vanspr...@broadcom.com> > Signed-off-by: Ian Molton <i...@mnementh.c

Re: [PATCH 33/34] brcmfmac: Remove array of functions

On 26-07-17 22:25, Ian Molton wrote: > Replace the array of functions with a pair of pointers to the > relevant functions. Acked-by: Arend van Spriel <arend.vanspr...@broadcom.com> > Signed-off-by: Ian Molton <i...@mnementh.co.uk> > > # Conflicts: > # drivers/n

Re: [PATCH 32/34] brcmfmac: Replace function index with function pointer

On 26-07-17 22:25, Ian Molton wrote: > In preparation for removing the function array, remove all code that > refers to function by index and replace with pointers to the function > itself. Reviewed-by: Arend van Spriel <arend.vanspr...@broadcom.com> > Signed-off

Re: [PATCH 31/34] brcmfmac: Remove func0 from function array

On 26-07-17 22:25, Ian Molton wrote: > Linux doesnt pass you func0 as a function when probing - instead > providing specific access functions to read/write it. > > This prepares for a patch to remove the actual array entry itself. Reviewed-by: Arend van Spriel <arend.vanspr.

Re: Problem with the wifi

+ linux-wireless + Larry Jesus christ..grow some ears! On 08-08-17 11:21, Paolo Bettini wrote: > Arend van Spriel ha scritto: >> + linux-wireless >> + Larry >> >> please keep linux-wireless in this thread. >> >> On 08-08-17 08:21, Paolo Bettini

Re: Problem with the wifi

+ linux-wireless + Larry please keep linux-wireless in this thread. On 08-08-17 08:21, Paolo Bettini wrote: > Arend van Spriel ha scritto: >> + linux-wireless On 07-08-17 21:38, Paolo Bettini wrote: >>> Hi , i am Paolo and i installed Debian stretch on my ezbook2 . One >&

Re: Problem with the wifi

+ linux-wireless On 07-08-17 21:38, Paolo Bettini wrote: > Hi , i am Paolo and i installed Debian stretch on my ezbook2 . One > problem is the wifi , the card a SDIO device , seems to be 02d0:a9a6 > linux id or Broadcom AP6212 for windowsi installed deb package > firmware-brcm80211 and nvram

Re: [PATCH 13/34] brcmfmac: Tidy register definitions a little

On 26-07-17 22:25, Ian Molton wrote: > Trivial tidy of register definitions. Initially skipped this one, but it is indeed trivial. Reviewed-by: Arend van Spriel <arend.vanspr...@broadcom.com> > Signed-off-by: Ian Molton <i...@mnementh.co.uk> comment below... > --- &g

Re: [PATCH] brcmfmac: add setting carrier state ON for successful roaming

state ON for the case. This seems a specific scenario where the initial connect attempt by the host actually results in the firmware roaming, ie. switching to another AP, before completing the connection. Still it is needed here so ... Acked-by: Arend van Spriel <arend.vanspr...@broadcom.com

Re: [PATCH v2 3/3] brcmfmac: fix wrong num_different_channels when mchan feature enabled

me time. The root cause is that the num_different_channels was always overridden to 1 in brcmf_setup_ifmodes even multi-channel was enabled. We correct the logic by moving num_different_channels setting forward. Acked-by: Arend van Spriel <arend.vanspr...@broadcom.com> Signed-off-by: Wright Feng <wright.f.

Re: [PATCH 29/34] brcmfmac: stabilise the value of ->sbwad in use for some xfer routines.

So now I jump to this patch On 7/26/2017 10:25 PM, Ian Molton wrote: The IO functions operate within the Chipcommon IO window. Explicitly set this, rather than relying on the last initialisation IO access to leave it set to the right value by chance. Signed-off-by: Ian Molton

Re: [PATCH v2 2/3] brcmfmac: Add support for CYW4373 SDIO/USB chipset

On 8/3/2017 11:37 AM, Wright Feng wrote: From: Chi-Hsien Lin <chi-hsien@cypress.com> Add support for CYW4373 SDIO/USB chipset. CYW4373 is a 1x1 dual-band 11ac chipset with 20/40/80Mhz channel support. It's a WiFi/BT combo device. Reviewed-by: Arend van Spriel <arend.vanspr...@bro

Re: [PATCH v2 1/3] brcmfmac: set wpa_auth to WPA_AUTH_DISABLED in AP/OPEN security mode

in softAP beacons confuse the supplicant in client side, and the user client will see [WPA-?] in supplicant scan result. So we set WPA_AUTH_DISABLED in softAP mode with OPEN security. Acked-by: Arend van Spriel <arend.vanspr...@broadcom.com> Signed-off-by: Wright Feng <wright.f...@cypress.co

Re: [PATCH 15/34] brcmfamc: remove unnecessary call to brcmf_sdiod_set_backplane_window()

On 8/7/2017 1:11 PM, Arend van Spriel wrote: On 7/26/2017 10:25 PM, Ian Molton wrote: All functions that might require the window address changing call brcmf_sdiod_set_backplane_window() prior to access. Thus resetting the window is not required. Actually noticed a minor nit. The subject says

Re: [PATCH 14/34] brcmfmac: Remove brcmf_sdiod_addrprep()

to understand. Reviewed-by: Arend van Spriel <arend.vanspr...@broadcom.com> Signed-off-by: Ian Molton <i...@mnementh.co.uk> comments below... # Conflicts: # drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c --- .../wireless/broadcom/brcm80211/brcmfmac/bc

Re: [PATCH 11/34] brcmfmac: Split brcmf_sdiod_buffrw function up.

On 7/26/2017 10:25 PM, Ian Molton wrote: This function needs to be split up into separate read / write variants for clarity. Reviewed-by: Arend van Spriel <arend.vanspr...@broadcom.com> Signed-off-by: Ian Molton <i...@mnementh.co.uk> more comments below... # Conflicts: #

Re: [PATCH 12/34] brcmfmac: Replace old IO functions with simpler ones.

longer use the quirky method of deciding which function to address via the address being accessed, take the opportunity to rename some IO functions more in line with common kernel code. As mentioned here this is more a rename than a replace so please use that in the subject as well. Reviewed-by:

Re: [PATCH 09/34] brcmfmac: Remove noisy debugging.

On 7/26/2017 10:25 PM, Ian Molton wrote: If you need debugging this low level, you're doing something wrong. Remove these noisy debug statements so the code is more readable. Needing this debugging does not necessarily means you are doing something wrong. You may be dealing with hardware that

Re: [PATCH 10/34] brcmfmac: Rename bcmerror to err

On 7/26/2017 10:25 PM, Ian Molton wrote: Trivial cleanup of nasty variable name Did not look, but here is... Acked-by: Arend van Spriel <arend.vanspr...@broadcom.com> Signed-off-by: Ian Molton <i...@mnementh.co.uk> --- drivers/net/wireless/broadcom/brcm80211/brcmfmac/b

Re: [PATCH 08/34] brcmfmac: Fix uninitialised variable

up that would have my preference. Reviewed-by: Arend van Spriel <arend.vanspr...@broadcom.com> Signed-off-by: Ian Molton <i...@mnementh.co.uk> --- drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

Re: [PATCH 03/34] brcmfmac: Split brcmf_sdiod_regrw_helper() up.

in the net result. It would have been easier if those patches were done before this one. Reviewed-by: Arend van Spriel <arend.vanspr...@broadcom.com> Signed-off-by: Ian Molton <i...@mnementh.co.uk> some minor comment below --- .../wireless/broadcom/brcm80211/brcmfmac/bc

Re: [PATCH 06/34] brcmfmac: Remove bandaid for SleepCSR

-by: Arend van Spriel <arend.vanspr...@broadcom.com> Signed-off-by: Ian Molton <i...@mnementh.co.uk> # Conflicts: # drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c --- .../wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 28 +- 1 file changed, 1 inse

Re: [PATCH 07/34] brcmfmac: Remove brcmf_sdiod_request_data()

it is broken. Reviewed-by: Arend van Spriel <arend.vanspr...@broadcom.com> Signed-off-by: Ian Molton <i...@mnementh.co.uk> more comments below. # Conflicts: # drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c --- .../wireless/broadcom/brcm80211/brcmfmac/bcm

Re: [PATCH 01/34] brcmfmac: Fix parameter order in brcmf_sdiod_f0_writeb()

Hi Ian, So it took me a while to get to this patch series. It is indeed way to big and not well structured making it difficult to review the patches on a per-patch basis. I decided to limit myself to looking at the patches involving bcmsdh.c doing a 'git log bcmsdh.c' on the applied

Re: [PATCH 02/34] brcmfmac: Register sizes on hardware are not dependent on compiler types

, I find the use of sizeof() here pretty useless so thanks for the change. Reviewed-by: Arend van Spriel <arend.vanspr...@broadcom.com> Signed-off-by: Ian Molton <i...@mnementh.co.uk> --- .../wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 22 +++--- 1 file changed, 1

Re: [PATCH 15/34] brcmfamc: remove unnecessary call to brcmf_sdiod_set_backplane_window()

On 7/26/2017 10:25 PM, Ian Molton wrote: All functions that might require the window address changing call brcmf_sdiod_set_backplane_window() prior to access. Thus resetting the window is not required. Acked-by: Arend van Spriel <arend.vanspr...@broadcom.com> Signed-off-by: Ian Mol

Re: [PATCH 04/34] brcmfmac: Clean up brcmf_sdiod_set_sbaddr_window()

an up. No beef here ;-) Reviewed-by: Arend van Spriel <arend.vanspr...@broadcom.com> > Signed-off-by: Ian Molton <i...@mnementh.co.uk> > > # Conflicts: > # drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c > --- > .../net/wireles

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

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, sorry! This one is long overdue (thanks for the reminder, Kalle). Not sure what the claim is here.

Re: [PATCH v3 9/9] wil6210: make debugfs compilation optional

On 03-08-17 15:25, Maya Erez wrote: > From: Gidon Studinski > > Since debugfs is a kernel configuration option, enable the driver to > compile without debugfs. > > Signed-off-by: Gidon Studinski > Signed-off-by: Maya Erez

Re: [PATCH] mwifiex: add module parameter to disable 40MHZ support in 2.4G band

On 03-08-17 11:26, Kalle Valo wrote: > Xinming Hu writes: > >> From: Xinming Hu >> >> This patch provide a new module parameter disable_2g4_40m, with >> which driver will not report 40M capability for 2.4GHZ to cfg80211. >> >> Signed-off-by: Xinming Hu

Re: [PATCH v2 9/9] wil6210: make debugfs compilation optional

On 02-08-17 23:00, Maya Erez wrote: > From: Gidon Studinski > > Since debugfs is a kernel configuration option, enable the driver to > compile without debugfs. > > Signed-off-by: Gidon Studinski > Signed-off-by: Maya Erez

Re: brcm43430 sdio wifi regression with 4.13-rc1

On 02-08-17 22:43, russianneuroman...@ya.ru wrote: > Hello! > > Sorry for late answer. > >> russianneuromancer has reported seeing a similar problem with 4.13. > >> russianneuromancer, can you check if the device you are seeing this with > also has a brcm43430 sdio wifi and if so if switching

Re: [PATCH v4] rtlwifi: Replace hardcode value with macro

On 8/2/2017 1:59 PM, Souptick Joarder wrote: In _rtl_init_mac80211(), hardcoded value for hw->max_listen_interval and hw->max_rate_tries are replaced by macro and removed the comment. Signed-off-by: Souptick Joarder --- drivers/net/wireless/realtek/rtlwifi/base.c | 5

Re: [PATCH v4] rtlwifi: Replace hardcode value with macro

On 8/2/2017 12:47 PM, Souptick Joarder wrote: Hi Kalle, On Wed, Aug 2, 2017 at 2:51 PM, Kalle Valo wrote: Larry Finger writes: On 07/31/2017 06:14 AM, Souptick Joarder wrote: In _rtl_init_mac80211(), hardcoded value for

Re: [PATCH 3/3] brcmfmac: fix wrong num_different_channels when mchan feature enabled

On 8/2/2017 11:32 AM, Kalle Valo wrote: Wright Feng writes: The num_different_channels in wiphy info is not correct when firmware supports mchan. When mchan is on, num_different_channels is always overridden to 1 in brcmf_setup_ifmodes. Correct the logic by moving

Re: [PATCH] mac80211: remove mic_fail_no_key label

On 8/2/2017 11:04 AM, Stanislaw Gruszka wrote: For historic reasons we have separate cases for mic_fail and mic_fail_no_key. But with current code we can merge those cases, as we already have NULL key check since: commit a66b98db570a638afd909459e1e6bfa272344bd3 Author: Arik Nemtsov

Re: [PATCH V5 2/2] brcmfmac: don't warn user about NVRAM if fallback to the platform one succeeds

firmware subsystem > let's try our fallback code first. If that fails as well, then it's a > right moment to print an error. > > This should reduce amount of false reports from users seeing this > warning while having wireless working perfectly fine with the platform > NVRAM.

Re: [PATCH 2/3] brcmfmac: Add support for CYW4373 SDIO/USB chipset

On 01-08-17 17:10, Chi-Hsien Lin wrote: > > > On 08/01/2017 8:43, Arend van Spriel wrote: >> >> >> On 01-08-17 10:48, Wright Feng wrote: >>> From: Chi-Hsien Lin <chi-hsien@cypress.com> >>> >>> These changes add support for CYW4373 S

Re: [PATCH 3/3] brcmfmac: fix wrong num_different_channels when mchan feature enabled

ward. Acked-by: Arend van Spriel <arend.vanspr...@broadcom.com> > Signed-off-by: Wright Feng <wright.f...@cypress.com> > --- > drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-)

Re: [PATCH 2/3] brcmfmac: Add support for CYW4373 SDIO/USB chipset

On 01-08-17 10:48, Wright Feng wrote: > From: Chi-Hsien Lin > > These changes add support for CYW4373 SDIO/USB chipset. Could you summarize 4373 features, ie. is it 11n or 11ac? How much streams does it support? That kind of stuff. Regards, Arend

Re: [PATCH 1/3] brcmfmac: set wpa_auth to WPA_AUTH_DISABLED in AP/opensecurity mode

On 01-08-17 10:48, Wright Feng wrote: > When setting wpa_auth to WPA_AUTH_NONE(1) in AP mode with WEP secuirty, > firmware will set privacy bit and add WPA OUI in VENDOR IE in beacon and > probe response. It confuses the supplicant in sation client by the > security type from softAP beacon and we

Re: AP mode with Broadcom 4330

On 31-07-17 14:59, Russell King - ARM Linux wrote: > On Fri, Jul 28, 2017 at 09:50:21PM +0200, Arend van Spriel wrote: >> I was going to agree with you, but having second thoughts. There are >> actually two use-cases that need to be handled properly. The regular AP >> c

Re: AP mode with Broadcom 4330

support. > > This patch adds support for multiple BSS interfaces (AP). In > total three AP configurations can be created. In order to use > multiple BSS firmware needs to support it. > > Reviewed-by: Arend Van Spriel <ar...@broadcom.com> > Reviewed

Re: [PATCH v4 09/10] rtlwifi: use debugfs to debug.

On 7/27/2017 12:17 PM, Kalle Valo wrote: Larry Finger writes: From: Ping-Ke Shih Use debugfs to dump register and btcoex status. The title is useless and the commit log does not mention anything about what files are added and to which

Re: Patch v4: Clean up brcmfmac driver

On 7/27/2017 12:00 PM, Ian Molton wrote: On 27/07/17 10:52, Arend van Spriel wrote: How many patches would you like at once? Hi Ian, ~10-15 patches should be fine although I am simply ploughing through the lot right now. Hi Arend, Noted for future series. I take it I shouldn't re-spin

Re: [PATCH v4 01/10] rtlwifi: Fill in_4way field by driver

On 7/27/2017 11:54 AM, Kalle Valo wrote: Larry Finger writes: From: Ping-Ke Shih Because it isn't always correct to use EAPOL to check 4-way, we add a timer to handle exception. Signed-off-by: Ping-Ke Shih Signed-off-by:

Re: Patch v4: Clean up brcmfmac driver

On 7/27/2017 11:47 AM, Ian Molton wrote: On 27/07/17 07:17, Kalle Valo wrote: Here's a v4 of the cleanup patchset - checkpatch clean(er - I have purposely left some warnings unaddressed). I also dropped an accidental adjustment of a debug macro from v3. Like I said already last time, please

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

+ 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

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

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-pcie wifi chip. > > This is with this fix: >

[PATCH for-4.13] brcmfmac: fix memleak due to calling brcmf_sdiod_sgtable_alloc() twice

Fixes: 4d7928959832 ("brcmfmac: switch to new platform data") Reported-by: Stefan Wahren <stefan.wah...@i2se.com> Tested-by: Stefan Wahren <stefan.wah...@i2se.com> Reviewed-by: Hante Meuleman <hante.meule...@broadcom.com> Signed-off-by: Arend van Spriel <arend.vanspr...

Re: brcmfmac: BCM43602 in Touch Bar MacBook Pros not working properly

On 7/25/2017 8:07 AM, Daniel Roschka wrote: Hi, All Apple MacBook Pro models with Touch Bar contain a BCM43602 Wi-Fi chip. This chip isn't working properly. While it is properly detected by brcmfmac and even shows wifi networks nearby, connections only succeed when being very, very close to the

Re: [PATCH v2] brcmfmac: Don't grow SKB by negative size

_xmit()") Signed-off-by: Daniel Stone <dani...@collabora.com> Cc: Arend Van Spriel <arend.vanspr...@broadcom.com> Cc: James Hughes <james.hug...@raspberrypi.org> Cc: Hante Meuleman <hante.meule...@broadcom.com> Cc: Pieter-Paul Giesberts <pieter-paul.giesbe...

Re: brcmfmac: BCM43431 won't get probed on Raspberry Pi Zero W

On 7/26/2017 8:19 AM, Stefan Wahren wrote: Hi, Stefan Wahren hat am 17. Juli 2017 um 22:31 geschrieben: Hi, Franky Lin hat am 17. Juli 2017 um 21:50 geschrieben: On Mon, Jul 17, 2017 at 6:10 AM, Stefan Wahren

Re: brcmfmac: Possible memleak brcmf_sdiod_sgtable_alloc

On 7/26/2017 8:12 AM, Stefan Wahren wrote: Hi Arend, Stefan Wahren <stefan.wah...@i2se.com> hat am 23. Juli 2017 um 02:24 geschrieben: Arend van Spriel <arend.vanspr...@broadcom.com> hat am 22. Juli 2017 um 21:40 geschrieben: On 22-07-17 15:18, Stefan Wahren wrote: Hi,

Re: brcmfmac: 43430, additional delay after core out of reset

On 7/21/2017 6:20 PM, Rafal wrote: Again, ap6212 device on board. When the module gets unloaded and then loaded again, sometimes the driver fails to bring up the device - it stops with the following errors: [ 125.668000] brcmfmac: brcmf_sdio_txfail: sdio error, abort command and terminate

Re: brcfmac: add possibility to turn off powersave on wiphy

On 7/21/2017 11:19 PM, Rafal wrote: On Fri, 21 Jul 2017, Dan Williams wrote: On Fri, 2017-07-21 at 16:56 +0200, Rafal wrote: I have a board with ap6212 chip and I have encountered two problems with the brcmfmac driver operating with this device. First problem I describe below, second one in

Re: PATCH v3 brcmfmac driver cleanup

On 19-07-17 21:07, Ian Molton wrote: > Hi all, > > Please find the 3rd revision of my cleanup patchset for brcmfmac. > > I've done some further cleanup and it now handles SDIO the ay the MMC > subsystem > was designed to. > > I've also taken the liberty of greatly reducing the amount of

Re: brcm43430 sdio wifi regression with 4.13-rc1

On 22-07-17 20:43, Hans de Goede wrote: > The real culprit here seems to be: > > jul 22 14:13:23 localhost.localdomain kernel: brcmfmac: > brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012 So I dug a little deeper in our firmware and as it turns out it is indeed a firmware halt which is

Re: brcm43430 sdio wifi regression with 4.13-rc1

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: >> >> There is a fix for this: >>

Re: brcmfmac: Possible memleak brcmf_sdiod_sgtable_alloc

On 22-07-17 15:18, Stefan Wahren wrote: > Hi, > > with enabled memleak detector on 4.13-rc1 (Raspberry Pi Zero W) i get the > following: > > root@raspberrypi:/sys/kernel/debug# cat kmemleak > unreferenced object 0xd824e400 (size 1024): > comm "kworker/0:0", pid 3, jiffies 4294939822 (age

Re: brcmfmac bus level addressing issues.

On 19-07-17 00:45, Ian Molton wrote: [...] > Fair enough - I guess now that its in the kernel it needs fixing before > 4.13 - but I would argue that no new features should go into the driver > for the short term once that is done. Lets give it a good spring clean. > > I am, actually, able to

<    1   2   3   4   5   6   7   8   9   10   >