Re: [PATCH v2] rtl8187: Enable monitor mode to fix multicast reception

On 02/20/2017 12:59 AM, Nils Holland wrote: The rtl8187 cards don't seem to receive multicast frames, which, among other things, makes them fail to receive RAs in IPv6 networks. The cause seems to be that the RTL818X_RX_CONF_MULTICAST flag doesn't have the desired effect. AFAIU you have

Re: [PATCH] ath10k: Update available channel list for 5G radio

On 02/20/2017 06:08 AM, c_tr...@qti.qualcomm.com wrote: diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c index 3029f25..0840efb 100644 --- a/drivers/net/wireless/ath/ath10k/mac.c +++ b/drivers/net/wireless/ath/ath10k/mac.c @@ -7623,6 +7623,38 @@ static

Re: [PATCH] ath10k: Update available channel list for 5G radio

hiya, we're working on something similar to this, but based on bmi-id. Why'd you withdraw this patch for now? -a

Re: [PATCH] Make EN2 pin optional in the TRF7970A driver

Hello all, Am 13.02.2017 um 22:31 schrieb Rob Herring: On Mon, Feb 13, 2017 at 12:38 AM, Heiko Schocher wrote: Hello Rob, Am 10.02.2017 um 16:51 schrieb Rob Herring: On Tue, Feb 07, 2017 at 06:22:04AM +0100, Heiko Schocher wrote: From: Guan Ben

[PATCH] ath10k: Update available channel list for 5G radio

From: Tamizh chelvam If a 5 GHz radio is calibrated for operation in both the low band (channels 36 to 64) and high band(channels 100 to 169), hardware allows operations in all the listed channels. However, if the chip has been calibrated only for the low/high band and

RE: [PATCHv2] ath10k: Update available channel list for 5G radio

Please ignore this patch:( > -Original Message- > From: Raja, Tamizh Chelvam > Sent: Monday, February 20, 2017 10:37 AM > To: ath...@lists.infradead.org > Cc: linux-wireless@vger.kernel.org; Raja, Tamizh Chelvam > > Subject: [PATCHv2] ath10k: Update available

[PATCHv2] ath10k: Update available channel list for 5G radio

From: Tamizh chelvam If a 5 GHz radio is calibrated for operation in both the low band (channels 36 to 64) and high band(channels 100 to 169), hardware allows operations in all the listed channels. However, if the chip has been calibrated only for the low/high band and

Re: [PATCH v2] rtl8187: Enable monitor mode to fix multicast reception

On 02/19/2017 05:59 PM, Nils Holland wrote: The rtl8187 cards don't seem to receive multicast frames, which, among other things, makes them fail to receive RAs in IPv6 networks. The cause seems to be that the RTL818X_RX_CONF_MULTICAST flag doesn't have the desired effect. Fix the issue by

[PATCH v2] rtl8187: Enable monitor mode to fix multicast reception

The rtl8187 cards don't seem to receive multicast frames, which, among other things, makes them fail to receive RAs in IPv6 networks. The cause seems to be that the RTL818X_RX_CONF_MULTICAST flag doesn't have the desired effect. Fix the issue by setting RTL818X_RX_CONF_MONITOR instead, which puts

Re: [PATCH] Fix rtl8187 multicast reception

On 02/19/2017 12:53 PM, Nils Holland wrote: On Sun, Feb 19, 2017 at 12:11:50PM -0600, Larry Finger wrote: On 02/19/2017 07:29 AM, Kalle Valo wrote: Nils Holland writes: On Sun, Feb 19, 2017 at 09:46:16AM +0200, Kalle Valo wrote: Larry Finger

RE: brcmfmac: BCM4343A0 P2P mode problem

Hello Arend, I tried already the firmware file from the linux-firmware repo, but this firmware doesn't work. I get SDIO communication timeouts after the firmware file is loaded. Here the requested Kernel Log: [1.503423] brcmfmac: brcmf_sdio_probe Enter [1.504311] brcmfmac: F1 signature

Re: brcmfmac: BCM4343A0 P2P mode problem

On 19-2-2017 20:00, Stefan Holzmann wrote: > Hello, > > I think my problem was just a firmware version issue. When I use the firmware > file "fw_bcm4343.bin" from here > https://android.googlesource.com/platform/hardware/broadcom/wlan I'am able > establish a P2P connection. > Is this the

Re: brcmfmac: BCM4343A0 P2P mode problem

Hello, I think my problem was just a firmware version issue. When I use the firmware file "fw_bcm4343.bin" from here https://android.googlesource.com/platform/hardware/broadcom/wlan I'am able establish a P2P connection. Is this the latest/recommended firmware version for the chipset? Firmware

Re: [PATCH] Fix rtl8187 multicast reception

On Sun, Feb 19, 2017 at 12:11:50PM -0600, Larry Finger wrote: > On 02/19/2017 07:29 AM, Kalle Valo wrote: > > Nils Holland writes: > > > >> On Sun, Feb 19, 2017 at 09:46:16AM +0200, Kalle Valo wrote: > >>> Larry Finger writes: > >>> > On

Re: [PATCH] Fix rtl8187 multicast reception

On 02/19/2017 07:29 AM, Kalle Valo wrote: Nils Holland writes: On Sun, Feb 19, 2017 at 09:46:16AM +0200, Kalle Valo wrote: Larry Finger writes: On 02/18/2017 07:35 PM, Nils Holland wrote: I would prefer a module parameter that would allow

[PATCH] wcn36xx: Fix error handling

Reorder 'out_free_dxe_pool' and 'out_free_dxe_ctl' error handling labels in order to match the way resources have been allocated. Signed-off-by: Christophe JAILLET --- drivers/net/wireless/ath/wcn36xx/main.c | 4 ++-- 1 file changed, 2 insertions(+), 2

Re: [RFC v3 0/8] ath10k sdio support

Erik Stromdahl writes: > Ok, I'll do another round of checkpatch before I submit anything. > I couldn't find the script you mentioned though (ath10k-check). Did you check the link I gave you:

Re: [RFC v3 0/8] ath10k sdio support

On 2017-02-19 15:05, Valo, Kalle wrote: Erik Stromdahl writes: I just noticed that Ryan Hsu submitted two patches containing similar functionality to what I have in my tree on github. They have not been integrated in the ath master yet, but they have been added to

Re: [PATCH] Fix rtl8187 multicast reception

On Sun, Feb 19, 2017 at 03:29:12PM +0200, Kalle Valo wrote: > Nils Holland writes: > > > On Sun, Feb 19, 2017 at 09:46:16AM +0200, Kalle Valo wrote: > >> Larry Finger writes: > >> > >> > On 02/18/2017 07:35 PM, Nils Holland wrote: > >> > > >> > I

Re: [RFC v3 0/8] ath10k sdio support

Ok, I'll do another round of checkpatch before I submit anything. I couldn't find the script you mentioned though (ath10k-check). Is it some kind of checkpatch wrapper? Anyway, I have a few warnings related to 'line over 80 chars' that is really hard to get rid of (without breaking indentation

Re: [RFC v3 0/8] ath10k sdio support

Erik Stromdahl writes: > I just noticed that Ryan Hsu submitted two patches containing similar > functionality to what I have in my tree on github. They have not been > integrated in the ath master yet, but they have been added to master-pending. > > Below are the

Re: [RFC v3 0/8] ath10k sdio support

Hej, I just noticed that Ryan Hsu submitted two patches containing similar functionality to what I have in my tree on github. They have not been integrated in the ath master yet, but they have been added to master-pending. Below are the commits I am talking about

Re: [RFC v3 0/8] ath10k sdio support

Kalle Valo writes: > Erik Stromdahl writes: > >> I was actually about to email you about this. >> >> I have made a few more updates to the sdio code so I think it would be >> best if I could submit a new series of patches based on this code

Re: [PATCH] Fix rtl8187 multicast reception

Nils Holland writes: > On Sun, Feb 19, 2017 at 09:46:16AM +0200, Kalle Valo wrote: >> Larry Finger writes: >> >> > On 02/18/2017 07:35 PM, Nils Holland wrote: >> > >> > I would prefer a module parameter that would allow this change to be >> >

Re: [RFC v3 0/8] ath10k sdio support

Hej, I just noticed that Ryan Hsu submitted two patches containing similar functionality to what I have in my tree on github. They have not been integrated in the ath master yet, but they have been added to master-pending. Below are the commits I am talking about

Re: [PATCH] wireless-regdb: Update rules for Australia (AU) and add 60GHz rules

Australian regulations differ from most of Europe, the USA and even New Zealand (which shares AS/NZS 4268) in that any unlicensed operation between 5600-5650MHz is prohibited outright, rather than being allowed after an extended DFS channel availability check. The situation appears to be similar

Re: [PATCH] wireless-regdb: Update rules for Australia (AU) and add 60GHz rules

Am 19.02.2017 um 01:01 schrieb Ryan Mounce: Hi Sebastian, There is no explicit channel width restriction in the document, however the only band in which the current regdb rules permit 160MHz operation (5490-5710MHz) would result in an overlap with the restricted weather radar band 5600-5650MHz.

[PATCH] NFC: st21nfca: Fix potential memory leak

If all bits of 'dev_mask' are already set, there is a memory leak because 'info' should be freed before returning. While fixing it, 'return -ENOMEM' directly if the first kzalloc fails. This makes the code more readable. Signed-off-by: Christophe JAILLET ---

RE: [RFC 2/5] iwlwifi: fix request_module() use

> > The return value of request_module() being 0 does not mean that the driver > which was requested has loaded. To properly check that the driver was > loaded each driver can use internal mechanisms to vet the driver is now > present. The helper try_then_request_module() was added to help with >

Re: [PATCH] Fix rtl8187 multicast reception

On Sun, Feb 19, 2017 at 09:46:16AM +0200, Kalle Valo wrote: > Larry Finger writes: > > > On 02/18/2017 07:35 PM, Nils Holland wrote: > >> The rtl8187 doesn't seem to receive multicast data, which, among other > >> thinks, make it fail to receive RAs in IPv6 networks. >

RE: [RFC 1/5] iwlwifi: fix drv cleanup on opmode registration failure

Hi Luis, > > The firmware async callback handles the device's opmode start call, but > optionally also allows opmode registration to take care of its opmode start. > If > the firmware callback handles it its error path in case of opmode start > failure > has a few pieces of code missing from

Re: brcmfmac: BCM4343A0 P2P mode problem

Thank you for your support. Yes, correct SDIO 0xA9A6 is BCM43430 I was confused by the naming of some firmware files. What firmware version/file shall be used for this chipset/driver combination? Currently I'am using the firmware file "fw_bcm43438a0_p2p.bin" from here