* Re: ath10k: Cleanup calling ath10k_htt_rx_h_unchain
From: Kalle Valo @ 2016-10-04 15:30 UTC (permalink / raw)
To: Mohammed Shafi Shajakhan
Cc: ath10k, mohammed, linux-wireless, Mohammed Shafi Shajakhan
In-Reply-To: <1474981314-15987-1-git-send-email-mohammed@qca.qualcomm.com>
Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> wrote:
> From: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
>
> 'ath10k_htt_rx_h_unchain' is need to be called only if the return
> value from 'ath10k_htt_rx_amsdu_pop' is 1('chained msdu's'), this
> change makes it more explicit and avoids doing a skb_peek, fetching
> rx descriptor pointer, checking rx msdu decap format for the case of
> ret = 0 (unchained msdus). Found this change during code walk through,
> not sure if this addresses any issue.
>
> Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Failed to apply to pending branch
error: patch failed: drivers/net/wireless/ath/ath10k/htt_rx.c:1550
error: drivers/net/wireless/ath/ath10k/htt_rx.c: patch does not apply
stg import: Diff does not apply cleanly
Patch set to Changes Requested.
--
https://patchwork.kernel.org/patch/9351833/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [1/2] ath: export alpha2 helper
From: Kalle Valo @ 2016-10-04 15:02 UTC (permalink / raw)
To: Bartosz Markowski
Cc: ath10k, linux-wireless, Michal Kazior, Bartosz Markowski
In-Reply-To: <1470140454-3899-2-git-send-email-bartosz.markowski@tieto.com>
Bartosz Markowski <bartosz.markowski@tieto.com> wrote:
> From: Michal Kazior <michal.kazior@tieto.com>
>
> This will be helpful for drivers that can acquire
> alpha2 regulatory codes.
>
> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
> Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com>
2 patches applied to ath-next branch of ath.git, thanks.
d291d8e0592a ath: export alpha2 helper
209b2a68de76 ath10k: add platform regulatory domain support
--
https://patchwork.kernel.org/patch/9256535/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: ath10k: add cc_wraparound type for QCA9888 and QCA9884
From: Kalle Valo @ 2016-10-04 14:58 UTC (permalink / raw)
To: akolli; +Cc: ath10k, Anilkumar Kolli, akolli, linux-wireless
In-Reply-To: <1474026327-7065-1-git-send-email-akolli@qti.qualcomm.com>
akolli@qti.qualcomm.com wrote:
> From: Anilkumar Kolli <akolli@qti.qualcomm.com>
>
> During offchannel scan, iw survey dump shows wrong values.
> Fix this by assigning cycle counter wranarround type for
> QCA9888 and QCA9884, they share same config with QCA4019.
>
> Signed-off-by: Anilkumar Kolli <akolli@qti.qualcomm.com>
Patch applied to ath-next branch of ath.git, thanks.
bafe492610d5 ath10k: add cc_wraparound type for QCA9888 and QCA9884
--
https://patchwork.kernel.org/patch/9335581/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: ath10k: Provide provision to get Transmit Power Control stats for 10.4
From: Kalle Valo @ 2016-10-04 14:52 UTC (permalink / raw)
To: c_mkenna; +Cc: ath10k, linux-wireless, mkenna, Maharaja Kennadyrajan
In-Reply-To: <1473949819-29154-1-git-send-email-c_mkenna@qti.qualcomm.com>
c_mkenna@qti.qualcomm.com wrote:
> From: Maharaja Kennadyrajan <c_mkenna@qti.qualcomm.com>
>
> This patch helps to get the TPC stats for 10.4 fw variants.
>
> Signed-off-by: Maharaja Kennadyrajan <c_mkenna@qti.qualcomm.com>
Patch applied to ath-next branch of ath.git, thanks.
ac86aa5755db ath10k: provide provision to get Transmit Power Control stats for 10.4
--
https://patchwork.kernel.org/patch/9333777/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH RESEND v3] mwifiex: parse device tree node for PCIe
From: Rob Herring @ 2016-10-04 13:34 UTC (permalink / raw)
To: Amitkumar Karwar; +Cc: linux-wireless, devicetree, rajatja, Xinming Hu
In-Reply-To: <1475167183-18376-1-git-send-email-akarwar@marvell.com>
On Thu, Sep 29, 2016 at 10:09:43PM +0530, Amitkumar Karwar wrote:
> From: Xinming Hu <huxm@marvell.com>
>
> This patch derives device tree node from pcie bus layer framework.
> Device tree bindings file has been renamed(marvell-sd8xxx.txt ->
> marvell-8xxx.txt) to accomodate PCIe changes.
>
> Signed-off-by: Xinming Hu <huxm@marvell.com>
> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
> ---
> v2: Included vendor and product IDs in compatible strings for PCIe
> chipsets(Rob Herring)
> v3: Patch is created using -M option so that it will only include diff of
> original and renamed files(Rob Herring)
> Resend v3: Resending the patch because I missed to include device tree mailing
> while sending v3.
> ---
> .../{marvell-sd8xxx.txt => marvell-8xxx.txt} | 8 +++++---
> drivers/net/wireless/marvell/mwifiex/pcie.c | 20 ++++++++++++++++++++
> drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 3 ++-
> 3 files changed, 27 insertions(+), 4 deletions(-)
> rename Documentation/devicetree/bindings/net/wireless/{marvell-sd8xxx.txt => marvell-8xxx.txt} (91%)
>
> diff --git a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
> similarity index 91%
> rename from Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
> rename to Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
> index c421aba..dfe5f8e 100644
> --- a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
> +++ b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
> @@ -1,8 +1,8 @@
> -Marvell 8897/8997 (sd8897/sd8997) SDIO devices
> +Marvell 8897/8997 (sd8897/sd8997/pcie8997) SDIO/PCIE devices
> ------
>
> -This node provides properties for controlling the marvell sdio wireless device.
> -The node is expected to be specified as a child node to the SDIO controller that
> +This node provides properties for controlling the marvell sdio/pcie wireless device.
Capitalize SDIO/PCIe
> +The node is expected to be specified as a child node to the SDIO/PCIE controller that
> connects the device to the system.
>
> Required properties:
> @@ -10,6 +10,8 @@ Required properties:
> - compatible : should be one of the following:
> * "marvell,sd8897"
> * "marvell,sd8997"
> + * "pci11ab,2b42"
> + * "pci1b4b,2b42"
The string is pciVVVV,DDDD. Looks like you have vendor and device
swapped.
Rob
^ permalink raw reply
* [PATCH] mac80211: remove unnecessary mesh check
From: Johannes Berg @ 2016-10-04 13:32 UTC (permalink / raw)
To: linux-wireless; +Cc: Thomas Pedersen, Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
sta_info_get_bss() is equivalent to sta_info_get() in the
mesh case, since sta->sdata->bss will be NULL (it's only
set for AP/AP_VLAN interfaces.) Thus, the mesh check here
isn't actually needed - remove it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/mac80211/cfg.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index fd6541f3ade3..7d0172395589 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -357,10 +357,7 @@ static int ieee80211_add_key(struct wiphy *wiphy, struct net_device *dev,
mutex_lock(&local->sta_mtx);
if (mac_addr) {
- if (ieee80211_vif_is_mesh(&sdata->vif))
- sta = sta_info_get(sdata, mac_addr);
- else
- sta = sta_info_get_bss(sdata, mac_addr);
+ sta = sta_info_get_bss(sdata, mac_addr);
/*
* The ASSOC test makes sure the driver is ready to
* receive the key. When wpa_supplicant has roamed
--
2.8.1
^ permalink raw reply related
* Re: [PATCH] cfg80211: Add HT and VHT information in start_ap
From: Johannes Berg @ 2016-10-04 13:25 UTC (permalink / raw)
To: Malinen, Jouni; +Cc: linux-wireless@vger.kernel.org, Xu, Peng
In-Reply-To: <20161003211523.GA6585@jouni.qca.qualcomm.com>
> The main goal of this was to see if we can reduce actual driver
> implementation size and maybe even more so to prepare for 802.11ax
> changes (i.e., see what we are doing currently for configuring HT/VHT
> in a way that could be done better).
Fair enough.
> Looking at the current in-tree drivers, it looks like following
> approaches have been used:
>
> ath6kl:
> Use cfg80211_get_chandef_type(&info->chandef) != NL80211_CHAN_NO_HT
> to determine whether HT is enabled. No VHT support. HT-required case
> not covered. No parsing of HT/VHT IEs used.
Hmm. Wouldn't the supported rates IE still advertise the cookie for HT
only, to make sure HT-required was done?
[snip other drivers]
> So I guess there could be some code sharing and cleanup done with the
> existing in-tree drivers. Especially the mwifiex example looks like
> something that triggered us to look at this. I'm not sure we'd
> propose adding any new driver with the driver code itself doing
> HT/VHT IE parsing and since ath6kl did not do this either, I don't
> see us changing existing in-tree drivers to use this either.
Maybe Marvell folks would like to change something there.
> I'm not sure there would really be enough justification to add this
> specific patch due to the assumed user space update. Adding some of
> the HT/VHT element parsing in cfg80211 might benefit on or two of the
> in-tree drivers if their maintainers are interested in that.
Right, I agree. If we want to unify/combine anything, the best place to
do that would just be cfg80211 at this point. Adding both the API and
the parsing seems fairly pointless now, and evidently drivers can live
with the status quo.
> That said, without additional interest, I'm starting to lean towards
> using this as an example of what type of parameters we need to add
> for HE from the beginning and not merge this patch.
Ok. I agree that for HE we should consider this more carefully. I
haven't looked at HE AP side yet, so I don't really know what might be
needed there, but when we get to it we can discuss it.
I'll drop this patch then, and if Broadcom or you (ath6kl) want to add
more parsing to the respective drivers we can consider code sharing
with mwifiex that seems to have a more (but not fully) complete version
in there - probably would have to be rewritten for cfg80211, but still.
johannes
^ permalink raw reply
* Re: [v2] mwifiex: report wakeup for wowlan
From: Kalle Valo @ 2016-10-04 12:46 UTC (permalink / raw)
To: Rajat Jain
Cc: Amitkumar Karwar, Nishant Sarmukadam, linux-wireless, netdev,
Wei-Ning Huang, Brian Norris, Eric Caruso, Rajat Jain
In-Reply-To: <CACK8Z6Fe34xdvd5-=3dNmqKXYC=Qr9+kpG46eCV7uFArLW+yyQ@mail.gmail.com>
Rajat Jain <rajatja@google.com> writes:
> Hello Kalie,
>
> On Mon, Oct 3, 2016 at 6:04 AM, Kalle Valo <kvalo@codeaurora.org> wrote:
>> Rajat Jain <rajatja@google.com> wrote:
>>> Enable notifying wakeup source to the PM core in case of
>>> a wake on wireless LAN event.
>>>
>>> Signed-off-by: Wei-Ning Huang <wnhuang@google.com>
>>> Signed-off-by: Rajat Jain <rajatja@google.com>
>>> Tested-by: Wei-Ning Huang <wnhuang@chromium.org>
>>> Reviewed-by: Eric Caruso <ejcaruso@chromium.org>
>>> Acked-by: Amitkumar Karwar <akarwar@marvell.com>
>>
>> The commit log doesn't give any background info. Does this fix a bug or
>> why is it needed?
>
> Some of chromeos' features (called "darkresume" in chromeos
> terminology) use and track the wake up sources using the wakeup
> attributes in sysfs. Since the wireless device can wake up the host,
> hence we wanted to add it as a wakeup source to the system, and in the
> case of an actual wakeup event, trigger to the PM core that it was
> indeed caused by the device and it increments the different counters
> etc. In the absence of this patch, the feature wasn't working very
> well (as it was apparently confused about the cause of wake up).
Thanks, makes sense. Please add that to the commit and send v3.
--
Kalle Valo
^ permalink raw reply
* [PATCH 2/2] ath10k: Remove extraneous error message in tx alloc
From: Mohammed Shafi Shajakhan @ 2016-10-04 12:39 UTC (permalink / raw)
To: ath10k; +Cc: mohammed, linux-wireless, Mohammed Shafi Shajakhan
In-Reply-To: <1475584772-4091-1-git-send-email-mohammed@qca.qualcomm.com>
From: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Remove extraneous error message in 'ath10k_htt_tx_alloc_cont_frag_desc'
as the caller 'ath10k_htt_tx_alloc' already dumps a proper error
message
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
---
drivers/net/wireless/ath/ath10k/htt_tx.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/htt_tx.c b/drivers/net/wireless/ath/ath10k/htt_tx.c
index 786fbd7..4255c1a 100644
--- a/drivers/net/wireless/ath/ath10k/htt_tx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_tx.c
@@ -283,10 +283,8 @@ static int ath10k_htt_tx_alloc_cont_frag_desc(struct ath10k_htt *htt)
htt->frag_desc.vaddr = dma_alloc_coherent(ar->dev, size,
&htt->frag_desc.paddr,
GFP_KERNEL);
- if (!htt->frag_desc.vaddr) {
- ath10k_err(ar, "failed to alloc fragment desc memory\n");
+ if (!htt->frag_desc.vaddr)
return -ENOMEM;
- }
return 0;
}
--
1.9.1
^ permalink raw reply related
* [PATCH 1/2] ath10k: clean up HTT tx buffer allocation and free
From: Mohammed Shafi Shajakhan @ 2016-10-04 12:39 UTC (permalink / raw)
To: ath10k; +Cc: mohammed, linux-wireless, Mohammed Shafi Shajakhan
In-Reply-To: <1475584772-4091-1-git-send-email-mohammed@qca.qualcomm.com>
From: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
cleanup 'ath10k_htt_tx_alloc' by introducing the API's
'ath10k_htt_tx_alloc/free_{cont_txbuf, txdone_fifo} and
re-use them whereever needed
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
---
drivers/net/wireless/ath/ath10k/htt_tx.c | 76 +++++++++++++++++++++-----------
1 file changed, 51 insertions(+), 25 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/htt_tx.c b/drivers/net/wireless/ath/ath10k/htt_tx.c
index 7c072b6..786fbd7 100644
--- a/drivers/net/wireless/ath/ath10k/htt_tx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_tx.c
@@ -229,6 +229,33 @@ void ath10k_htt_tx_free_msdu_id(struct ath10k_htt *htt, u16 msdu_id)
idr_remove(&htt->pending_tx, msdu_id);
}
+static void ath10k_htt_tx_free_cont_txbuf(struct ath10k_htt *htt)
+{
+ size_t size;
+
+ if (!htt->txbuf.vaddr)
+ return;
+
+ size = htt->max_num_pending_tx * sizeof(struct ath10k_htt_txbuf);
+ dma_free_coherent(htt->ar->dev, size, htt->txbuf.vaddr,
+ htt->txbuf.paddr);
+}
+
+static int ath10k_htt_tx_alloc_cont_txbuf(struct ath10k_htt *htt)
+{
+ struct ath10k *ar = htt->ar;
+ size_t size;
+
+ size = htt->max_num_pending_tx * sizeof(struct ath10k_htt_txbuf);
+ htt->txbuf.vaddr = dma_alloc_coherent(ar->dev, size,
+ &htt->txbuf.paddr,
+ GFP_KERNEL);
+ if (!htt->txbuf.vaddr)
+ return -ENOMEM;
+
+ return 0;
+}
+
static void ath10k_htt_tx_free_cont_frag_desc(struct ath10k_htt *htt)
{
size_t size;
@@ -310,10 +337,26 @@ static int ath10k_htt_tx_alloc_txq(struct ath10k_htt *htt)
return 0;
}
+static void ath10k_htt_tx_free_txdone_fifo(struct ath10k_htt *htt)
+{
+ WARN_ON(!kfifo_is_empty(&htt->txdone_fifo));
+ kfifo_free(&htt->txdone_fifo);
+}
+
+static int ath10k_htt_tx_alloc_txdone_fifo(struct ath10k_htt *htt)
+{
+ int ret;
+ size_t size;
+
+ size = roundup_pow_of_two(htt->max_num_pending_tx);
+ ret = kfifo_alloc(&htt->txdone_fifo, size, GFP_KERNEL);
+ return ret;
+}
+
int ath10k_htt_tx_alloc(struct ath10k_htt *htt)
{
struct ath10k *ar = htt->ar;
- int ret, size;
+ int ret;
ath10k_dbg(ar, ATH10K_DBG_BOOT, "htt tx max num pending tx %d\n",
htt->max_num_pending_tx);
@@ -321,13 +364,9 @@ int ath10k_htt_tx_alloc(struct ath10k_htt *htt)
spin_lock_init(&htt->tx_lock);
idr_init(&htt->pending_tx);
- size = htt->max_num_pending_tx * sizeof(struct ath10k_htt_txbuf);
- htt->txbuf.vaddr = dma_alloc_coherent(ar->dev, size,
- &htt->txbuf.paddr,
- GFP_KERNEL);
- if (!htt->txbuf.vaddr) {
- ath10k_err(ar, "failed to alloc tx buffer\n");
- ret = -ENOMEM;
+ ret = ath10k_htt_tx_alloc_cont_txbuf(htt);
+ if (ret) {
+ ath10k_err(ar, "failed to alloc cont tx buffer: %d\n", ret);
goto free_idr_pending_tx;
}
@@ -343,8 +382,7 @@ int ath10k_htt_tx_alloc(struct ath10k_htt *htt)
goto free_frag_desc;
}
- size = roundup_pow_of_two(htt->max_num_pending_tx);
- ret = kfifo_alloc(&htt->txdone_fifo, size, GFP_KERNEL);
+ ret = ath10k_htt_tx_alloc_txdone_fifo(htt);
if (ret) {
ath10k_err(ar, "failed to alloc txdone fifo: %d\n", ret);
goto free_txq;
@@ -359,10 +397,7 @@ free_frag_desc:
ath10k_htt_tx_free_cont_frag_desc(htt);
free_txbuf:
- size = htt->max_num_pending_tx *
- sizeof(struct ath10k_htt_txbuf);
- dma_free_coherent(htt->ar->dev, size, htt->txbuf.vaddr,
- htt->txbuf.paddr);
+ ath10k_htt_tx_free_cont_txbuf(htt);
free_idr_pending_tx:
idr_destroy(&htt->pending_tx);
@@ -388,24 +423,15 @@ static int ath10k_htt_tx_clean_up_pending(int msdu_id, void *skb, void *ctx)
void ath10k_htt_tx_free(struct ath10k_htt *htt)
{
- int size;
-
tasklet_kill(&htt->txrx_compl_task);
idr_for_each(&htt->pending_tx, ath10k_htt_tx_clean_up_pending, htt->ar);
idr_destroy(&htt->pending_tx);
- if (htt->txbuf.vaddr) {
- size = htt->max_num_pending_tx *
- sizeof(struct ath10k_htt_txbuf);
- dma_free_coherent(htt->ar->dev, size, htt->txbuf.vaddr,
- htt->txbuf.paddr);
- }
-
+ ath10k_htt_tx_free_cont_txbuf(htt);
ath10k_htt_tx_free_txq(htt);
ath10k_htt_tx_free_cont_frag_desc(htt);
- WARN_ON(!kfifo_is_empty(&htt->txdone_fifo));
- kfifo_free(&htt->txdone_fifo);
+ ath10k_htt_tx_free_txdone_fifo(htt);
}
void ath10k_htt_htc_tx_complete(struct ath10k *ar, struct sk_buff *skb)
--
1.9.1
^ permalink raw reply related
* [PATCH 0/2] ath10k: Trivial cleanup in HTT tx buffer allocation
From: Mohammed Shafi Shajakhan @ 2016-10-04 12:39 UTC (permalink / raw)
To: ath10k; +Cc: mohammed, linux-wireless, Mohammed Shafi Shajakhan
From: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Pre-requisite cleanup changes for one time tx buffer allocation
to avoid contigous DMA tx buffer allocation failure for tx
(thanks Vasanth) for long hour stress testing with continuous wifi
down/up with multiple vaps in low memory systems. This change also
holds good as a trivial standalone cleanup change
Mohammed Shafi Shajakhan (2):
ath10k: clean up HTT tx buffer allocation and free
ath10k: Remove extraneous error message in tx alloc
drivers/net/wireless/ath/ath10k/htt_tx.c | 80 +++++++++++++++++++++-----------
1 file changed, 52 insertions(+), 28 deletions(-)
--
1.9.1
^ permalink raw reply
* Re: bcmdhd: Strange Power Save messages
From: Krishna Chaitanya @ 2016-10-04 12:37 UTC (permalink / raw)
To: Gucea Doru
Cc: Arend van Spriel, Arend van Spriel, Andra Paraschiv,
linux-wireless
In-Reply-To: <CANfLQrbRvQb5a2AsqY0jGYeuDqC1c_7x8tUbQSm2=QPt1gT5eA@mail.gmail.com>
On Tue, Oct 4, 2016 at 5:09 PM, Gucea Doru <gucea.doru@gmail.com> wrote:
> On Sat, Oct 1, 2016 at 2:52 PM, Arend van Spriel
>> <arend.vanspriel@broadcom.com> wrote:
>>>
>>>
>>> On 29-09-16 13:32, Gucea Doru wrote:
>>>> On Tue, Sep 27, 2016 at 12:03 PM, Gucea Doru <gucea.doru@gmail.com> wrote:
>>>>> What is the decision triggering the exit from the PS mode immediately
>>>>> after the ping request? I am asking this because 802.11 PS legacy
>>>>> specifies that the client should wait for a beacon with TIM set in
>>>>> order to wake up: in my case, there is no beacon between the ping
>>>>> request message and the Null frame that announces the exit from the PS
>>>>> mode.
>>>>
>>>>
>>>> Any help would be highly appreciated :)
>>>
>>> Actually though I already sent you are reply, but alas here it is.
>>>
>>> bcmdhd is our aosp driver. I am maintaining the upstream brcm80211
>>> drivers. Regardless your question is more for firmware running on the
>>> device. So like the same behavior would be observed when using brcmfmac
>>> with same firmware.
>>>
>>>> IEEE Std 802.11-2012, section 10.2.1.8 specifies that "when the STA
>>>> detects that the bit corresponding to its AID is 1 i the TIM, the STA
>>>> shall issue a PS Poll". In my capture there are cases when the STA
>>>> exits the PS mode without waiting for a beacon.
>>>
>>> It is a bit tricky, but the standard does not explicitly say the STA
>>> should be in power-save at any other time. So it is difficult to say
>>> what event occurred on the STA side to exit PS mode. Also STA means
>>> P2P-Client as you say. That means that you have multiple interfaces:
>>> regular STA and P2P-Client. So is the STA connected to some other AP or
>>> just not connected. wpa_supplicant will do intermittent scan or initiate
>>> scheduled scan by which firmware will scan at a certain interval. That
>>> is just some things I can come up with and I am sure there are more.
>
> I agree that there may be some events belonging to the regular STA
> interface that could trigger the Null Frame (which includes the exit
> from PS Mode). However, I would expect to see some management frames
> in the air before/after the Null Packet (e.g.: a Probe request in case
> of a scheduled scan). But in my case the trigger for the Null frame
> seems to be the ping request packet, the scenario is the same every
> time: ping request -> Block ACK -> Null Frame (Wireshark trace
> confirms this behavior).
>
> I thought that you had a power save optimization algorithm that keeps
> the card on a few milliseconds just to see if we can have a fast reply
> from the peer. Does this ring a bell? :)
>
> On Sat, Oct 1, 2016 at 3:02 PM, Krishna Chaitanya
> <chaitanya.mgit@gmail.com> wrote:
>> Keeping the STA aside, as far as AP is concerned the STA is still in PS,
>> so it should set the TIM/DTIM bit to 1 before sending out data to the STA.
>
> Not necessarily, see section 10.2.1.6/l from IEEE Std 802.11-2012:
> "When an AP is informed that a STA has changed to the Active mode,
> then the AP shall send buffered BUs (if any exist) to the STA without
> waiting for a PS Poll...."
Yes, but in this case the STA did not inform AP (as per sniffer captures)?
so AP should set TIM/DTIM...
^ permalink raw reply
* Re: bcmdhd: Strange Power Save messages
From: Gucea Doru @ 2016-10-04 11:39 UTC (permalink / raw)
To: Krishna Chaitanya
Cc: Arend van Spriel, Arend van Spriel, Andra Paraschiv,
linux-wireless
In-Reply-To: <CABPxzYKWJ=uGchDkEOd_jL__h5qiR_BAmkPJ-CiaQC-SF5JtCA@mail.gmail.com>
On Sat, Oct 1, 2016 at 2:52 PM, Arend van Spriel
> <arend.vanspriel@broadcom.com> wrote:
>>
>>
>> On 29-09-16 13:32, Gucea Doru wrote:
>>> On Tue, Sep 27, 2016 at 12:03 PM, Gucea Doru <gucea.doru@gmail.com> wrote:
>>>> What is the decision triggering the exit from the PS mode immediately
>>>> after the ping request? I am asking this because 802.11 PS legacy
>>>> specifies that the client should wait for a beacon with TIM set in
>>>> order to wake up: in my case, there is no beacon between the ping
>>>> request message and the Null frame that announces the exit from the PS
>>>> mode.
>>>
>>>
>>> Any help would be highly appreciated :)
>>
>> Actually though I already sent you are reply, but alas here it is.
>>
>> bcmdhd is our aosp driver. I am maintaining the upstream brcm80211
>> drivers. Regardless your question is more for firmware running on the
>> device. So like the same behavior would be observed when using brcmfmac
>> with same firmware.
>>
>>> IEEE Std 802.11-2012, section 10.2.1.8 specifies that "when the STA
>>> detects that the bit corresponding to its AID is 1 i the TIM, the STA
>>> shall issue a PS Poll". In my capture there are cases when the STA
>>> exits the PS mode without waiting for a beacon.
>>
>> It is a bit tricky, but the standard does not explicitly say the STA
>> should be in power-save at any other time. So it is difficult to say
>> what event occurred on the STA side to exit PS mode. Also STA means
>> P2P-Client as you say. That means that you have multiple interfaces:
>> regular STA and P2P-Client. So is the STA connected to some other AP or
>> just not connected. wpa_supplicant will do intermittent scan or initiate
>> scheduled scan by which firmware will scan at a certain interval. That
>> is just some things I can come up with and I am sure there are more.
I agree that there may be some events belonging to the regular STA
interface that could trigger the Null Frame (which includes the exit
from PS Mode). However, I would expect to see some management frames
in the air before/after the Null Packet (e.g.: a Probe request in case
of a scheduled scan). But in my case the trigger for the Null frame
seems to be the ping request packet, the scenario is the same every
time: ping request -> Block ACK -> Null Frame (Wireshark trace
confirms this behavior).
I thought that you had a power save optimization algorithm that keeps
the card on a few milliseconds just to see if we can have a fast reply
from the peer. Does this ring a bell? :)
On Sat, Oct 1, 2016 at 3:02 PM, Krishna Chaitanya
<chaitanya.mgit@gmail.com> wrote:
> Keeping the STA aside, as far as AP is concerned the STA is still in PS,
> so it should set the TIM/DTIM bit to 1 before sending out data to the STA.
Not necessarily, see section 10.2.1.6/l from IEEE Std 802.11-2012:
"When an AP is informed that a STA has changed to the Active mode,
then the AP shall send buffered BUs (if any exist) to the STA without
waiting for a PS Poll...."
^ permalink raw reply
* [PATCH 2/2] mwifiex: check hw_status in suspend and resume handlers
From: Amitkumar Karwar @ 2016-10-04 10:34 UTC (permalink / raw)
To: linux-wireless
Cc: Cathy Luo, Nishant Sarmukadam, rajatja, briannorris, Xinming Hu,
Amitkumar Karwar
In-Reply-To: <1475577253-1126-1-git-send-email-akarwar@marvell.com>
From: Xinming Hu <huxm@marvell.com>
We have observed a kernel crash when system immediately suspends
after booting. There is a race between suspend and driver
initialization paths.
This patch adds hw_status checks to fix the problem
Signed-off-by: Xinming Hu <huxm@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
drivers/net/wireless/marvell/mwifiex/pcie.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c
index ba9e068..376e01c 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -122,7 +122,8 @@ static int mwifiex_pcie_suspend(struct device *dev)
if (pdev) {
card = pci_get_drvdata(pdev);
- if (!card || !card->adapter) {
+ if (!card || !card->adapter ||
+ card->adapter->hw_status != MWIFIEX_HW_STATUS_READY) {
pr_err("Card or adapter structure is not valid\n");
return 0;
}
@@ -166,7 +167,8 @@ static int mwifiex_pcie_resume(struct device *dev)
if (pdev) {
card = pci_get_drvdata(pdev);
- if (!card || !card->adapter) {
+ if (!card || !card->adapter ||
+ card->adapter->hw_status != MWIFIEX_HW_STATUS_READY) {
pr_err("Card or adapter structure is not valid\n");
return 0;
}
--
1.9.1
^ permalink raw reply related
* [PATCH 1/2] mwifiex: reset card->adapter during device unregister
From: Amitkumar Karwar @ 2016-10-04 10:34 UTC (permalink / raw)
To: linux-wireless
Cc: Cathy Luo, Nishant Sarmukadam, rajatja, briannorris, Xinming Hu,
Amitkumar Karwar
From: Xinming Hu <huxm@marvell.com>
card->adapter gets initialized during device registration.
As it's not cleared, we may end up accessing invalid memory
in some corner cases. This patch fixes the problem.
Signed-off-by: Xinming Hu <huxm@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
drivers/net/wireless/marvell/mwifiex/pcie.c | 1 +
drivers/net/wireless/marvell/mwifiex/sdio.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c
index f1eeb73..ba9e068 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -3042,6 +3042,7 @@ static void mwifiex_unregister_dev(struct mwifiex_adapter *adapter)
pci_disable_msi(pdev);
}
}
+ card->adapter = NULL;
}
/* This function initializes the PCI-E host memory space, WCB rings, etc.
diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c b/drivers/net/wireless/marvell/mwifiex/sdio.c
index 8718950..4cad1c2 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.c
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
@@ -2066,6 +2066,7 @@ mwifiex_unregister_dev(struct mwifiex_adapter *adapter)
struct sdio_mmc_card *card = adapter->card;
if (adapter->card) {
+ card->adapter = NULL;
sdio_claim_host(card->func);
sdio_disable_func(card->func);
sdio_release_host(card->func);
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] cfg80211: cap 20MHz VHT bitrate at MCS 8
From: Johannes Berg @ 2016-10-04 9:32 UTC (permalink / raw)
To: Ben Greear, Pedersen, Thomas; +Cc: linux-wireless
In-Reply-To: <57E01026.9030604@candelatech.com>
Sorry - needed some time to think through this thread again.
> I think it is a moot point as far as this change goes: Regardless of
> whether the NIC should or not, it _does_. So, mis-reporting it up
> the stack only hides the issue and does not even give the user a clue
> that on-the-air encoding may be slightly off-spec.
Arguably, reporting something that *seems* sane, like this patch does,
will do more to hide it than reporting 0 which is clearly bogus, no?
I realize you were replying to whether or not the *driver* should
"misreport" it, but the same argument applies the other way here, imho.
> If the on-air encoding is an issue, then we need to hack the firmware
> to disable this 'feature', but that is a completely separate issue.
I guess it trusts rate control enough to try, and if it cannot be
received by a spec-abiding receiver, it won't use it due to the
failures ... not such a big deal I guess, even though it's odd.
Does /anyone/ know why the spec disallowed it? Perhaps those "system"
people you refer to?
> Once this patch goes in, someone might consider properly reporting
> CCK rx rates for 5Ghz band too: ath10k can do this 'feature' as
> well, at least in some firmware. Probably can reproduce by sending
> off-channel mgt frames on 5Ghz when associated on 2.4, or something
> similar to this. I was using ath9k as sniffer when I found this long
> ago, so at least ath9k needs the change....
I don't see how this is related? It's not advertising those rates, so
it probably also can't use/report them as far as mac80211 and the rest
of the stack are concerned.
johannes
^ permalink raw reply
* Re: nl80211 fine timing measurement support
From: Johannes Berg @ 2016-10-04 9:25 UTC (permalink / raw)
To: Arend van Spriel, Lior David, Luca Coelho
Cc: Maya Erez, Jouni Malinen, linux-wireless
In-Reply-To: <6b1f015b-2796-9821-25c6-d4d5070939c9@broadcom.com>
> If raw results are mainly used for analysis algorithms how about
> providing raw measurement data through debugfs. May even consider
> adding rtt calculation in cfg80211/mac80211 for drivers that choose
> to provide raw measurement data and still only report final RTT in
> nl80211 api.
>
I think the "analysis algorithms" in this case are what actually gives
you the distance value.
However, I don't think we should accept that everybody wants to run
their proprietary algorithms on top and expose only the values needed
for those. That makes the drivers only usable with additional
proprietary software, which may even be incompatible with the GPL.
If the algorithms are in the device, then we can expose the final
results, and that's most useful for applications in the API.
If they're not, then we need to expose something that can be used
without additional proprietary and device-specific algorithms.
If those algorithms cannot be run in the device, then we should put
them into the driver instead.
johannes
^ permalink raw reply
* Re: 802.11ad chip
From: Lior David @ 2016-10-04 9:10 UTC (permalink / raw)
To: Vikram, linux-wireless
In-Reply-To: <CALZLQ=Y+J8D6ChXhBjw6dCZPHCRTR0zWm1JRs7_ZsC9_+skA0Q@mail.gmail.com>
On 10/3/2016 8:13 AM, Vikram wrote:
> Hi,
>
> I want to purchase a 802.11ad chip which works with wil6210 linux
> driver on latest stable kernel 4.7.4. I want to test some 802.11ad
> WiGig functionalities.
>
> Please suggest me as to which one to buy.
>
> Regards,
> Vikram
>
Acer has a few laptops with a compatible 11ad chip. You can go to this site:
http://www.acer.com/ac/en/US/content/professional-models/laptops/travelmatep6
and filter "wireless LAN Standard" by "IEEE 802.11a/b/g/n/ac/ad"
on the left.
Also the TP-Link AD7200 router contains a compatible 11ad chip:
https://www.amazon.com/TP-Link-AD7200-Wireless-Tri-Band-Talon/dp/B01FRP2758
Thanks,
Lior
^ permalink raw reply
* Re: [PATCHv3] wireless: check A-MSDU inner frame source address on AP interfaces
From: Johannes Berg @ 2016-10-04 8:36 UTC (permalink / raw)
To: Michael Braun
Cc: kvalo, akarwar, nishants, Larry.Finger, Jes.Sorensen,
linux-wireless, projekt-wlan
In-Reply-To: <1475569759.5324.22.camel@sipsolutions.net>
On Tue, 2016-10-04 at 10:29 +0200, Johannes Berg wrote:
> > IEEE 802.11-2012 8.3.2.2 contains the note "NOTE—It is possible to
> > have different DA and SA parameter values in A-MSDU subframe
> > headers of the same A-MSDU as long as they all map to the same
> > Address 1 and Address 2 parameter values."
> >
> > I conclude that embedding multicast in unicast A-MSDU frames is
> > generally allowed, because "mapping" does not mean "be identical".
>
> Yeah, I saw this. It's not clear to me that they intended this
> wording to be about multicast though. I'm not really sure what they
> had in mind here, but there's an exception for multicast for DMS,
> which would seem pointless if they had intended this "mapping" to be
> about multicast.
>
> Then again, I don't know of any "address mapping" service or the like
> in the spec either.
Actually, I just came up with an explanation: The DA and RA can be
different, and the DA inside need not necessarily be the RA. Taken in
the context of the overall paragraph, that makes sense:
An A-MSDU contains only MSDUs whose DA and SA parameter values map
to the same receiver address (RA) and transmitter address (TA)
values, i.e., all the MSDUs are intended to be received by a single
receiver, and necessarily they are all transmitted by the same
transmitter. The rules for determining RA and TA are independent of
whether the frame body carries an A-MSDU.
NOTE—It is possible to have different DA and SA parameter values in
A-MSDU subframe headers of the same A-MSDU as long as they all map
to the same Address 1 and Address 2 parameter values.
Obviously, now that I think about it, your patch also would break
client mode since it would refuse to accept any A-MSDU with SA != TA,
which is highly unlikely in most cases, since traffic doesn't usually
originate from the AP.
Overall, it seems to me we should do the following:
* allow checking both DA and SA, by having optional arguments to the
function for this
* pass DA == RA for client mode (not when 4-addr)
* pass SA == TA for AP/VLAN modes (not when 4-addr)
* pass both on TDLS links
* pass both for IBSS mode (I think)
For the "to the AP" case, this of course also covers multicast, since
the DA is A3 and won't be checked.
johannes
^ permalink raw reply
* Re: [PATCHv3] wireless: check A-MSDU inner frame source address on AP interfaces
From: Johannes Berg @ 2016-10-04 8:29 UTC (permalink / raw)
To: Michael Braun
Cc: kvalo, akarwar, nishants, Larry.Finger, Jes.Sorensen,
linux-wireless, projekt-wlan
In-Reply-To: <f9d33317-f23f-9d5e-8e9e-1e63eff1882a@fem.tu-ilmenau.de>
> > First of all - there's nothing specific to "AP interfaces", which
> > you say in the subject, as far as I can tell? That should be
> > removed?
>
> >
> > >
> > > if (unlikely(ta &&
> > > + (iftype == NL80211_IFTYPE_AP ||
> > > + iftype == NL80211_IFTYPE_AP_VLAN)
> > > &&
> > > + !ether_addr_equal(ta, eth.h_source)
> > > + ))
> > > + goto purge;
>
> So the A-MSDU packets are only dropped if received by an interface in
> AP or AP_VLAN mode, not on client side, as my original issue was
> about arp/ip filters being circumvented on AP side.
D'oh. Not paying attention, I guess.
Nevertheless, why should this be conditional on the interface type? It
seems to me that we should apply this to any type? What if, for
example, another BSS client sends an A-MSDU encrypted with the GTK and
then fakes something inside that way? We verify today that only
multicast frames can be encrypted with the GTK, but that applies to the
outer header, so we're susceptible to a variant of the hole-196 attack,
afaict?
> > > IEEE 802.11-2012 mandates that the outer source mac address
> > > should match the inner source address (section 8.3.2.2). For the
> > > destination mac address, matching is not required (section
> > > 10.23.15).
> >
> > I think this is wrong. As we do not support DMS (yet), we should
> > adhere to 8.3.2.2 and only accept matching TA/SA and DA/RA.
>
> IEEE 802.11-2012 8.3.2.2 contains the note "NOTE—It is possible to
> have different DA and SA parameter values in A-MSDU subframe headers
> of the same A-MSDU as long as they all map to the same Address 1 and
> Address 2 parameter values."
>
> I conclude that embedding multicast in unicast A-MSDU frames is
> generally allowed, because "mapping" does not mean "be identical".
Yeah, I saw this. It's not clear to me that they intended this wording
to be about multicast though. I'm not really sure what they had in mind
here, but there's an exception for multicast for DMS, which would seem
pointless if they had intended this "mapping" to be about multicast.
Then again, I don't know of any "address mapping" service or the like
in the spec either.
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: fix CMD_FRAME for AP_VLAN
From: Johannes Berg @ 2016-10-04 8:19 UTC (permalink / raw)
To: M. Braun; +Cc: linux-wireless, projekt-wlan
In-Reply-To: <fb4aeb32-8a13-92e6-a84e-12a6228dc7a1@fami-braun.de>
On Mon, 2016-10-03 at 13:31 +0200, M. Braun wrote:
> Am 03.10.2016 um 13:03 schrieb M. Braun:
> >
> > because the in ieee80211_mgmt_tx the
>
> ups, that was the patch itself.
>
> I think I carried it over from ieee80211_add_key, that does
>
> >
> >
> > if (mac_addr) {
> > if (ieee80211_vif_is_mesh(&sdata->vif))
> > sta = sta_info_get(sdata, mac_addr);
> > else
> > sta = sta_info_get_bss(sdata, mac_addr);
> >
>
Ok, so that's there, but I still don't see the point - sta->sdata->bss
will be NULL for any mesh STA.
Thomas, do you remember anything about why you did this back in commit
ff973af74aa6932ca4758266bccec68e8135ddf7
Author: Thomas Pedersen <thomas@cozybit.com>
Date: Tue May 3 16:57:12 2011 -0700
nl80211: allow installing keys for a meshif
?
(yeah, long shot, it's 5.5 years ago ...)
johannes
^ permalink raw reply
* pull-request: mac80211-next 2016-10-04
From: Johannes Berg @ 2016-10-04 7:31 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-wireless
Hi Dave,
Here's a version with the conflicts resolved - had to jigger some
code around, but it's all described in the merge commit message.
Let me know if there's any problem.
Thanks,
johannes
The following changes since commit 9a8dd213d2a38349e5ea2ca8888400952112b45c:
Merge branch 'ncsi-next' (2016-10-04 02:11:58 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git tags/mac80211-next-for-davem-2016-10-04
for you to fetch changes up to 1e1430d5282bc3a572465ef3261eea793d98a653:
Merge remote-tracking branch 'net-next/master' into mac80211-next (2016-10-04 09:46:44 +0200)
----------------------------------------------------------------
This time around, we have
* Neighbor Awareness Networking (NAN) APIs
* a fix for a previous patch that caused memory corruption
in wireless extensions key settings
* beacon rate configuration for AP and mesh
* memory limits for mac80211's internal TXQs
* a (fairly involved) fix for the TXQ vs. crypto problems
* direct cfg80211 driver API for WEP keys
This also pulls in net-next to fix the merge conflicts, see
the merge commit for more details.
----------------------------------------------------------------
Ayala Beker (9):
cfg80211: add start / stop NAN commands
mac80211: add boilerplate code for start / stop NAN
cfg80211: add add_nan_func / del_nan_func
cfg80211: allow the user space to change current NAN configuration
cfg80211: provide a function to report a match for NAN
cfg80211: Provide an API to report NAN function termination
mac80211: implement nan_change_conf
mac80211: Implement add_nan_func and rm_nan_func
mac80211: Add API to report NAN function match
David Spinadel (1):
cfg80211: Add support for static WEP in the driver
Johannes Berg (3):
cfg80211: add checks for beacon rate, extend to mesh
cfg80211: wext: really don't store non-WEP keys
Merge remote-tracking branch 'net-next/master' into mac80211-next
Pedersen, Thomas (2):
mac80211: add offset_tsf driver op and use it for mesh
mac80211: mesh: decrease max drift
Purushottam Kushwaha (1):
cfg80211: Add support to configure a beacon data rate
Toke Høiland-Jørgensen (5):
mac80211: Move ieee802111_tx_dequeue() to later in tx.c
fq.h: Port memory limit mechanism from fq_codel
mac80211: Export fq memory limit information in debugfs
mac80211: Set lower memory limit for non-VHT devices
mac80211: Move reorder-sensitive TX handlers to after TXQ dequeue
include/net/cfg80211.h | 223 +++++++-
include/net/fq.h | 3 +
include/net/fq_impl.h | 7 +-
include/net/mac80211.h | 75 +++
include/uapi/linux/nl80211.h | 270 ++++++++-
net/mac80211/cfg.c | 208 +++++++
net/mac80211/chan.c | 6 +
net/mac80211/debugfs.c | 8 +
net/mac80211/debugfs_netdev.c | 12 +-
net/mac80211/driver-ops.c | 15 +
net/mac80211/driver-ops.h | 83 +++
net/mac80211/ieee80211_i.h | 26 +
net/mac80211/iface.c | 28 +-
net/mac80211/main.c | 8 +
net/mac80211/mesh_sync.c | 12 +-
net/mac80211/offchannel.c | 4 +-
net/mac80211/rx.c | 7 +-
net/mac80211/sta_info.c | 10 +-
net/mac80211/trace.h | 159 ++++++
net/mac80211/tx.c | 420 +++++++++-----
net/mac80211/util.c | 61 ++-
net/wireless/chan.c | 2 +
net/wireless/core.c | 35 ++
net/wireless/core.h | 7 +-
net/wireless/ibss.c | 5 +-
net/wireless/mlme.c | 1 +
net/wireless/nl80211.c | 1220 ++++++++++++++++++++++++++++++++---------
net/wireless/rdev-ops.h | 58 ++
net/wireless/sme.c | 6 +-
net/wireless/trace.h | 90 +++
net/wireless/util.c | 30 +-
net/wireless/wext-compat.c | 14 +-
net/wireless/wext-sme.c | 2 +-
33 files changed, 2682 insertions(+), 433 deletions(-)
^ permalink raw reply
* Re: [PATCH 2/3] mac80211: multicast to unicast conversion
From: Johannes Berg @ 2016-10-04 6:56 UTC (permalink / raw)
To: M. Braun; +Cc: linux-wireless
In-Reply-To: <7ff03edc-2c24-9038-6e69-0cd3456c8e24@fami-braun.de>
On Tue, 2016-10-04 at 06:36 +0200, M. Braun wrote:
> Am 30.09.2016 um 09:29 schrieb Johannes Berg:
> >
> > >
> > > +static ssize_t ieee80211_if_fmt_unicast(
> > > + const struct ieee80211_sub_if_data *sdata, char *buf,
> > > int
> > > buflen)
> >
> > That's a very ... unusual way to break the lines here
>
> it is the same style as used in debugfs_netdev.c for other
> attributes,
> see e.g. ieee80211_if_fmt_tsf, ieee80211_if_parse_tsf.
>
Fair enough, I didn't check. Maybe I'll change it all wholesale at some
other point then.
johannes
^ permalink raw reply
* Re: [PATCH 2/3] mac80211: multicast to unicast conversion
From: M. Braun @ 2016-10-04 4:36 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1475220560.17481.7.camel@sipsolutions.net>
Am 30.09.2016 um 09:29 schrieb Johannes Berg:
>> +static ssize_t ieee80211_if_fmt_unicast(
>> + const struct ieee80211_sub_if_data *sdata, char *buf, int
>> buflen)
>
> That's a very ... unusual way to break the lines here
it is the same style as used in debugfs_netdev.c for other attributes,
see e.g. ieee80211_if_fmt_tsf, ieee80211_if_parse_tsf.
Michael
^ permalink raw reply
* Re: [v2] mwifiex: report wakeup for wowlan
From: Rajat Jain @ 2016-10-04 0:16 UTC (permalink / raw)
To: Kalle Valo
Cc: Amitkumar Karwar, Nishant Sarmukadam, linux-wireless, netdev,
Wei-Ning Huang, Brian Norris, Eric Caruso, Rajat Jain
In-Reply-To: <20161003130407.4D94161803@smtp.codeaurora.org>
Hello Kalie,
On Mon, Oct 3, 2016 at 6:04 AM, Kalle Valo <kvalo@codeaurora.org> wrote:
> Rajat Jain <rajatja@google.com> wrote:
>> Enable notifying wakeup source to the PM core in case of
>> a wake on wireless LAN event.
>>
>> Signed-off-by: Wei-Ning Huang <wnhuang@google.com>
>> Signed-off-by: Rajat Jain <rajatja@google.com>
>> Tested-by: Wei-Ning Huang <wnhuang@chromium.org>
>> Reviewed-by: Eric Caruso <ejcaruso@chromium.org>
>> Acked-by: Amitkumar Karwar <akarwar@marvell.com>
>
> The commit log doesn't give any background info. Does this fix a bug or
> why is it needed?
Some of chromeos' features (called "darkresume" in chromeos
terminology) use and track the wake up sources using the wakeup
attributes in sysfs. Since the wireless device can wake up the host,
hence we wanted to add it as a wakeup source to the system, and in the
case of an actual wakeup event, trigger to the PM core that it was
indeed caused by the device and it increments the different counters
etc. In the absence of this patch, the feature wasn't working very
well (as it was apparently confused about the cause of wake up).
Thanks,
Rajat
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox