* Re: [bug report] mac80211: Move reorder-sensitive TX handlers to after TXQ dequeue
From: Toke Høiland-Jørgensen @ 2016-10-12 15:57 UTC (permalink / raw)
To: Dan Carpenter; +Cc: linux-wireless
In-Reply-To: <20161012061458.GM12841@mwanda>
Dan Carpenter <dan.carpenter@oracle.com> writes:
> Hello Toke H=C3=B8iland-J=C3=B8rgensen,
>
> This is a semi-automatic email about new static checker warnings.
>
> The patch bb42f2d13ffc: "mac80211: Move reorder-sensitive TX handlers=20
> to after TXQ dequeue" from Sep 22, 2016, leads to the following=20
> Smatch complaint:
>
> net/mac80211/tx.c:3242 ieee80211_xmit_fast_finish()
> error: we previously assumed 'key' could be null (see line 3209)
>
> net/mac80211/tx.c
> 3208=09
> 3209 if (key)
> ^^^
> Check.
>
> 3210 info->control.hw_key =3D &key->conf;
> 3211=09
> 3212 ieee80211_tx_stats(skb->dev, skb->len);
> 3213=09
> 3214 if (hdr->frame_control & cpu_to_le16(IEEE80211_STYPE_QOS_DATA)) {
> 3215 tid =3D skb->priority & IEEE80211_QOS_CTL_TAG1D_MASK;
> 3216 *ieee80211_get_qos_ctl(hdr) =3D tid;
> 3217 hdr->seq_ctrl =3D ieee80211_tx_next_seq(sta, tid);
> 3218 } else {
> 3219 info->flags |=3D IEEE80211_TX_CTL_ASSIGN_SEQ;
> 3220 hdr->seq_ctrl =3D cpu_to_le16(sdata->sequence_number);
> 3221 sdata->sequence_number +=3D 0x10;
> 3222 }
> 3223=09
> 3224 if (skb_shinfo(skb)->gso_size)
> 3225 sta->tx_stats.msdu[tid] +=3D
> 3226 DIV_ROUND_UP(skb->len, skb_shinfo(skb)->gso_size);
> 3227 else
> 3228 sta->tx_stats.msdu[tid]++;
> 3229=09
> 3230 info->hw_queue =3D sdata->vif.hw_queue[skb_get_queue_mapping(skb)=
];
> 3231=09
> 3232 /* statistics normally done by ieee80211_tx_h_stats (but that
> 3233 * has to consider fragmentation, so is more complex)
> 3234 */
> 3235 sta->tx_stats.bytes[skb_get_queue_mapping(skb)] +=3D skb->len;
> 3236 sta->tx_stats.packets[skb_get_queue_mapping(skb)]++;
> 3237=09
> 3238 if (pn_offs) {
> ^^^^^^^
> Maybe when pn_offs is non-zero that implies key is non-NULL?
Yes, it does. fast_tx->pn_offs is set in ieee80211_check_fast_xmit()
which only sets it if fast_tx->key is set. The other call to
ieee80211_xmit_fast_finish() is in ieee80211_tx_dequeue() which also
only sets pn_offs if the key is set.
-Toke
^ permalink raw reply
* Re: [PATCH] rtlwifi: Fix regression caused by commit d86e64768859
From: Larry Finger @ 2016-10-12 15:39 UTC (permalink / raw)
To: Kalle Valo
Cc: devel, linux-wireless, Stable [ 4 . 8+ ], Julia Lawall,
Thorsten Leemhuis
In-Reply-To: <87r37mf1gi.fsf@kamboji.qca.qualcomm.com>
On 10/12/2016 02:53 AM, Kalle Valo wrote:
> Larry Finger <Larry.Finger@lwfinger.net> writes:
>
>> In commit d86e64768859 ("rtlwifi: rtl818x: constify local structures"),
>> the configuration struct for most of the drivers was changed to be
>> constant. The problem is that five of the modified drivers need to be
>> able to update the firmware name based on the exact model of the card.
>> As the file names were stored in one of the members of that struct,
>> these drivers would fail with a kernel BUG splat when they tried to
>> update the firmware name.
>>
>> Rather than reverting the previous commit, I used a suggestion by
>> Johannes Berg and made the firmware file name pointers be local to
>> the routines that update the software variables.
>>
>> The configuration struct of rtl8192cu, which was not touched in the
>> previous patch, is now constantfied.
>>
>> Fixes: d86e64768859 ("rtlwifi: rtl818x: constify local structures")
>> Suggested-by: Johannes Berg <johannes@sipsolutions.net>
>> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
>> Cc: Stable [4.8+] <stable@vger.kernel.org>
>
> This should be:
>
> Cc: Stable <stable@vger.kernel.org> # 4.8
I know that info should be at the end of the Cc for Stable; however, versions of
git since 2.6 are incorrectly mangling the line and producing the following:
Stable <stable@vger.kernel.org#4.8+>
Of course, the smtp server refuses to send that mail, thus I got creative with
my formatting.
Thanks for Thorsten's address. I will try to keep him notified of any future
regressions that I find. Thus far, I have only communicated with him indirectly
through LKML.
Larry
^ permalink raw reply
* Re: [PATCH] ath9k: Move generic entries below specific ones in ath_pci_id_table.
From: Valo, Kalle @ 2016-10-12 15:01 UTC (permalink / raw)
To: Vittorio Gambaletta (VittGam)
Cc: linux-wireless@vger.kernel.org, ath9k-devel,
ath9k-devel@venema.h4ckr.net, stable@vger.kernel.org
In-Reply-To: <6ae887d799b201d78b4474ab9bbf6917@vittgam.net>
"Vittorio Gambaletta (VittGam)" <linux-wireless@vittgam.net> writes:
>>> So, after seeing that the rest of the file is sorted this way (generic
>>> section after the specific ones), I concluded that the 0x002A sorting
>>> was wrong in the first place, and so is 0x0029. Then I sent this patch
>>> to fix this.
>>
>> I can't see how changing the order in ath_pci_id_table[] would make any
>> difference in functionality, but I might be missing something.
>
> It does: I've looked through the relevant code, and found that PCI device
> matching from that table is done sequentially in pci_match_id() from
> drivers/pci/pci-driver.c.
>
> So if a generic PCI_VDEVICE entry (that has both subvendor and subdevice =
IDs
> set to PCI_ANY_ID) is put before a more specific one (PCI_DEVICE_SUB), th=
en
> the generic PCI_VDEVICE entry will match first and will be used.
Ah, now it makes sense. Thanks for patiently explaining this to me :)
So to tell the full story I'll change the commit log to something like
below. Does it look ok to you?
----------------------------------------------------------------------
ath9k: Really fix LED polarity for some Mini PCI AR9220 MB92 cards.
The active_high LED of my Wistron DNMA-92 is still being recognized as
active_low on 4.7.6 mainline. When I was preparing my former commit
0f9edcdd88a9 ("ath9k: Fix LED polarity for some Mini PCI AR9220 MB92
cards.") to fix that I must have somehow messed up with testing, because
I tested the final version of that patch before sending it, and it was
apparently working; but now it is not working on 4.7.6 mainline.
I initially added the PCI_DEVICE_SUB section for 0x0029/0x2096 above the
PCI_VDEVICE section for 0x0029; but then I moved the former below the
latter after seeing how 0x002A sections were sorted in the file.
So if a generic PCI_VDEVICE entry (that has both subvendor and subdevice
IDs set to PCI_ANY_ID) is put before a more specific one
(PCI_DEVICE_SUB), then the generic PCI_VDEVICE entry will match first
and will be used.
With this patch, 0x0029/0x2096 has finally got active_high LED on 4.7.6.
Fixes: 0f9edcdd88a9 ("ath9k: Fix LED polarity for some Mini PCI AR9220 MB92=
cards.")
Cc: <stable@vger.kernel.org> #4.7+
Signed-off-by: Vittorio Gambaletta <linuxbugs@vittgam.net>
[kvalo@qca.qualcomm.com: improve the commit log based on email discussions]
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
----------------------------------------------------------------------
--=20
Kalle Valo=
^ permalink raw reply
* Re: [PATCH] rsi: update in vap_capabilities frame to device
From: Valo, Kalle @ 2016-10-12 14:39 UTC (permalink / raw)
To: Prameela Rani Garnepudi
Cc: linux-wireless@vger.kernel.org, hofrat@osadl.org,
xypron.glpk@gmx.de, prameela.garnepudi@redpinesignals.com
In-Reply-To: <87k2ddej46.fsf@kamboji.qca.qualcomm.com>
Kalle Valo <kvalo@codeaurora.org> writes:
> Prameela Rani Garnepudi <prameela.j04cs@gmail.com> writes:
>
>> added vap status(add/delete) field in vap capabilities frame to device
>> added sending vap capabilites frame(with vap status 'delete') in remove =
interface
>>
>> Signed-off-by: Prameela Rani Garnepudi <prameela.j04cs@gmail.com>
>
> Why? How is this better now? I'm sure there is a good reason why you add
> this but we don't know as the commit tells nothing we don't already know
> just from looking at the patch.
>
> The most important part of commit log is to answer the question "Why?",
> not "What?".
Oh, and USE capitalisation, punctuation and so on in the commit log. It
will be archived to git.
--=20
Kalle Valo=
^ permalink raw reply
* Re: [PATCH] rsi: update in boot parameters
From: Kalle Valo @ 2016-10-12 14:37 UTC (permalink / raw)
To: Prameela Rani Garnepudi
Cc: linux-wireless, johannes.berg, hofrat, xypron.glpk,
prameela.garnepudi
In-Reply-To: <1475660148-14087-1-git-send-email-prameela.j04cs@gmail.com>
Prameela Rani Garnepudi <prameela.j04cs@gmail.com> writes:
> Added more clock switch fields in boot parameters configured to device
>
> Signed-off-by: Prameela Rani Garnepudi <prameela.j04cs@gmail.com>
Why? How does this help?
> .tapll_info_g = {
> - .pll_reg_1 = cpu_to_le16((TA_PLL_N_VAL_20 << 8)|
> - (TA_PLL_M_VAL_20)),
> - .pll_reg_2 = cpu_to_le16(TA_PLL_P_VAL_20),
> + .pll_reg_1 = cpu_to_le16((TAPLL_N_VAL_20 << 8) |
> + (TAPLL_M_VAL_20)),
> + .pll_reg_2 = cpu_to_le16(TAPLL_P_VAL_20),
Doing changes from TA_PLL_N_VAL_20 to TAPLL_N_VAL_20 makes this hard to
review. Only one logical change per patch, please. And make style
changes separately from functional changes.
> },
> .pll960_info_g = {
> - .pll_reg_1 = cpu_to_le16((PLL960_P_VAL_20 << 8)|
> + .pll_reg_1 = cpu_to_le16((PLL960_P_VAL_20 << 8) |
Again unnecessary style change.
> -#define TA_PLL_M_VAL_20 8
> -#define TA_PLL_N_VAL_20 1
> -#define TA_PLL_P_VAL_20 4
> +#define TAPLL_M_VAL_20 8
> +#define TAPLL_N_VAL_20 1
> +#define TAPLL_P_VAL_20 4
I don't really see the point with the rename. Changing the spaces to
tabs I understand, though.
But now that you are just starting don't waste time doing code style
changes, instead focus on fixing functionality or adding new features.
The style changes can be done later when you are more familiar with
everything.
I stopped now, please resend without the style changes so that it's
easier to review.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] rsi: update in vap_capabilities frame to device
From: Kalle Valo @ 2016-10-12 14:29 UTC (permalink / raw)
To: Prameela Rani Garnepudi
Cc: linux-wireless, hofrat, xypron.glpk, prameela.garnepudi
In-Reply-To: <1474885981-6810-1-git-send-email-prameela.j04cs@gmail.com>
Prameela Rani Garnepudi <prameela.j04cs@gmail.com> writes:
> added vap status(add/delete) field in vap capabilities frame to device
> added sending vap capabilites frame(with vap status 'delete') in remove interface
>
> Signed-off-by: Prameela Rani Garnepudi <prameela.j04cs@gmail.com>
Why? How is this better now? I'm sure there is a good reason why you add
this but we don't know as the commit tells nothing we don't already know
just from looking at the patch.
The most important part of commit log is to answer the question "Why?",
not "What?".
> rsi_dbg(ERR_ZONE,
> - "%s: Interface type %d not supported\n", __func__,
> - vif->type);
> + "%s: Interface type %d not supported\n",
> + __func__, vif->type);
Unnecessary style change, please drop.
> - rsi_dbg(MGMT_TX_ZONE, "%s: Sending VAP capabilities frame\n", __func__);
> + rsi_dbg(MGMT_TX_ZONE,
> + "%s: Sending VAP capabilities frame\n", __func__);
Same here.
--
Kalle Valo
^ permalink raw reply
* Re: bcmdhd: Strange Power Save messages
From: Gucea Doru @ 2016-10-12 14:26 UTC (permalink / raw)
To: Arend van Spriel
Cc: Krishna Chaitanya, Arend van Spriel, Andra Paraschiv,
linux-wireless
In-Reply-To: <a948f377-5a87-e1a3-e56f-9768ee6d87a0@broadcom.com>
On Tue, Oct 11, 2016 at 10:12 PM, Arend van Spriel
<arend.vanspriel@broadcom.com> wrote:
> On 07-10-16 16:33, Gucea Doru wrote:
>> On Thu, Oct 6, 2016 at 10:25 AM, Arend Van Spriel
>> <arend.vanspriel@broadcom.com> wrote:
>>> On 6-10-2016 10:07, Gucea Doru wrote:
>>>> On Wed, Oct 5, 2016 at 11:12 AM, Arend Van Spriel
>>>> <arend.vanspriel@broadcom.com> wrote:
>>>>> On 4-10-2016 13:39, Gucea Doru 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? :)
>>>>>
>>>>> It does not. That would be implemented in firmware. As said I am working
>>>>> on brcmfmac/brcmsmac. So bcmdhd and firmware are not my expertise.
>>>>>
>>>>
>>>> Arend, could you please redirect me to a Broadcom firmware maintainer?
>>>
>>> Can you please elaborate on your platform, broadcom chipset, and what
>>> version of bcmdhd you are using.
>>>
>>
>> Platform: Nexus 5 running CM13 (Android 6.0.1)
>> Broadcom chipset: BCM4339 Wi-Fi Chipset
>> bcmdhd version:Dongle Host Driver, version 1.88.45 (r)
>>
>> Do you need more information?
>
> So can you indicate the mac addresses of the two nexus devices and which
> one is P2P-GO. I entered the wpa key you mentioned in your initial
> email, but my wireshark does not seem to be able to decrypt the packets,
> which makes it a bit harder to analyze.
Do you have a wpa-pwd entry "JYdrhZp3:DIRECT-35-Android_Intel" inside
Edit->Preferences->Protocols->IEEE 802.11->Decryption Keys? I use
Wireshark 2.0.4.
P2P-GO MAC: 66:89:9a:81:0d:95
P2P Client MAC: 66:89:9a:81:0f:20
Thanks,
Doru
^ permalink raw reply
* Re: TCP data throughput for BCM43362
From: Jörg Krause @ 2016-10-12 14:27 UTC (permalink / raw)
To: Arend Van Spriel
Cc: brcm80211-dev-list, Brett Rudley, Franky Lin, Hante Meuleman,
linux-wireless, Franky Lin, Arend van Spriel
In-Reply-To: <01642203-65dc-3b44-bbd4-2585bfdab15e@broadcom.com>
On Mi, 2016-10-12 at 10:11 +0200, Arend Van Spriel wrote:
> On 11-10-2016 8:14, Jörg Krause wrote:
> >
> >
> >
> > Hi Arend,
> >
> > Am 22. September 2016 16:00:36 MESZ, schrieb Arend Van Spriel <aren
> > d.vanspriel@broadcom.com>:
> > >
> > > Op 22 sep. 2016 14:52 schreef "Jörg Krause"
> > > <joerg.krause@embedded.rocks>:
> > > >
> > > >
> > > > On Do, 2016-09-22 at 10:09 +0200, Arend Van Spriel wrote:
> > > > >
> > > > > On 19-9-2016 8:36, Jörg Krause wrote:
> > > > > >
> > > > > >
> > > > > > Hi Arend,
> > > > > >
> > > > > > On Wed, 2016-09-14 at 20:13 +0200, Arend Van Spriel wrote:
> > > > > > >
> > > > > > >
> > > > > > > On 14-9-2016 15:41, Jörg Krause wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > On Mon, 2016-08-29 at 23:15 +0200, Jörg Krause wrote:
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Mi, 2016-08-24 at 20:35 +0200, Arend Van Spriel
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On 22-8-2016 15:37, Jörg Krause wrote:
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Hi all,
> > > > > > > > > > >
> > > > > > > > > > > I am back from vacation and I'd like to do more
> > > > > > > > > > > investigations
> > > > > > > > > > > about
> > > > > > > > > > > this issue. Please see my comments below...
> > > > > > > > > > >
> > > > > > > > > > > On Sun, 2016-08-07 at 13:41 +0200, Arend van
> > > > > > > > > > > Spriel
> > > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > On 06-08-16 16:12, Jörg Krause wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > Hi all,
> > > > > > > > > > > >
> > > > > > > > > > > > A bit weird email format making it a bit hard
> > > > > > > > > > > > to
> > > > > > > > > > > > determine
> > > > > > > > > > > > where
> > > > > > > > > > > > your
> > > > > > > > > > > > last reply starts...
> > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Fr, 2016-08-05 at 17:56 -0700, Franky Lin
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Fri, Aug 5, 2016 at 2:29 PM, Jörg Krause
> > > > > > > > > > > > > <joerg.krause
> > > > > > > > > > > > > @emb
> > > > > > > > > > > > > ed
> > > > > > > > > > > > > ded.
> > > > > > > > > > > > > ro
> > > > > > > > > > > > > cks>
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > Am 5. August 2016 23:01:10 MESZ, schrieb
> > > > > > > > > > > > > Arend Van
> > > > > > > > > > > > > Spriel
> > > > > > > > > > > > > <
> > > > > > > > > > > > > arend.vanspriel@broadcom.com>:
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > Op 5 aug. 2016 22:46 schreef "Jörg Krause"
> > > > > > > > > > > > > <joerg.krause@embedded.rocks>:
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > Hi,
> > > > > > > > > > > > >
> > > > > > > > > > > > > I'm using a custom ARM board with an BCM43362
> > > > > > > > > > > > > wifi
> > > > > > > > > > > > > chip
> > > > > > > > > > > > > from
> > > > > > > > > > > > >
> > > > > > > > > > > > > Broadcom.
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > The wifi chip is attached via SDIO to the
> > > controller
> > > >
> > > > >
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > with
> > > > > > > > > > > > > a
> > > > > > > > > > > > > clock of
> > > > > > > > > > > > > 48MHz. Linux kernel version is 4.7.
> > > > > > > > > > > > >
> > > > > > > > > > > > > When measuring the network bandwidth with
> > > > > > > > > > > > > iperf3 I
> > > > > > > > > > > > > get a
> > > > > > > > > > > > > bandwith of
> > > > > > > > > > > > > only around 5 Mbps. I found a similar thread
> > > > > > > > > > > > > at the
> > > > > > > > > > > > > Broadcom
> > > > > > > > > > > > >
> > > > > > > > > > > > > community
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > [1] where the test was done with a M4 CPU +
> > > BCM43362
> > > >
> > > > >
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > and
> > > > > > > > > > > > > an
> > > > > > > > > > > > > average
> > > > > > > > > > > > > result of 3.3 Mbps.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Interestingly, a BCM43362 Wi-Fi Dev Kit [2]
> > > > > > > > > > > > > notes a
> > > > > > > > > > > > > TCP
> > > > > > > > > > > > > data
> > > > > > > > > > > > >
> > > > > > > > > > > > > throughput
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > greater than 20 Mbps.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Why is the throughput I measured much lower?
> > > > > > > > > > > > > Note
> > > > > > > > > > > > > that I
> > > > > > > > > > > > > measured
> > > > > > > > > > > > > several times with almost no neighbor devices
> > > > > > > > > > > > > or
> > > > > > > > > > > > > networks.
> > > > > > > > > > > > >
> > > > > > > > > > > > > This is a test sample measured with iperf3:
> > > > > > > > > > > > >
> > > > > > > > > > > > > $ iperf3 -c 192.168.2.1 -i 1 -t 10
> > > > > > > > > > > > > Connecting to host 192.168.2.1, port 5201
> > > > > > > > > > > > > [ 4] local 192.168.2.155 port 36442
> > > > > > > > > > > > > connected
> > > to
> > > >
> > > > >
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > 192.168.2.1
> > > > > > > > > > > > >
> > > > > > > > > > > > > port
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > 5201
> > > > > > > > > > > > > [ ID]
> > > > > > > > > > > > > Interval Transfer Bandwidth
> > > > > > > > > > > > >
> > > Retr
> > > >
> > > > >
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > Cwn
> > > > > > > > > > > > > d
> > > > > > > > > > > > > [ 4] 0.00-1.00 sec 615
> > > > > > > > > > > > > KBytes 5.04
> > > > > > > > > > > > > Mbits/sec 0 56.6
> > > > > > > > > > > > > KBytes
> > > > > > > > > > > > > [ 4] 1.00-2.00 sec 622
> > > > > > > > > > > > > KBytes 5.10
> > > > > > > > > > > > > Mbits/sec 0 84.8
> > > > > > > > > > > > > KBytes
> > > > > > > > > > > > > [ 4] 2.00-3.00 sec 625
> > > > > > > > > > > > > KBytes 5.12
> > > > > > > > > > > > > Mbits/sec 0 113
> > > > > > > > > > > > > KBytes
> > > > > > > > > > > > > [ 4] 3.00-4.00 sec 571
> > > > > > > > > > > > > KBytes 4.68
> > > > > > > > > > > > > Mbits/sec 0 140
> > > > > > > > > > > > > KBytes
> > > > > > > > > > > > > [ 4] 4.00-5.00 sec 594
> > > > > > > > > > > > > KBytes 4.87
> > > > > > > > > > > > > Mbits/sec 0 167
> > > > > > > > > > > > > KBytes
> > > > > > > > > > > > > [ 4] 5.00-6.00 sec 628
> > > > > > > > > > > > > KBytes 5.14
> > > > > > > > > > > > > Mbits/sec 0 195
> > > > > > > > > > > > > KBytes
> > > > > > > > > > > > > [ 4] 6.00-7.00 sec 619
> > > > > > > > > > > > > KBytes 5.07
> > > > > > > > > > > > > Mbits/sec 0 202
> > > > > > > > > > > > > KBytes
> > > > > > > > > > > > > [ 4] 7.00-8.00 sec 608
> > > > > > > > > > > > > KBytes 4.98
> > > > > > > > > > > > > Mbits/sec 0 202
> > > > > > > > > > > > > KBytes
> > > > > > > > > > > > > [ 4] 8.00-9.00 sec 602
> > > > > > > > > > > > > KBytes 4.93
> > > > > > > > > > > > > Mbits/sec 0 202
> > > > > > > > > > > > > KBytes
> > > > > > > > > > > > > [ 4] 9.00-10.00 sec 537
> > > > > > > > > > > > > KBytes 4.40
> > > > > > > > > > > > > Mbits/sec 0 202
> > > > > > > > > > > > > KBytes
> > > > > > > > > > > > > - - - - - - - - - - - - - - - - - - - - -
> > > > > > > > > > > > > - - -
> > > -
> > > >
> > > > >
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > [ ID]
> > > > > > > > > > > > > Interval Transfer Bandwidth
> > > > > > > > > > > > >
> > > Retr
> > > >
> > > > >
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > [ 4] 0.00-10.00 sec 5.88
> > > > > > > > > > > > > MBytes 4.93
> > > > > > > > > > > > > Mbits/sec 0 sender
> > > > > > > > > > > > > [ 4] 0.00-10.00 sec 5.68
> > > > > > > > > > > > > MBytes 4.76
> > > > > > > > > > > > > Mbits/sec receiver
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > Not overly familiar with iperf3. Do these
> > > > > > > > > > > > > lines
> > > mean
> > > >
> > > > >
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > you
> > > > > > > > > > > > > are
> > > > > > > > > > > > > doing
> > > > > > > > > > > > > bidirectional test, ie. upstream and
> > > > > > > > > > > > > downstream at
> > > > > > > > > > > > > the
> > > > > > > > > > > > > same
> > > > > > > > > > > > > time.
> > > > > > > > > > > > > Another
> > > > > > > > > > > > > thing affecting tput could be power-save.
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > No, iperf3 does not support bidrectional
> > > > > > > > > > > > > test.
> > > Power-
> > > >
> > > > >
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > save
> > > > > > > > > > > > > is
> > > > > > > > > > > > > turned
> > > > > > > > > > > > > off.
> > > > > > > > > > > > >
> > > > > > > > > > > > > What does iw link say?
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > but I guess it starts here!
> > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > I compared the results with a Cubietruck I
> > > > > > > > > > > > > have:
> > > > > > > > > > > > >
> > > > > > > > > > > > > # iperf3 -s
> > > > > > > > > > > > > -------------------------------------------
> > > > > > > > > > > > > --------
> > > > > > > > > > > > > ----
> > > > > > > > > > > > > ----
> > > > > > > > > > > > > Server listening on 5201
> > > > > > > > > > > > > -------------------------------------------
> > > > > > > > > > > > > --------
> > > > > > > > > > > > > ----
> > > > > > > > > > > > > ----
> > > > > > > > > > > > > Accepted connection from 192.168.178.46, port
> > > > > > > > > > > > > 42906
> > > > > > > > > > > > > [ 5] local 192.168.178.38 port 5201
> > > > > > > > > > > > > connected to
> > > > > > > > > > > > > 192.168.178.46
> > > > > > > > > > > > > port
> > > > > > > > > > > > > 42908
> > > > > > > > > > > > > [ ID]
> > > > > > > > > > > > > Interval Transfer Bandwidth
> > > > > > > > > > > > > [ 5] 0.00-1.00 sec 2.29 MBytes 19.2
> > > > > > > > > > > > > Mbits/sec
> > > > > > > > > > > > > [ 5] 1.00-2.00 sec 2.21 MBytes 18.5
> > > > > > > > > > > > > Mbits/sec
> > > > > > > > > > > > > [ 5] 2.00-3.00 sec 2.17 MBytes 18.2
> > > > > > > > > > > > > Mbits/sec
> > > > > > > > > > > > > [ 5] 3.00-4.00 sec 2.09 MBytes 17.6
> > > > > > > > > > > > > Mbits/sec
> > > > > > > > > > > > > [ 5] 4.00-5.00 sec 2.20 MBytes 18.5
> > > > > > > > > > > > > Mbits/sec
> > > > > > > > > > > > > [ 5] 5.00-6.00 sec 2.64 MBytes 22.1
> > > > > > > > > > > > > Mbits/sec
> > > > > > > > > > > > > [ 5] 6.00-7.00 sec 2.67 MBytes 22.4
> > > > > > > > > > > > > Mbits/sec
> > > > > > > > > > > > > [ 5] 7.00-8.00 sec 2.62 MBytes 22.0
> > > > > > > > > > > > > Mbits/sec
> > > > > > > > > > > > > [ 5] 8.00-9.00 sec 2.35 MBytes 19.8
> > > > > > > > > > > > > Mbits/sec
> > > > > > > > > > > > > [ 5] 9.00-10.00 sec 2.30 MBytes 19.3
> > > > > > > > > > > > > Mbits/sec
> > > > > > > > > > > > > [ 5] 10.00-10.03 sec 83.4 KBytes 23.5
> > > > > > > > > > > > > Mbits/sec
> > > > > > > > > > > > > - - - - - - - - - - - - - - - - - - - - - - -
> > > > > > > > > > > > > - -
> > > > > > > > > > > > > [ ID]
> > > > > > > > > > > > > Interval Transfer Bandwidth
> > > > > > > > > > > > >
> > > Retr
> > > >
> > > > >
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > [ 5] 0.00-10.03 sec 23.9 MBytes 20.0
> > > > > > > > > > > > > Mbits/sec 0 sender
> > > > > > > > > > > > > [ 5] 0.00-10.03 sec 23.6 MBytes 19.8
> > > > > > > > > > > > > Mbits/sec receiver
> > > > > > > > > > > > >
> > > > > > > > > > > > > # iw dev wlan0 link
> > > > > > > > > > > > > Connected to xx:xx:xx:xx:xx (on wlan0)
> > > > > > > > > > > > > SSID: xxx
> > > > > > > > > > > > > freq: 2437
> > > > > > > > > > > > > tx bitrate: 65.0 MBit/s
> > > > > > > > > > > > >
> > > > > > > > > > > > > bss flags: short-preamble short-
> > > > > > > > > > > > > slot-
> > > > > > > > > > > > > time
> > > > > > > > > > > > > dtim period: 1
> > > > > > > > > > > > > beacon int: 100
> > > > > > > > > > > >
> > > > > > > > > > > > Too bad RSSI is not in the output above. That
> > > > > > > > > > > > may be
> > > > > > > > > > > > due to
> > > > > > > > > > > > a
> > > > > > > > > > > > regression
> > > > > > > > > > > > in our driver which has been fixed by commit
> > > > > > > > > > > > 94abd778a7bb
> > > > > > > > > > > > ("brcmfmac:
> > > > > > > > > > > > add fallback for devices that do not report
> > > > > > > > > > > > per-chain
> > > > > > > > > > > > values").
> > > > > > > > > > > > However,
> > > > > > > > > > > > the tx bitrate seems within the same range as
> > > > > > > > > > > > the
> > > other
> > > >
> > > > >
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > platform.
> > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > The Cubietruck works also with the brcmfmac
> > > > > > > > > > > > > driver.
> > > > > > > > > > > > >
> > > > > > > > > > > > > May it depend on the NVRAM file?
> > > > > > > > > > > >
> > > > > > > > > > > > Not sure. Can you tell me a bit more about the
> > > > > > > > > > > > custom
> > > > > > > > > > > > ARM
> > > > > > > > > > > > board.
> > > > > > > > > > > > Does
> > > > > > > > > > > > it
> > > > > > > > > > > > use the same wifi module as Cubietruck, ie. the
> > > > > > > > > > > > AMPAK
> > > > > > > > > > > > AP6210?
> > > > > > > > > > > > If
> > > > > > > > > > > > you
> > > > > > > > > > > > can
> > > > > > > > > > > > make a wireshark sniff we can check the actual
> > > bitrate
> > > >
> > > > >
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > and
> > > > > > > > > > > > medium
> > > > > > > > > > > > density in terms of packets. Another thing to
> > > > > > > > > > > > look at
> > > > > > > > > > > > is
> > > > > > > > > > > > the
> > > > > > > > > > > > SDIO
> > > > > > > > > > > > host
> > > > > > > > > > > > controller. In brcmf_sdiod_sgtable_alloc() some
> > > > > > > > > > > > key
> > > > > > > > > > > > values
> > > > > > > > > > > > are
> > > > > > > > > > > > used
> > > > > > > > > > > > from
> > > > > > > > > > > > the host controller. It only logs the number of
> > > entries
> > > >
> > > > >
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > of
> > > > > > > > > > > > the
> > > > > > > > > > > > scatter-gather table, but could you add the
> > > > > > > > > > > > other
> > > > > > > > > > > > values in
> > > > > > > > > > > > this
> > > > > > > > > > > > function that are used to determine the number
> > > > > > > > > > > > of
> > > > > > > > > > > > entries.
> > > > > > > > > > >
> > > > > > > > > > > My board uses the BCM43362 chip solely (no
> > > > > > > > > > > Bluetooth)
> > > > > > > > > > > attached to
> > > > > > > > > > > the
> > > > > > > > > > > SDIO interface of a NXP i.MX28 processor.
> > > > > > > > > > >
> > > > > > > > > > > I added some additional printk() to
> > > > > > > > > > > brcmf_sdiod_sgtable_alloc().
> > > > > > > > > > > These
> > > > > > > > > > > are the values printed after modprobe brcmfmac:
> > > > > > > > > > >
> > > > > > > > > > > [ 8.926657] sg_support=1
> > > > > > > > > > > [ 8.929440] max_blocks=511
> > > > > > > > > > > [ 8.932213] max_request_size=261632
> > > > > > > > > > > [ 8.935741] max_segment_count=52
> > > > > > > > > > > [ 8.939005] max_segment_size=65280
> > > > > > > > > > > [ 8.946095] nents=35
> > > > > > > > > >
> > > > > > > > > > Thanks. That looks good.
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Additionally I attached a xz compresses wireshark
> > > > > > > > > > > sniff
> > > > > > > > > > > while
> > > > > > > > > > > running
> > > > > > > > > > > iper3 between the BCM43362 running as in AP mode
> > > > > > > > > > > with
> > > > > > > > > > > iperf3
> > > > > > > > > > > as a
> > > > > > > > > > > server and a PC in station mode running iperf3 as
> > > > > > > > > > > a
> > > > > > > > > > > client.
> > > > > > > > > >
> > > > > > > > > > Looking at the sniff it seems you captured on the
> > > ethernet
> > > >
> > > > >
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > side.
> > > > > > > > > > That
> > > > > > > > > > does not give me any 802.11 specific info. Can you
> > > > > > > > > > make a
> > > > > > > > > > wireless
> > > > > > > > > > capture preferably without encryption.
> > > > > > > > >
> > > > > > > > > You,re right! Sorry for this mistake. I did a re-
> > > > > > > > > capture on
> > > > > > > > > the
> > > > > > > > > wireless side now.
> > > > > > > >
> > > > > > > > Anything new about this? Anything I can do to help?
> > > > > > >
> > > > > > > I missed your previous email. Was already wondering
> > > > > > > whether to
> > > > > > > ping
> > > > > > > you.
> > > > > > > Digging around in my email folders I found it so will
> > > > > > > take a
> > > look
> > > >
> > > > >
> > > > > >
> > > > > > >
> > > > > > > at
> > > > > > > it.
> > > > > >
> > > > > > Did you had some time to look at this?
> > > > >
> > > > > Ehm. I still only see TCP stuff. To capture 802.11 management
> > > frames
> > > >
> > > > >
> > > > > you
> > > > > need preferably a dedicated device using monitor mode [1].
> > > >
> > > > Stupid me! Now I used a monitor interface on a desktop to
> > > > monitor the
> > > > traffic between the BCM43362 operating in soft-AP mode and a
> > > > notebook
> > > > operating in managed mode.
> > > >
> > > > The BCM43362 runs the iperf server, the notebook the iperf
> > > > client.
> > >
> > > Thanks.
> > >
> > > Week almost through so might next week.
> >
> > Did you had some time to look at this?
>
> So the bcm43362 is your AP and running iperf server.
It is running the iperf server. It is running in station mode as well
as in AP mode, depending on the use case. The wireshark dump was taken
when the bcm43362 is operating in AP mode.
> What specs does the ARM on your custom board have?
Which specs do you mean?
> The trace shows that it does not do
> aggregation. What it does not show is whether A-MPDU was setup, ie.
> ADDBA message exchange. So could you create a similar capture
> including
> connection setup, ie. AUTH/ASSOC, etc.
Yes, I can do that. Note, that I am using wpa_supplicant 2.5 for AP
mode operation (not hostapd).
> Just to confirm. You are using the firmware from linux-firmware,
> right?
Right.
> Or are you using firmware from the wiced dev kit?
No. I guess you mean bcmdhd?
Best regards
Jörg Krause
^ permalink raw reply
* Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)
From: Johannes Berg @ 2016-10-12 14:22 UTC (permalink / raw)
To: Sergey Senozhatsky
Cc: Andy Lutomirski, David S. Miller, linux-wireless, netdev,
linux-kernel, Sergey Senozhatsky, linux-next, Stephen Rothwell,
Herbert Xu
In-Reply-To: <20161012141245.GA436@swordfish>
> > Can you elaborate on how exactly it kills your system?
>
> the last time I saw it it was a NULL deref at
> ieee80211_aes_ccm_decrypt.
Hm. I was expecting something within the crypto code would cause the
crash, this seems strange.
Anyway, I'm surely out of my depth wrt. the actual cause. Something
like the patch below probably works around it, but it's horribly
inefficient due to the locking and doesn't cover CMAC/GMAC either.
johannes
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 103187ca9474..e820f437f02e 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -27,6 +27,7 @@
#include <linux/leds.h>
#include <linux/idr.h>
#include <linux/rhashtable.h>
+#include <crypto/aes.h>
#include <net/ieee80211_radiotap.h>
#include <net/cfg80211.h>
#include <net/mac80211.h>
@@ -1224,6 +1225,10 @@ struct ieee80211_local {
spinlock_t rx_path_lock;
+ /* temporary buffers for software crypto */
+ u8 aad[2 * AES_BLOCK_SIZE];
+ u8 b_0[AES_BLOCK_SIZE];
+
/* Station data */
/*
* The mutex only protects the list, hash table and
diff --git a/net/mac80211/wpa.c b/net/mac80211/wpa.c
index b48c1e13e281..a3f17a710b85 100644
--- a/net/mac80211/wpa.c
+++ b/net/mac80211/wpa.c
@@ -405,8 +405,8 @@ static int ccmp_encrypt_skb(struct ieee80211_tx_data *tx, struct sk_buff *skb,
u8 *pos;
u8 pn[6];
u64 pn64;
- u8 aad[2 * AES_BLOCK_SIZE];
- u8 b_0[AES_BLOCK_SIZE];
+ u8 *aad = tx->local->aad;
+ u8 *b_0 = tx->local->b_0;
if (info->control.hw_key &&
!(info->control.hw_key->flags & IEEE80211_KEY_FLAG_GENERATE_IV) &&
@@ -460,9 +460,11 @@ static int ccmp_encrypt_skb(struct ieee80211_tx_data *tx, struct sk_buff *skb,
return 0;
pos += IEEE80211_CCMP_HDR_LEN;
+ spin_lock_bh(&tx->local->rx_path_lock);
ccmp_special_blocks(skb, pn, b_0, aad);
ieee80211_aes_ccm_encrypt(key->u.ccmp.tfm, b_0, aad, pos, len,
skb_put(skb, mic_len), mic_len);
+ spin_unlock_bh(&tx->local->rx_path_lock);
return 0;
}
@@ -534,8 +536,9 @@ ieee80211_crypto_ccmp_decrypt(struct ieee80211_rx_data *rx,
}
if (!(status->flag & RX_FLAG_DECRYPTED)) {
- u8 aad[2 * AES_BLOCK_SIZE];
- u8 b_0[AES_BLOCK_SIZE];
+ u8 *aad = rx->local->aad;
+ u8 *b_0 = rx->local->b_0;
+
/* hardware didn't decrypt/verify MIC */
ccmp_special_blocks(skb, pn, b_0, aad);
@@ -639,8 +642,8 @@ static int gcmp_encrypt_skb(struct ieee80211_tx_data *tx, struct sk_buff *skb)
u8 *pos;
u8 pn[6];
u64 pn64;
- u8 aad[2 * AES_BLOCK_SIZE];
- u8 j_0[AES_BLOCK_SIZE];
+ u8 *aad = tx->local->aad;
+ u8 *j_0 = tx->local->b_0;
if (info->control.hw_key &&
!(info->control.hw_key->flags & IEEE80211_KEY_FLAG_GENERATE_IV) &&
@@ -695,9 +698,11 @@ static int gcmp_encrypt_skb(struct ieee80211_tx_data *tx, struct sk_buff *skb)
return 0;
pos += IEEE80211_GCMP_HDR_LEN;
+ spin_lock_bh(&tx->local->rx_path_lock);
gcmp_special_blocks(skb, pn, j_0, aad);
ieee80211_aes_gcm_encrypt(key->u.gcmp.tfm, j_0, aad, pos, len,
skb_put(skb, IEEE80211_GCMP_MIC_LEN));
+ spin_unlock_bh(&tx->local->rx_path_lock);
return 0;
}
@@ -764,8 +769,9 @@ ieee80211_crypto_gcmp_decrypt(struct ieee80211_rx_data *rx)
}
if (!(status->flag & RX_FLAG_DECRYPTED)) {
- u8 aad[2 * AES_BLOCK_SIZE];
- u8 j_0[AES_BLOCK_SIZE];
+ u8 *aad = rx->local->aad;
+ u8 *j_0 = rx->local->b_0;
+
/* hardware didn't decrypt/verify MIC */
gcmp_special_blocks(skb, pn, j_0, aad);
^ permalink raw reply related
* Re: [PATCH] rsi: fix memory leak in module unload
From: Kalle Valo @ 2016-10-12 14:22 UTC (permalink / raw)
To: Prameela Rani Garnepudi
Cc: linux-wireless, johannes.berg, hofrat, xypron.glpk,
prameela.garnepudi
In-Reply-To: <1474447162-19956-1-git-send-email-prameela.j04cs@gmail.com>
Prameela Rani Garnepudi <prameela.j04cs@gmail.com> writes:
> debugfs entry removal statement moved inside CONFIG_RSI_DEBUGSFS flag
> added freeing of below structures
> * channel list for each supported band
> * rsi debugfs info
>
> Signed-off-by: Prameela Rani Garnepudi <prameela.j04cs@gmail.com>
[...]
> --- a/drivers/net/wireless/rsi/rsi_91x_mac80211.c
> +++ b/drivers/net/wireless/rsi/rsi_91x_mac80211.c
> @@ -194,6 +194,7 @@ static void rsi_register_rates_channels(struct rsi_hw *adapter, int band)
> void rsi_mac80211_detach(struct rsi_hw *adapter)
> {
> struct ieee80211_hw *hw = adapter->hw;
> + enum nl80211_band band;
>
> if (hw) {
> ieee80211_stop_queues(hw);
> @@ -201,7 +202,17 @@ void rsi_mac80211_detach(struct rsi_hw *adapter)
> ieee80211_free_hw(hw);
> }
>
> + for (band = 0; band < 2; band++) {
> + struct ieee80211_supported_band *sband =
> + &adapter->sbands[band];
> +
> + kfree(sband->channels);
> + }
Like Arend already mentioned[1] you should use NUM_NL80211_BANDS here
instead of hardcoded value. Yes, that will also go through
NL80211_BAND_60GHZ item but it doesn't matter as it should be empty
anyway.
[1] https://patchwork.kernel.org/patch/9341095/
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] ath9k: Move generic entries below specific ones in ath_pci_id_table.
From: Vittorio Gambaletta (VittGam) @ 2016-10-12 14:13 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, ath9k-devel, ath9k-devel, stable
In-Reply-To: <87eg3lg07d.fsf@kamboji.qca.qualcomm.com>
Hello,
On 12/10/2016 15:34:46 CEST, Kalle Valo wrote:
> "Vittorio Gambaletta (VittGam)" <linux-wireless@vittgam.net> writes:
>
>> Hello,
>>
>> On 04/10/2016 17:46:44 CEST, Kalle Valo wrote:
>>> "Vittorio Gambaletta (VittGam)" <linux-wireless@vittgam.net> writes:
>>>
>>>> If generic entries are positioned above specific ones, then the
>>>> former will be matched first and used instead of the latter.
>>>>
>>>> Cc: <linux-wireless@vger.kernel.org>
>>>> Cc: <ath9k-devel@qca.qualcomm.com>
>>>> Cc: <ath9k-devel@lists.ath9k.org>
>>>> Cc: <stable@vger.kernel.org>
>>>> Signed-off-by: Vittorio Gambaletta <linuxbugs@vittgam.net>
>>>
>>> Why? What kind of bug you are fixing? You are not really describing the
>>> problem you are trying fix.
>>
>> The active_high LED of my Wistron DNMA-92 is still being recognized as
>> active_low on 4.7.6 mainline.
>
> This kind of information is important, always add that to the commit log
> so that we don't need to guess.
Okay, sorry about missing that before.
>> When I was preparing my former patch to fix that, I initially added the
>> PCI_DEVICE_SUB section for 0x0029/0x2096 above the PCI_VDEVICE section
>> for 0x0029; but then I moved the former below the latter after seeing
>> how 0x002A sections were sorted in the file.
>>
>> I must have somehow messed up with testing, because I tested the final
>> version of that patch before sending it, and it was apparently working;
>> but now it is not working on 4.7.6 mainline.
>>
>> With this patch, 0x0029/0x2096 has finally got active_high LED on
>> 4.7.6.
>
> I'm confused, are you now saying that this patch doesn't work?
No: the previous patch (which is already merged and added the LED driver_data
for my card) doesn't work. This one does work.
>> So, after seeing that the rest of the file is sorted this way (generic
>> section after the specific ones), I concluded that the 0x002A sorting
>> was wrong in the first place, and so is 0x0029. Then I sent this patch
>> to fix this.
>
> I can't see how changing the order in ath_pci_id_table[] would make any
> difference in functionality, but I might be missing something.
It does: I've looked through the relevant code, and found that PCI device
matching from that table is done sequentially in pci_match_id() from
drivers/pci/pci-driver.c.
So if a generic PCI_VDEVICE entry (that has both subvendor and subdevice IDs
set to PCI_ANY_ID) is put before a more specific one (PCI_DEVICE_SUB), then
the generic PCI_VDEVICE entry will match first and will be used.
>>> And your email headers look weird:
>>>
>>> To: <kvalo@codeaurora.org>
>>> Cc: <linux-wireless@vger.kernel.org>
>>> Cc: <ath9k-devel@qca.qualcomm.com>
>>> Cc: <ath9k-devel@venema.h4ckr.net>
>>> Cc: <stable@vger.kernel.org>
>>> Date: Mon, 3 Oct 2016 12:00:56 +0200
>>>
>>> What software are you using to send this? Only one CC header is valid
>>> according to the spec (thanks to Luca for checking) even though mailers
>>> seem to handle multiple CC headers. But for example my patchwork script
>>> fails with this and uses only the first CC header.
>>
>> Sorry about this, I used a custom mailer to send the patch since I was
>> having problems with git-send-email...
>
> Ok, that explains it.
^ permalink raw reply
* Re: [PATCH] rsi: fix memory lean in module unload
From: Kalle Valo @ 2016-10-12 14:14 UTC (permalink / raw)
To: Prameela Rani Garnepudi
Cc: linux-wireless, johannes.berg, hofrat, xypron.glpk
In-Reply-To: <1474437546-6590-1-git-send-email-prameela.j04cs@gmail.com>
Prameela Rani Garnepudi <prameela.j04cs@gmail.com> writes:
> Moved debugfs entry removal under CONFIG_RSI_DEBUGFS flag
> Added freeing of below structures
> * channels list in each supported band
> * rsi debugfs info
>
> Signed-off-by: Prameela Rani Garnepudi <prameela.j04cs@gmail.com>
There are four similar patches without any version information:
[ 1] rsi: fix memory leak in debugfs entry and supported bands 2016-09-19 Prameela Ran Deferred
[ 2] [1/1] rsi: fix memory leak in debugfs entry and supported... 2016-09-20 Prameela Ran Deferred
[ 3] rsi: fix memory lean in module unload 2016-09-21 Prameela Ran Deferred
[ 4] rsi: fix memory leak in module unload 2016-09-21 Prameela Ran Deferred
When sending a new version of the patch please add a version number to
it. See the instructions for more:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#subject_name
--
Kalle Valo
^ permalink raw reply
* Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)
From: Sergey Senozhatsky @ 2016-10-12 14:12 UTC (permalink / raw)
To: Johannes Berg
Cc: Sergey Senozhatsky, Andy Lutomirski, David S. Miller,
linux-wireless, netdev, linux-kernel, Sergey Senozhatsky,
linux-next, Stephen Rothwell, Herbert Xu
In-Reply-To: <1476263106.5271.23.camel@sipsolutions.net>
Hello,
On (10/12/16 11:05), Johannes Berg wrote:
> Sorry - I meant to look into this yesterday but forgot.
>
> > Andy, can this be related to CONFIG_VMAP_STACK?
>
> I think it is.
yeah, the system works fine with !CONFIG_VMAP_STACK.
> > > current -git kills my system.
>
> Can you elaborate on how exactly it kills your system?
the last time I saw it it was a NULL deref at ieee80211_aes_ccm_decrypt.
-ss
^ permalink raw reply
* Re: QCA9887 Firmware Memory Usage
From: Sebastian Gottschall @ 2016-10-12 14:12 UTC (permalink / raw)
To: Valo, Kalle, David Hutchison
Cc: ath10k@lists.infradead.org, linux-wireless@vger.kernel.org
In-Reply-To: <8760oxfzg4.fsf@kamboji.qca.qualcomm.com>
Am 12.10.2016 um 15:51 schrieb Valo, Kalle:
> David Hutchison <dhutchison@bluemesh.net> writes:
>
>> I am using a Mikrotik hAP AC Lite which has a QCA9887 radio. It
>> appears to be working; however ath10k ( or the qca9887 firmware ) is
>> utilizing 15 - 20mb of memory. I applied the kfree(caldata) patch, to
>> insure there is no memory leak.
>>
>> It doesn't appear to be leaking, and it will run Ok with the high
>> memory footprint. However the Mikrotik hAP AC Lite is only a 64mb
>> platform; so when I initialize the 2nd radio with ath9k I get OOMs.
>>
>> It just doesn't seem right that when ath10k + qca9887 is in AP mode
>> that it's utilizing as much memory as it is. I don't think the issue
>> is with ath10k, I think it's the qca9887 firmware (
>> firmware-5.bin_10.2.4-1.0-00013 ).
>>
>> Is there a newer build available that may potentially fix these memory
>> issues? The latest one available on
>> https://github.com/kvalo/ath10k-firmware/blob/master/QCA9887/hw1.0/firmware-5.bin_10.2.4-1.0-00013
>> is 2 months old. Perhaps there is a newer build to test that may have
>> the fix?
>>
>> Any thoughts as to what it could be? I can provide more information if needed.
> 64MB of RAM nowadays is not much and ath10k is not really tested in such
> setups AFAIK. I guess you could try if reducing TARGET_10X_NUM_MSDU_DESC
> helps with the memory consumption, but no idea if that would even work
> without further modifications to ath10k.
>
> Also if you have fq-codel&co enabled that might increase memory
> consumption. Adding linux-wireless as people there might have better
the high memory consumption is a very common old problem. and no, 64 mb
might not by much. but consider that qca9880 cards for instance are only
used on embedded devices.
there is not even a windows driver available for it. its mainly used in
routers and 64 mb ram is not uncommon here.
the problem with qca9887 sounds similar here. and the best. it only
occures on ath10k. with the closed source qca driver it will work on
embedded platforms. since
it was mentioned that this problem is caused by the firmware itself. so
there wont be a solution until qca is finally getting in touch with this
problem
> ideas.
>
--
Mit freundlichen Grüssen / Regards
Sebastian Gottschall / CTO
NewMedia-NET GmbH - DD-WRT
Firmensitz: Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565
^ permalink raw reply
* Re: [PATCH 1/2] ath10k: add per peer htt tx stats support for 10.4
From: Valo, Kalle @ 2016-10-12 13:59 UTC (permalink / raw)
To: Yeoh Chun-Yeow
Cc: Kolli, Anilkumar, akolli@codeaurora.org,
linux-wireless@vger.kernel.org, ath10k@lists.infradead.org
In-Reply-To: <CAEFj9859-wSpMGJrr+Fzr8QZASBs2r-W3XByH+PD_5h8zMS-rQ@mail.gmail.com>
Yeoh Chun-Yeow <yeohchunyeow@gmail.com> writes:
>> My understanding is that 10.2 branch does not have this feature,
>> unfortunately.
>>
>
> Alright, noted.
>
> Is QCA988X going to have firmware 10.4 support?
I wish it would have but I don't know the current status.
--=20
Kalle Valo=
^ permalink raw reply
* Re: QCA9887 Firmware Memory Usage
From: Valo, Kalle @ 2016-10-12 13:51 UTC (permalink / raw)
To: David Hutchison
Cc: ath10k@lists.infradead.org, linux-wireless@vger.kernel.org
In-Reply-To: <CA+i30h8YsG7mce5FMwGw2fRNAn3USYV6K==QMjMQVeSGB0dj=w@mail.gmail.com>
David Hutchison <dhutchison@bluemesh.net> writes:
> I am using a Mikrotik hAP AC Lite which has a QCA9887 radio. It
> appears to be working; however ath10k ( or the qca9887 firmware ) is
> utilizing 15 - 20mb of memory. I applied the kfree(caldata) patch, to
> insure there is no memory leak.
>
> It doesn't appear to be leaking, and it will run Ok with the high
> memory footprint. However the Mikrotik hAP AC Lite is only a 64mb
> platform; so when I initialize the 2nd radio with ath9k I get OOMs.
>
> It just doesn't seem right that when ath10k + qca9887 is in AP mode
> that it's utilizing as much memory as it is. I don't think the issue
> is with ath10k, I think it's the qca9887 firmware (
> firmware-5.bin_10.2.4-1.0-00013 ).
>
> Is there a newer build available that may potentially fix these memory
> issues? The latest one available on
> https://github.com/kvalo/ath10k-firmware/blob/master/QCA9887/hw1.0/firmwa=
re-5.bin_10.2.4-1.0-00013
> is 2 months old. Perhaps there is a newer build to test that may have
> the fix?
>
> Any thoughts as to what it could be? I can provide more information if ne=
eded.
64MB of RAM nowadays is not much and ath10k is not really tested in such
setups AFAIK. I guess you could try if reducing TARGET_10X_NUM_MSDU_DESC
helps with the memory consumption, but no idea if that would even work
without further modifications to ath10k.
Also if you have fq-codel&co enabled that might increase memory
consumption. Adding linux-wireless as people there might have better
ideas.
--=20
Kalle Valo=
^ permalink raw reply
* Re: [PATCH 1/2] ath10k: add per peer htt tx stats support for 10.4
From: Yeoh Chun-Yeow @ 2016-10-12 13:36 UTC (permalink / raw)
To: Valo, Kalle
Cc: Kolli, Anilkumar, akolli@codeaurora.org,
linux-wireless@vger.kernel.org, ath10k@lists.infradead.org
In-Reply-To: <87r37mgo1n.fsf@kamboji.qca.qualcomm.com>
>
> My understanding is that 10.2 branch does not have this feature,
> unfortunately.
>
Alright, noted.
Is QCA988X going to have firmware 10.4 support?
---
Chun-Yeow
^ permalink raw reply
* Re: [PATCH] ath9k: Move generic entries below specific ones in ath_pci_id_table.
From: Kalle Valo @ 2016-10-12 13:34 UTC (permalink / raw)
To: Vittorio Gambaletta (VittGam)
Cc: linux-wireless, ath9k-devel, ath9k-devel, stable
In-Reply-To: <cd3ff141b0ba69399a377a96a9ae75fb@vittgam.net>
"Vittorio Gambaletta (VittGam)" <linux-wireless@vittgam.net> writes:
> Hello,
>
> On 04/10/2016 17:46:44 CEST, Kalle Valo wrote:
>> "Vittorio Gambaletta (VittGam)" <linux-wireless@vittgam.net> writes:
>>
>>> If generic entries are positioned above specific ones, then the
>>> former will be matched first and used instead of the latter.
>>>
>>> Cc: <linux-wireless@vger.kernel.org>
>>> Cc: <ath9k-devel@qca.qualcomm.com>
>>> Cc: <ath9k-devel@lists.ath9k.org>
>>> Cc: <stable@vger.kernel.org>
>>> Signed-off-by: Vittorio Gambaletta <linuxbugs@vittgam.net>
>>
>> Why? What kind of bug you are fixing? You are not really describing the
>> problem you are trying fix.
>
> The active_high LED of my Wistron DNMA-92 is still being recognized as
> active_low on 4.7.6 mainline.
This kind of information is important, always add that to the commit log
so that we don't need to guess.
> When I was preparing my former patch to fix that, I initially added the
> PCI_DEVICE_SUB section for 0x0029/0x2096 above the PCI_VDEVICE section
> for 0x0029; but then I moved the former below the latter after seeing
> how 0x002A sections were sorted in the file.
>
> I must have somehow messed up with testing, because I tested the final
> version of that patch before sending it, and it was apparently working;
> but now it is not working on 4.7.6 mainline.
>
> With this patch, 0x0029/0x2096 has finally got active_high LED on
> 4.7.6.
I'm confused, are you now saying that this patch doesn't work?
> So, after seeing that the rest of the file is sorted this way (generic
> section after the specific ones), I concluded that the 0x002A sorting
> was wrong in the first place, and so is 0x0029. Then I sent this patch
> to fix this.
I can't see how changing the order in ath_pci_id_table[] would make any
difference in functionality, but I might be missing something.
>> And your email headers look weird:
>>
>> To: <kvalo@codeaurora.org>
>> Cc: <linux-wireless@vger.kernel.org>
>> Cc: <ath9k-devel@qca.qualcomm.com>
>> Cc: <ath9k-devel@venema.h4ckr.net>
>> Cc: <stable@vger.kernel.org>
>> Date: Mon, 3 Oct 2016 12:00:56 +0200
>>
>> What software are you using to send this? Only one CC header is valid
>> according to the spec (thanks to Luca for checking) even though mailers
>> seem to handle multiple CC headers. But for example my patchwork script
>> fails with this and uses only the first CC header.
>
> Sorry about this, I used a custom mailer to send the patch since I was
> having problems with git-send-email...
Ok, that explains it.
--
Kalle Valo
^ permalink raw reply
* [PATCH v3 2/2] ath10k: Remove extraneous error message in tx alloc
From: Mohammed Shafi Shajakhan @ 2016-10-12 13:26 UTC (permalink / raw)
To: ath10k; +Cc: mohammed, linux-wireless, Mohammed Shafi Shajakhan
In-Reply-To: <1476278778-4253-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 ab2ee90..ccbc8c03 100644
--- a/drivers/net/wireless/ath/ath10k/htt_tx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_tx.c
@@ -282,10 +282,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.7.9.5
^ permalink raw reply related
* [PATCH v3 1/2] ath10k: clean up HTT tx buffer allocation and free
From: Mohammed Shafi Shajakhan @ 2016-10-12 13:26 UTC (permalink / raw)
To: ath10k; +Cc: mohammed, linux-wireless, Mohammed Shafi Shajakhan
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 | 75 ++++++++++++++++++++----------
1 file changed, 50 insertions(+), 25 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/htt_tx.c b/drivers/net/wireless/ath/ath10k/htt_tx.c
index ae5b33f..ab2ee90 100644
--- a/drivers/net/wireless/ath/ath10k/htt_tx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_tx.c
@@ -229,6 +229,32 @@ 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)
+{
+ struct ath10k *ar = htt->ar;
+ size_t size;
+
+ if (!htt->txbuf.vaddr)
+ return;
+
+ size = htt->max_num_pending_tx * sizeof(struct ath10k_htt_txbuf);
+ dma_free_coherent(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 +336,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 +363,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 +381,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 +396,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,22 +422,13 @@ 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;
-
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.7.9.5
^ permalink raw reply related
* Re: [PATCH] iwlwifi: pcie: reduce "unsupported splx" to a warning
From: Luca Coelho @ 2016-10-12 13:06 UTC (permalink / raw)
To: Paul Bolle, Chris Rorvick
Cc: Intel Linux Wireless, Emmanuel Grumbach, Johannes Berg,
Kalle Valo, Oren Givon, linux-wireless, netdev, linux-kernel
In-Reply-To: <1476275787.9670.12.camel@tiscali.nl>
On Wed, 2016-10-12 at 14:36 +0200, Paul Bolle wrote:
> On Wed, 2016-10-12 at 15:24 +0300, Luca Coelho wrote:
> > Okay... Actually this is a structure in the BIOS and the actual method
> > we call is SPLC. The SPLC method may return one item from this table,
> > or something entirely different, possible one of the three values
> > depending on a configuration option or so.
> >
> > Can you to find and send me the actual SPLC method that we call, from
> > your BIOS?
>
>
> It seems Chris and I basically have identical setups, so I'll answer.
Thanks! Yeah, I implied any of you two. ;)
> There are 20 SPLC methods in the BIOS. The first reads
> Method (SPLC, 0, Serialized)
> {
> DerefOf (SPLX [One]) [Zero] = DOM1 /* \DOM1 */
> DerefOf (SPLX [One]) [One] = LIM1 /* \LIM1 */
> DerefOf (SPLX [One]) [0x02] = TIM1 /* \TIM1 */
> DerefOf (SPLX [0x02]) [Zero] = DOM2 /* \DOM2 */
> DerefOf (SPLX [0x02]) [One] = LIM2 /* \LIM2 */
> DerefOf (SPLX [0x02]) [0x02] = TIM2 /* \TIM2 */
> DerefOf (SPLX [0x03]) [Zero] = DOM3 /* \DOM3 */
> DerefOf (SPLX [0x03]) [One] = LIM3 /* \LIM3 */
> DerefOf (SPLX [0x03]) [0x02] = TIM3 /* \TIM3 */
> Return (SPLX) /* \_SB_.PCI0.RP01.PXSX.SPLX */
> }
>
> The only difference is in the last comment. Ie, RP01 is increased until
> it reaches RP20. (The machine has 20 PCI devices according to lspci. I
> have no clue how to match that RPxx number to the 20 devices showing up
> in lspci, sorry.)
No problem, these BIOSes are usually quite cryptic. :) But what you're
saying makes sense. They have added the SPLC method to all PCI root-
ports (which is what RP stands for here).
And, the values in the SPLX structs are being changed here, to DOM1,
LIM1, TIM1 etc., before being returned. This also matches your
description that, at runtime, you got something different than the pure
dump. If you follow these DOM*, LIM*, TIM* symbols, you'll probably
end up getting the values you observed at runtime.
Basically this tells me that indeed 3 "structs" are being returned (as
your dumps already showed). And, according to the specs that I found
(which unfortunately are confidential, so I can't share) this is
correct and the driver code is broken.
I'll send you a patch for testing soon.
Thanks for all the help!
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH v2 0/7] ath9k: EEPROM swapping improvements
From: Kalle Valo @ 2016-10-12 13:18 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: ath9k-devel, linux-wireless, ath9k-devel, devicetree, arnd,
chunkeey, nbd
In-Reply-To: <20161002222913.12223-1-martin.blumenstingl@googlemail.com>
Martin Blumenstingl <martin.blumenstingl@googlemail.com> writes:
> There are two types of swapping the EEPROM data in the ath9k driver.
> Before this series one type of swapping could not be used without the
> other.
>
> The first type of swapping looks at the "magic bytes" at the start of
> the EEPROM data and performs swab16 on the EEPROM contents if needed.
> The second type of swapping is EEPROM format specific and swaps
> specific fields within the EEPROM itself (swab16, swab32 - depends on
> the EEPROM format).
>
> With this series the second part now looks at the EEPMISC register
> inside the EEPROM, which uses a bit to indicate if the EEPROM data
> is Big Endian (this is also done by the FreeBSD kernel).
> This has a nice advantage: currently there are some out-of-tree hacks
> (in OpenWrt and LEDE) where the EEPROM has a Big Endian header on a
> Big Endian system (= no swab16 is performed) but the EEPROM itself
> indicates that it's data is Little Endian. Until now the out-of-tree
> code simply did a swab16 before passing the data to ath9k, so ath9k
> first did the swab16 - this also enabled the format specific swapping.
> These out-of-tree hacks are still working with the new logic, but it
> is recommended to remove them. This implementation is based on a
> discussion with Arnd Bergmann who raised concerns about the
> robustness and portability of the swapping logic in the original OF
> support patch review, see [0].
>
> After a second round of patches (= v1 of this series) neither Arnd
> Bergmann nor I were really happy with the complexity of the EEPROM
> swapping logic. Based on a discussion (see [1] and [2]) we decided
> that ath9k should use a defined format (specifying the endianness
> of the data - I went with __le16 and __le32) when accessing the
> EEPROM fields. A benefit of this is that we enable the EEPMISC based
> swapping logic by default, just like the FreeBSD driver, see [3]. On
> the devices which I have tested (see below) ath9k now works without
> having to specify the "endian_check" field in ath9k_platform_data (or
> a similar logic which could provide this via devicetree) as ath9k now
> detects the endianness automatically. Only EEPROMs which are mangled
> by some out-of-tree code still need the endian_check flag (or one can
> simply remove that mangling from the out-of-tree code).
>
> Testing:
> - tested by myself on AR9287 with Big Endian EEPROM
> - tested by myself on AR9227 with Little Endian EEPROM
> - tested by myself on AR9381 (using the ar9003_eeprom implementation,
> which did not suffer from this whole problem)
> - how do we proceed with testing? maybe we could keep this in a
> feature-branch and add these patches to LEDE once we have an ACK to
> get more people to test this
>
> This series depends on my other series (v7):
> "add devicetree support to ath9k" - see [4]
I think this looks pretty good. If there's a bug somewhere it should be
quite easy to fix so I'm not that worried and would be willing to take
these as soon as I have applied the dependency series. IIRC your
devicetree patches will have at least one more review round so that will
take some time still. In the meantime it would be great if LEDE folks
could take a look at these and comment (or test).
--
Kalle Valo
^ permalink raw reply
* [PATCH v2] cfg80211: Create structure for combination check/iter function parameters
From: Purushottam Kushwaha @ 2016-10-12 12:55 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, jouni, usdutt, amarnath, pkushwah
Move growing parameter list to a structure for check/iter combination
functions in cfg80211 and mac80211.
Signed-off-by: Purushottam Kushwaha <pkushwah@qti.qualcomm.com>
---
.../broadcom/brcm80211/brcmfmac/cfg80211.c | 26 ++++++-----
include/net/cfg80211.h | 46 ++++++++++----------
net/mac80211/util.c | 50 +++++++++++-----------
net/wireless/util.c | 28 ++++++------
4 files changed, 78 insertions(+), 72 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index b777e1b..44e1c70 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -414,23 +414,26 @@ static int brcmf_vif_change_validate(struct brcmf_cfg80211_info *cfg,
struct brcmf_cfg80211_vif *vif,
enum nl80211_iftype new_type)
{
- int iftype_num[NUM_NL80211_IFTYPES];
struct brcmf_cfg80211_vif *pos;
bool check_combos = false;
int ret = 0;
+ struct iface_combination_params params = {
+ .num_different_channels = 1,
+ .radar_detect = 0,
+ .iftype_num = {0},
+ };
- memset(&iftype_num[0], 0, sizeof(iftype_num));
list_for_each_entry(pos, &cfg->vif_list, list)
if (pos == vif) {
- iftype_num[new_type]++;
+ params.iftype_num[new_type]++;
} else {
/* concurrent interfaces so need check combinations */
check_combos = true;
- iftype_num[pos->wdev.iftype]++;
+ params.iftype_num[pos->wdev.iftype]++;
}
if (check_combos)
- ret = cfg80211_check_combinations(cfg->wiphy, 1, 0, iftype_num);
+ ret = cfg80211_check_combinations(cfg->wiphy, ¶ms);
return ret;
}
@@ -438,15 +441,18 @@ static int brcmf_vif_change_validate(struct brcmf_cfg80211_info *cfg,
static int brcmf_vif_add_validate(struct brcmf_cfg80211_info *cfg,
enum nl80211_iftype new_type)
{
- int iftype_num[NUM_NL80211_IFTYPES];
struct brcmf_cfg80211_vif *pos;
+ struct iface_combination_params params = {
+ .num_different_channels = 1,
+ .radar_detect = 0,
+ .iftype_num = {0},
+ };
- memset(&iftype_num[0], 0, sizeof(iftype_num));
list_for_each_entry(pos, &cfg->vif_list, list)
- iftype_num[pos->wdev.iftype]++;
+ params.iftype_num[pos->wdev.iftype]++;
- iftype_num[new_type]++;
- return cfg80211_check_combinations(cfg->wiphy, 1, 0, iftype_num);
+ params.iftype_num[new_type]++;
+ return cfg80211_check_combinations(cfg->wiphy, ¶ms);
}
static void convert_key_from_CPU(struct brcmf_wsec_key *key,
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index fe78f02..21bbe44 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -772,6 +772,26 @@ struct cfg80211_csa_settings {
};
/**
+ * struct iface_combination_params - input parameters for interface combinations
+ *
+ * Used to pass interface combination parameters
+ *
+ * @num_different_channels: the number of different channels we want
+ * to use for verification
+ * @radar_detect: a bitmap where each bit corresponds to a channel
+ * width where radar detection is needed, as in the definition of
+ * &struct ieee80211_iface_combination.@radar_detect_widths
+ * @iftype_num: array with the numbers of interfaces of each interface
+ * type. The index is the interface type as specified in &enum
+ * nl80211_iftype.
+ */
+struct iface_combination_params {
+ int num_different_channels;
+ u8 radar_detect;
+ int iftype_num[NUM_NL80211_IFTYPES];
+};
+
+/**
* enum station_parameters_apply_mask - station parameter values to apply
* @STATION_PARAM_APPLY_UAPSD: apply new uAPSD parameters (uapsd_queues, max_sp)
* @STATION_PARAM_APPLY_CAPABILITY: apply new capability
@@ -5575,36 +5595,20 @@ void cfg80211_report_wowlan_wakeup(struct wireless_dev *wdev,
* cfg80211_check_combinations - check interface combinations
*
* @wiphy: the wiphy
- * @num_different_channels: the number of different channels we want
- * to use for verification
- * @radar_detect: a bitmap where each bit corresponds to a channel
- * width where radar detection is needed, as in the definition of
- * &struct ieee80211_iface_combination.@radar_detect_widths
- * @iftype_num: array with the numbers of interfaces of each interface
- * type. The index is the interface type as specified in &enum
- * nl80211_iftype.
+ * @params: the interface combinations parameter
*
* This function can be called by the driver to check whether a
* combination of interfaces and their types are allowed according to
* the interface combinations.
*/
int cfg80211_check_combinations(struct wiphy *wiphy,
- const int num_different_channels,
- const u8 radar_detect,
- const int iftype_num[NUM_NL80211_IFTYPES]);
+ struct iface_combination_params *params);
/**
* cfg80211_iter_combinations - iterate over matching combinations
*
* @wiphy: the wiphy
- * @num_different_channels: the number of different channels we want
- * to use for verification
- * @radar_detect: a bitmap where each bit corresponds to a channel
- * width where radar detection is needed, as in the definition of
- * &struct ieee80211_iface_combination.@radar_detect_widths
- * @iftype_num: array with the numbers of interfaces of each interface
- * type. The index is the interface type as specified in &enum
- * nl80211_iftype.
+ * @params: the interface combinations parameter
* @iter: function to call for each matching combination
* @data: pointer to pass to iter function
*
@@ -5613,9 +5617,7 @@ int cfg80211_check_combinations(struct wiphy *wiphy,
* purposes.
*/
int cfg80211_iter_combinations(struct wiphy *wiphy,
- const int num_different_channels,
- const u8 radar_detect,
- const int iftype_num[NUM_NL80211_IFTYPES],
+ struct iface_combination_params *params,
void (*iter)(const struct ieee80211_iface_combination *c,
void *data),
void *data);
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index 545c79a..cfec67d 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -3308,10 +3308,13 @@ int ieee80211_check_combinations(struct ieee80211_sub_if_data *sdata,
struct ieee80211_local *local = sdata->local;
struct ieee80211_sub_if_data *sdata_iter;
enum nl80211_iftype iftype = sdata->wdev.iftype;
- int num[NUM_NL80211_IFTYPES];
struct ieee80211_chanctx *ctx;
- int num_different_channels = 0;
int total = 1;
+ struct iface_combination_params params = {
+ .num_different_channels = 0,
+ .radar_detect = radar_detect,
+ .iftype_num = {0},
+ };
lockdep_assert_held(&local->chanctx_mtx);
@@ -3322,9 +3325,6 @@ int ieee80211_check_combinations(struct ieee80211_sub_if_data *sdata,
!chandef->chan))
return -EINVAL;
- if (chandef)
- num_different_channels = 1;
-
if (WARN_ON(iftype >= NUM_NL80211_IFTYPES))
return -EINVAL;
@@ -3335,24 +3335,26 @@ int ieee80211_check_combinations(struct ieee80211_sub_if_data *sdata,
return 0;
}
- memset(num, 0, sizeof(num));
+ if (chandef)
+ params.num_different_channels = 1;
if (iftype != NL80211_IFTYPE_UNSPECIFIED)
- num[iftype] = 1;
+ params.iftype_num[iftype] = 1;
list_for_each_entry(ctx, &local->chanctx_list, list) {
if (ctx->replace_state == IEEE80211_CHANCTX_WILL_BE_REPLACED)
continue;
- radar_detect |= ieee80211_chanctx_radar_detect(local, ctx);
+ params.radar_detect |=
+ ieee80211_chanctx_radar_detect(local, ctx);
if (ctx->mode == IEEE80211_CHANCTX_EXCLUSIVE) {
- num_different_channels++;
+ params.num_different_channels++;
continue;
}
if (chandef && chanmode == IEEE80211_CHANCTX_SHARED &&
cfg80211_chandef_compatible(chandef,
&ctx->conf.def))
continue;
- num_different_channels++;
+ params.num_different_channels++;
}
list_for_each_entry_rcu(sdata_iter, &local->interfaces, list) {
@@ -3365,16 +3367,14 @@ int ieee80211_check_combinations(struct ieee80211_sub_if_data *sdata,
local->hw.wiphy->software_iftypes & BIT(wdev_iter->iftype))
continue;
- num[wdev_iter->iftype]++;
+ params.iftype_num[wdev_iter->iftype]++;
total++;
}
- if (total == 1 && !radar_detect)
+ if (total == 1 && !params.radar_detect)
return 0;
- return cfg80211_check_combinations(local->hw.wiphy,
- num_different_channels,
- radar_detect, num);
+ return cfg80211_check_combinations(local->hw.wiphy, ¶ms);
}
static void
@@ -3390,12 +3390,14 @@ int ieee80211_check_combinations(struct ieee80211_sub_if_data *sdata,
int ieee80211_max_num_channels(struct ieee80211_local *local)
{
struct ieee80211_sub_if_data *sdata;
- int num[NUM_NL80211_IFTYPES] = {};
struct ieee80211_chanctx *ctx;
- int num_different_channels = 0;
- u8 radar_detect = 0;
u32 max_num_different_channels = 1;
int err;
+ struct iface_combination_params params = {
+ .num_different_channels = 0,
+ .radar_detect = 0,
+ .iftype_num = {0},
+ };
lockdep_assert_held(&local->chanctx_mtx);
@@ -3403,17 +3405,17 @@ int ieee80211_max_num_channels(struct ieee80211_local *local)
if (ctx->replace_state == IEEE80211_CHANCTX_WILL_BE_REPLACED)
continue;
- num_different_channels++;
+ params.num_different_channels++;
- radar_detect |= ieee80211_chanctx_radar_detect(local, ctx);
+ params.radar_detect |=
+ ieee80211_chanctx_radar_detect(local, ctx);
}
list_for_each_entry_rcu(sdata, &local->interfaces, list)
- num[sdata->wdev.iftype]++;
+ params.iftype_num[sdata->wdev.iftype]++;
- err = cfg80211_iter_combinations(local->hw.wiphy,
- num_different_channels, radar_detect,
- num, ieee80211_iter_max_chans,
+ err = cfg80211_iter_combinations(local->hw.wiphy, ¶ms,
+ ieee80211_iter_max_chans,
&max_num_different_channels);
if (err < 0)
return err;
diff --git a/net/wireless/util.c b/net/wireless/util.c
index 8edce22..0d69b25 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -1580,9 +1580,7 @@ int cfg80211_validate_beacon_int(struct cfg80211_registered_device *rdev,
}
int cfg80211_iter_combinations(struct wiphy *wiphy,
- const int num_different_channels,
- const u8 radar_detect,
- const int iftype_num[NUM_NL80211_IFTYPES],
+ struct iface_combination_params *params,
void (*iter)(const struct ieee80211_iface_combination *c,
void *data),
void *data)
@@ -1593,7 +1591,7 @@ int cfg80211_iter_combinations(struct wiphy *wiphy,
int num_interfaces = 0;
u32 used_iftypes = 0;
- if (radar_detect) {
+ if (params->radar_detect) {
rcu_read_lock();
regdom = rcu_dereference(cfg80211_regdomain);
if (regdom)
@@ -1602,8 +1600,8 @@ int cfg80211_iter_combinations(struct wiphy *wiphy,
}
for (iftype = 0; iftype < NUM_NL80211_IFTYPES; iftype++) {
- num_interfaces += iftype_num[iftype];
- if (iftype_num[iftype] > 0 &&
+ num_interfaces += params->iftype_num[iftype];
+ if (params->iftype_num[iftype] > 0 &&
!(wiphy->software_iftypes & BIT(iftype)))
used_iftypes |= BIT(iftype);
}
@@ -1617,7 +1615,7 @@ int cfg80211_iter_combinations(struct wiphy *wiphy,
if (num_interfaces > c->max_interfaces)
continue;
- if (num_different_channels > c->num_different_channels)
+ if (params->num_different_channels > c->num_different_channels)
continue;
limits = kmemdup(c->limits, sizeof(limits[0]) * c->n_limits,
@@ -1632,16 +1630,17 @@ int cfg80211_iter_combinations(struct wiphy *wiphy,
all_iftypes |= limits[j].types;
if (!(limits[j].types & BIT(iftype)))
continue;
- if (limits[j].max < iftype_num[iftype])
+ if (limits[j].max < params->iftype_num[iftype])
goto cont;
- limits[j].max -= iftype_num[iftype];
+ limits[j].max -= params->iftype_num[iftype];
}
}
- if (radar_detect != (c->radar_detect_widths & radar_detect))
+ if (params->radar_detect !=
+ (c->radar_detect_widths & params->radar_detect))
goto cont;
- if (radar_detect && c->radar_detect_regions &&
+ if (params->radar_detect && c->radar_detect_regions &&
!(c->radar_detect_regions & BIT(region)))
goto cont;
@@ -1675,14 +1674,11 @@ int cfg80211_iter_combinations(struct wiphy *wiphy,
}
int cfg80211_check_combinations(struct wiphy *wiphy,
- const int num_different_channels,
- const u8 radar_detect,
- const int iftype_num[NUM_NL80211_IFTYPES])
+ struct iface_combination_params *params)
{
int err, num = 0;
- err = cfg80211_iter_combinations(wiphy, num_different_channels,
- radar_detect, iftype_num,
+ err = cfg80211_iter_combinations(wiphy, params,
cfg80211_iter_sum_ifcombs, &num);
if (err)
return err;
--
1.9.1
^ permalink raw reply related
* [PATCH v10] cfg80211: Provision to allow the support for different beacon intervals
From: Purushottam Kushwaha @ 2016-10-12 12:56 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, jouni, usdutt, amarnath, pkushwah
This commit provides a mechanism for the host drivers to advertise the
support for different beacon intervals among the respective interface
combinations in a group, through beacon_int_min_gcd (u32).
This beacon_int_min_gcd will be compared against GCD of all beaconing
interfaces of matching combinations.
Following sets the expectation for beacon_int_min_gcd.
= 0 - all beacon intervals for different interfaces must be same.
> 0 - any beacon interval for the interface part of this combination AND
*GCD* of all beacon intervals from beaconing interfaces of this
combination must be greator or equal to this value.
Signed-off-by: Purushottam Kushwaha <pkushwah@qti.qualcomm.com>
---
.../broadcom/brcm80211/brcmfmac/cfg80211.c | 4 +++
include/net/cfg80211.h | 14 +++++++-
include/uapi/linux/nl80211.h | 8 +++--
net/wireless/core.h | 2 +-
net/wireless/nl80211.c | 14 ++++++--
net/wireless/util.c | 37 ++++++++++++++++++++--
6 files changed, 70 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 44e1c70..2624569 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -421,6 +421,8 @@ static int brcmf_vif_change_validate(struct brcmf_cfg80211_info *cfg,
.num_different_channels = 1,
.radar_detect = 0,
.iftype_num = {0},
+ .beacon_gcd = 0,
+ .diff_bi = false,
};
list_for_each_entry(pos, &cfg->vif_list, list)
@@ -446,6 +448,8 @@ static int brcmf_vif_add_validate(struct brcmf_cfg80211_info *cfg,
.num_different_channels = 1,
.radar_detect = 0,
.iftype_num = {0},
+ .beacon_gcd = 0,
+ .diff_bi = false,
};
list_for_each_entry(pos, &cfg->vif_list, list)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 21bbe44..f0bcd55 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -784,11 +784,15 @@ struct cfg80211_csa_settings {
* @iftype_num: array with the numbers of interfaces of each interface
* type. The index is the interface type as specified in &enum
* nl80211_iftype.
+ * @beacon_gcd: a value specifying GCD of all beaconing interfaces.
+ * @diff_bi: a flag which denotes beacon intervals are different or same.
*/
struct iface_combination_params {
int num_different_channels;
u8 radar_detect;
int iftype_num[NUM_NL80211_IFTYPES];
+ u32 beacon_gcd;
+ bool diff_bi;
};
/**
@@ -3100,6 +3104,12 @@ struct ieee80211_iface_limit {
* only in special cases.
* @radar_detect_widths: bitmap of channel widths supported for radar detection
* @radar_detect_regions: bitmap of regions supported for radar detection
+ * @beacon_int_min_gcd: This interface combination supports different
+ * beacon intervals.
+ * = 0 - all beacon intervals for different interface must be same.
+ * > 0 - any beacon interval for the interface part of this combination AND
+ * *GCD* of all beacon intervals from beaconing interfaces of this
+ * combination must be greator or equal to this value.
*
* With this structure the driver can describe which interface
* combinations it supports concurrently.
@@ -3120,7 +3130,7 @@ struct ieee80211_iface_limit {
* };
*
*
- * 2. Allow #{AP, P2P-GO} <= 8, channels = 1, 8 total:
+ * 2. Allow #{AP, P2P-GO} <= 8, BI min gcd = 10, channels = 1, 8 total:
*
* struct ieee80211_iface_limit limits2[] = {
* { .max = 8, .types = BIT(NL80211_IFTYPE_AP) |
@@ -3131,6 +3141,7 @@ struct ieee80211_iface_limit {
* .n_limits = ARRAY_SIZE(limits2),
* .max_interfaces = 8,
* .num_different_channels = 1,
+ * .beacon_int_min_gcd = 10,
* };
*
*
@@ -3158,6 +3169,7 @@ struct ieee80211_iface_combination {
bool beacon_int_infra_match;
u8 radar_detect_widths;
u8 radar_detect_regions;
+ u32 beacon_int_min_gcd;
};
struct ieee80211_txrx_stypes {
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 56368e9..3c19cca 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -4280,6 +4280,9 @@ enum nl80211_iface_limit_attrs {
* of supported channel widths for radar detection.
* @NL80211_IFACE_COMB_RADAR_DETECT_REGIONS: u32 attribute containing the bitmap
* of supported regulatory regions for radar detection.
+ * @NL80211_IFACE_COMB_BI_MIN_GCD: u32 attribute specifying the minimum GCD of
+ * different beacon intervals supported by all the interface combinations
+ * in this group (if not present, all beacon interval must match).
* @NUM_NL80211_IFACE_COMB: number of attributes
* @MAX_NL80211_IFACE_COMB: highest attribute number
*
@@ -4287,8 +4290,8 @@ enum nl80211_iface_limit_attrs {
* limits = [ #{STA} <= 1, #{AP} <= 1 ], matching BI, channels = 1, max = 2
* => allows an AP and a STA that must match BIs
*
- * numbers = [ #{AP, P2P-GO} <= 8 ], channels = 1, max = 8
- * => allows 8 of AP/GO
+ * numbers = [ #{AP, P2P-GO} <= 8 ], BI min gcd, channels = 1, max = 8,
+ * => allows 8 of AP/GO that can have BI gcd >= min gcd
*
* numbers = [ #{STA} <= 2 ], channels = 2, max = 2
* => allows two STAs on different channels
@@ -4314,6 +4317,7 @@ enum nl80211_if_combination_attrs {
NL80211_IFACE_COMB_NUM_CHANNELS,
NL80211_IFACE_COMB_RADAR_DETECT_WIDTHS,
NL80211_IFACE_COMB_RADAR_DETECT_REGIONS,
+ NL80211_IFACE_COMB_BI_MIN_GCD,
/* keep last */
NUM_NL80211_IFACE_COMB,
diff --git a/net/wireless/core.h b/net/wireless/core.h
index 08d2e94..21e3188 100644
--- a/net/wireless/core.h
+++ b/net/wireless/core.h
@@ -475,7 +475,7 @@ int ieee80211_get_ratemask(struct ieee80211_supported_band *sband,
u32 *mask);
int cfg80211_validate_beacon_int(struct cfg80211_registered_device *rdev,
- u32 beacon_int);
+ enum nl80211_iftype iftype, u32 beacon_int);
void cfg80211_update_iface_num(struct cfg80211_registered_device *rdev,
enum nl80211_iftype iftype, int num);
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index c510810..903cd5a 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -1075,6 +1075,10 @@ static int nl80211_put_iface_combinations(struct wiphy *wiphy,
nla_put_u32(msg, NL80211_IFACE_COMB_RADAR_DETECT_REGIONS,
c->radar_detect_regions)))
goto nla_put_failure;
+ if (c->beacon_int_min_gcd &&
+ nla_put_u32(msg, NL80211_IFACE_COMB_BI_MIN_GCD,
+ c->beacon_int_min_gcd))
+ goto nla_put_failure;
nla_nest_end(msg, nl_combi);
}
@@ -3803,7 +3807,8 @@ static int nl80211_start_ap(struct sk_buff *skb, struct genl_info *info)
params.dtim_period =
nla_get_u32(info->attrs[NL80211_ATTR_DTIM_PERIOD]);
- err = cfg80211_validate_beacon_int(rdev, params.beacon_interval);
+ err = cfg80211_validate_beacon_int(rdev, dev->ieee80211_ptr->iftype,
+ params.beacon_interval);
if (err)
return err;
@@ -8152,7 +8157,8 @@ static int nl80211_join_ibss(struct sk_buff *skb, struct genl_info *info)
ibss.beacon_interval =
nla_get_u32(info->attrs[NL80211_ATTR_BEACON_INTERVAL]);
- err = cfg80211_validate_beacon_int(rdev, ibss.beacon_interval);
+ err = cfg80211_validate_beacon_int(rdev, NL80211_IFTYPE_ADHOC,
+ ibss.beacon_interval);
if (err)
return err;
@@ -9417,7 +9423,9 @@ static int nl80211_join_mesh(struct sk_buff *skb, struct genl_info *info)
setup.beacon_interval =
nla_get_u32(info->attrs[NL80211_ATTR_BEACON_INTERVAL]);
- err = cfg80211_validate_beacon_int(rdev, setup.beacon_interval);
+ err = cfg80211_validate_beacon_int(rdev,
+ NL80211_IFTYPE_MESH_POINT,
+ setup.beacon_interval);
if (err)
return err;
}
diff --git a/net/wireless/util.c b/net/wireless/util.c
index 0d69b25..3f3d684 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -1559,24 +1559,49 @@ bool ieee80211_chandef_to_operating_class(struct cfg80211_chan_def *chandef,
EXPORT_SYMBOL(ieee80211_chandef_to_operating_class);
int cfg80211_validate_beacon_int(struct cfg80211_registered_device *rdev,
+ enum nl80211_iftype iftype,
u32 beacon_int)
{
struct wireless_dev *wdev;
int res = 0;
+ u32 bi_prev, tmp_bi;
+ struct iface_combination_params params = {
+ .num_different_channels = 0,
+ .radar_detect = 0,
+ .iftype_num = {0},
+ .beacon_gcd = beacon_int, /* GCD(n) = n */
+ .diff_bi = false,
+ };
if (beacon_int < 10 || beacon_int > 10000)
return -EINVAL;
+ params.iftype_num[iftype] = 1;
+ list_for_each_entry(wdev, &rdev->wiphy.wdev_list, list) {
+ if (!wdev->beacon_interval)
+ continue;
+
+ params.iftype_num[wdev->iftype]++;
+ }
+
list_for_each_entry(wdev, &rdev->wiphy.wdev_list, list) {
if (!wdev->beacon_interval)
continue;
if (wdev->beacon_interval != beacon_int) {
- res = -EINVAL;
+ params.diff_bi = true;
+ /* Get the GCD */
+ bi_prev = wdev->beacon_interval;
+ while (bi_prev != 0) {
+ tmp_bi = bi_prev;
+ bi_prev = params.beacon_gcd % bi_prev;
+ params.beacon_gcd = tmp_bi;
+ }
break;
}
}
- return res;
+ res = cfg80211_check_combinations(&rdev->wiphy, ¶ms);
+ return (res < 0) ? res : 0;
}
int cfg80211_iter_combinations(struct wiphy *wiphy,
@@ -1652,6 +1677,14 @@ int cfg80211_iter_combinations(struct wiphy *wiphy,
if ((all_iftypes & used_iftypes) != used_iftypes)
goto cont;
+ if (params->beacon_gcd) {
+ if (c->beacon_int_min_gcd &&
+ params->beacon_gcd < c->beacon_int_min_gcd)
+ return -EINVAL;
+ if (!c->beacon_int_min_gcd && params->diff_bi)
+ goto cont;
+ }
+
/* This combination covered all interface types and
* supported the requested numbers, so we're good.
*/
--
1.9.1
^ permalink raw reply related
* [PATCH v2] cfg80211: Check radar_detect and num_different_channels with beacon interface combinations.
From: Purushottam Kushwaha @ 2016-10-12 12:57 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, jouni, usdutt, amarnath, pkushwah
This commit enhances the current beacon interval validation to also consider
the "radar_detect" and "num_different_channels".
Rename "cfg80211_validate_beacon_int" to "cfg80211_validate_beacon_combination"
as the validation considers other parameters.
Signed-off-by: Purushottam Kushwaha <pkushwah@qti.qualcomm.com>
---
net/wireless/core.h | 7 +++++--
net/wireless/mesh.c | 7 +++++++
net/wireless/nl80211.c | 32 ++++++++++++++-----------------
net/wireless/util.c | 51 +++++++++++++++++++++++++++++++++++++++++++++-----
4 files changed, 72 insertions(+), 25 deletions(-)
diff --git a/net/wireless/core.h b/net/wireless/core.h
index 21e3188..e39c8a9 100644
--- a/net/wireless/core.h
+++ b/net/wireless/core.h
@@ -474,8 +474,11 @@ int ieee80211_get_ratemask(struct ieee80211_supported_band *sband,
const u8 *rates, unsigned int n_rates,
u32 *mask);
-int cfg80211_validate_beacon_int(struct cfg80211_registered_device *rdev,
- enum nl80211_iftype iftype, u32 beacon_int);
+int
+cfg80211_validate_beacon_combination(struct cfg80211_registered_device *rdev,
+ enum nl80211_iftype iftype,
+ struct cfg80211_chan_def *chandef,
+ u32 beacon_int);
void cfg80211_update_iface_num(struct cfg80211_registered_device *rdev,
enum nl80211_iftype iftype, int num);
diff --git a/net/wireless/mesh.c b/net/wireless/mesh.c
index fa2066b..1d864b4 100644
--- a/net/wireless/mesh.c
+++ b/net/wireless/mesh.c
@@ -178,6 +178,13 @@ int __cfg80211_join_mesh(struct cfg80211_registered_device *rdev,
NL80211_IFTYPE_MESH_POINT))
return -EINVAL;
+ err = cfg80211_validate_beacon_combination(rdev,
+ NL80211_IFTYPE_MESH_POINT,
+ &setup->chandef,
+ setup->beacon_interval);
+ if (err)
+ return err;
+
err = rdev_join_mesh(rdev, dev, conf, setup);
if (!err) {
memcpy(wdev->ssid, setup->mesh_id, setup->mesh_id_len);
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 903cd5a..eb2bfae 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -3807,11 +3807,6 @@ static int nl80211_start_ap(struct sk_buff *skb, struct genl_info *info)
params.dtim_period =
nla_get_u32(info->attrs[NL80211_ATTR_DTIM_PERIOD]);
- err = cfg80211_validate_beacon_int(rdev, dev->ieee80211_ptr->iftype,
- params.beacon_interval);
- if (err)
- return err;
-
/*
* In theory, some of these attributes should be required here
* but since they were not used when the command was originally
@@ -3899,6 +3894,13 @@ static int nl80211_start_ap(struct sk_buff *skb, struct genl_info *info)
wdev->iftype))
return -EINVAL;
+ err = cfg80211_validate_beacon_combination(rdev,
+ dev->ieee80211_ptr->iftype,
+ ¶ms.chandef,
+ params.beacon_interval);
+ if (err)
+ return err;
+
if (info->attrs[NL80211_ATTR_TX_RATES]) {
err = nl80211_parse_tx_bitrate_mask(info, ¶ms.beacon_rate);
if (err)
@@ -8157,11 +8159,6 @@ static int nl80211_join_ibss(struct sk_buff *skb, struct genl_info *info)
ibss.beacon_interval =
nla_get_u32(info->attrs[NL80211_ATTR_BEACON_INTERVAL]);
- err = cfg80211_validate_beacon_int(rdev, NL80211_IFTYPE_ADHOC,
- ibss.beacon_interval);
- if (err)
- return err;
-
if (!rdev->ops->join_ibss)
return -EOPNOTSUPP;
@@ -8188,6 +8185,12 @@ static int nl80211_join_ibss(struct sk_buff *skb, struct genl_info *info)
if (err)
return err;
+ err = cfg80211_validate_beacon_combination(rdev, NL80211_IFTYPE_ADHOC,
+ &ibss.chandef,
+ ibss.beacon_interval);
+ if (err)
+ return err;
+
if (!cfg80211_reg_can_beacon(&rdev->wiphy, &ibss.chandef,
NL80211_IFTYPE_ADHOC))
return -EINVAL;
@@ -9419,17 +9422,10 @@ static int nl80211_join_mesh(struct sk_buff *skb, struct genl_info *info)
nla_get_u32(info->attrs[NL80211_ATTR_MCAST_RATE])))
return -EINVAL;
- if (info->attrs[NL80211_ATTR_BEACON_INTERVAL]) {
+ if (info->attrs[NL80211_ATTR_BEACON_INTERVAL])
setup.beacon_interval =
nla_get_u32(info->attrs[NL80211_ATTR_BEACON_INTERVAL]);
- err = cfg80211_validate_beacon_int(rdev,
- NL80211_IFTYPE_MESH_POINT,
- setup.beacon_interval);
- if (err)
- return err;
- }
-
if (info->attrs[NL80211_ATTR_DTIM_PERIOD]) {
setup.dtim_period =
nla_get_u32(info->attrs[NL80211_ATTR_DTIM_PERIOD]);
diff --git a/net/wireless/util.c b/net/wireless/util.c
index 3f3d684..a5810ba 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -1558,15 +1558,21 @@ bool ieee80211_chandef_to_operating_class(struct cfg80211_chan_def *chandef,
}
EXPORT_SYMBOL(ieee80211_chandef_to_operating_class);
-int cfg80211_validate_beacon_int(struct cfg80211_registered_device *rdev,
- enum nl80211_iftype iftype,
- u32 beacon_int)
+int
+cfg80211_validate_beacon_combination(struct cfg80211_registered_device *rdev,
+ enum nl80211_iftype iftype,
+ struct cfg80211_chan_def *chandef,
+ u32 beacon_int)
{
struct wireless_dev *wdev;
- int res = 0;
+ int res = 0, i;
u32 bi_prev, tmp_bi;
+ struct ieee80211_channel *ch;
+ enum cfg80211_chan_mode chmode;
+ struct ieee80211_channel
+ *used_channels[CFG80211_MAX_NUM_DIFFERENT_CHANNELS];
struct iface_combination_params params = {
- .num_different_channels = 0,
+ .num_different_channels = 1,
.radar_detect = 0,
.iftype_num = {0},
.beacon_gcd = beacon_int, /* GCD(n) = n */
@@ -1576,11 +1582,46 @@ int cfg80211_validate_beacon_int(struct cfg80211_registered_device *rdev,
if (beacon_int < 10 || beacon_int > 10000)
return -EINVAL;
+ used_channels[0] = chandef->chan;
params.iftype_num[iftype] = 1;
+
+ res = cfg80211_chandef_dfs_required(&rdev->wiphy, chandef, iftype);
+ if (res < 0)
+ return res;
+ if (res)
+ params.radar_detect = BIT(chandef->width);
+
list_for_each_entry(wdev, &rdev->wiphy.wdev_list, list) {
if (!wdev->beacon_interval)
continue;
+ mutex_lock_nested(&wdev->mtx, 1);
+ __acquire(wdev->mtx);
+ cfg80211_get_chan_state(wdev, &ch, &chmode,
+ ¶ms.radar_detect);
+ wdev_unlock(wdev);
+
+ switch (chmode) {
+ case CHAN_MODE_UNDEFINED:
+ break;
+ case CHAN_MODE_SHARED:
+ for (i = 0; i < CFG80211_MAX_NUM_DIFFERENT_CHANNELS; i++)
+ if (!used_channels[i] || used_channels[i] == ch)
+ break;
+
+ if (i == CFG80211_MAX_NUM_DIFFERENT_CHANNELS)
+ return -EBUSY;
+
+ if (!used_channels[i]) {
+ used_channels[i] = ch;
+ params.num_different_channels++;
+ }
+ break;
+ case CHAN_MODE_EXCLUSIVE:
+ params.num_different_channels++;
+ break;
+ }
+
params.iftype_num[wdev->iftype]++;
}
--
1.9.1
^ permalink raw reply related
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