Re: [PATCH 1/3] brcmfmac: allow specifying features per firmware version

On 23.05.2018 09:58, Arend van Spriel wrote: On 5/22/2018 3:18 PM, Rafał Miłecki wrote: From: Rafał Miłecki Some features supported by firmware aren't advertised and there is no way for a driver to query them. This includes e.g. monitor mode details. Some firmwares support

Re: [PATCH] ath10k: add dynamic vlan support

Am 23.05.2018 um 12:39 schrieb Johannes Berg: On Wed, 2018-05-23 at 16:09 +0530, Manikanta Pubbisetty wrote: + * @IEEE80211_HW_SUPPORTS_SW_ENCRYPT: Device is capable of transmitting + * frames encrypted in software, only valid when SW_CRYPTO_CONTROL + * is enabled. Based on this flag,

Re: linux-next: build warning after merge of the mac80211-next tree

Arnd Bergmann writes: > On Fri, May 11, 2018 at 2:20 PM, Kalle Valo wrote: >> Stephen Rothwell writes: >> >>> After merging the mac80211-next tree, today's linux-next build (arm_multi >>> v7_defconfig) produced this warning: >>> >>>

Can no one help me?

I realize this is a development mailinglist and not a support forum, but I'm really at the end of my rope here. If someone can get this working, I'll buy them a nice lunch if they're ever near Cincinnati. I've tried booting alternative distros to see if it is a software problem, but no distro

[PATCH] staging: wilc1000: Avoid overriding rates_no while parsing ies element.

Commit d4b4aaba515a ("staging: wilc1000: fix line over 80 characters in host_int_parse_join_bss_param()") introduced a bug by not keeping the rates_no value while parsing ies elements. It also increments auth_total_cnt as a pointer instead of its reference. This commit fixes the bug by passing

Re: [PATCH v2] ath10k: transmit queued frames after waking queues

On Wed, May 23, 2018 at 06:25:49PM +0200, Erik Stromdahl wrote: > > > On 05/22/2018 11:15 PM, Niklas Cassel wrote: > > > > > > > > Earlier we observed performance issues in calling push_pending from each > > > tx completion. IMHO this change may introduce the same problem again. > > > > I

Re: [PATCH v3] ath10k: transmit queued frames after processing rx packets

On Thu, May 24, 2018 at 12:15:08AM +0200, Niklas Cassel wrote: > This problem cannot be reproduced on low-latency devices, e.g. pci, > since they call ath10k_mac_tx_push_pending() from > ath10k_htt_txrx_compl_task(). ath10k_htt_txrx_compl_task() is not called > on high-latency devices. > Fix the

[PATCH v3] ath10k: transmit queued frames after processing rx packets

When running iperf on ath10k SDIO, TX can stop working: iperf -c 192.168.1.1 -i 1 -t 20 -w 10K [ 3] 0.0- 1.0 sec 2.00 MBytes 16.8 Mbits/sec [ 3] 1.0- 2.0 sec 3.12 MBytes 26.2 Mbits/sec [ 3] 2.0- 3.0 sec 3.25 MBytes 27.3 Mbits/sec [ 3] 3.0- 4.0 sec 655 KBytes 5.36 Mbits/sec [ 3]

Re: linux-next: build warning after merge of the mac80211-next tree

On Fri, May 11, 2018 at 2:20 PM, Kalle Valo wrote: > Stephen Rothwell writes: > >> After merging the mac80211-next tree, today's linux-next build (arm_multi >> v7_defconfig) produced this warning: >> >>

Re: pull-request: mac80211-next 2018-05-23

From: Johannes Berg Date: Wed, 23 May 2018 14:14:31 +0200 > Here's a new version of the pull request for net-next, now > with the stack size fixes included, which were the reason I > withdrew my earlier one. Other things are also included all > over the map. > >

Re: pull-request: wireless-drivers 2018-05-22

From: Kalle Valo Date: Tue, 22 May 2018 17:28:11 +0300 > here's a pull request to net tree for 4.17. Please let me know if you > have any problems. Pulled, thanks Kalle.

Re: [PATCH v2] ath10k: transmit queued frames after waking queues

On 2018-05-23 09:25, Erik Stromdahl wrote: On 05/22/2018 11:15 PM, Niklas Cassel wrote: [...] Perhaps it would be possible to call ath10k_mac_tx_push_pending() from the equivalent to ath10k_htt_txrx_compl_task(), but from SDIO's point of view. An equivalent for SDIO would most likely be

Re: [PATCHv2 0/5] Runtime PM support for wlcore

* Reizer, Eyal [180523 12:45]: > > > > > > > > Here's a modified version of your patch, does that put wlcore to > > > idle with wowlan during suspend for you? > > > > > > > Still no joy. > > It suspends/resumes ok but leaves the firmware disabled from entering ELP. > > Spent some

Re: [PATCH v2] ath10k: transmit queued frames after waking queues

On 05/22/2018 11:15 PM, Niklas Cassel wrote: Earlier we observed performance issues in calling push_pending from each tx completion. IMHO this change may introduce the same problem again. I prefer functional TX over performance issues, but I agree that it is unfortunate that SDIO doesn't

Re: [PATCH] staging: wilc1000: fix spelling mistake: "Preamle" -> "Preamble"

On 22.05.2018 19:49, Colin King wrote: > From: Colin Ian King > > Trivial fix to spelling mistake in netdev_err error message > > Signed-off-by: Colin Ian King Reviewed-by: Claudiu Beznea > --- >

Re: [EXT] Re: [PATCH V2 3/6] mwifiex: support sysfs initiated device coredump

Ganapathi Bhat writes: > Hi Kalle, > >> Arend van Spriel writes: >> >> > On 5/23/2018 9:54 AM, Kalle Valo wrote: >> >> Ganapathi Bhat writes: >> >> >> >>> In V2: >> >>> >> >>> return ret; >> >>> } >> >>>

Re: [V2,1/6] brcmfmac: move ALLFFMAC variable in flowring module

Arend Van Spriel wrote: > The only user of ALLFFMAC is the flowring module so no need to > expose it in a header file. > > Reviewed-by: Hante Meuleman > Reviewed-by: Pieter-Paul Giesberts >

Re: pull-request: mac80211 2018-05-23

From: Johannes Berg Date: Wed, 23 May 2018 11:47:57 +0200 > Just another handful of fixes as we wind down towards the > merge window. > > Please pull and let me know if there's any problem. Pulled, thanks Johannes. Please don't tell me you will soon queue up a patch

[PATCH] cfg80211: use better order for kcalloc() arguments

From: Johannes Berg The arguments should be (# of elements, size of each) instead of the other way around, which really ends up being mostly equivalent but smatch complains about it, so swap them. Signed-off-by: Johannes Berg ---

Re: [PATCH v3] iw: avgerage ack rssi changes for data frames

Sure Johannes, I will send another version of patch. On 2018-05-23 15:30, Johannes Berg wrote: On Thu, 2018-03-08 at 12:49 +0530, Balaji Pothunoori wrote: This patch is to display the average ack rssi for data frames. "avg ack signal" field diplay limited by host based on firmware capablities.

RE: [PATCHv2 0/5] Runtime PM support for wlcore

> > > > > Here's a modified version of your patch, does that put wlcore to > > idle with wowlan during suspend for you? > > > > Still no joy. > It suspends/resumes ok but leaves the firmware disabled from entering ELP. Spent some time on it today and looks like adding calls to

pull-request: mac80211-next 2018-05-23

Hi Dave, Here's a new version of the pull request for net-next, now with the stack size fixes included, which were the reason I withdrew my earlier one. Other things are also included all over the map. Please pull and let me know if there's any problem. Thanks, johannes The following changes

RE: [EXT] Re: [PATCH V2 3/6] mwifiex: support sysfs initiated device coredump

Hi Kalle, > Arend van Spriel writes: > > > On 5/23/2018 9:54 AM, Kalle Valo wrote: > >> Ganapathi Bhat writes: > >> > >>> In V2: > >>> > >>> return ret; > >>> } > >>> +EXPORT_SYMBOL_GPL(mwifiex_send_cmd); > >>> > >>> Instead of

Re: [v8, bpf-next, 4/9] net/wireless/iwlwifi: fix iwlwifi_dev_ucode_error tracepoint

On Wed, 2018-03-28 at 12:05 -0700, Alexei Starovoitov wrote: > fix iwlwifi_dev_ucode_error tracepoint to pass pointer to a table > instead of all 17 arguments by value. > dvm/main.c and mvm/utils.c have 'struct iwl_error_event_table' > defined with very similar yet subtly different fields and

Re: [PATCH] ath10k: add dynamic vlan support

On 5/23/2018 4:09 PM, Johannes Berg wrote: On Wed, 2018-05-23 at 16:09 +0530, Manikanta Pubbisetty wrote: + * @IEEE80211_HW_SUPPORTS_SW_ENCRYPT: Device is capable of transmitting + * frames encrypted in software, only valid when SW_CRYPTO_CONTROL + * is enabled. Based on this flag,

Re: [PATCH] ath10k: add dynamic vlan support

On Wed, 2018-05-23 at 16:09 +0530, Manikanta Pubbisetty wrote: > > > > > + * @IEEE80211_HW_SUPPORTS_SW_ENCRYPT: Device is capable of > > > > > transmitting > > > > > + * frames encrypted in software, only valid when > > > > > SW_CRYPTO_CONTROL > > > > > + * is enabled. Based on this

Re: [PATCH] ath10k: add dynamic vlan support

+ * @IEEE80211_HW_SUPPORTS_SW_ENCRYPT: Device is capable of transmitting + * frames encrypted in software, only valid when SW_CRYPTO_CONTROL + * is enabled. Based on this flag, mac80211 can allow/disallow VLAN + * operations in the BSS. Based on the name and initial description,

[PATCH] atmel: Add missing call to pci_disable_device()

add pci_disable_device in error handling while init_atmel_card failed. Signed-off-by: YueHaibing --- drivers/net/wireless/atmel/atmel_pci.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/net/wireless/atmel/atmel_pci.c

Re: [PATCH 2/3] brcmfmac: handle monitor mode marked msgbuf packets

://github.com/0day-ci/linux/commits/Rafa-Mi-ecki/brcmfmac-allow-specifying-features-per-firmware-version/20180523-160546 base: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git master reproduce: # apt-get install sparse make ARCH=x86_64 allmodconfig

Re: [PATCH 00/10] Some more patches for wcn36xx

Hi Kalle, On Friday, May 18, 2018 01:28 PM, Kalle Valo wrote: Daniel Mack writes: On Wednesday, May 16, 2018 04:08 PM, Daniel Mack wrote: Hence I believe that some sort of firmware internal buffer is overrun if too many SMD requests fly in in a short amount of time. The

Re: [PATCH v3] iw: avgerage ack rssi changes for data frames

On Thu, 2018-03-08 at 12:49 +0530, Balaji Pothunoori wrote: > This patch is to display the average ack rssi for data > frames. "avg ack signal" field diplay limited by host based on > firmware capablities. This doesn't compile, please respin (and you could fix the "average" typo in the subject)

Re: [PATCH] cfg80211: Add cumulative channel survey dump support.

On Tue, 2018-05-22 at 14:45 +0530, Venkateswara Naralasetty wrote: > This patch provides support to send accumulated survey data to > user if low level drivers provides non-accumulated survey data. I think the commit log should say what you need this for? It's simultaneously a new flag, and a

Re: [PATCH] ath10k: add dynamic vlan support

On Mon, 2018-05-21 at 12:12 +0530, Manikanta Pubbisetty wrote: > > Do you know why it actually broke it? I mean, we should've turned off > > the strict requirement for sw crypto control only for the GTK, and that > > shouldn't matter so much? > > With the change db3bdcb9c3ff, AP/VLAN support is

pull-request: mac80211 2018-05-23

Hi Dave, Just another handful of fixes as we wind down towards the merge window. Please pull and let me know if there's any problem. Thanks, johannes The following changes since commit 6caf9fb3bda17df59de4ed6ed4950c43ca1361e3: Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf

Re: [RFC] mac80211: add stop/start logic for software TXQs

On Sat, 2018-05-19 at 01:06 +0530, Manikanta Pubbisetty wrote: > Sometimes, it is required to stop the transmissions momentarily and > resume it later; stopping the txqs becomes very critical in scenarios where > the packet transmission has to be ceased completely. For example, during > the

Re: [EXT] Re: [PATCH V2 3/6] mwifiex: support sysfs initiated device coredump

Arend van Spriel writes: > On 5/23/2018 9:54 AM, Kalle Valo wrote: >> Ganapathi Bhat writes: >> >>> In V2: >>> >>> return ret; >>> } >>> +EXPORT_SYMBOL_GPL(mwifiex_send_cmd); >>> >>> Instead of exporting 'mwifiex_send_cmd' we can

Re: [EXT] Re: [PATCH V2 3/6] mwifiex: support sysfs initiated device coredump

On 5/23/2018 9:54 AM, Kalle Valo wrote: Ganapathi Bhat writes: In V2: return ret; } +EXPORT_SYMBOL_GPL(mwifiex_send_cmd); Instead of exporting 'mwifiex_send_cmd' we can prepare a wrapper for the command 'MWIFIEX_IFACE_WORK_DEVICE_DUMP' in mwifiex module. Let me

Re: mwifiex: correct histogram data with appropriate index

Xinming Hu wrote: > Correct snr/nr/rssi data index to avoid possible buffer underflow. > > Signed-off-by: Xinming Hu Patch applied to wireless-drivers-next.git, thanks. 30bfce0b63fa mwifiex: correct histogram data with appropriate index --

Re: [PATCH 1/3] brcmfmac: allow specifying features per firmware version

On 5/22/2018 3:18 PM, Rafał Miłecki wrote: From: Rafał Miłecki Some features supported by firmware aren't advertised and there is no way for a driver to query them. This includes e.g. monitor mode details. Some firmwares support tagging monitor frames, some build radiotap

Re: [1/5] mt76: only stop tx queues on offchannel, not during the entire scan

Felix Fietkau wrote: > During scans, mac80211 frequently switches back to the home channel to > minimize interruption of ongoing traffic. Keep regular tx queues active > during that time. > > Signed-off-by: Felix Fietkau 5 patches applied to

Re: [1/2] mt76: fix sending encrypted broadcast packets for secondary interfaces

Felix Fietkau wrote: > For encryption to work properly, the BSS index needs to be initialized > for the WCID entry used for the interface. > > Signed-off-by: Felix Fietkau 2 patches applied to wireless-drivers-next.git, thanks. d98fb328ad10 mt76: fix sending

Re: mt76x2: apply coverage class on slot time too

Lorenzo Bianconi wrote: > According to 802.11-2007 17.3.8.6 (slot time), the slot time should > be increased by 3 us * coverage class. Taking into account coverage > class in slot time configuration allows to increase by an order of > magnitude the throughput on a

Re: [EXT] Re: [PATCH V2 3/6] mwifiex: support sysfs initiated device coredump

Ganapathi Bhat writes: > In V2: > > return ret; > } > +EXPORT_SYMBOL_GPL(mwifiex_send_cmd); > > Instead of exporting 'mwifiex_send_cmd' we can prepare a wrapper for > the command 'MWIFIEX_IFACE_WORK_DEVICE_DUMP' in mwifiex module. Let me > know if we can send a follow

Re: [PATCH] cfg80211: Fix support for flushing old scan results

Hi Denis, > > I'm not sure. It still indicates that a hidden SSID was found, and in > > general even a real SSID on the same BSSID doesn't indicate that this > > was the only hidden SSID ... > > Right, but you still get that info conveyed through the Beacon IEs > elements on the

RE: [EXTERNAL] [PATCHv2 0/5] Runtime PM support for wlcore

> > Here's a modified version of your patch, does that put wlcore to > idle with wowlan during suspend for you? > Still no joy. It suspends/resumes ok but leaves the firmware disabled from entering ELP. You can see the log below with some prints added to wlcore_runtime_suspend() And