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: [PATCH] brcmfmac: only lock and unlock fws if fws is not null

On 12/02/2015 12:45 PM, Colin King wrote: From: Colin Ian King There is a null ptr check for fws to set bcmc_credit_check, however, there a lock and unlock on fws should only performed if fwts is also not null to also avoid a potential null pointer deference. Acked-by: Arend van Spriel

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: [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 writes: 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

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

On 11/22/2015 06:23 PM, Kalle Valo wrote: Arend van Spriel writes: 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

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 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 --- I would

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 use the new location.

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] 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 Signed-off-by: Julia Lawall --- drivers/net/wireless/brcm80211/brcmfmac/bus.h |2 +- drivers/net

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] net: brcm80211: Delete an unnecessary check before the function call "release_firmware"

the Coccinelle software. Acked-by: Arend van Spriel Signed-off-by: Markus Elfring --- drivers/net/wireless/brcm80211/brcmfmac/firmware.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/net/wireless/brcm80211/brcmfmac/firmware.c b/drivers/net/wireless/brcm80211/brcmfmac

Re: [PATCH] net: brcm80211: Delete an unnecessary check before the function call "release_firmware"

issue was detected by using the Coccinelle software. Acked-by: Arend van Spriel <ar...@broadcom.com> Signed-off-by: Markus Elfring <elfr...@users.sourceforge.net> --- drivers/net/wireless/brcm80211/brcmfmac/firmware.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff -

Re: Problems loading firmware using built-in drivers with kernels that use initramfs.

On 10/16/2015 09:35 PM, Luis R. Rodriguez wrote: On Thu, Sep 03, 2015 at 10:33:51AM -0700, Dmitry Torokhov wrote: On Thu, Sep 3, 2015 at 10:23 AM, Arend van Spriel wrote: On 09/03/2015 01:46 AM, Luis R. Rodriguez wrote: On Wed, Sep 2, 2015 at 4:29 PM, Dmitry Torokhov wrote: On Wed, Sep 2

Re: Problems loading firmware using built-in drivers with kernels that use initramfs.

On 10/16/2015 09:35 PM, Luis R. Rodriguez wrote: On Thu, Sep 03, 2015 at 10:33:51AM -0700, Dmitry Torokhov wrote: On Thu, Sep 3, 2015 at 10:23 AM, Arend van Spriel <ar...@broadcom.com> wrote: On 09/03/2015 01:46 AM, Luis R. Rodriguez wrote: On Wed, Sep 2, 2015 at 4:29 PM, Dmitry To

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. > >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] 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] 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] 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] brcm80211:Use proper skb wrapper function in the function brcmf_sdio_txpkt_postp

On 10/03/2015 06:24 AM, Nicholas Krause wrote: This uses the proper skb wrapper function sk_unlink in the function brcmf_sdio_txpkt_postp to properly protect against concurrent users accessing this skb_buff pointer or skb_buff_head pointer by locking the spinlock as part of the passed

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] brcm80211:Use proper skb wrapper function in the function brcmf_sdio_txpkt_postp

On 10/03/2015 06:24 AM, Nicholas Krause wrote: This uses the proper skb wrapper function sk_unlink in the function brcmf_sdio_txpkt_postp to properly protect against concurrent users accessing this skb_buff pointer or skb_buff_head pointer by locking the spinlock as part of the passed

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: Problems loading firmware using built-in drivers with kernels that use initramfs.

On 09/03/2015 01:46 AM, Luis R. Rodriguez wrote: On Wed, Sep 2, 2015 at 4:29 PM, Dmitry Torokhov wrote: On Wed, Sep 2, 2015 at 4:22 PM, Luis R. Rodriguez wrote: On Wed, Sep 02, 2015 at 04:13:51PM -0700, Dmitry Torokhov wrote: On Wed, Sep 2, 2015 at 2:03 PM, Arend van Spriel wrote: Ok. So

Re: Problems loading firmware using built-in drivers with kernels that use initramfs.

Sep 2, 2015 at 2:03 PM, Arend van Spriel <ar...@broadcom.com> wrote: Ok. So some background why we need it in brcm80211 drivers. So as a wireless network device driver the answer we got when asking for an event to load firware is upon IF_UP for a registered net device. Because we try to do thi

Re: Problems loading firmware using built-in drivers with kernels that use initramfs.

On 09/02/2015 08:58 PM, Luis R. Rodriguez wrote: On Wed, Sep 02, 2015 at 02:13:49PM +0200, Arend van Spriel wrote: On 09/02/2015 02:09 PM, Arend van Spriel wrote: On 09/02/2015 03:19 AM, Luis R. Rodriguez wrote: On Mon, Aug 31, 2015 at 10:21:34PM +0800, Ming Lei wrote: On Sun, Aug 30, 2015

Re: Problems loading firmware using built-in drivers with kernels that use initramfs.

On 09/02/2015 02:09 PM, Arend van Spriel wrote: On 09/02/2015 03:19 AM, Luis R. Rodriguez wrote: On Mon, Aug 31, 2015 at 10:21:34PM +0800, Ming Lei wrote: On Sun, Aug 30, 2015 at 4:25 PM, Arend van Spriel wrote: Does this mean a built-in driver can not get firmware from initramfs or built

Re: Problems loading firmware using built-in drivers with kernels that use initramfs.

On 09/02/2015 03:19 AM, Luis R. Rodriguez wrote: On Mon, Aug 31, 2015 at 10:21:34PM +0800, Ming Lei wrote: On Sun, Aug 30, 2015 at 4:25 PM, Arend van Spriel wrote: Does this mean a built-in driver can not get firmware from initramfs or built in the kernel early. Seems a bit too aggressive

Re: Problems loading firmware using built-in drivers with kernels that use initramfs.

On 09/02/2015 08:58 PM, Luis R. Rodriguez wrote: On Wed, Sep 02, 2015 at 02:13:49PM +0200, Arend van Spriel wrote: On 09/02/2015 02:09 PM, Arend van Spriel wrote: On 09/02/2015 03:19 AM, Luis R. Rodriguez wrote: On Mon, Aug 31, 2015 at 10:21:34PM +0800, Ming Lei wrote: On Sun, Aug 30, 2015

Re: Problems loading firmware using built-in drivers with kernels that use initramfs.

On 09/02/2015 03:19 AM, Luis R. Rodriguez wrote: On Mon, Aug 31, 2015 at 10:21:34PM +0800, Ming Lei wrote: On Sun, Aug 30, 2015 at 4:25 PM, Arend van Spriel <ar...@broadcom.com> wrote: Does this mean a built-in driver can not get firmware from initramfs or built in the kernel early.

Re: Problems loading firmware using built-in drivers with kernels that use initramfs.

On 09/02/2015 02:09 PM, Arend van Spriel wrote: On 09/02/2015 03:19 AM, Luis R. Rodriguez wrote: On Mon, Aug 31, 2015 at 10:21:34PM +0800, Ming Lei wrote: On Sun, Aug 30, 2015 at 4:25 PM, Arend van Spriel <ar...@broadcom.com> wrote: Does this mean a built-in driver can not get firmwar

Re: Problems loading firmware using built-in drivers with kernels that use initramfs.

On 08/29/2015 12:38 PM, Ming Lei wrote: On Sat, 29 Aug 2015 10:50:22 +0200 Arend van Spriel wrote: On 08/29/2015 09:11 AM, Takashi Iwai wrote: On Sat, 29 Aug 2015 06:09:01 +0200, Ming Lei wrote: On Sat, Aug 29, 2015 at 9:11 AM, Luis R. Rodriguez wrote: On Thu, Aug 27, 2015 at 08:55:13AM

Re: Problems loading firmware using built-in drivers with kernels that use initramfs.

On 08/29/2015 12:38 PM, Ming Lei wrote: On Sat, 29 Aug 2015 10:50:22 +0200 Arend van Spriel ar...@broadcom.com wrote: On 08/29/2015 09:11 AM, Takashi Iwai wrote: On Sat, 29 Aug 2015 06:09:01 +0200, Ming Lei wrote: On Sat, Aug 29, 2015 at 9:11 AM, Luis R. Rodriguez mcg...@suse.com wrote

Re: Problems loading firmware using built-in drivers with kernels that use initramfs.

On 08/29/2015 09:11 AM, Takashi Iwai wrote: On Sat, 29 Aug 2015 06:09:01 +0200, Ming Lei wrote: On Sat, Aug 29, 2015 at 9:11 AM, Luis R. Rodriguez wrote: On Thu, Aug 27, 2015 at 08:55:13AM +0800, Ming Lei wrote: On Thu, Aug 27, 2015 at 2:07 AM, Linus Torvalds wrote: On Wed, Aug 26, 2015

Re: Problems loading firmware using built-in drivers with kernels that use initramfs.

On 08/29/2015 09:11 AM, Takashi Iwai wrote: On Sat, 29 Aug 2015 06:09:01 +0200, Ming Lei wrote: On Sat, Aug 29, 2015 at 9:11 AM, Luis R. Rodriguez mcg...@suse.com wrote: On Thu, Aug 27, 2015 at 08:55:13AM +0800, Ming Lei wrote: On Thu, Aug 27, 2015 at 2:07 AM, Linus Torvalds

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 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

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

On 08/26/2015 12:22 PM, Thierry Reding wrote: From: Thierry Reding 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: In function

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: Question on adding a firmware ihex file in the kernel source

On 08/20/2015 11:46 PM, Murali Karicheri wrote: All, Please help me understand the procedure to add a firmware ihex file to kernel source tree under firmware/ folder. The README.AddingFirmware file explains that file should be added to

Re: Question on adding a firmware ihex file in the kernel source

On 08/20/2015 11:46 PM, Murali Karicheri wrote: All, Please help me understand the procedure to add a firmware ihex file to kernel source tree under firmware/ folder. The README.AddingFirmware file explains that file should be added to

Re: [PATCHv2 5/5] staging: wilc1000: replace MALLOC_WILC_BUFFER() macro to avoid possible memory leak

On 08/17/2015 09:28 PM, Raphaël Beamonte wrote: The MACRO_WILC_BUFFER() macro was using a return statement, and didn't Probable MACRO_WILC_BUFFER should be MALLOC_WILC_BUFFER here. take care of possible memory leaks and subsequent bugs when it was failing after succeeding some allocations.

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: [PATCHv2 5/5] staging: wilc1000: replace MALLOC_WILC_BUFFER() macro to avoid possible memory leak

On 08/17/2015 09:28 PM, Raphaël Beamonte wrote: The MACRO_WILC_BUFFER() macro was using a return statement, and didn't Probable MACRO_WILC_BUFFER should be MALLOC_WILC_BUFFER here. take care of possible memory leaks and subsequent bugs when it was failing after succeeding some allocations.

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

. 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 Cc: Arend van Spriel Cc: "Franky (Zhenhui) Lin" Cc: Hante Me

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 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 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 v2] brcmsmac: Use kstrdup to simplify code

-by: Arend van Spriel Signed-off-by: Christophe JAILLET --- 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/mac80211_if.c b/drivers/net/wireless/brcm80211

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

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 Cc: Arend van Spriel Cc: "Franky (Zhenhui) Lin" Cc: Hante Meuleman Cc: Kalle Valo Cc: Pieter-Paul Giesberts Cc: Daniel Kim

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

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

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: Interaction issue of intel wifi and broadcom bluetooth - it appears that nobody feels responsible for doing something

+ Marcel, wireless list, and bt list. On 06/05/15 07:12, Jonas Thiem wrote: Hi Jeremiah, thanks for responding! I did have my mobile phone very nearby also connected to the bluetooth headphones while my laptop was still using 11n wifi. I didn't have any noticeable issues with bluetooth there.

Re: Interaction issue of intel wifi and broadcom bluetooth - it appears that nobody feels responsible for doing something

+ Marcel, wireless list, and bt list. On 06/05/15 07:12, Jonas Thiem wrote: Hi Jeremiah, thanks for responding! I did have my mobile phone very nearby also connected to the bluetooth headphones while my laptop was still using 11n wifi. I didn't have any noticeable issues with bluetooth there.

Re: linux-next: build failure after merge of the wireless-drivers-next tree

Crap. struct acpi_device details are only known when CONFIG_ACPI is set. The attached patch should fix the issue. Regards, Arend >From fd56b4446c613ceec15c11758ed817d13efb9bba Mon Sep 17 00:00:00 2001 From: Arend van Spriel Date: Wed, 27 May 2015 10:48:46 +0200 Subject: [PATCH] brcmfmac: fi

Re: linux-next: build failure after merge of the wireless-drivers-next tree

acpi_device details are only known when CONFIG_ACPI is set. The attached patch should fix the issue. Regards, Arend From fd56b4446c613ceec15c11758ed817d13efb9bba Mon Sep 17 00:00:00 2001 From: Arend van Spriel ar...@broadcom.com Date: Wed, 27 May 2015 10:48:46 +0200 Subject: [PATCH] brcmfmac: fix invalid

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/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: [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 v3] brcmfmac: prohibit ACPI power management for brcmfmac driver

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 informs ACPI not to manage WiFi chip's power state. Signed-off-by: Zhonghui Fu Acked-by: Arend van Spriel --- Changes

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: [PATCH resend] README: clarify redistribution requirements covering patents

On 05/14/15 19:56, Luis R. Rodriguez wrote: From: "Luis R. Rodriguez" Firmware licenses on linux-firmware should include an implicit or explicit patent grant to end users for full device operation otherwise it would start making linux-firmware useless for many Linux distributions which have

Re: [PATCH resend] README: clarify redistribution requirements covering patents

On 05/14/15 19:56, Luis R. Rodriguez wrote: From: Luis R. Rodriguezmcg...@suse.com Firmware licenses on linux-firmware should include an implicit or explicit patent grant to end users for full device operation otherwise it would start making linux-firmware useless for many Linux distributions

Re: 4.1-rc2: build issue with duplicate redefinition of _PAGE_GLOBAL_SHIFT

On 05/13/15 21:19, Jonas Gorski wrote: Hi Arend, On Wed, May 13, 2015 at 8:43 PM, Arend van Spriel wrote: For our upstream brcm80211 drivers we build for a number of architectures including MIPS. In recent builds we get an error/warning: CC [M] drivers/net/wireless/brcm80211/brcmfmac

4.1-rc2: build issue with duplicate redefinition of _PAGE_GLOBAL_SHIFT

For our upstream brcm80211 drivers we build for a number of architectures including MIPS. In recent builds we get an error/warning: CC [M] drivers/net/wireless/brcm80211/brcmfmac/cfg80211.o In file included from ./arch/mips/include/asm/io.h:27:0, from

4.1-rc2: build issue with duplicate redefinition of _PAGE_GLOBAL_SHIFT

For our upstream brcm80211 drivers we build for a number of architectures including MIPS. In recent builds we get an error/warning: CC [M] drivers/net/wireless/brcm80211/brcmfmac/cfg80211.o In file included from ./arch/mips/include/asm/io.h:27:0, from

Re: 4.1-rc2: build issue with duplicate redefinition of _PAGE_GLOBAL_SHIFT

On 05/13/15 21:19, Jonas Gorski wrote: Hi Arend, On Wed, May 13, 2015 at 8:43 PM, Arend van Sprielar...@broadcom.com wrote: For our upstream brcm80211 drivers we build for a number of architectures including MIPS. In recent builds we get an error/warning: CC [M]

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

e wonder whether a mistake has been made. So I would prefer to have the assignment separate for the if statement. For the update patch you may add: Acked-by: Arend van Spriel Regards, Arend + adev->flags.power_manageable = 0; + /* Consume func num 1 but

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

here it makes someone reading the code wonder whether a mistake has been made. So I would prefer to have the assignment separate for the if statement. For the update patch you may add: Acked-by: Arend van Spriel ar...@broadcom.com Regards, Arend + adev-flags.power_manageable = 0

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 2/2] brcmfmac: keep WiFi chip's power during system suspension

On 04/27/15 07:06, Fu, Zhonghui wrote: Need to keep the power supply for WiFi chip during system suspension. Otherwise, the context of WiFi chip will be lost. I already submitted a patch doing exactly the same thing [1] Regards, Arend [1] https://patchwork.kernel.org/patch/6217391/

Re: [PATCH 2/2] brcmfmac: keep WiFi chip's power during system suspension

On 04/27/15 07:06, Fu, Zhonghui wrote: Need to keep the power supply for WiFi chip during system suspension. Otherwise, the context of WiFi chip will be lost. I already submitted a patch doing exactly the same thing [1] Regards, Arend [1] https://patchwork.kernel.org/patch/6217391/

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: Broadcom 43340 module on iMX6DL

On 04/24/15 21:03, Arend van Spriel wrote: On 04/24/15 20:24, John Tobias wrote: Hi Arend, Apologize for the confusion. I am asking the repo for the device driver for 43340. Looking at the link you sent, it's more userspace support and didn't see the device driver there... crap. you

Re: Broadcom 43340 module on iMX6DL

On 04/24/15 21:03, Arend van Spriel wrote: On 04/24/15 20:24, John Tobias wrote: Hi Arend, Apologize for the confusion. I am asking the repo for the device driver for 43340. Looking at the link you sent, it's more userspace support and didn't see the device driver there... crap. you

Re: Broadcom 43340 module on iMX6DL

a kernel repo. There are some on the site I referred to, but you may need to contact Freescale whether they provide it publicly like on github or so. Regards, Arend Regards, John On Fri, Apr 24, 2015 at 11:14 AM, Arend van Spriel wrote: On 04/24/15 19:49, John Tobias wrote: Hi Arend, I

Re: Broadcom 43340 module on iMX6DL

for your device. Regards, Arend Regards, John On Fri, Apr 24, 2015 at 1:20 AM, Arend van Spriel wrote: On 04/24/15 03:04, John Tobias wrote: Btw, where I could get a copy of the latest driver?. The open-source bcmdhd is in AOSP [1]. I would stick to the android release branch you

Re: Broadcom 43340 module on iMX6DL

On 04/24/15 02:57, John Stultz wrote: On Thu, Apr 23, 2015 at 12:00 PM, Arend van Spriel wrote: By the name of the file I suspected you did. Personally, I verified the firmware works on 43341. John Stultz tested both 43340 and 43341 with this firmware. Minor correction here, I only tested

Re: Broadcom 43340 module on iMX6DL

/ Regards, John On Thu, Apr 23, 2015 at 5:59 PM, John Tobias wrote: Hi John, Is it possible to have a copy of the firmware for 43340?. Regards, John On Thu, Apr 23, 2015 at 5:57 PM, John Stultz wrote: On Thu, Apr 23, 2015 at 12:00 PM, Arend van Spriel wrote: By the name of the file I

Re: Broadcom 43340 module on iMX6DL

On 04/24/15 03:04, John Tobias wrote: Btw, where I could get a copy of the latest driver?. The open-source bcmdhd is in AOSP [1]. I would stick to the android release branch you are running on your device. Regards, Arend [1] https://android.googlesource.com/platform/hardware/broadcom/wlan/

Re: Broadcom 43340 module on iMX6DL

On 04/24/15 02:57, John Stultz wrote: On Thu, Apr 23, 2015 at 12:00 PM, Arend van Sprielar...@broadcom.com wrote: By the name of the file I suspected you did. Personally, I verified the firmware works on 43341. John Stultz tested both 43340 and 43341 with this firmware. Minor correction

Re: Broadcom 43340 module on iMX6DL

On 04/24/15 19:49, John Tobias wrote: Hi Arend, I am not pretty sure if the brcm43340 driver for android is the latest one. May I know repo?. Not sure what you are asking. I gave the url. Did you try using the brcmfmac4334-sdio.bin firmware file. I would like to know if that one works for

Re: Broadcom 43340 module on iMX6DL

On 04/24/15 20:24, John Tobias wrote: Hi Arend, Apologize for the confusion. I am asking the repo for the device driver for 43340. Looking at the link you sent, it's more userspace support and didn't see the device driver there... crap. you are right. it is userspace and firmware. You need a

Re: Broadcom 43340 module on iMX6DL

:0xa94c rev:0x2 I will have to check whether that is correct revision for this firmware. I can check. You could try the brcmfmac4334-sdio.bin file instead. All bets are off, but it can not get worse. ;-) Gr. AvS Regards, John On Thu, Apr 23, 2015 at 11:39 AM, Arend van Spriel wrote

Re: Broadcom 43340 module on iMX6DL

On 04/23/15 20:10, John Tobias wrote: Hello Guys, I am trying to use the bcmdhd wifi driver 43340 module on iMX6DL processor using kernel Freescale GA (3.10.53). I am having an issue with the sdio registration. I would like to know if anyone here had the same issue and how did you solve it?.

Re: Broadcom 43340 module on iMX6DL

On 04/23/15 20:10, John Tobias wrote: Hello Guys, I am trying to use the bcmdhd wifi driver 43340 module on iMX6DL processor using kernel Freescale GA (3.10.53). I am having an issue with the sdio registration. I would like to know if anyone here had the same issue and how did you solve it?.

Re: Broadcom 43340 module on iMX6DL

+ John Stultz On 04/23/15 20:44, John Tobias wrote: Thanks Dmitry for the info. Arend: Yes, it's an android... Here's the info: 00060e80 de 02 f0 18 8c 00 e8 5e 8f 00 37 a3 00 e0 5e 8a |...^..7...^.| 00060e90 f4 77 a2 00 02 de 02 f0 00 00 01 bc 60 03 00 07 |.w..`...|

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