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] 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 wrote: >> On 26 September 2016 at 13:46, Arend Van Spriel >> wrote: >>> On 26-9-2016 12:23, Rafał Miłecki wrote: >>>> From: Rafał Miłecki >>>> >>>&

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 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 >> wrote: >>> >>> On 26-9-2016 12:23, Rafał Miłecki wrote: >>>> >>>> From: Rafał M

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

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 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. The problem is that

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 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 > (BCDC). > > So

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] brcmfmac: fix memory leak in brcmf_fill_bss_param

On 21-9-2016 8:23, Rafał Miłecki wrote: > From: Rafał Miłecki > > 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 > Signed-off-by: Rafał Miłecki &g

Re: [v2] bcma: use of_dma_configure() to set initial dma mask

On 5-9-2016 17:26, Arnd Bergmann wrote: > On Saturday, September 3, 2016 2:08:19 PM CEST Kalle Valo wrote: >> Arnd Bergmann wrote: >>> While fixing another bug, I noticed that bcma manually sets up >>> a dma_mask pointer for its child devices. We have a generic >>> helper for

Re: [v2] bcma: use of_dma_configure() to set initial dma mask

On 5-9-2016 17:26, Arnd Bergmann wrote: > On Saturday, September 3, 2016 2:08:19 PM CEST Kalle Valo wrote: >> Arnd Bergmann wrote: >>> While fixing another bug, I noticed that bcma manually sets up >>> a dma_mask pointer for its child devices. We have a generic >>> helper for that now, which

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 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 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 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 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 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 making any functional changes.

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

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: [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 sent >>> fw request") >>> Acked-by: Rafał Miłecki >>> >>>

Re: [PATCH v2 8/8] p54: convert to sysdata API

On 10-8-2016 20:32, Luis R. Rodriguez wrote: > On Fri, Jun 17, 2016 at 08:35:03PM +0200, Luis R. Rodriguez wrote: >> On Thu, Jun 16, 2016 at 05:09:30PM -1000, Linus Torvalds wrote: >>> On Thu, Jun 16, 2016 at 3:36 PM, Luis R. Rodriguez >>> wrote: Reason this could

Re: [PATCH v2 8/8] p54: convert to sysdata API

On 10-8-2016 20:32, Luis R. Rodriguez wrote: > On Fri, Jun 17, 2016 at 08:35:03PM +0200, Luis R. Rodriguez wrote: >> On Thu, Jun 16, 2016 at 05:09:30PM -1000, Linus Torvalds wrote: >>> On Thu, Jun 16, 2016 at 3:36 PM, Luis R. Rodriguez >>> wrote: Reason this could not wait is folks

Re: [RFC v0 7/8] Input: ims-pcu: use firmware_stat instead of completion

On 03-08-16 17:35, Dmitry Torokhov wrote: >> In my opinion the kernel should provide functionality to user-space and >> > user-space providing functionality to the kernel should be avoided. > Why? We have bunch of stuff running in userspace for the kernel. Fuse > for example. I am sure there are

Re: [RFC v0 7/8] Input: ims-pcu: use firmware_stat instead of completion

On 03-08-16 17:35, Dmitry Torokhov wrote: >> In my opinion the kernel should provide functionality to user-space and >> > user-space providing functionality to the kernel should be avoided. > Why? We have bunch of stuff running in userspace for the kernel. Fuse > for example. I am sure there are

Re: [RFC v0 7/8] Input: ims-pcu: use firmware_stat instead of completion

On 03-08-16 09:42, Dmitry Torokhov wrote: > On Tue, Aug 2, 2016 at 12:41 AM, Luis R. Rodriguez wrote: >> On Tue, Aug 02, 2016 at 08:53:55AM +0200, Daniel Wagner wrote: >>> On 08/02/2016 08:34 AM, Luis R. Rodriguez wrote: On Tue, Aug 02, 2016 at 07:49:19AM +0200, Daniel

Re: [RFC v0 7/8] Input: ims-pcu: use firmware_stat instead of completion

On 03-08-16 09:42, Dmitry Torokhov wrote: > On Tue, Aug 2, 2016 at 12:41 AM, Luis R. Rodriguez wrote: >> On Tue, Aug 02, 2016 at 08:53:55AM +0200, Daniel Wagner wrote: >>> On 08/02/2016 08:34 AM, Luis R. Rodriguez wrote: On Tue, Aug 02, 2016 at 07:49:19AM +0200, Daniel Wagner wrote: >>

Re: [RFC v0 7/8] Input: ims-pcu: use firmware_stat instead of completion

+ Luis (again) ;-) On 29-07-16 08:13, Daniel Wagner wrote: > On 07/28/2016 09:01 PM, Bjorn Andersson wrote: >> On Thu 28 Jul 11:33 PDT 2016, Dmitry Torokhov wrote: >> >>> On Thu, Jul 28, 2016 at 09:55:11AM +0200, Daniel Wagner wrote: From: Daniel Wagner >>

Re: [RFC v0 7/8] Input: ims-pcu: use firmware_stat instead of completion

+ Luis (again) ;-) On 29-07-16 08:13, Daniel Wagner wrote: > On 07/28/2016 09:01 PM, Bjorn Andersson wrote: >> On Thu 28 Jul 11:33 PDT 2016, Dmitry Torokhov wrote: >> >>> On Thu, Jul 28, 2016 at 09:55:11AM +0200, Daniel Wagner wrote: From: Daniel Wagner >> [..] >>> >>> Do not quite

side-effect when enabling CONFIG_MODULES

A question for whoever can provide the answer. I have a kernel defconfig with everything built-in. However, I want to compile a driver module against it for testing. So I enabled CONFING_MODULES, but as a side-effect several implicitly selected config options changed from CONFIG_FOO=y to

side-effect when enabling CONFIG_MODULES

A question for whoever can provide the answer. I have a kernel defconfig with everything built-in. However, I want to compile a driver module against it for testing. So I enabled CONFING_MODULES, but as a side-effect several implicitly selected config options changed from CONFIG_FOO=y to

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 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 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 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] 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] 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 > 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 allow deleting them. >>> &g

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: [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] 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] 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: 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: 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 > Signed-off-by: Rafał Miłecki > --- > .../broadcom/brcm80211/brcmfmac/cfg80211.c | 37 > ++ > 1 file changed, 16 insertions(

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: 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 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: [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: building and using modules on arm64 hikey board

On 01-06-16 11:01, Arend Van Spriel wrote: > > > On 31-5-2016 22:58, Ard Biesheuvel wrote: >> On 31 May 2016 at 22:24, Dmitry Shmidt <dimitr...@google.com> wrote: >>> On Mon, May 30, 2016 at 4:30 AM, Ard Biesheuvel >>> <ard.biesheu...@linaro.org>

Re: building and using modules on arm64 hikey board

On 01-06-16 11:01, Arend Van Spriel wrote: > > > On 31-5-2016 22:58, Ard Biesheuvel wrote: >> On 31 May 2016 at 22:24, Dmitry Shmidt wrote: >>> On Mon, May 30, 2016 at 4:30 AM, Ard Biesheuvel >>> wrote: >>>> This is likely caused by the fact that t

Re: building and using modules on arm64 hikey board

LD_CFLAGS_MODULE+= -mcmodel=large endif And that Kconfig item is indeed set. Regards, Arend >>>> On 30 mei 2016, at 12:21, Arend Van Spriel <arend.vanspr...@broadcom.com> >>>> wrote: >>>> >>>> I got myself an arm64 HiKey board from LeMaker

Re: building and using modules on arm64 hikey board

module I noticed it uses command line parameter -mcmodel=large so I suppose that could be how I ended up with PREL32. In arch/arm64/Makefile there is this: ifeq ($(CONFIG_ARM64_ERRATUM_843419), y) KBUILD_CFLAGS_MODULE += -mcmodel=large endif And that Kconfig item is indeed set. Regards,

Re: building and using modules on arm64 hikey board

d line twice. To no avail so that ain't working. Regards, Arend >> On 30 mei 2016, at 12:21, Arend Van Spriel <arend.vanspr...@broadcom.com> >> wrote: >> >> I got myself an arm64 HiKey board from LeMaker and build an Android AOSP >> image for it (see

Re: building and using modules on arm64 hikey board

d line twice. To no avail so that ain't working. Regards, Arend >> On 30 mei 2016, at 12:21, Arend Van Spriel >> wrote: >> >> I got myself an arm64 HiKey board from LeMaker and build an Android AOSP >> image for it (see [1]). For development I would like to use &g

building and using modules on arm64 hikey board

I got myself an arm64 HiKey board from LeMaker and build an Android AOSP image for it (see [1]). For development I would like to use CONFIG_MODULES. However, when I try to insmod the build module I get: [ 287.903653] module cfg80211: overflow in relocation type 261 val ffbffc006530 Looking

building and using modules on arm64 hikey board

I got myself an arm64 HiKey board from LeMaker and build an Android AOSP image for it (see [1]). For development I would like to use CONFIG_MODULES. However, when I try to insmod the build module I get: [ 287.903653] module cfg80211: overflow in relocation type 261 val ffbffc006530 Looking

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 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 message > V3: Add one

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] 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: [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 message > --- >

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] 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 > Signed-off-by: Muhammad

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 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 > Signed-off-by: Rafał Miłecki > --- > .../broadcom/brcm80211/brcmfmac/cfg80211.c | 17

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 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 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 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 > Signed-off-by: Heinrich Schuchardt > --- > drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c | 2 +- > 1 file changed, 1 insertion

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: [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 AM, Dan Williams wrote: >

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 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 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 changing the scope of the pdev

Re: [REGRESSION 4.6-rc1] NFS mounts (using autofs) failing

On 29-03-16 16:02, Al Viro wrote: > On Tue, Mar 29, 2016 at 01:11:55PM +0200, Arend Van Spriel wrote: >> Hi Al, >> >> Moved to 4.6-rc1 and found NFS mounts were failing moving to the new >> kernel. The NFS mounts are done using autofs. Below is the bisect log >>

Re: [REGRESSION 4.6-rc1] NFS mounts (using autofs) failing

On 29-03-16 16:02, Al Viro wrote: > On Tue, Mar 29, 2016 at 01:11:55PM +0200, Arend Van Spriel wrote: >> Hi Al, >> >> Moved to 4.6-rc1 and found NFS mounts were failing moving to the new >> kernel. The NFS mounts are done using autofs. Below is the bisect log >>

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 wrote: >> On 25-01-16 12:06, Julian Calaby wrote: >>> Hi Sjoerd, >>> >>> On Mon, Jan 25, 2016 at 9:47 PM, Sjoerd Simons >>> wrote: >&g

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 wrote: >> On 25-01-16 11:47, Sjoerd Simons wrote: >>> On a Radxa Rock2 board with a Ampak AP6335 (Broadcom 4339 core) it seems >>> the card responds very quickl

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 >> initialisation it sometimes

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

need this fix for now so... Acked-by: Arend van Spriel > Signed-off-by: Sjoerd Simons > > --- Still would like to know whether it is firmware initialization or some mmc stack procedure. Any suggestions to debug this are welcome. Regards, Arend --- > > drivers/net/wireless/broa

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

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] 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: 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 wrote: >> On 02-01-16 12:21, SF Markus Elfring wrote: >>>> Did you look at the resulting assembly code for different target >>>> architectures? >>> >>> N

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 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: 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: 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()

local variable that is redefined before its first use. That being said here is my Acked-by: Arend van Spriel Signed-off-by: Markus Elfring --- drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net

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