Re: [PATCH 1/2] brcmfmac: prohibit ACPI power management for brcmfmac driver

On 04/27/15 07:00, Fu, Zhonghui wrote: ACPI will manage WiFi chip's power state during suspend/resume process on some tablet platforms(such as ASUS T100TA). This is not supported by brcmfmac driver now, and the context of WiFi chip will be damaged after resume. This patch disconnects the

Re: [PATCH v3] brcmfmac: prohibit ACPI power management for brcmfmac driver

On 05/18/15 08:26, Fu, Zhonghui wrote: Hi guys, Any comments about this patch? My acked is already there. I have not been able to test it, but I assume you did. Regards, Arend Thanks, Zhonghui On 2015/5/11 10:41, Fu, Zhonghui wrote: ACPI will manage WiFi chip's power state during

Re: [RESEND][PATCH] Bluetooth: Make request workqueue freezable

On 05/22/15 09:37, Arend van Spriel wrote: On 05/22/15 02:21, Laura Abbott wrote: On 05/21/2015 08:26 AM, Alan Stern wrote: On Thu, 21 May 2015, Marcel Holtmann wrote: Hi Alan, Then avoiding the failed firmware is no solution, indeed. If it's a new probe, it should be never executed during

Re: [RESEND][PATCH] Bluetooth: Make request workqueue freezable

On 05/22/15 02:21, Laura Abbott wrote: On 05/21/2015 08:26 AM, Alan Stern wrote: On Thu, 21 May 2015, Marcel Holtmann wrote: Hi Alan, Then avoiding the failed firmware is no solution, indeed. If it's a new probe, it should be never executed during resume. Can you expand this comment?

Re: [RESEND][PATCH] Bluetooth: Make request workqueue freezable

On 05/21/15 19:32, Takashi Iwai wrote: At Thu, 21 May 2015 19:27:41 +0200, Arend van Spriel wrote: On 05/21/15 17:35, Takashi Iwai wrote: At Thu, 21 May 2015 11:26:17 -0400 (EDT), Alan Stern wrote: On Thu, 21 May 2015, Takashi Iwai wrote: At Thu, 21 May 2015 10:18:08 -0400 (EDT), Alan

Re: [RESEND][PATCH] Bluetooth: Make request workqueue freezable

On 05/21/15 17:35, Takashi Iwai wrote: At Thu, 21 May 2015 11:26:17 -0400 (EDT), Alan Stern wrote: On Thu, 21 May 2015, Takashi Iwai wrote: At Thu, 21 May 2015 10:18:08 -0400 (EDT), Alan Stern wrote: On Thu, 21 May 2015, Takashi Iwai wrote: Then avoiding the failed firmware is no

Re: [PATCH] net/wireless: enable wiphy device to suspend/resume asynchronously

+ Rafael On 08/17/2015 09:29 AM, Johannes Berg wrote: On Mon, 2015-08-17 at 09:48 +0800, Fu, Zhonghui wrote: The suspend/resume timing of wiphy device and related devices will be ensured by their parent/child relationship. So, enabling wiphy device to suspend/resume asynchronously does not

Re: [PATCH 2/3] brcmfmac: dhd_sdio.c: use existing atomic_or primitive

of @val for 64 bit arches. Assuming LP64 programming model for linux on say x86_64: atomic_or() callers in this driver use long (sana 64 bit) storage and pass it to atomic_orr/atomic_or which downcasts it to 32 bits. Is that OK ? --- Cc: Brett Rudley brud...@broadcom.com Cc: Arend van Spriel ar

Re: [PATCH] brcm80211:Fix error handling in the function brcmf_sdio_htclk

Hi Nick, On 10/06/2015 04:36 AM, Nicholas Krause wrote: This fixes error handling in the function brcmf_sdio_htclk to properly check if the call to the function brcmf_sdio_regrb fails in the else if condition where the clkstate is in the CLK_PENDING state in order to avoid incorrect execution

Re: [PATCH] brcmfmac: fix waitqueue_active without memory barrier in brcmfmac driver

On 10/09/2015 02:35 AM, Kosuke Tatsukawa wrote: > brcmf_msgbuf_ioctl_resp_wake() seems to be missing a memory barrier > which might cause the waker to not notice the waiter and miss sending a > wake_up as in the following figure. > >brcmf_msgbuf_ioctl_resp_wake

Re: [PATCH] brcmfmac: fix waitqueue_active without memory barrier in brcmfmac driver

On 10/09/2015 02:35 AM, Kosuke Tatsukawa wrote: > brcmf_msgbuf_ioctl_resp_wake() seems to be missing a memory barrier > which might cause the waker to not notice the waiter and miss sending a > wake_up as in the following figure. My mail reader treats this as HTML format or so. Can you resend it

Re: [PATCH v2] brcmsmac: Use kstrdup to simplify code

-by: Arend van Spriel ar...@broadcom.com Signed-off-by: Christophe JAILLET christophe.jail...@wanadoo.fr --- v2: fix the subject drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/net/wireless/brcm80211/brcmsmac

Re: [PATCH 2/3] brcmfmac: dhd_sdio.c: use existing atomic_or primitive

downcasts it to 32 bits. Is that OK ? The function is used with 32bit register value from the device so I think it is ok. Regards, Arend --- Cc: Brett Rudley brud...@broadcom.com Cc: Arend van Spriel ar...@broadcom.com Cc: Franky (Zhenhui) Lin fran...@broadcom.com Cc: Hante Meuleman meule

Re: [PATCH 2/3] brcmfmac: dhd_sdio.c: use existing atomic_or primitive

On 07/09/2015 08:25 PM, Arend van Spriel wrote: On 07/09/2015 10:13 AM, Vineet Gupta wrote: There's already a generic implementation so use that instead. There is or there was? If there is now I am fine with this patch, but if it already was there the author might have had a reason for adding

Re: [PATCH 2/3] brcmfmac: dhd_sdio.c: use existing atomic_or primitive

On 07/10/2015 06:49 AM, Vineet Gupta wrote: On Thursday 09 July 2015 11:55 PM, Arend van Spriel wrote: On 07/09/2015 10:13 AM, Vineet Gupta wrote: There's already a generic implementation so use that instead. There is or there was? If there is now I am fine with this patch, but if it already

Re: [PATCH] brcmfmac: constify brcmf_bus_ops structures

On 11/14/2015 05:22 PM, Julia Lawall wrote: The brcmf_bus_ops structures are never modified, so declare them as const. Done with the help of Coccinelle. Acked-by: Arend van Spriel <ar...@broadcom.com> Signed-off-by: Julia Lawall <julia.law...@lip6.fr> --- drivers/net/wirele

Re: [PATCH] mac80211: Do not use sizeof() on pointer type

On 08/26/2015 12:22 PM, Thierry Reding wrote: From: Thierry Reding tred...@nvidia.com The rate_control_cap_mask() function takes a parameter mcs_mask, which GCC will take to be u8 * even though it was declared with a fixed size. This causes the following warning: net/mac80211/rate.c:

Re: [PATCH] mac80211: Do not use sizeof() on pointer type

On 08/26/2015 10:23 PM, Arend van Spriel wrote: On 08/26/2015 12:22 PM, Thierry Reding wrote: From: Thierry Reding tred...@nvidia.com The rate_control_cap_mask() function takes a parameter mcs_mask, which GCC will take to be u8 * even though it was declared with a fixed size. This causes

Re: [PATCH] brcm80211:Fix locking region in the function brcmf_sdio_sendfromq

On 10/03/2015 06:19 PM, Nicholas Krause wrote: This fixes the locking region in the function brcmf_sdio_sendfromq to properly lock around the call to the function brcmrf_sdio_txpkt in order to avoid concurrent access issues when calling this function as stated in the function's comments about

Re: [PATCH] brcmfmac: only lock and unlock fws if fws is not null

Acked-by: Arend van Spriel <ar...@broadcom.com> Signed-off-by: Colin Ian King <colin.k...@canonical.com> --- drivers/net/wireless/brcm80211/brcmfmac/fwsignal.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/net/wireless/brcm80211/brcmfmac/fwsigna

Re: net-libertas: Better exception handling in if_spi_host_to_card_worker()

On 03-01-16 16:18, Rafał Miłecki wrote: > On 3 January 2016 at 10:36, Arend van Spriel <aspr...@gmail.com> wrote: >> On 02-01-16 12:21, SF Markus Elfring wrote: >>>> Did you look at the resulting assembly code for different target >>>> architectures? &g

Re: net-libertas: Better exception handling in if_spi_host_to_card_worker()

On 02-01-16 10:08, SF Markus Elfring wrote: >>> I assume that a software development taste can evolve, can't it? >> >> So far, you have gotten several down votes for this kind of change, > > I am curious when more contributors will share corresponding opinions. Let's burn some cycles on this

Re: [PATCH] net-brcmfmac: Delete an unnecessary variable initialisation in brcmf_sdio_download_firmware()

plicit initialisation at the beginning for one local variable that is redefined before its first use. That being said here is my Acked-by: Arend van Spriel <ar...@broadcom.com> Signed-off-by: Markus Elfring <elfr...@users.sourceforge.net> --- drivers/net/wireless/broadcom/brcm80211/b

Re: net-libertas: Better exception handling in if_spi_host_to_card_worker()

On 02-01-16 12:21, SF Markus Elfring wrote: >> I have never seen much evolution going on in this area. > > I can get an other impression from a specific document for example. > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/Documentation/CodingStyle > > >> What the patch

Re: [PATCH v2 06/27] brcm80211: move under broadcom vendor directory

On 11/19/2015 08:48 AM, Kalle Valo wrote: Hauke Mehrtens writes: On 11/18/2015 03:45 PM, Kalle Valo wrote: Part of reorganising wireless drivers directory and Kconfig. Note that I had to edit Makefiles from subdirectories to use the new location. Signed-off-by: Kalle Valo

Re: [PATCH v2 06/27] brcm80211: move under broadcom vendor directory

On 11/19/2015 08:54 AM, Kalle Valo wrote: Florian Fainelli writes: On 18/11/15 11:19, Hauke Mehrtens wrote: On 11/18/2015 03:45 PM, Kalle Valo wrote: Part of reorganising wireless drivers directory and Kconfig. Note that I had to edit Makefiles from subdirectories to

Re: [PATCH v2 06/27] brcm80211: move under broadcom vendor directory

On 11/23/2015 11:28 AM, Arend van Spriel wrote: On 11/22/2015 06:23 PM, Kalle Valo wrote: Arend van Spriel <ar...@broadcom.com> writes: On 11/19/2015 08:48 AM, Kalle Valo wrote: Hauke Mehrtens <ha...@hauke-m.de> writes: On 11/18/2015 03:45 PM, Kalle Valo wrote: Part of

Re: [PATCH v2 06/27] brcm80211: move under broadcom vendor directory

On 11/22/2015 06:23 PM, Kalle Valo wrote: Arend van Spriel <ar...@broadcom.com> writes: On 11/19/2015 08:48 AM, Kalle Valo wrote: Hauke Mehrtens <ha...@hauke-m.de> writes: On 11/18/2015 03:45 PM, Kalle Valo wrote: Part of reorganising wireless drivers directory and Kconfig. Not

Re: [PATCH] brcmfmac: rework function picking free BSS index

On 26-05-16 01:44, Rafał Miłecki wrote: > The old implementation was overcomplicated and slightly bugged in some > corner cases. > > Consider following state of BSS-es (limited to 6 for simplification): > drvr->iflist[0]: { bsscfgidx:0, ndev->name:wlan1, } > drvr->iflist[1]: (null) >

Re: [PATCH] brcmfmac: slightly simplify building interface combinations

fore preparing limits). > 3) It modifies mbss code to use i variable just like other combos do. Acked-by: Arend van Spriel <arend.vanspr...@broadcom.com> > Signed-off-by: Rafał Miłecki <zaj...@gmail.com> > --- > .../broadcom/brcm80211/brcmfmac/cfg80211.c | 37 > +

Re: [PATCH] brcmfmac: fix setting AP channel with new firmwares

On 24-05-16 11:09, Rafał Miłecki wrote: > Firmware for new chipsets is based on a new major version of code > internally maintained at Broadcom. E.g. brcmfmac4366b-pcie.bin (used for > BCM4366B1) is based on 10.10.69.3309 while brcmfmac43602-pcie.ap.bin was > based on 7.35.177.56. > > Currently

Re: [PATCH V2] brcmfmac: print error if p2p_ifadd firmware command fails

On 24-05-16 23:05, Rafał Miłecki wrote: > This is helpful for debugging, without this all I was getting from "iw" > command on device with BCM43602 was: >> command failed: Too many open files in system (-23) > > Signed-off-by: Rafał Miłecki > --- > V2: s/in/if/ in commit

Re: [PATCHv2 1/2] add basic register-field manipulation macros

On 14-06-16 13:44, Jakub Kicinski wrote: > C bitfields are problematic and best avoided. Developers > interacting with hardware registers find themselves searching > for easy-to-use alternatives. Common approach is to define > structures or sets of macros containing mask and shift pair. >

Re: [PATCH] brcmfmac: rework function picking free BSS index

On 09-06-16 21:16, Arend van Spriel wrote: > On 26-05-16 01:44, Rafał Miłecki wrote: >> The old implementation was overcomplicated and slightly bugged in some >> corner cases. >> [...] >> New code is simpler, placed in file where it's really used, handles &g

Re: [PATCH V3] brcmfmac: print error if p2p_ifadd firmware command fails

On 26-5-2016 0:44, Rafał Miłecki wrote: > This is helpful for debugging, without this all I was getting from "iw" > command on device with BCM43602 was: >> command failed: Too many open files in system (-23) > > Signed-off-by: Rafał Miłecki > --- > V2: s/in/if/ in commit

Re: [PATCH RFC] brcmfmac: support deleting MBSS AP interfaces

On 01-06-16 16:36, Rafał Miłecki wrote: > We already support adding extra (AP) interfaces so it also makes an > obvious sense to allow deleting them. > > Adding a new interface is implemented by sending request to firmware for > creating a new BSS and waiting for a proper event. Ideally deleting

Re: 4.7-rc1 wifi driver bug report

On 31-5-2016 13:46, Grey Christoforo wrote: > Hi, > > I found the following in my dmesg today when I tried out 4.7-rc1 on my > Dell XPS15 9550. My WiFi doesn't work. > > Relevant bits of my lsusb & lspci are: > > $ lsusb > ... > Bus 001 Device 002: ID 0a5c:6410 Broadcom Corp. > ... > $ lspci >

Re: [PATCH RFC] brcmfmac: support deleting MBSS AP interfaces

On 17-06-16 14:30, Rafał Miłecki wrote: > On 1 June 2016 at 21:00, Arend van Spriel <arend.vanspr...@broadcom.com> > wrote: >> On 01-06-16 16:36, Rafał Miłecki wrote: >>> We already support adding extra (AP) interfaces so it also makes an >>> obvious sense to

Re: [PATCH RFC 1/2] brcmfmac: remove interface before notifying listener

On 18-06-16 20:18, Rafał Miłecki wrote: > So far when receiving event about in-firmware-interface removal we were > notifying our listener and afterwards we were removing Linux interface. > [snip] > > diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c >

Re: [PATCH RFC 2/2] brcmfmac: support removing AP interfaces with "interface_remove"

On 18-06-16 20:18, Rafał Miłecki wrote: > New firmwares (e.g. 10.10.69.36 for BCM4366) support "interface_remove" > for removing interfaces. Try to use this method on cfg80211 request. In > case of older firmwares (e.g. 7.35.177.56 for BCM43602 as I tested) this > will just result in firmware

Re: [PATCH] brcmfmac: sdio: Increase the default timeouts a bit

On 26-01-16 00:41, Julian Calaby wrote: > Hi Arend, > > On Tue, Jan 26, 2016 at 2:39 AM, Arend van Spriel <aspr...@gmail.com> wrote: >> On 25-01-16 12:06, Julian Calaby wrote: >>> Hi Sjoerd, >>> >>> On Mon, Jan 25, 2016 at 9:47 PM, Sjoerd

Re: [PATCH] brcmfmac: sdio: Increase the default timeouts a bit

On 25-1-2016 20:23, Doug Anderson wrote: > Hi, > > On Mon, Jan 25, 2016 at 7:36 AM, Arend van Spriel <aspr...@gmail.com> wrote: >> On 25-01-16 11:47, Sjoerd Simons wrote: >>> On a Radxa Rock2 board with a Ampak AP6335 (Broadcom 4339 core) it seems >>&

Re: [PATCH] brcmfmac: sdio: Increase the default timeouts a bit

On 25-01-16 12:06, Julian Calaby wrote: > Hi Sjoerd, > > On Mon, Jan 25, 2016 at 9:47 PM, Sjoerd Simons > wrote: >> On a Radxa Rock2 board with a Ampak AP6335 (Broadcom 4339 core) it seems >> the card responds very quickly most of the time, unfortunately during >>

Re: [PATCH] brcmfmac: sdio: Increase the default timeouts a bit

need this fix for now so... Acked-by: Arend van Spriel <ar...@broadcom.com> > Signed-off-by: Sjoerd Simons <sjoerd.sim...@collabora.co.uk> > > --- Still would like to know whether it is firmware initialization or some mmc stack procedure. Any suggestions to debug this ar

Re: [PATCH v3] prism54: isl_38xx: Replace 'struct timeval'

On 13-4-2016 10:38, Johannes Berg wrote: > >> The patch was build-tested / debugged by removing the >> "if VERBOSE > SHOW_ERROR_MESSAGES" guards. > > Stands to reason that we should just remove the (more or less) dead > code, since I don't think anyone really ever touches this driver any > more

Re: [PATCH v2] mwifiex: fix possible NULL dereference

On 12-04-16 13:46, Sudip Mukherjee wrote: > From: Sudip Mukherjee > > We have a check for card just after dereferencing it. So if it is NULL > we have already dereferenced it before its check. Lets dereference it > after checking card for NULL. And you are

Re: [PATCH 4.8 2/2] brcmfmac: support get_channel cfg80211 callback

On 19-5-2016 13:02, Rafał Miłecki wrote: > This is important for brcmfmac as the firmware may pick different > channel than requested. This has been tested with BCM4366B1 (in D-Link > DIR-885L). Can you elaborate? Is this for AP or STA mode? > Signed-off-by: Rafał Miłecki >

Re: [PATCH] brcmfmac: use kmemdup

On 19-5-2016 15:59, Muhammad Falak R Wani wrote: > Use kmemdup when some other buffer is immediately copied into allocated > region. It replaces call to allocation followed by memcpy, by a single > call to kmemdup. Acked-by: Arend van Spriel <arend.vanspr...@broadcom.com&g

Re: [PATCH 4.8 1/2] brcmutil: add field storing control channel to the struct brcmu_chan

control channel. The need to "access all info" is probably the other patch so you might hint here that this change is needed for the .get_channel() callback. Reviewed-by: Arend van Spriel <arend.vanspr...@broadcom.com> > Signed-off-by: Rafał Miłecki <zaj...@gmail.

Re: [PATCH 1/1] brcm80211: simplify assignment

On 18-5-2016 2:57, Heinrich Schuchardt wrote: > Simplify assignment in wlc_phy_rxcal_gainctrl_nphy_rev5. Acked-by: Arend van Spriel <arend.vanspr...@broadcom.com> > Signed-off-by: Heinrich Schuchardt <xypron.g...@gmx.de> > --- > drivers/net/wireless/broadcom/brcm80211/

Re: [PATCH] cfg80211/nl80211: add wifi tx power mode switching support

On 12-05-16 11:34, Wei-Ning Huang wrote: > On Thu, May 12, 2016 at 2:33 AM, Dan Williams wrote: >> On Wed, 2016-05-11 at 13:03 +0800, Wei-Ning Huang wrote: >>> On Fri, May 6, 2016 at 4:19 PM, Wei-Ning Huang >>> wrote: On Fri, May 6, 2016 at 12:07

Re: [BUGFIX PATCH 1/2] brcmfmac: Check rtnl_lock is locked when removing interface

On 15-8-2016 13:52, Rafał Miłecki wrote: > On 15 August 2016 at 12:57, Kalle Valo wrote: >> Rafał Miłecki writes: >> Signed-off-by: Masami Hiramatsu >>> >>> Fixes: a63b09872c1d ("brcmfmac: delete interface directly in code that

Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data

On 27-1-2017 10:43, Pali Rohár wrote: > On Friday 27 January 2017 09:33:40 Kalle Valo wrote: >> Pali Rohár writes: >> >>> NVS calibration data for wl1251 are model specific. Every one device with >>> wl1251 chip has different and calibrated in factory. >>> >>> Not all wl1251

Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data

On 27-1-2017 11:10, Pali Rohár wrote: > On Friday 27 January 2017 11:05:32 Arend Van Spriel wrote: >> On 27-1-2017 10:43, Pali Rohár wrote: >>> On Friday 27 January 2017 09:33:40 Kalle Valo wrote: >>>> Pali Rohár <pali.ro...@gmail.com> writes: >>>>

Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data

On 27-1-2017 13:26, Kalle Valo wrote: > Pali Rohár writes: > >> On Friday 27 January 2017 13:49:03 Kalle Valo wrote: >>> Pali Rohár writes: >>> > So > for those other platforms there will be a delay waiting for user-mode > helper to fail,

Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data

On 27-1-2017 8:33, Kalle Valo wrote: > Pali Rohár writes: > >> NVS calibration data for wl1251 are model specific. Every one device with >> wl1251 chip has different and calibrated in factory. >> >> Not all wl1251 chips have own EEPROM where are calibration data stored. And

Re: [PATCH] brcmfmac: Use net_device_stats from struct net_device

On 13-2-2017 11:14, Tobias Klauser wrote: > Instead of using a private copy of struct net_device_stats in struct > brcm_if, use stats from struct net_device. Also remove the now > unnecessary .ndo_get_stats function. Acked-by: Arend van Spriel <arend.vanspr...@broadcom.com&g

Re: [PATCH] mwifiex: propagate error if IRQ request fails in mwifiex_sdio_of()

On 18-08-16 16:17, Javier Martinez Canillas wrote: > If request_irq() fails in mwifiex_sdio_probe_of(), only an error message > is printed but the actual error is not propagated to the caller function. Hmm. The caller function, ie. mwifiex_sdio_probe(), does not seem to care. The device may

Re: [PATCH] mwifiex: propagate error if IRQ request fails in mwifiex_sdio_of()

On 18-08-16 21:29, Javier Martinez Canillas wrote: > Hello Arend, > > Thanks a lot for your feedback. > > On 08/18/2016 03:14 PM, Arend van Spriel wrote: >> On 18-08-16 16:17, Javier Martinez Canillas wrote: >>> If request_irq() fails in mwifiex_sdio_pro

Re: [BUGFIX PATCH 2/2] brcmfmac: Change vif_event_lock to spinlock

x3f0 > [ 186.678741] [] ? mntput_no_expire+0x5/0x3f0 > [ 186.678743] [] ? mntput+0x24/0x40 > [ 186.678744] [] ? __fput+0x190/0x200 > [ 186.678746] [] __sys_sendmsg+0x45/0x80 > [ 186.678748] [] SyS_sendmsg+0x12/0x20 > [ 186.678749] [] entry_SYSCALL_64_fastpath+0x23/0xc1 &

Re: [PATCH 0/3] hostap: Fine-tuning for a few functions

On 20-08-16 18:43, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sat, 20 Aug 2016 18:35:43 +0200 > > A few update suggestions were taken into account > from static source code analysis. Is it worth touching this old stuff especially when you are not

Re: [PATCH 1/1] brcmfmac: fix pmksa->bssid usage

On 22-8-2016 15:03, Nicolas Iooss wrote: > Hello, > > After I sent the following patch a few weeks ago, I have not received > any feedback. Could you please review it and tell me what I may have > done wrong? Nothing. People went on vacation :-) > Thanks, > Nicolas > > On 05/08/16 22:34,

Re: [PATCH] brcmfmac: implement more accurate skb tracking

On 29-9-2016 23:57, Rafał Miłecki wrote: > On 27 September 2016 at 11:24, Arend Van Spriel > <arend.vanspr...@broadcom.com> wrote: >> On 26-9-2016 14:38, Rafał Miłecki wrote: >>> On 26 September 2016 at 14:13, Rafał Miłecki <zaj...@gmail.com> wrote: >>>

Re: [PATCH] brcmfmac: fix memory leak in brcmf_fill_bss_param

On 21-9-2016 8:23, Rafał Miłecki wrote: > From: Rafał Miłecki <ra...@milecki.pl> > > This function is called from get_station callback which means that every > time user space was getting/dumping station(s) we were leaking 2 KiB. > Acked-by: Arend van Spriel <aren

Re: [PATCH v2] fix:brcmfmac: add missing header dependencies

On 27-8-2016 8:08, Baoyou Xie wrote: > We get 1 warning when biuld kernel with W=1: > drivers/net/wireless/broadcom/brcm80211/brcmfmac/tracepoint.c:23:6: warning: > no previous prototype for '__brcmf_err' [-Wmissing- > prototypes] > > In fact, this function is declared in brcmfmac/debug.h, so

Re: [PATCH 4.9] brcmfmac: use correct skb freeing helper when deleting flowring

On 27-9-2016 13:27, Kalle Valo wrote: > Arend Van Spriel <arend.vanspr...@broadcom.com> writes: > >> On 27-9-2016 11:14, Rafał Miłecki wrote: >>> From: Rafał Miłecki <ra...@milecki.pl> >>> >>> Flowrings contain skbs waiting for transmission that

Re: [PATCH 4.9] brcmfmac: use correct skb freeing helper when deleting flowring

use freeing function > that will check for 802.1x type as well. > > Freeing skbs without a proper check was leading to counter not being > properly decreased. This was triggering a WARNING every time > brcmf_netdev_wait_pend8021x was called. Acked-by: Arend van Spriel <ar.

Re: [PATCH 4.9] brcmfmac: use correct skb freeing helper when deleting flowring

On 27-9-2016 13:58, Rafał Miłecki wrote: > On 27 September 2016 at 13:44, Rafał Miłecki <zaj...@gmail.com> wrote: >> On 27 September 2016 at 13:27, Kalle Valo <kv...@codeaurora.org> wrote: >>> Arend Van Spriel <arend.vanspr...@broadcom.com> writes: >>>

Re: [PATCH] brcmfmac: replace WARNING on timeout with a simple error message

anymore > and backtrace wasn't much useful. Indeed the interesting part would be in another context. So: Acked-by: Arend van Spriel <arend.vanspr...@broadcom.com> > Signed-off-by: Rafał Miłecki <ra...@milecki.pl> > --- > drivers/net/wireless/broadcom/brcm80211/brcmfmac/c

Re: [PATCH] brcmfmac: implement more accurate skb tracking

On 26-9-2016 16:59, Dan Williams wrote: > On Mon, 2016-09-26 at 14:13 +0200, Rafał Miłecki wrote: >> On 26 September 2016 at 13:46, Arend Van Spriel >> <arend.vanspr...@broadcom.com> wrote: >>> >>> On 26-9-2016 12:23, Rafał Miłecki wrote: >>

Re: [PATCH] brcmfmac: implement more accurate skb tracking

On 26-9-2016 14:38, Rafał Miłecki wrote: > On 26 September 2016 at 14:13, Rafał Miłecki <zaj...@gmail.com> wrote: >> On 26 September 2016 at 13:46, Arend Van Spriel >> <arend.vanspr...@broadcom.com> wrote: >>> On 26-9-2016 12:23, Rafał Miłecki wrote: >&g

Re: [PATCH 1/2] brcmfmac: initialize fws(ignal) for BCDC protocol only

On 24-9-2016 22:44, Rafał Miłecki wrote: > From: Rafał Miłecki > > There are two protocols used by Broadcom FullMAC devices: BCDC and > msgbuf. They use different ways for (some part of) communication with > the firmware. Firmware Signaling is required for the first one only >

Re: [PATCH] brcmfmac: implement more accurate skb tracking

On 26-9-2016 12:23, Rafał Miłecki wrote: > From: Rafał Miłecki > > We need to track 802.1x packets to know if there are any pending ones > for transmission. This is required for performing key update in the > firmware. The problem we are trying to solve is a pretty old one.

Re: [PATCH] brcmfmac: implement more accurate skb tracking

On 26-9-2016 14:13, Rafał Miłecki wrote: > On 26 September 2016 at 13:46, Arend Van Spriel > <arend.vanspr...@broadcom.com> wrote: >> On 26-9-2016 12:23, Rafał Miłecki wrote: >>> From: Rafał Miłecki <ra...@milecki.pl> >>> >>> We need to track 8

Re: wl1251 & mac address & calibration data

On 22-11-2016 18:05, Pali Rohár wrote: > On Tuesday 22 November 2016 17:14:28 Michal Kazior wrote: >> On 22 November 2016 at 16:31, Pali Rohár wrote: >>> On Tuesday 22 November 2016 16:22:57 Michal Kazior wrote: On 21 November 2016 at 16:51, Pali Rohár

Re: [PATCH 1/1] orinoco: fix improper return value

On 8-12-2016 1:40, Pan Bian wrote: > Function orinoco_ioctl_commit() returns 0 (indicates success) when the > call to orinoco_lock() fails. Thus, the return value is inconsistent with > the execution status. It may be better to return "-EBUSY" when the call > to orinoco_lock() fails. > >

Re: [PATCH 8/8] Makefile: drop -D__CHECK_ENDIAN__ from cflags

| 2 -- > drivers/net/wireless/ath/wil6210/Makefile | 2 -- > drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile | 2 -- > drivers/net/wireless/broadcom/brcm80211/brcmsmac/Makefile | 1 - For brcm80211 drivers: Acked-by: Arend van Spriel <arend.vanspr...@broadcom.com> Regards, Arend

Re: wl1251 & mac address & calibration data

On 15-12-2016 16:33, Pali Rohár wrote: > On Thu Dec 15 09:18:44 2016 Kalle Valo wrote: >> (Adding Luis because he has been working on request_firmware() lately) >> >> Pali Rohár writes: >> > So no, there is no argument against... request_firmware()

Re: wl1251 & mac address & calibration data

On 18-12-2016 13:09, Pali Rohár wrote: > On Sunday 18 December 2016 12:54:00 Arend Van Spriel wrote: >> On 18-12-2016 12:04, Pali Rohár wrote: >>> On Sunday 18 December 2016 11:49:53 Arend Van Spriel wrote: >>>> On 16-12-2016 11:40, Pali Rohár wrote: >>>

Re: wl1251 & mac address & calibration data

On 16-12-2016 11:40, Pali Rohár wrote: > On Friday 16 December 2016 08:25:44 Daniel Wagner wrote: >> On 12/16/2016 03:03 AM, Luis R. Rodriguez wrote: >>> For the new API a solution for "fallback mechanisms" should be >>> clean though and I am looking to stay as far as possible from the >>>

Re: wl1251 & mac address & calibration data

On 18-12-2016 12:04, Pali Rohár wrote: > On Sunday 18 December 2016 11:49:53 Arend Van Spriel wrote: >> On 16-12-2016 11:40, Pali Rohár wrote: >>> On Friday 16 December 2016 08:25:44 Daniel Wagner wrote: >>>> On 12/16/2016 03:03 AM, Luis R. Rodriguez wrote: &g

Re: [PATCH] brcmfmac: fix spelling mistakes on "Ivalid"

On 23-12-2016 1:43, Colin King wrote: > From: Colin Ian King <colin.k...@canonical.com> > > Trivial fixes to spelling mistake "Ivalid" to "Invalid" in > brcmf_err error messages. Acked-by: Arend van Spriel <arend.vanspr...@broadcom.com> > Signed-o

Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data

On 24-12-2016 17:52, Pali Rohár wrote: > NVS calibration data for wl1251 are model specific. Every one device with > wl1251 chip has different and calibrated in factory. > > Not all wl1251 chips have own EEPROM where are calibration data stored. And > in that case there is no "standard" place.

Re: [PATCH 2/2] net: wireless: fix to uses struct

On 21-12-2016 23:23, Ozgur Karatas wrote: > > The patch fixed to struct uses in reg.c, I think doesn't need to be use to > "struct". > There is dataype not have to logical link and each is different definitons. > > I'm undecided on this patch. I compiled and didn't to errors. There must be

Re: [4.9.13] brcmf use-after-free on resume

+ Johannes On 6-3-2017 11:48, Arend Van Spriel wrote: > + linux-wireless > > On 6-3-2017 8:04, Daniel J Blueman wrote: >> When resuming from suspend with a BCM43602 on Ubuntu 16.04 with >> 4.9.13, we see use after free [1]. >> >> We see the struct cfg80211_o

Re: [4.9.13] brcmf use-after-free on resume

On 27-3-2017 11:24, Arend Van Spriel wrote: > + Johannes > > On 6-3-2017 11:48, Arend Van Spriel wrote: >> + linux-wireless >> >> On 6-3-2017 8:04, Daniel J Blueman wrote: >>> When resuming from suspend with a BCM43602 on Ubuntu 16.04 with >>> 4.9.

Re: [PATCH] brcm80211: brcmfmac: Ensure that incoming skb's are writable

+ linux-wireless On 4/20/2017 1:16 PM, James Hughes wrote: The driver was adding header information to incoming skb without ensuring the head was uncloned and hence writable. skb_cow_head has been used to ensure they are writable, however, this required some changes to error handling to ensure

Re: [PATCH] brcm80211: brcmfmac: Ensure that incoming skb's are writable

On 4/20/2017 2:09 PM, James Hughes wrote: On 20 April 2017 at 12:31, Kalle Valo wrote: + linux-wireless James Hughes writes: The driver was adding header information to incoming skb without ensuring the head was uncloned and hence

Re: [PATCH] brcm80211: brcmfmac: Ensure that incoming skb's are writable

On 21-4-2017 11:22, James Hughes wrote: > On 20 April 2017 at 20:48, Arend van Spriel > <arend.vanspr...@broadcom.com> wrote: >> + linux-wireless >> >> On 4/20/2017 1:16 PM, James Hughes wrote: >>> >>> The driver was adding header informati

Re: [PATCH] 4.9.13 brcmfmac: fix use-after-free on resume

On 13-3-2017 10:33, Arend Van Spriel wrote: > On 6-3-2017 15:50, Daniel J Blueman wrote: >> On 6 March 2017 at 21:00, Arend Van Spriel <arend.vanspr...@broadcom.com> >> wrote: >>> + linux-wireless >>> >>> On 6-3-2017 8:14, Daniel J Blueman wrot

Re: [PATCH] 4.9.13 brcmfmac: fix use-after-free on resume

On 6-3-2017 15:50, Daniel J Blueman wrote: > On 6 March 2017 at 21:00, Arend Van Spriel <arend.vanspr...@broadcom.com> > wrote: >> + linux-wireless >> >> On 6-3-2017 8:14, Daniel J Blueman wrote: >>> KASAN reported 'struct wireless_dev wdev' was read afte

Re: [PATCH 07/26] brcmsmac: reduce stack size with KASAN

On 6-3-2017 11:38, Arnd Bergmann wrote: > On Mon, Mar 6, 2017 at 10:16 AM, Arend Van Spriel > <arend.vanspr...@broadcom.com> wrote: >> On 2-3-2017 17:38, Arnd Bergmann wrote: >>> The wlc_phy_table_write_nphy/wlc_phy_table_read_nphy functions always put >>&g

Re: [PATCH] 4.9.13 brcmfmac: fix use-after-free on resume

+ linux-wireless On 6-3-2017 8:14, Daniel J Blueman wrote: > KASAN reported 'struct wireless_dev wdev' was read after being freed. > Fix by freeing after the access. I would rather like to see the KASAN report, because something is off here. This function is called with wdev as a parameter so

Re: [4.9.13] brcmf use-after-free on resume

+ linux-wireless On 6-3-2017 8:04, Daniel J Blueman wrote: > When resuming from suspend with a BCM43602 on Ubuntu 16.04 with > 4.9.13, we see use after free [1]. > > We see the struct cfg80211_ops is accessed in the resume path, after > it was previously freed: > > (gdb) list

Re: [PATCH 08/26] brcmsmac: make some local variables 'static const' to reduce stack size

On 7-3-2017 10:44, Kalle Valo wrote: > Arnd Bergmann <a...@arndb.de> writes: > >> On Mon, Mar 6, 2017 at 5:19 PM, Kalle Valo <kv...@codeaurora.org> wrote: >>> Arend Van Spriel <arend.vanspr...@broadcom.com> writes: >>> >>>> On 2-3-20

Re: [PATCH 09/26] brcmsmac: split up wlc_phy_workarounds_nphy

me. > > I'm leaving the original indentation to make the review easier. Thanks ;-) Acked-by: Arend van Spriel <arend.vanspr...@broadcom.com> > Signed-off-by: Arnd Bergmann <a...@arndb.de> > --- > .../broadcom/brcm80211/brcmsmac/phy/phy_n.c| 178 > +

Re: [PATCH 08/26] brcmsmac: make some local variables 'static const' to reduce stack size

:17138:1: warning: the frame size of > 2864 bytes is larger than 2048 bytes [-Wframe-larger-than=] > > Here, I'm reducing the stack size by marking as many local variables as > 'static const' as I can without changing the actual code. Acked-by: Arend van Spriel <arend.vanspr

Re: [PATCH 10/26] brcmsmac: reindent split functions

e intended here. Acked-by: Arend van Spriel <arend.vanspr...@broadcom.com> > Signed-off-by: Arnd Bergmann <a...@arndb.de> > --- > .../broadcom/brcm80211/brcmsmac/phy/phy_n.c| 1507 > +--- > 1 file changed, 697 insertions(+), 810 deletions(-) >

Re: [PATCH 07/26] brcmsmac: reduce stack size with KASAN

On 2-3-2017 17:38, Arnd Bergmann wrote: > The wlc_phy_table_write_nphy/wlc_phy_table_read_nphy functions always put an > object > on the stack, which will each require a redzone with KASAN and lead to > possible > stack overflow: > > drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:

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.

  1   2   >