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 for
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.
Signed-of
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
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 firmware-6.bin_WLAN.RM.4.4.1-00102-QCARMSWP-1
'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 b/net/wireless/reg.c
ind
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
drivers/net/wireless/broadcom
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
> patches.
>
> Please let me
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 there, of
> course.
>
> Pl
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 in
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
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 for_each_net(), which is enoug
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 a/drivers/net/wireless/ath/ath10k/wmi.c
b/drivers/net/wireless/ath/ath10k/wmi.c
index
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 a/drivers/net/wireless/ath/ath6kl/debug.c
b/drivers/net/wireless/ath/ath6kl/debug.c
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 transf
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 p
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
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 a/net/netfilter/nf_conntrack_core.c
b/net/net
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
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 c
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
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 a/drivers/net/wireless/st/cw1200/txrx.c
b/drivers/net/wireless/st/c
Em Thu, 29 Mar 2018 16:26:33 +0200
Johannes Berg escreveu:
> 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?
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
---
drivers/net/wireless/rsi/rsi_91x_core.c | 11 +
drivers/net/wireless/rs
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 queues are unblocked after sendi
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: Amitkumar Karwar
---
drivers/net/wireless/rsi/rsi_91x_h
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
---
drivers/net/wireless/rsi/rsi_91x_mgmt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
d
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 need major improvements. Couple o
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
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.
> >
> > However, something seem
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 queues are unblocked after sendi
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
---
drivers/net/wireless/rsi/rsi_91x_core.c | 11 +
drivers/net/wireless/rs
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
---
drivers/net/wireless/rsi/rsi_91x_mgmt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
d
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 need major improvements. Couple o
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: Amitkumar Karwar
---
drivers/net/wireless/rsi/rsi_91x_h
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 change
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,
joh
Alright, I've applied all of this.
johannes
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
> wmi_prio_
+ 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 :-)
+ * @UPDATE_FILS
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 paramete
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 Kanchanap
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 HTT_MGMT_TX_CMPL_INFO_ACK_RSSI_MASK
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 packe
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)
>
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.
a72c92629108 ath: Remove unnecessary ath_bcast_mac and use eth_bro
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
> are captured only in extend
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 P
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
> scena
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.
>
> Si
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 ETSI
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 = &rrule->wmm_rule->ap[ac];
+ else
+ wmm_ac = &rrule->wmm_rule->client[ac];
+ qparam->cw_min = max_t(u
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 messages from the list in
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 buffer coruption and firm
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
> Signed-off-by: Kalle Valo
Patch
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: refactor ath10k_pci_dump_memory() in preparation fo
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 yet, suppressing the unkno
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 rtnl_dere
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 /sys/class/ieee80211/phy*/device/hwmon/hwmo
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 call ath10k_station_assoc(
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 5GHz sub-bands, becaus
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 have been fixed, a
On Wed, 2018-03-28 at 10:29 -0700, Peter Oh wrote:
> > + if (sdata->vif.type == NL80211_IFTYPE_AP)
> > + wmm_ac = &rrule->wmm_rule->ap[ac];
> > + else
> > + wmm_ac = &rrule->wmm_rule->client[ac];
> > + qparam->cw_min = max_t(u16, qparam->cw_min, wmm_ac->cw_min);
> > + qp
(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 wcn36xx digital block is associated with an exter
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 PIL (peripheral image loa
(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 the id and disable 5GHz b
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 scan if the relevant nl80211 flags are set by the
>> > userspace
(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 Fried
> ---
> v2: fixe
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.
>>
68 matches
Mail list logo
