[PATCH] ath10k: Convert wow pattern from 802.3 to 802.11

When trying to set wow wakeup patterns it fails with this command: iw phyxx wowlan enable patterns offset xx+ IP address xx.xx.xx.xx The reason is that the wow pattern from upper layer is in 802.3 format for this case, it need to convert it to 802.11 format. The input offset parameter is used

[PATCH 1/2] ath10k: Add WMI_SERVICE_AVAILABLE_EVENT support

Add WMI_SERVICE_AVAILABLE_EVENT to extend WMI_SERVICE_READY_EVENT, the 128bit service map in WMI_SERVICE_READY_EVENT is not enough for firmware to notice new WLAN service to host driver. Hereby, for thoese new WLAN service, firmware will notice host driver by WMI_SERVICE_AVAILABLE_EVENT.

[PATCH 0/2] ath10k: support MAC address randomization in scan

The feature MAC address randomization depends on the firmware capability, if the firmware indicates WMI_SERVICE_SPOOF_MAC_SUPPORT service the host driver will report it to upper layer. The service bit is above the 128 bit limit so a new service check macro is needed. Carl Huang (2): ath10k: Add

[PATCH 2/2] ath10k: support MAC address randomization in scan

The ath10k reports the random_mac_addr capability to upper layer based on the service bit firmware reported. Driver sets the spoofed flag in scan_ctrl_flag to firmware if upper layer has enabled this feature in scan request. Test with QCA6174 hw3.0 and

[PATCH net-next] cfg80211: fix possible memory leak in regdb_query_country()

'wmm_ptrs' is malloced in regdb_query_country() and should be freed before leaving from the error handling cases, otherwise it will cause memory leak. Signed-off-by: Wei Yongjun --- net/wireless/reg.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/wireless/reg.c

Re: Passing uninitialised local variable

On 3/28/2018 1:20 PM, Himanshu Jha wrote: Hello everyone, You added everyone, but me :-( Not really a problem, but it would help if the driver name was mentioned in the subject. I recently found that a local variable in passed uninitialised to the function at

Re: pull-request: wireless-drivers-next 2018-03-29

From: Kalle Valo Date: Thu, 29 Mar 2018 16:21:44 +0300 > here's a pull request to net-next for 4.17. If the merge window starts > on Sunday this will be the last pull request. Do note that I pulled > wireless-drivers into wireless-drivers-next as iwlwifi needed some >

Re: pull-request: mac80211-next 2018-03-29

From: Johannes Berg Date: Thu, 29 Mar 2018 15:10:02 +0200 > Last update for -next, I guess, but I wanted to get the ETSI adaptivity > requirements code and the eapol-over-nl80211 thing out - both have been > around for a while. A number of other smaller things are also

Re: [PATCH] wcn36xx: allocate skbs with GFP_KERNEL during init

On Monday, March 19, 2018 07:30 AM, Daniel Mack wrote: > GFP_ATOMIC should only be used when the allocation is done from atomic > context. Introduce a new flag to wcn36xx_dxe_fill_skb() and use GFP_KERNEL > when pre-allocating buffers during init. > > This doesn't fix an issue that was observed

License info

Kalle, What is your position regarding license information? Should the standard GPL-V2 boiler plate be replaced with "SPDX-License-Identifier: GPL-2.0" in wireless files? Thanks, Larry

Re: [PATCH net-next 0/5] Introduce net_rwsem to protect net_namespace_list

From: Kirill Tkhai Date: Thu, 29 Mar 2018 19:20:23 +0300 > The series introduces fine grained rw_semaphore, which will be used > instead of rtnl_lock() to protect net_namespace_list. > > This improves scalability and allows to do non-exclusive sleepable > iteration

[PATCH] ath10k: fix spelling mistake: "tiggers" -> "triggers"

From: Colin Ian King Trivial fix to spelling mistake in message text Signed-off-by: Colin Ian King --- drivers/net/wireless/ath/ath10k/wmi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH] ath6kl: fix spelling mistake: "chache" -> "cache"

From: Colin Ian King Trivial fix to spelling mistake in message text Signed-off-by: Colin Ian King --- drivers/net/wireless/ath/ath6kl/debug.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [PATCH 1/2] NFC: pn533: Use kmalloc-ed memory for USB transfer buffers

Samuel, Can I get an ack for these please? Anything I need to do to get these picked up / merged? Regards, Hans On 19-03-18 17:40, Hans de Goede wrote: Commit 8b55d7581fc5 ("NFC: pn533: use constant off-stack buffer for sending acks"), fixed the ack case of using on stack mem for the

[PATCH net-next 0/5] Introduce net_rwsem to protect net_namespace_list

The series introduces fine grained rw_semaphore, which will be used instead of rtnl_lock() to protect net_namespace_list. This improves scalability and allows to do non-exclusive sleepable iteration for_each_net(), which is enough for most cases. scripts/get_maintainer.pl gives enormous list of

[PATCH net-next 4/5] ovs: Remove rtnl_lock() from ovs_exit_net()

Here we iterate for_each_net() and removes vport from alive net to the exiting net. ovs_net::dps are protected by ovs_mutex(), and the others, who change it (ovs_dp_cmd_new(), __dp_destroy()) also take it. The same with datapath::ports list. So, we remove rtnl_lock() here. Signed-off-by: Kirill

[PATCH net-next 5/5] net: Remove rtnl_lock() in nf_ct_iterate_destroy()

rtnl_lock() doesn't protect net::ct::count, and it's not needed for__nf_ct_unconfirmed_destroy() and for nf_queue_nf_hook_drop(). Signed-off-by: Kirill Tkhai --- net/netfilter/nf_conntrack_core.c |2 -- 1 file changed, 2 deletions(-) diff --git

[PATCH net-next 3/5] security: Remove rtnl_lock() in selinux_xfrm_notify_policyload()

rt_genid_bump_all() consists of ipv4 and ipv6 part. ipv4 part is incrementing of net::ipv4::rt_genid, and I see many places, where it's read without rtnl_lock(). ipv6 part calls __fib6_clean_all(), and it's also called without rtnl_lock() in other places. So, rtnl_lock() here was used to iterate

[PATCH net-next 2/5] net: Don't take rtnl_lock() in wireless_nlevent_flush()

This function iterates over net_namespace_list and flushes the queue for every of them. What does this rtnl_lock() protects?! Since we may add skbs to net::wext_nlevents without rtnl_lock(), it does not protects us about queuers. It guarantees, two threads can't flush the queue in parallel, that

[PATCH net-next 1/5] net: Introduce net_rwsem to protect net_namespace_list

rtnl_lock() is used everywhere, and contention is very high. When someone wants to iterate over alive net namespaces, he/she has no a possibility to do that without exclusive lock. But the exclusive rtnl_lock() in such places is overkill, and it just increases the contention. Yes, there is already

[PATCH] cw1200: fix spelling mistake: "Mailformed" -> "Malformed"

From: Colin Ian King Trivial fix to spelling mistake in wiphy_warn warning message text Signed-off-by: Colin Ian King --- drivers/net/wireless/st/cw1200/txrx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[v2 RESEND 2/4] rsi: move descriptor preparation to core

From: Prameela Rani Garnepudi Descriptors preparation is moved to core instead of HAL to avoid synchronization issues in sending TX frames Signed-off-by: Prameela Rani Garnepudi Signed-off-by: Amitkumar Karwar

[v2 RESEND 4/4] rsi: roaming enhancements

From: Prameela Rani Garnepudi To support roaming below changes are done: * Station notify frame is send to firmware after sending assoc request. This will avoid dropping of first EAPOL frame due to delay in creation of station control block in firmware. * Data

[v2 RESEND 1/4] rsi: move xtend_desc structure from rsi_main.h to rsi_mgmt.h

From: Prameela Rani Garnepudi All descriptor structures are in rsi_mgmt.h except this extended descriptor structure. Hence moving it to rsi_mgmt.h and also renaming to rsi_xtend_desc. Signed-off-by: Prameela Rani Garnepudi Signed-off-by:

[v2 RESEND 3/4] rsi: enable 80MHz clock by default

From: Prameela Rani Garnepudi 80MHz clock for device should be enabled by default in TX command frame radio capabilities. Signed-off-by: Prameela Rani Garnepudi Signed-off-by: Amitkumar Karwar ---

[v2 RESEND 0/4] rsi driver enhancements

From: Amitkumar Karwar This patch series includes some code rearrangement and roaming related improvements. Changes in v2: v2 1/4 is same as v1 2/10 v2 2/4 is same as v1 3/10 v2 3/4 is same as v1 4/10 v2 4/4 is updated version of v1 5/10 Remaining patches in v1

Re: nested structs parsing

Hi, > The original patchset for nested structs was supporting it only > when not inlined. This should be fixed on this patchset: > > https://lkml.org/lkml/2018/2/19/387 > > Do you have those patches on your tree? No, looks like I don't have those yet. I'll wait for those then. > With

Re: nested structs parsing

Em Thu, 29 Mar 2018 11:47:07 +0200 Johannes Berg escreveu: > On Thu, 2018-03-29 at 11:46 +0200, Johannes Berg wrote: > > Hi, > > > > For a while I haven't looked at my documentation for 802.11, and now I > > noticed I'm getting warnings due to the nested parsing. > >

[v2 4/4] rsi: roaming enhancements

From: Prameela Rani Garnepudi To support roaming below changes are done: * Station notify frame is send to firmware after sending assoc request. This will avoid dropping of first EAPOL frame due to delay in creation of station control block in firmware. * Data

[v2 2/4] rsi: move descriptor preparation to core

From: Prameela Rani Garnepudi Descriptors preparation is moved to core instead of HAL to avoid synchronization issues in sending TX frames Signed-off-by: Prameela Rani Garnepudi Signed-off-by: Amitkumar Karwar

[v2 3/4] rsi: enable 80MHz clock by default

From: Prameela Rani Garnepudi 80MHz clock for device should be enabled by default in TX command frame radio capabilities. Signed-off-by: Prameela Rani Garnepudi Signed-off-by: Amitkumar Karwar ---

[v2 0/4] rsi driver enhancements

From: Amitkumar Karwar This patch series includes some code rearrangement and roaming related improvements. Changes in v2: v2 1/4 is same as v1 2/10 v2 2/4 is same as v1 3/10 v2 3/4 is same as v1 4/10 v2 4/4 is updated version of v1 5/10 Remaining patches in v1

[v2 1/4] rsi: move xtend_desc structure from rsi_main.h to rsi_mgmt.h

From: Prameela Rani Garnepudi All descriptor structures are in rsi_mgmt.h except this extended descriptor structure. Hence moving it to rsi_mgmt.h and also renaming to rsi_xtend_desc. Signed-off-by: Prameela Rani Garnepudi Signed-off-by:

pull-request: wireless-drivers-next 2018-03-29

Hi Dave, here's a pull request to net-next for 4.17. If the merge window starts on Sunday this will be the last pull request. Do note that I pulled wireless-drivers into wireless-drivers-next as iwlwifi needed some patches. Please let me know if you have any problems. Kalle The following

pull-request: mac80211-next 2018-03-29

Hi Dave, Last update for -next, I guess, but I wanted to get the ETSI adaptivity requirements code and the eapol-over-nl80211 thing out - both have been around for a while. A number of other smaller things are also there, of course. Please pull and let me know if there's any problem. Thanks,

Re: [PATCH v7 00/11] EAPoL over NL80211

Alright, I've applied all of this. johannes

RE: wil6210: low level sector API

From: linux-wireless-ow...@vger.kernel.org [mailto:linux-wireless-ow...@vger.kernel.org] On Behalf Of David Dean Sent: Monday, March 26, 2018 9:38 PM > My question is how I can disable TXSS. One way I found in the wmi.h is > setting the number of sectors of TXSS to 0 or 1 > by using >

Re: [PATCH] nl80211: Update ERP info using NL80211_CMD_UPDATE_CONNECT_PARAMS

+ Jithu, Eylon On 3/29/2018 1:16 PM, Johannes Berg wrote: Hi Arend, Picking up a somewhat old thread as I did not see a follow-up on this patch. I got queried about it over here by our FILS team. So what is needed for this patch to pass the bar? That's indeed a bit old :-) + *

Re: [PATCH] nl80211: Update ERP info using NL80211_CMD_UPDATE_CONNECT_PARAMS

Hi Arend, > Picking up a somewhat old thread as I did not see a follow-up on this > patch. I got queried about it over here by our FILS team. So what is > needed for this patch to pass the bar? That's indeed a bit old :-) > > > + * @UPDATE_FILS_ERP_INFO: Indicates that FILS connection

Re: [PATCH] nl80211: Update ERP info using NL80211_CMD_UPDATE_CONNECT_PARAMS

Hi Johannes, Picking up a somewhat old thread as I did not see a follow-up on this patch. I got queried about it over here by our FILS team. So what is needed for this patch to pass the bar? On 12/11/2017 12:12 PM, Johannes Berg wrote: On Wed, 2017-10-25 at 14:50 +0530, Vidyullatha

[PATCHv3] ath10k: Add tx ack signal support for management frames

This patch add support to get RSSI from acknowledgment frames for transmitted management frames. hardware_used: QCA4019, QCA9984. firmware version: 10.4-3.5.3-00052. Signed-off-by: Venkateswara Naralasetty --- v2: * renamed HTT_MGMT_TX_CMPL_INFO_ACK_RSSI to

nested structs parsing

Hi, For a while I haven't looked at my documentation for 802.11, and now I noticed I'm getting warnings due to the nested parsing. However, something seems to be wrong? I have, for example, this (in net/mac80211/sta_info.h) struct sta_info { ... struct { u64

Re: nested structs parsing

On Thu, 2018-03-29 at 11:46 +0200, Johannes Berg wrote: > Hi, > > For a while I haven't looked at my documentation for 802.11, and now I > noticed I'm getting warnings due to the nested parsing. > > However, something seems to be wrong? I have, for example, this (in > net/mac80211/sta_info.h) >

Re: ath: Remove unnecessary ath_bcast_mac and use eth_broadcast_addr

Joe Perches wrote: > Remove the static array and use the generic routine to set the > Ethernet broadcast address. > > Signed-off-by: Joe Perches > Signed-off-by: Kalle Valo Patch applied to ath-next branch of ath.git, thanks.

Re: ath10k: fix vdev stats for 10.4 firmware

Rajkumar Manoharan wrote: > Currently vdev stats displayed in fw_stats are applicable > only for TLV based firmware and fix it for 10.4 firmware > as of now. The vdev stats in 10.4 firmware is split into two > parts (vdev_stats, vdev_stats_extended). The actual stats >

Re: ath10k: fix recent bandwidth conversion bug

ako...@codeaurora.org wrote: > The commit "cfg80211: make RATE_INFO_BW_20 the default" changed > the index of RATE_INFO_BW_20, but the updates to ath10k missed > the special bandwidth calculation case in > ath10k_update_per_peer_tx_stats(). > > This will fix below warning, > > WARNING: CPU: 0

Re: ath10k: Advertize beacon_int_min_gcd

ako...@codeaurora.org wrote: > This patch fixes regression caused by 0c317a02ca98 > ("cfg80211: support virtual interfaces with different beacon intervals"), > with this change cfg80211 expects the driver to advertize > 'beacon_int_min_gcd' to support different beacon intervals in multivap >

Re: [v7,2/5] ath10k: Enable TDLS peer buffer STA feature

yint...@qti.qualcomm.com wrote: > Enable TDLS peer buffer STA feature. > QCA6174 firmware(version: WLAN.RM.4.4) support TDLS peer buffer STA, > it reports this capability through wmi service map in wmi service ready > event. Set related parameter in TDLS WMI command to enable this feature. > >

Re: [PATCH v3 2/3] mac80211: limit wmm params to comply with ETSI requirements

On Thu, 2018-03-29 at 10:55 +0200, Arend van Spriel wrote: > > > No, the regulations say you have to use a long content window, hence > > Guess you mean "contention window" :-p Heh, yes. > > limiting both min and max at the lower end (hence max_t). > > Do you have any reference to the new

Re: [PATCH v3 2/3] mac80211: limit wmm params to comply with ETSI requirements

On 3/29/2018 10:35 AM, Johannes Berg wrote: On Wed, 2018-03-28 at 10:29 -0700, Peter Oh wrote: + if (sdata->vif.type == NL80211_IFTYPE_AP) + wmm_ac = >wmm_rule->ap[ac]; + else + wmm_ac = >wmm_rule->client[ac]; + qparam->cw_min = max_t(u16,

Re: [v2] wcn36xx: dequeue all pending indicator messages

Daniel Mack wrote: > In case wcn36xx_smd_rsp_process() is called more than once before > hal_ind_work was dispatched, the messages will end up in hal_ind_queue, > but wcn36xx_ind_smd_work() will only look at the first message in that > list. > > Fix this by dequeing the

Re: wcn36xx: Fix firmware crash due to corrupted buffer address

Ramon Fried wrote: > wcn36xx_start_tx function retrieves the buffer descriptor from the > channel control queue to start filling tx buffer information. However, > nothing prevents this same buffer to be concurrently accessed in a > concurent tx call, leading to potential

Re: wcn36xx: turn off probe response offloading

Ramon Fried wrote: > It appears that the WCN36xx firmware doesn't actually respond to > probe requests. Until it's resolved, switch the probe response > responsibility to the 802.11 layer to allow creation of > hidden SSID AP's. > > Signed-off-by: Ramon Fried

Re: [1/2] ath10k: refactor ath10k_pci_dump_memory() in preparation for QCA9984 support

Kalle Valo wrote: > As QCA9984 needs two region types refactor the code to make it easier add the > new types. No functional changes. > > Signed-off-by: Kalle Valo 2 patches applied to ath-next branch of ath.git, thanks. 10c228843081 ath10k:

Re: ath10k: Suppress "Unknown eventid: 36925" warnings

Sathishkumar Muruganandam wrote: > FW has Smart Logging feature enabled by default for detecting failures > and processing FATAL_CONDITION_EVENTID (36925 - 0x903D) back to host. > > Since ath10k doesn't implement the Smart Logging and FATAL CONDITION > EVENT processing

Re: [PATCH v3 2/3] mac80211: limit wmm params to comply with ETSI requirements

On Wed, 2018-03-28 at 13:24 +0300, Luca Coelho wrote: > > --- a/net/wireless/reg.c > +++ b/net/wireless/reg.c > @@ -135,12 +135,12 @@ static void restore_regulatory_settings(bool > reset_user); > > static const struct ieee80211_regdomain *get_cfg80211_regdom(void) > { > - return

Re: [1/2] ath10k: enable QCA6174/QCA9377 to read the chip temperature

ryan...@codeaurora.org wrote: > The firmware of QCA6174/QCA9377 already support the feature, just enable > it to be able to handle the get_temperature command and process the event. > > You can read the temperature by using the hwmon interface, > > cat

Re: [PATCHv2] Revert "ath10k: send (re)assoc peer command when NSS changed"

Karthikeyan Periyasamy wrote: > This reverts commit 55884c045d31a29cf69db8332d1064a1b61dd159. > > When Ath10k is in AP mode and an unassociated STA sends a VHT action frame > (Operating Mode Notification for the NSS change) periodically to AP this > causes > ath10k to

Re: [v2] ath9k: fix DFS detector synchronization

Timothy Redaelli wrote: > some userspace programs (e.g. hostapd) need to set the regulatory domain > before selecting the operating channel. Synchronize DFS detector regardless of > the value of ah->curchan, to avoid situations where wireless scan can't be > done > on some

Re: pull-request: iwlwifi-next 2018-03-28

Luca Coelho writes: > This is a batch of patches intended for v4.17. Nothing major here, > just the usual continued development, bugfixes, new FW APIs and some > minor features. More details about the contents in the tag > description. > > The commit messages you commented on

Re: [PATCH v3 2/3] mac80211: limit wmm params to comply with ETSI requirements

On Wed, 2018-03-28 at 10:29 -0700, Peter Oh wrote: > > + if (sdata->vif.type == NL80211_IFTYPE_AP) > > + wmm_ac = >wmm_rule->ap[ac]; > > + else > > + wmm_ac = >wmm_rule->client[ac]; > > + qparam->cw_min = max_t(u16, qparam->cw_min, wmm_ac->cw_min); > > + qparam->cw_max

Re: [PATCH v2] wcn36xx: Disable 5GHz for wcn3610

(really adding Bjorn) Ramon Fried writes: > (adding Bjorn Andersson) > > > On 3/29/2018 10:15 AM, Kalle Valo wrote: >> (adding devicetree list) >> >> Ramon Fried writes: >> >>> wcn3610 can only operate on 2.4GHz band due to RF limitation. >>> If

Re: [PATCH v2] wcn36xx: Disable 5GHz for wcn3610

Hi Ramon, On 29 March 2018 at 09:32, Ramon Fried wrote: >> Should we document qcom,wcn3610 just like wcn3620 is: >> >> Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.txt: >>"qcom,wcn3620", > IMHO the mentioned bindings is related to the

Re: [PATCH v2] wcn36xx: Disable 5GHz for wcn3610

(adding Bjorn Andersson) On 3/29/2018 10:15 AM, Kalle Valo wrote: > (adding devicetree list) > > Ramon Fried writes: > >> wcn3610 can only operate on 2.4GHz band due to RF limitation. >> If wcn36xx digital block is associated with an external IRIS >> RF module, retrieve

Re: [PATCH 07/14] iwlwifi: mvm: add support for oce

Luciano Coelho writes: > On Wed, 2018-03-28 at 19:20 +0300, Kalle Valo wrote: >> Luca Coelho writes: >> >> > From: "Zamir, Roee" >> > >> > Get capabilities from the fw, expose them with nl80211, and enable >> > them >> > in UMAC

Re: [PATCH v2] wcn36xx: Disable 5GHz for wcn3610

(adding devicetree list) Ramon Fried writes: > wcn3610 can only operate on 2.4GHz band due to RF limitation. > If wcn36xx digital block is associated with an external IRIS > RF module, retrieve the id and disable 5GHz band in case of > wcn3610 id. > > Signed-off-by: Ramon

Re: [PATCH] wcn36xx: Disable 5GHz for wcn3610

On 3/29/2018 9:58 AM, Rafał Miłecki wrote: > On 03/29/2018 08:20 AM, Ramon Fried wrote: >> wcn3610 can only operate on 2.4GHz band due to RF limitation. >> If wcn36xx digital block is associated with an external IRIS >> RF module, retrieve the id and disable 5GHz band in case of >> wcn3610 id.

Re: [PATCH] wcn36xx: Disable 5GHz for wcn3610

On 03/29/2018 08:20 AM, Ramon Fried wrote: wcn3610 can only operate on 2.4GHz band due to RF limitation. If wcn36xx digital block is associated with an external IRIS RF module, retrieve the id and disable 5GHz band in case of wcn3610 id. Signed-off-by: Ramon Fried ---

[PATCH v2] wcn36xx: Disable 5GHz for wcn3610

wcn3610 can only operate on 2.4GHz band due to RF limitation. If wcn36xx digital block is associated with an external IRIS RF module, retrieve the id and disable 5GHz band in case of wcn3610 id. Signed-off-by: Ramon Fried --- v2: fixed wrong assignment, which is logically

[PATCH] wcn36xx: Disable 5GHz for wcn3610

wcn3610 can only operate on 2.4GHz band due to RF limitation. If wcn36xx digital block is associated with an external IRIS RF module, retrieve the id and disable 5GHz band in case of wcn3610 id. Signed-off-by: Ramon Fried --- drivers/net/wireless/ath/wcn36xx/main.c| 4