* [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
* Re: pull-request: mac80211-next 2016-09-30
From: David Miller @ 2016-10-04 0:07 UTC (permalink / raw)
To: johannes; +Cc: netdev, linux-wireless
In-Reply-To: <1475489220.5817.0.camel@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Mon, 03 Oct 2016 12:07:00 +0200
> On Mon, 2016-10-03 at 01:54 -0400, David Miller wrote:
>>
>> Could you please look into this and send me a new pull request with
>> the conflicts resolved?
>>
>
> Sure, will do (tomorrow, we have a holiday today).
>
> Would you prefer I send you the merge resolution for your tree, or just
> pull in net for a new pull request?
Resolve it using net-next since that is what I will pull it into.
^ permalink raw reply
* Re: Final 4.8 w-t build is wt-2016-10-03
From: Bob Copeland @ 2016-10-03 23:36 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless, Kalle Valo
In-Reply-To: <1651822.AbJigUgJvV@debian64>
On Mon, Oct 03, 2016 at 04:42:58PM +0200, Christian Lamparter wrote:
> Thanks for the timely update.
> I have a request: can you please pull Linus' kernel tags?
> Currently the last tag from Linus' is v4.4-rc4 [0] and
> everything between v4.4-rc5 and v4.8 is missing?!
I've done this now.
--
Bob Copeland %% http://bobcopeland.com/
^ permalink raw reply
* Re: [PATCH] cfg80211: Add HT and VHT information in start_ap
From: Malinen, Jouni @ 2016-10-03 21:15 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless@vger.kernel.org, Xu, Peng
In-Reply-To: <1473674982.29016.10.camel@sipsolutions.net>
T24gTW9uLCBTZXAgMTIsIDIwMTYgYXQgMTI6MDk6NDJQTSArMDIwMCwgSm9oYW5uZXMgQmVyZyB3
cm90ZToNCj4gSSBoYXZlIG5vIG1ham9yIG9iamVjdGlvbnMgdG8gdGhpcy4gSG93ZXZlciwgYSBm
ZXcgdGhpbmdzOg0KPiANCj4gMSkgYXJlIHlvdSBwbGFubmluZyB0byBhZGQgc3VwcG9ydCBmb3Ig
dGhpcyBpbnRvIGEga2VybmVsIGRyaXZlciBhdA0KPiDCoCDCoGFsbCwgYW55d2F5Pw0KPiAyKSBh
cmUgeW91IHBsYW5uaW5nIHRvIGhhdmUgYSBkcml2ZXIgdXBzdHJlYW0gdGhhdCBjb250YWlucyB0
aGUgbm93DQo+IMKgIMKgbmVjZXNzYXJ5IHBhcnNpbmc/DQo+IA0KPiBEZXBlbmRpbmcgb24gdGhl
IGFuc3dlcnMsIEkgc3VwcG9zZSB3ZSBjb3VsZC9zaG91bGQgbWVyZ2UgdGhpczoNCj4gDQo+IG5v
IMKgKiDCoDogZG9uJ3QgbWVyZ2UNCj4geWVzIG5vIDogbWVyZ2UNCj4geWVzIHllczogZG9uJ3Qg
bWVyZ2UsIHB1dCBwYXJzaW5nIGludG8gY2ZnODAyMTENCj4gDQo+IEkgZ3Vlc3M/DQoNClRoZSBt
YWluIGdvYWwgb2YgdGhpcyB3YXMgdG8gc2VlIGlmIHdlIGNhbiByZWR1Y2UgYWN0dWFsIGRyaXZl
cg0KaW1wbGVtZW50YXRpb24gc2l6ZSBhbmQgbWF5YmUgZXZlbiBtb3JlIHNvIHRvIHByZXBhcmUg
Zm9yIDgwMi4xMWF4DQpjaGFuZ2VzIChpLmUuLCBzZWUgd2hhdCB3ZSBhcmUgZG9pbmcgY3VycmVu
dGx5IGZvciBjb25maWd1cmluZyBIVC9WSFQgaW4NCmEgd2F5IHRoYXQgY291bGQgYmUgZG9uZSBi
ZXR0ZXIpLg0KDQpBcyB5b3Ugbm90ZWQgZWFybGllciwgdGhpcyB3b3VsZCBub3QgcmVhbGx5IGFs
bG93IHRoZSBkcml2ZXIgdG8gZHJvcCBpdHMNCkhUL1ZIVCByZWxhdGVkIHBhcnNpbmcgb3BlcmF0
aW9ucyB3aXRob3V0IG1ha2luZyBzdXJlIHVzZXIgc3BhY2UNCmNvbXBvbmVudHMgd2VyZSB1cGRh
dGVkIGFzIHdlbGwuIFRoZSBhcHByb2FjaCB0byBhdm9pZCB0aGF0IGlzIHRoYXQNCiJwYXJzaW5n
IGludG8gY2ZnODAyMTEiLg0KDQpMb29raW5nIGF0IHRoZSBjdXJyZW50IGluLXRyZWUgZHJpdmVy
cywgaXQgbG9va3MgbGlrZSBmb2xsb3dpbmcNCmFwcHJvYWNoZXMgaGF2ZSBiZWVuIHVzZWQ6DQoN
CmF0aDZrbDoNClVzZSBjZmc4MDIxMV9nZXRfY2hhbmRlZl90eXBlKCZpbmZvLT5jaGFuZGVmKSAh
PSBOTDgwMjExX0NIQU5fTk9fSFQgdG8NCmRldGVybWluZSB3aGV0aGVyIEhUIGlzIGVuYWJsZWQu
IE5vIFZIVCBzdXBwb3J0LiBIVC1yZXF1aXJlZCBjYXNlIG5vdA0KY292ZXJlZC4gTm8gcGFyc2lu
ZyBvZiBIVC9WSFQgSUVzIHVzZWQuDQoNCmJyY21mbWFjOg0KVXNlcyBpbmZvLT5jaGFuZGVmLiBO
b3QgY2xlYXIgaG93IEhUL1ZIVCBjb3VsZCBiZSBkaXNhYmxlZCBvciByZXF1aXJlZC4NCk5vdGU6
IFBhcnNlcyBCZWFjb24gSUVzIGZvciBDb3VudHJ5IGFuZCBTU0lEIChhcyBiYWNrdXAgZm9yIHNz
aWQgPT0NCk5VTEwhPyksIFJTTiwgV1BBLg0KDQptd2lmaWV4Og0KVXNlcyBpbmZvLT5jaGFuZGVm
LiBQYXJzZXMgQmVhY29uIHRhaWw6IEVuYWJsZXMgVkhUIGJhc2VkIG9uIHNlYXJjaGluZw0KaW5m
by0+YmVhY29uLnRhaWwgZm9yIFZIVCBDYXBhYmlsaXR5IGVsZW1lbnQuIFBhcnNlcyBIVCBDYXBh
YmlsaXR5IHRvDQpkZXRlcm1pbmUgd2hldGhlciBIVCBpcyB0byBiZSBzdXBwb3J0ZWQgYW5kIGFs
c28gdG8gc2V0IHZhcmlvdXMgSFQNCnBhcmFtZXRlcnMuIERvZXMgbm90IHNlZW0gdG8gaGF2ZSBz
dXBwb3J0IGZvciBIVC9WSFQtcmVxdWlyZWQuDQoNCg0KU28gSSBndWVzcyB0aGVyZSBjb3VsZCBi
ZSBzb21lIGNvZGUgc2hhcmluZyBhbmQgY2xlYW51cCBkb25lIHdpdGggdGhlDQpleGlzdGluZyBp
bi10cmVlIGRyaXZlcnMuIEVzcGVjaWFsbHkgdGhlIG13aWZpZXggZXhhbXBsZSBsb29rcyBsaWtl
DQpzb21ldGhpbmcgdGhhdCB0cmlnZ2VyZWQgdXMgdG8gbG9vayBhdCB0aGlzLiBJJ20gbm90IHN1
cmUgd2UnZCBwcm9wb3NlDQphZGRpbmcgYW55IG5ldyBkcml2ZXIgd2l0aCB0aGUgZHJpdmVyIGNv
ZGUgaXRzZWxmIGRvaW5nIEhUL1ZIVCBJRQ0KcGFyc2luZyBhbmQgc2luY2UgYXRoNmtsIGRpZCBu
b3QgZG8gdGhpcyBlaXRoZXIsIEkgZG9uJ3Qgc2VlIHVzIGNoYW5naW5nDQpleGlzdGluZyBpbi10
cmVlIGRyaXZlcnMgdG8gdXNlIHRoaXMgZWl0aGVyLg0KDQpJJ20gbm90IHN1cmUgdGhlcmUgd291
bGQgcmVhbGx5IGJlIGVub3VnaCBqdXN0aWZpY2F0aW9uIHRvIGFkZCB0aGlzDQpzcGVjaWZpYyBw
YXRjaCBkdWUgdG8gdGhlIGFzc3VtZWQgdXNlciBzcGFjZSB1cGRhdGUuIEFkZGluZyBzb21lIG9m
IHRoZQ0KSFQvVkhUIGVsZW1lbnQgcGFyc2luZyBpbiBjZmc4MDIxMSBtaWdodCBiZW5lZml0IG9u
IG9yIHR3byBvZiB0aGUNCmluLXRyZWUgZHJpdmVycyBpZiB0aGVpciBtYWludGFpbmVycyBhcmUg
aW50ZXJlc3RlZCBpbiB0aGF0LiBUaGF0IHNhaWQsDQp3aXRob3V0IGFkZGl0aW9uYWwgaW50ZXJl
c3QsIEknbSBzdGFydGluZyB0byBsZWFuIHRvd2FyZHMgdXNpbmcgdGhpcyBhcw0KYW4gZXhhbXBs
ZSBvZiB3aGF0IHR5cGUgb2YgcGFyYW1ldGVycyB3ZSBuZWVkIHRvIGFkZCBmb3IgSEUgZnJvbSB0
aGUNCmJlZ2lubmluZyBhbmQgbm90IG1lcmdlIHRoaXMgcGF0Y2guDQoNCi0tIA0KSm91bmkgTWFs
aW5lbiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUEdQIGlkIEVG
Qzg5NUZB
^ permalink raw reply
* [PATCH 3/3] ath6kl: configure SDIO when power is reapplied
From: James Minor @ 2016-10-03 18:00 UTC (permalink / raw)
To: linux-wireless, ath6kl
Cc: kvalo, julia.cartwright, steve.derosier, James Minor
In-Reply-To: <1475517604-17710-1-git-send-email-james.minor@ni.com>
When power is removed from the device, all of the SDIO settings
return to default. Fix that by reconfiguring after power is
applied.
Signed-off-by: James Minor <james.minor@ni.com>
Reviewed-by: Steve deRosier <steve.derosier@lairdtech.com>
---
drivers/net/wireless/ath/ath6kl/sdio.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/net/wireless/ath/ath6kl/sdio.c b/drivers/net/wireless/ath/ath6kl/sdio.c
index 8261e24..c2df075 100644
--- a/drivers/net/wireless/ath/ath6kl/sdio.c
+++ b/drivers/net/wireless/ath/ath6kl/sdio.c
@@ -75,6 +75,8 @@ struct ath6kl_sdio {
#define CMD53_ARG_FIXED_ADDRESS 0
#define CMD53_ARG_INCR_ADDRESS 1
+static int ath6kl_sdio_config(struct ath6kl *ar);
+
static inline struct ath6kl_sdio *ath6kl_sdio_priv(struct ath6kl *ar)
{
return ar->hif_priv;
@@ -526,8 +528,15 @@ static int ath6kl_sdio_power_on(struct ath6kl *ar)
*/
msleep(10);
+ ret = ath6kl_sdio_config(ar);
+ if (ret) {
+ ath6kl_err("Failed to config sdio: %d\n", ret);
+ goto out;
+ }
+
ar_sdio->is_disabled = false;
+out:
return ret;
}
--
1.9.1
^ permalink raw reply related
* [PATCH 1/3] ath6kl: fix busreqs so they can be reused when sg is cleaned up
From: James Minor @ 2016-10-03 18:00 UTC (permalink / raw)
To: linux-wireless, ath6kl
Cc: kvalo, julia.cartwright, steve.derosier, James Minor
In-Reply-To: <1475517604-17710-1-git-send-email-james.minor@ni.com>
To reuse the busreqs in case of hardware restart, they must be
properly reinitialized. If the scat_req pointer isn't reset to
0, __ath6kl_sdio_write_async() will assume there is sg work to be
done (causing a kernel OOPS).
Signed-off-by: James Minor <james.minor@ni.com>
Reviewed-by: Steve deRosier <steve.derosier@lairdtech.com>
---
drivers/net/wireless/ath/ath6kl/sdio.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath6kl/sdio.c b/drivers/net/wireless/ath/ath6kl/sdio.c
index eab0ab9..96ed060 100644
--- a/drivers/net/wireless/ath/ath6kl/sdio.c
+++ b/drivers/net/wireless/ath/ath6kl/sdio.c
@@ -703,8 +703,10 @@ static void ath6kl_sdio_cleanup_scatter(struct ath6kl *ar)
* ath6kl_hif_rw_comp_handler() with status -ECANCELED so
* that the packet is properly freed?
*/
- if (s_req->busrequest)
+ if (s_req->busrequest) {
+ s_req->busrequest->scat_req = 0;
ath6kl_sdio_free_bus_req(ar_sdio, s_req->busrequest);
+ }
kfree(s_req->virt_dma_buf);
kfree(s_req->sgentries);
kfree(s_req);
--
1.9.1
^ permalink raw reply related
* [PATCH 0/3] Allow ath6kl to be restarted
From: James Minor @ 2016-10-03 18:00 UTC (permalink / raw)
To: linux-wireless, ath6kl
Cc: kvalo, julia.cartwright, steve.derosier, James Minor
In-Reply-To: <1475510510-16906-1-git-send-email-james.minor@ni.com>
To work around a boot issue with the AR6234, I discovered a few
instances where error cleanup code is not working as expected.
A full solution for the boot issue is being worked up, but in the
mean time these fixes make error cleanup work properly.
James Minor (3):
ath6kl: fix busreqs so they can be reused when sg is cleaned up
ath6kl: after cleanup properly reflect that sg is disabled
ath6kl: configure SDIO when power is reapplied
drivers/net/wireless/ath/ath6kl/sdio.c | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
--
1.9.1
^ permalink raw reply
* [PATCH 2/3] ath6kl: after cleanup properly reflect that sg is disabled
From: James Minor @ 2016-10-03 18:00 UTC (permalink / raw)
To: linux-wireless, ath6kl
Cc: kvalo, julia.cartwright, steve.derosier, James Minor
In-Reply-To: <1475517604-17710-1-git-send-email-james.minor@ni.com>
This allows the hardware to be restarted, as it will cause the
sg to be reinitialized.
Signed-off-by: James Minor <james.minor@ni.com>
Reviewed-by: Steve deRosier <steve.derosier@lairdtech.com>
---
drivers/net/wireless/ath/ath6kl/sdio.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/wireless/ath/ath6kl/sdio.c b/drivers/net/wireless/ath/ath6kl/sdio.c
index 96ed060..8261e24 100644
--- a/drivers/net/wireless/ath/ath6kl/sdio.c
+++ b/drivers/net/wireless/ath/ath6kl/sdio.c
@@ -714,6 +714,8 @@ static void ath6kl_sdio_cleanup_scatter(struct ath6kl *ar)
spin_lock_bh(&ar_sdio->scat_lock);
}
spin_unlock_bh(&ar_sdio->scat_lock);
+
+ ar_sdio->scatter_enabled = false;
}
/* setup of HIF scatter resources */
--
1.9.1
^ permalink raw reply related
* Re: Final 4.8 w-t build is wt-2016-10-03
From: Bob Copeland @ 2016-10-03 15:41 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless, Kalle Valo
In-Reply-To: <1651822.AbJigUgJvV@debian64>
On Mon, Oct 03, 2016 at 04:42:58PM +0200, Christian Lamparter wrote:
> Hello,
>
> On Monday, October 3, 2016 9:45:07 AM CEST Bob Copeland wrote:
> > Per the subject, Linus released 4.8 yesterday so, unless I broke something
> > in recent conflict resolutions, wireless-testing is on pause until the
> > merge window closes in two weeks. Have a happy (Canadian) thanksgiving!
> >
> > https://git.kernel.org/cgit/linux/kernel/git/wireless/wireless-testing.git
>
> Thanks for the timely update.
> I have a request: can you please pull Linus' kernel tags?
> Currently the last tag from Linus' is v4.4-rc4 [0] and
> everything between v4.4-rc5 and v4.8 is missing?!
Sure, I can start including them. I stopped pushing them in 4.4 era
because I thought it might be too cluttered to have these non-wt tags
sitting around, but it's no problem to go back and push the old ones
and do that going forward.
--
Bob Copeland %% http://bobcopeland.com/
^ permalink raw reply
* Re: [RFC 0/3] of: add common bindings to (de)activate IEEE 802.11 bands
From: Rob Herring @ 2016-10-03 15:22 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: Mark Rutland, Frank Rowand, devicetree@vger.kernel.org,
Felix Fietkau, linux-wireless, ath9k-devel, ath9k-devel,
Kalle Valo
In-Reply-To: <20161002225059.16757-1-martin.blumenstingl@googlemail.com>
On Sun, Oct 2, 2016 at 5:50 PM, Martin Blumenstingl
<martin.blumenstingl@googlemail.com> wrote:
> There are at least two drivers (ath9k and mt76) out there, where
> devicetree authors need to override the enabled bands.
>
> For ath9k there is only one use-case: disabling a band which has been
> incorrectly enabled by the vendor in the EEPROM (enabling a band is not
> possible because the calibration data would be missing in the EEPROM).
> The mt76 driver (currently pending for review) however allows enabling
> and disabling the 2.4GHz and 5GHz band, see [0].
>
> Based on the discussion of (earlier versions of) my ath9k devicetree
> patch it was suggested [1] that we use enable- and disable- properties.
> The current patch implements:
> - bands can be enabled or disabled with the corresponding property
> - if both (disable and enable) properties are given and a driver asks
> whether the band is enabled then the logic will return false (= not
> enabled, preferring the disabled flag)
> - if both (disable and enable) properties are given and a driver asks
> whether the band is disabled then the logic will return true (again,
> preferring the disabled flag over the enabled flag)
>
> We can still change the logic to do what the mt76 driver does (I am
> fine with both solutions):
> - property not available: driver decides which bands to enable
> - property set to 0: disable the band
> - property set to 1: enable the band
I prefer this way. Really, I'd prefer just a boolean disable property.
I'm not sure why you need the enable. We usually have these tri-state
properties when you want not present to mean use the bootloader or
default setting. Try to make not present the most common case.
> The new code has been integrated into ath9k to demonstrate how to use
> it (with the benefit that the disable_2ghz and disable_5ghz settings
> from the ath9k_platform_data can now also be configured via .dts).
>
> open questions/decisions needed:
> - where to place this new code? I put it into drivers/of/of_ieee80211
> because that's where most other functions live.
> However, I found that this makes backporting the code harder (using
> wireless-backports from the driver-backports project [2])
We are generally moving subsystem specific code like this out of
drivers/of/, so please do that here. Maybe someone will get motivated
to move the other networking code out too.
> - we need a decision whether we want to go with two flags for each
> band (enable-ieee80211-band and disable-ieee80211-band) or if we
> prefer the solution from the mt76 driver (which means that the
> property for a band is absent for auto-detection, or
> ieee80211-band-enabled = <0/1> is specified. we could also move
> the 0 and 1 to a header file of course to make it easer to read,
> such as IEEE80211_BAND_ENABLED and IEEE80211_BAND_DISABLED)
Please don't add defines for this. 0/1 meaning false/true is clear enough IMO.
Rob
^ 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