* Re: BCM43602 firmware reports multiple BRCMF_E_DEAUTH
From: Rafał Miłecki @ 2016-10-14 6:33 UTC (permalink / raw)
To: Arend Van Spriel, linux-wireless@vger.kernel.org,
brcm80211 development
In-Reply-To: <90e69e94-2210-22ec-3aec-67d9605b4b7c@broadcom.com>
On 10/05/2016 11:08 AM, Arend Van Spriel wrote:
> On 4-10-2016 20:15, Rafał Miłecki wrote:
>> On 09/28/2015 11:00 AM, Rafał Miłecki wrote:
>>> I'm using recent brcmfmac and brcmfmac43602-pcie.ap.bin that currently
>>> sits in linux-firmware.git.
>>>
>>> In OpenWrt we have hostapd with a feature of banning STAs. It works in
>>> a quite simple way. Whenever hostapd gets NL80211_CMD_NEW_STATION for
>>> STA that is banned it sends NL80211_CMD_DEL_STATION.
>>>
>>> The problem is that in such case BCM43602 firmware happens to randomly
>>> send more than 1 BRCMF_E_DEAUTH event. It seems it can send random
>>> amount between 1 and 3. Looks a bit like some kind of race. It's
>>> nothing really critical, just makes hostapd log a bit confusing.
>>>
>>> Could someone at Broadcom look at firmware source to see if you can
>>> fix this, please?
>>
>> Hey, I didn't get any reply on this for a year. I just saw similar
>> problem with
>> BCM4366. Below you will find a nice log with my extra comments.
>>
>> Could take a look at this issue this time, please?
>
> Can try.
Thank you and sorry for my late reply! I'm back home now ready to provide any
extra details.
>> I think it may be another problem related to the A-MPDU thing (bug?) I
>> reported
>> in "AMPDU stalls with brcmfmac4366b-pcie.bin triggering WARNINGs" e-mail
>> thread.
>
> So what firmware version do you have? A colleague pointed me to firmware
> fix that may be related so I want to know the target string to build.
> Firmware version is in the bin file:
>
> $ hexdump -C fw.bin | tail -40
Well, I am pretty sure I was using the one released by Broadcom. Also my only
device with 4366b1 is DIR-885L. Once I was looking for 4366c0 firmware as
described in the kernel's bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=135321
but I don't think I replaced them or anything.
Anyway, I repeated my tests paying attention to the firmware file. I'm pretty
sure it's the same one you can find in:
https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree/brcm/brcmfmac4366b-pcie.bin
root@lede:/# md5sum /lib/firmware/brcm/brcmfmac4366b-pcie.bin
596f13d84e0042035cdb41202cfc385a /lib/firmware/brcm/brcmfmac4366b-pcie.bin
root@lede:/# hexdump -C /lib/firmware/brcm/brcmfmac4366b-pcie.bin | tail -40
000f1670 40 00 03 07 07 07 40 00 03 07 07 07 40 00 03 07 |@.....@.....@...|
000f1680 07 07 40 00 72 61 74 65 73 65 6c 00 73 74 66 00 |..@.ratesel.stf.|
000f1690 63 63 6b 5f 6f 6e 65 63 6f 72 65 5f 74 78 00 74 |cck_onecore_tx.t|
000f16a0 65 6d 70 73 5f 70 65 72 69 6f 64 00 74 78 63 68 |emps_period.txch|
000f16b0 61 69 6e 00 72 78 63 68 61 69 6e 00 4d cc 07 00 |ain.rxchain.M...|
000f16c0 69 44 26 00 71 c9 07 00 91 c6 07 00 2d e9 ff 41 |iD&.q.......-..A|
000f16d0 80 46 4f f4 40 70 0d 46 17 46 1e 46 1f f5 4c ff |.FO.@p.F.F.F..L.|
000f16e0 04 46 48 b9 28 46 1f f5 4d ff 02 46 23 49 24 48 |.FH.(F..M..F#I$H|
000f16f0 13 f7 24 fb 1e 20 3e e0 00 21 4f f4 40 72 12 f5 |..$.. >..!O.@r..|
000f1700 9d fd 0a 9b 40 46 00 93 04 f1 f8 03 01 93 04 f1 |....@F..........|
000f1710 fc 03 02 93 29 46 3a 46 33 46 e0 f7 5f fa c4 f8 |....)F:F3F.._...|
000f1720 f4 00 28 b9 17 48 15 49 0b 25 13 f7 07 fb 1e e0 |..(..H.I.%......|
000f1730 00 22 40 f6 12 01 00 25 22 f5 26 fb c4 f8 00 01 |."@....%".&.....|
000f1740 40 f6 12 01 d4 f8 f4 00 22 f5 06 fa c4 f8 e8 00 |@.......".......|
000f1750 20 46 51 f7 8d fb 0c 21 00 22 20 46 51 f7 94 fb | FQ....!." FQ...|
000f1760 20 46 4d f7 69 f8 d4 f8 f4 00 df f7 d1 fe 20 46 | FM.i......... F|
000f1770 1f f5 16 ff 28 46 04 b0 bd e8 f0 81 88 17 2f 00 |....(F......../.|
000f1780 97 1b 2a 00 e2 f1 29 00 77 6c 63 5f 62 6d 61 63 |..*...).wlc_bmac|
000f1790 5f 70 72 6f 63 65 73 73 5f 75 63 6f 64 65 5f 73 |_process_ucode_s|
000f17a0 72 00 00 00 84 73 3b b4 0a 0a 45 ed 3d 22 90 56 |r....s;...E.=".V|
000f17b0 00 00 07 00 00 00 00 00 00 00 00 00 00 00 00 a4 |................|
000f17c0 91 7a c4 13 01 bd 32 08 01 00 34 33 36 36 62 31 |.z....2...4366b1|
000f17d0 2d 72 6f 6d 6c 2f 70 63 69 65 2d 61 67 2d 73 70 |-roml/pcie-ag-sp|
000f17e0 6c 69 74 72 78 2d 66 64 61 70 2d 6d 62 73 73 2d |litrx-fdap-mbss-|
000f17f0 6d 66 70 2d 77 6e 6d 2d 6f 73 65 6e 2d 77 6c 31 |mfp-wnm-osen-wl1|
000f1800 31 6b 2d 77 6c 31 31 75 2d 74 78 62 66 2d 70 6b |1k-wl11u-txbf-pk|
000f1810 74 63 74 78 2d 61 6d 73 64 75 74 78 2d 61 6d 70 |tctx-amsdutx-amp|
000f1820 64 75 72 65 74 72 79 2d 63 68 6b 64 32 68 64 6d |duretry-chkd2hdm|
000f1830 61 2d 70 72 6f 70 74 78 73 74 61 74 75 73 2d 31 |a-proptxstatus-1|
000f1840 31 6e 70 72 6f 70 2d 6f 62 73 73 2d 64 62 77 73 |1nprop-obss-dbws|
000f1850 77 2d 72 69 6e 67 65 72 2d 64 6d 61 69 6e 64 65 |w-ringer-dmainde|
000f1860 78 31 36 2d 62 67 64 66 73 20 56 65 72 73 69 6f |x16-bgdfs Versio|
000f1870 6e 3a 20 31 30 2e 31 30 2e 36 39 2e 32 33 37 20 |n: 10.10.69.237 |
000f1880 43 52 43 3a 20 34 62 63 34 38 63 37 62 20 44 61 |CRC: 4bc48c7b Da|
000f1890 74 65 3a 20 46 72 69 20 32 30 31 36 2d 30 31 2d |te: Fri 2016-01-|
000f18a0 30 38 20 31 32 3a 35 35 3a 32 35 20 50 53 54 20 |08 12:55:25 PST |
000f18b0 55 63 6f 64 65 20 56 65 72 3a 20 31 30 37 33 2e |Ucode Ver: 1073.|
000f18c0 35 33 31 20 46 57 49 44 3a 20 30 31 2d 63 34 37 |531 FWID: 01-c47|
000f18d0 61 39 31 61 34 0a 00 0d 01 |a91a4....|
000f18d9
And there is a log using that very firmware I verified above.
# I got some timeouts, this time without ampdu_dbg or wlc_ampdu_watchdog
Fri Oct 14 06:09:07 2016 kern.err kernel: [ 437.579199] brcmfmac: brcmf_netdev_wait_pend8021x: Timed out waiting for no pending 802.1x packets
Fri Oct 14 06:09:08 2016 kern.err kernel: [ 438.529199] brcmfmac: brcmf_netdev_wait_pend8021x: Timed out waiting for no pending 802.1x packets
# Firmware sends BRCMF_E_DEAUTH and BRCMF_E_DISASSOC_IND events.
# My smartphone never receives deauth/disassoc and it believes it's still
# connected to the AP.
Fri Oct 14 06:09:12 2016 kern.debug kernel: [ 442.276363] brcmfmac: CONSOLE: 027172.113 wl0: Proxy STA 78:d6:f0:9b:ba:bc link is already gone !!??
Fri Oct 14 06:09:12 2016 kern.err kernel: [ 442.276405] brcmfmac: brcmf_notify_connect_status_ap: event 5, reason 3
Fri Oct 14 06:09:12 2016 daemon.info hostapd: wlan1-1: STA 78:d6:f0:9b:ba:bc IEEE 802.11: disassociated
Fri Oct 14 06:09:12 2016 kern.err kernel: [ 442.276447] brcmfmac: brcmf_notify_connect_status_ap: event 5, reason 3
Fri Oct 14 06:09:12 2016 daemon.info hostapd: wlan1-1: STA 78:d6:f0:9b:ba:bc IEEE 802.11: disassociated
# My smartphone starts sending packets. Firmware reacts by sending
# BRCMF_E_DEAUTH events to the driver.
Fri Oct 14 06:10:57 2016 kern.err kernel: [ 547.213534] brcmfmac: brcmf_notify_connect_status_ap: event 5, reason 7
Fri Oct 14 06:10:57 2016 daemon.info hostapd: wlan1-1: STA 78:d6:f0:9b:ba:bc IEEE 802.11: disassociated
Fri Oct 14 06:10:57 2016 kern.err kernel: [ 547.321590] brcmfmac: brcmf_notify_connect_status_ap: event 5, reason 7
Fri Oct 14 06:10:57 2016 daemon.info hostapd: wlan1-1: STA 78:d6:f0:9b:ba:bc IEEE 802.11: disassociated
Fri Oct 14 06:10:57 2016 kern.err kernel: [ 547.321918] brcmfmac: brcmf_notify_connect_status_ap: event 5, reason 7
Fri Oct 14 06:10:57 2016 daemon.info hostapd: wlan1-1: STA 78:d6:f0:9b:ba:bc IEEE 802.11: disassociated
^ permalink raw reply
* Re: [RFC 0/5] ath6kl: non WMI data service support
From: Valo, Kalle @ 2016-10-14 4:32 UTC (permalink / raw)
To: Steve deRosier; +Cc: Erik Stromdahl, linux-wireless
In-Reply-To: <CALupW3CrY5sZYBcx5Bd3E_M_Kx2sx8_N9h_uexvg_DSO0c-tJA@mail.gmail.com>
Steve deRosier <derosier@gmail.com> writes:
> Hi Eric,
>
> On Thu, Oct 13, 2016 at 9:39 AM, Erik Stromdahl
> <erik.stromdahl@gmail.com> wrote:
>> This patch series is intended to prepare the ath6kl driver
>> for newer chipsets that doesn't use the current WMI data
>> endpoints for data traffic.
>>
>> The chipset I have been working with (and used for testing)
>> is QCA6584. It is SDIO based (at least the variant I have
>> been using) with 802.11p WAVE DSRC capabilities.
>>
>> This chipset is different from the AR600X family in that
>> it does not use the WMI data services (service id's 0x101
>> to 0x104 ) for data traffic.
>> Instead it uses the HTT data service for data and wmi unified
>> for control messages.
>> It is also different when it comes to mailbox addresses
>> and HTC header format as well, but these differences are not
>> part of this patch series.
>>
>
> I've only taken a quick look and I'll make specific comments to
> specific patches later, but I've got to ask the question, should these
> changes go into ath6kl or be a new driver?
>
> Just because the number starts with 6000 doesn't mean it's a ath6kl
> chip. The 10k series chips all start with 9000 for example, but they
> rate their own driver.
>
> You state that all of the underpinnings of the communication with the
> chip are totally different:
> * Doesn't use WMI
> * Different mailboxing
> * Different HTC layer
>
> If all of the commands and all of the communication layers to the chip
> are totally different, then perhaps it isn't an ath6kl chip. So if
> it's largely similar, then OK, but seems to me with the changes you're
> saying above, it's mostly different.
>
> I'm saying all that without any knowledge of this chip. My experience
> is limited to various versions of the 6003 and 6004 chips.
Exactly what I was thinking. When I saw terms like "HTT" and "unified
WMI" my first thought was that is this actually an ath10k based design?
The product numbers really don't give any indication what driver
supports, the division goes something like this:
* ath9k: "non-mobile" 11n chips
* ath6k: mobile 11n chips
* ath10k: mobile and "non-mobile" 11ac chips
For example QCA6174 is an 11ac mobile chip supported by ath10k. ath10k
only supports PCI bus at the moment, but I'm hoping someone would add
USB and SDIO support. Patches are very welcome.
I'm starting to suspect that QCA6584 is actually based on the same
design as QCA6174. If that's the case when we should also think if
instead we should add SDIO support to ath10k, maybe by taking relevant
parts from ath6kl?
I'll investigate more what this QCA6584 is, I haven't heard about it
before.
--=20
Kalle Valo=
^ permalink raw reply
* Re: [RFC 0/5] ath6kl: non WMI data service support
From: Steve deRosier @ 2016-10-13 23:57 UTC (permalink / raw)
To: Erik Stromdahl; +Cc: Kalle Valo, linux-wireless
In-Reply-To: <1476376769-4708-1-git-send-email-erik.stromdahl@gmail.com>
Hi Eric,
On Thu, Oct 13, 2016 at 9:39 AM, Erik Stromdahl
<erik.stromdahl@gmail.com> wrote:
> This patch series is intended to prepare the ath6kl driver
> for newer chipsets that doesn't use the current WMI data
> endpoints for data traffic.
>
> The chipset I have been working with (and used for testing)
> is QCA6584. It is SDIO based (at least the variant I have
> been using) with 802.11p WAVE DSRC capabilities.
>
> This chipset is different from the AR600X family in that
> it does not use the WMI data services (service id's 0x101
> to 0x104 ) for data traffic.
> Instead it uses the HTT data service for data and wmi unified
> for control messages.
> It is also different when it comes to mailbox addresses
> and HTC header format as well, but these differences are not
> part of this patch series.
>
I've only taken a quick look and I'll make specific comments to
specific patches later, but I've got to ask the question, should these
changes go into ath6kl or be a new driver?
Just because the number starts with 6000 doesn't mean it's a ath6kl
chip. The 10k series chips all start with 9000 for example, but they
rate their own driver.
You state that all of the underpinnings of the communication with the
chip are totally different:
* Doesn't use WMI
* Different mailboxing
* Different HTC layer
If all of the commands and all of the communication layers to the chip
are totally different, then perhaps it isn't an ath6kl chip. So if
it's largely similar, then OK, but seems to me with the changes you're
saying above, it's mostly different.
I'm saying all that without any knowledge of this chip. My experience
is limited to various versions of the 6003 and 6004 chips.
Just trying to stimulate discussion here.
Thanks,
- Steve
^ permalink raw reply
* Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)
From: Andy Lutomirski @ 2016-10-13 21:49 UTC (permalink / raw)
To: Johannes Berg
Cc: Stephen Rothwell, linux-next@vger.kernel.org, Sergey Senozhatsky,
Network Development, Sergey Senozhatsky, Herbert Xu,
David S. Miller, Linux Wireless List,
linux-kernel@vger.kernel.org
In-Reply-To: <1476366354.4904.31.camel@sipsolutions.net>
On Oct 13, 2016 6:46 AM, "Johannes Berg" <johannes@sipsolutions.net> wrote:
>
> On Thu, 2016-10-13 at 22:42 +0900, Sergey Senozhatsky wrote:
> >
> > > > https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commi
> > > > t/?h=x86/vmap_stack&id=0a39cfa6fbb5d5635c85253cc7d6b44b54822afd
> > > > https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commi
> > > > t/?h=x86/vmap_stack&id=bf8cfa200b5a01383ea39fc8ce2f32909767baa8
> > >
> > > That truly sounds like something we'd rather avoid in the TX/RX
> > > paths though, which should perform well.
> >
> > didn't fix.
>
> It couldn't, since the new helpers weren't used in mac80211 in those
> patches yet.
>
> > so I finally had some time to do a better bug-reporter job.
> >
> > I added a bunch of printk-s and several virt_addr_valid()-s
> > to ieee80211_aes_ccm_encrypt().
> >
> > and right befoe the Oops I see the following report from
> > virt_addr_valid()
> >
> >
> > FAIL: 00004100002cba02 > ffffc900802cba02 || 1 -> (00004100002cba02
> > >> 39) == 130
>
> Yeah, we already know that in this function the aad variable is on the
> stack, it explicitly is.
>
> The question, though, is why precisely that fails in the crypto code.
> Can you send the Oops report itself?
>
It's failing before that. With CONFIG_VMAP_STACK=y, the stack may not
be physically contiguous and can't be used for DMA, so putting it in a
scatterlist is bogus in general, and the crypto code mostly wants a
scatterlist.
There are a couple (faster!) APIs for crypto that don't use
scatterlists, but I don't think AEAD works with them.
--Andy
^ permalink raw reply
* Re: [PATCH] cfg80211: Add support to update connection parameters
From: Arend van Spriel @ 2016-10-13 18:58 UTC (permalink / raw)
To: Jouni Malinen, Johannes Berg; +Cc: linux-wireless, vamsi krishna
In-Reply-To: <1476373178-31105-1-git-send-email-jouni@qca.qualcomm.com>
On 13-10-16 17:39, Jouni Malinen wrote:
> From: vamsi krishna <vamsin@qti.qualcomm.com>
>
> Add functionality to update the connection parameters when in connected
> state, so that driver/firmware uses the updated parameters for
> subsequent roaming. This is for drivers that support internal BSS
> selection and roaming. The new command does not change the current
> association state, i.e., it can be used to update IE contents for future
> (re)associations without causing an immediate disassociation or
> reassociation with the current BSS.
>
> This commit implements the required functionality for updating IEs for
> (Re)Association Request frame only. Other parameters can be added in
> future when required.
>
> Signed-off-by: vamsi krishna <vamsin@qti.qualcomm.com>
> Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
> ---
> include/net/cfg80211.h | 22 ++++++++++++++++++++++
> include/uapi/linux/nl80211.h | 7 +++++++
> net/wireless/core.h | 4 ++++
> net/wireless/nl80211.c | 33 +++++++++++++++++++++++++++++++++
> net/wireless/rdev-ops.h | 13 +++++++++++++
> net/wireless/sme.c | 10 ++++++++++
> net/wireless/trace.h | 19 +++++++++++++++++++
> 7 files changed, 108 insertions(+)
>
> diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
> index 5000ec7..a4fc28a 100644
> --- a/include/net/cfg80211.h
> +++ b/include/net/cfg80211.h
> @@ -2044,6 +2044,18 @@ struct cfg80211_connect_params {
> };
>
> /**
> + * struct cfg80211_connect_params_valid - Connection parame ters to be updated
What's in a name? Could we just use '_updated' instead of '_valid' here
and below.
> + *
> + * This structure provides information of all connect parameters that
> + * have to be updated as part of update_connect_params() call.
> + *
> + * @assoc_ies_valid: Indicates whether association request IEs are updated
> + */
> +struct cfg80211_connect_params_valid {
> + bool assoc_ies_valid;
> +};
> +
> +/**
> * enum wiphy_params_flags - set_wiphy_params bitfield values
> * @WIPHY_PARAM_RETRY_SHORT: wiphy->retry_short has changed
> * @WIPHY_PARAM_RETRY_LONG: wiphy->retry_long has changed
> @@ -2564,6 +2576,12 @@ struct cfg80211_nan_func {
> * cases, the result of roaming is indicated with a call to
> * cfg80211_roamed() or cfg80211_roamed_bss().
> * (invoked with the wireless_dev mutex held)
> + * @update_connect_params: Update the connect parameters while connected to a
> + * BSS. The updated parameters can be used by driver/firmware for
> + * subsequent BSS selection (roaming) decisions and to form the
> + * Authentication/(Re)Association Request frames. This call does not
> + * request an immediate disassociation or reassociation with the current
> + * BSS, i.e., this impacts only subsequence (re)associations.
typo: should be 'subsequent' (I think ;-) ).
> * @disconnect: Disconnect from the BSS/ESS. Once done, call
> * cfg80211_disconnected().
> * (invoked with the wireless_dev mutex held)
> @@ -2848,6 +2866,10 @@ struct cfg80211_ops {
>
> int (*connect)(struct wiphy *wiphy, struct net_device *dev,
> struct cfg80211_connect_params *sme);
> + int (*update_connect_params)(struct wiphy *wiphy,
> + struct net_device *dev,
> + struct cfg80211_connect_params *sme,
> + struct cfg80211_connect_params_valid *cpv);
If the struct is renamed as proposed earlier the parameter might be
called 'cpu' although that might confuse code readers :-p
> int (*disconnect)(struct wiphy *wiphy, struct net_device *dev,
> u16 reason_code);
>
[...]
> diff --git a/net/wireless/sme.c b/net/wireless/sme.c
> index a77db33..93106da 100644
> --- a/net/wireless/sme.c
> +++ b/net/wireless/sme.c
> @@ -1073,6 +1073,16 @@ int cfg80211_connect(struct cfg80211_registered_device *rdev,
> return 0;
> }
>
> +int cfg80211_update_connect_params(struct cfg80211_registered_device *rdev,
> + struct net_device *dev,
> + struct cfg80211_connect_params *connect,
> + struct cfg80211_connect_params_valid *cpv)
> +{
> + if (rdev->ops->update_connect_params)
> + return rdev_update_connect_params(rdev, dev, connect, cpv);
> + return 0;
> +}
So why is this function added in sme.c. It does not do an awful lot so
is there still something up your sleeve by which this makes more sense?
Regards,
Arend
^ permalink raw reply
* Re: [PATCH] iwlwifi: pcie: fix SPLC structure parsing
From: Luca Coelho @ 2016-10-13 17:49 UTC (permalink / raw)
To: Paul Bolle, linux-wireless, chris
Cc: linuxwifi, emmanuel.grumbach, johannes, kvalo, oren.givon, netdev,
linux-kernel
In-Reply-To: <1476363353.1999.17.camel@tiscali.nl>
On Thu, 2016-10-13 at 14:55 +0200, Paul Bolle wrote:
> On Thu, 2016-10-13 at 15:44 +0300, Luca Coelho wrote:
> > Even though there is apparently something wrong with this part of the
> > ACPI table on you laptop, since it doesn't match our specifications.
> > In any case, it's mostly harmless.
>
>
> Would a correct implementation by Dell have any benefits for the users
> of these laptops? In other words: should I bother somehow contacting
> Dell and point them to this discussion in order to have them fix this?
This value provides a way for the OEM to fine tune the power budget of
the device. This is (usually) used to prevent parts of the platform
from getting too hot. We have a certain default that is good enough
for most cases. If Dell didn't want to set proper limits for this
device, it probably means that it is not a concern. Dell does set
these values correctly for other platforms.
So, I guess it's up to you if you want to clarify this with them. This
could be some default "blank" values when they don't want to change
them.
--
Luca.
^ permalink raw reply
* [RFC 5/5] ath6kl: service connect rewrite
From: Erik Stromdahl @ 2016-10-13 16:39 UTC (permalink / raw)
To: kvalo, linux-wireless; +Cc: Erik Stromdahl
In-Reply-To: <1476376769-4708-1-git-send-email-erik.stromdahl@gmail.com>
This patch removes the hardcoded struct
htc_service_connect_req from ath6kl_init_service_ep and adds
an array of struct htc_service_connect_req's to each element
in hw_list.
The rationale behind this patch is to make it possible to select
which services to connect to depending on chipset.
Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>
---
drivers/net/wireless/ath/ath6kl/core.h | 3 +
drivers/net/wireless/ath/ath6kl/htc-ops.h | 2 +-
drivers/net/wireless/ath/ath6kl/htc.h | 2 +-
drivers/net/wireless/ath/ath6kl/htc_mbox.c | 2 +-
drivers/net/wireless/ath/ath6kl/htc_pipe.c | 2 +-
drivers/net/wireless/ath/ath6kl/init.c | 187 +++++++++++++++++------------
6 files changed, 117 insertions(+), 81 deletions(-)
diff --git a/drivers/net/wireless/ath/ath6kl/core.h b/drivers/net/wireless/ath/ath6kl/core.h
index ac25f17..f907ef4 100644
--- a/drivers/net/wireless/ath/ath6kl/core.h
+++ b/drivers/net/wireless/ath/ath6kl/core.h
@@ -799,6 +799,9 @@ struct ath6kl {
const char *testscript;
} fw;
+ const struct htc_service_connect_req *services;
+ u32 service_count;
+
const char *fw_board;
const char *fw_default_board;
} hw;
diff --git a/drivers/net/wireless/ath/ath6kl/htc-ops.h b/drivers/net/wireless/ath/ath6kl/htc-ops.h
index 2d4eed5..80700a4 100644
--- a/drivers/net/wireless/ath/ath6kl/htc-ops.h
+++ b/drivers/net/wireless/ath/ath6kl/htc-ops.h
@@ -36,7 +36,7 @@ static inline int ath6kl_htc_start(struct htc_target *target)
}
static inline int ath6kl_htc_conn_service(struct htc_target *target,
- struct htc_service_connect_req *req,
+ const struct htc_service_connect_req *req,
struct htc_service_connect_resp *resp)
{
return target->dev->ar->htc_ops->conn_service(target, req, resp);
diff --git a/drivers/net/wireless/ath/ath6kl/htc.h b/drivers/net/wireless/ath/ath6kl/htc.h
index 532b13b..bfff466 100644
--- a/drivers/net/wireless/ath/ath6kl/htc.h
+++ b/drivers/net/wireless/ath/ath6kl/htc.h
@@ -550,7 +550,7 @@ struct ath6kl_htc_ops {
int (*wait_target)(struct htc_target *target);
int (*start)(struct htc_target *target);
int (*conn_service)(struct htc_target *target,
- struct htc_service_connect_req *req,
+ const struct htc_service_connect_req *req,
struct htc_service_connect_resp *resp);
int (*tx)(struct htc_target *target, struct htc_packet *packet);
void (*stop)(struct htc_target *target);
diff --git a/drivers/net/wireless/ath/ath6kl/htc_mbox.c b/drivers/net/wireless/ath/ath6kl/htc_mbox.c
index eed3939..24fb9a7 100644
--- a/drivers/net/wireless/ath/ath6kl/htc_mbox.c
+++ b/drivers/net/wireless/ath/ath6kl/htc_mbox.c
@@ -2386,7 +2386,7 @@ static void ath6kl_htc_mbox_flush_rx_buf(struct htc_target *target)
}
static int ath6kl_htc_mbox_conn_service(struct htc_target *target,
- struct htc_service_connect_req *conn_req,
+ const struct htc_service_connect_req *conn_req,
struct htc_service_connect_resp *conn_resp)
{
struct htc_packet *rx_pkt = NULL;
diff --git a/drivers/net/wireless/ath/ath6kl/htc_pipe.c b/drivers/net/wireless/ath/ath6kl/htc_pipe.c
index 93aac63..9a39f3d 100644
--- a/drivers/net/wireless/ath/ath6kl/htc_pipe.c
+++ b/drivers/net/wireless/ath/ath6kl/htc_pipe.c
@@ -1226,7 +1226,7 @@ static u8 htc_get_credit_alloc(struct htc_target *target, u16 service_id)
}
static int ath6kl_htc_pipe_conn_service(struct htc_target *target,
- struct htc_service_connect_req *conn_req,
+ const struct htc_service_connect_req *conn_req,
struct htc_service_connect_resp *conn_resp)
{
struct ath6kl *ar = target->dev->ar;
diff --git a/drivers/net/wireless/ath/ath6kl/init.c b/drivers/net/wireless/ath/ath6kl/init.c
index 58fb227..a4c7abe 100644
--- a/drivers/net/wireless/ath/ath6kl/init.c
+++ b/drivers/net/wireless/ath/ath6kl/init.c
@@ -32,6 +32,94 @@
#include "hif-ops.h"
#include "htc-ops.h"
+const struct htc_service_connect_req ar600x_services[] = {
+ {
+ .svc_id = WMI_CONTROL_SVC,
+ .ep_cb = {
+ .tx_comp_multi = ath6kl_tx_complete,
+ .rx = ath6kl_rx,
+ .rx_refill = ath6kl_rx_refill,
+ .tx_full = ath6kl_tx_queue_full,
+ .rx_refill_thresh = ATH6KL_MAX_RX_BUFFERS / 4,
+ },
+ .max_txq_depth = MAX_DEFAULT_SEND_QUEUE_DEPTH,
+ },
+ {
+ .svc_id = WMI_DATA_BE_SVC,
+ .conn_flags = HTC_CONN_FLGS_REDUCE_CRED_DRIB |
+ HTC_CONN_FLGS_THRESH_LVL_HALF,
+ .ep_cb = {
+ .tx_comp_multi = ath6kl_tx_complete,
+ .rx = ath6kl_rx,
+ .rx_refill = ath6kl_rx_refill,
+ .tx_full = ath6kl_tx_queue_full,
+ .rx_refill_thresh = ATH6KL_MAX_RX_BUFFERS / 4,
+ .rx_alloc_thresh = ATH6KL_BUFFER_SIZE,
+ .rx_allocthresh = ath6kl_alloc_amsdu_rxbuf,
+ },
+ .max_txq_depth = MAX_DEFAULT_SEND_QUEUE_DEPTH,
+ .flags = HTC_FLGS_TX_BNDL_PAD_EN,
+ .max_rxmsg_sz = WMI_MAX_TX_DATA_FRAME_LENGTH,
+ },
+ {
+ .svc_id = WMI_DATA_BK_SVC,
+ .conn_flags = HTC_CONN_FLGS_REDUCE_CRED_DRIB |
+ HTC_CONN_FLGS_THRESH_LVL_HALF,
+ .ep_cb = {
+ .tx_comp_multi = ath6kl_tx_complete,
+ .rx = ath6kl_rx,
+ .rx_refill = ath6kl_rx_refill,
+ .tx_full = ath6kl_tx_queue_full,
+ .rx_refill_thresh = ATH6KL_MAX_RX_BUFFERS / 4,
+ .rx_alloc_thresh = ATH6KL_BUFFER_SIZE,
+ .rx_allocthresh = ath6kl_alloc_amsdu_rxbuf,
+ },
+ .max_txq_depth = MAX_DEFAULT_SEND_QUEUE_DEPTH,
+ .flags = HTC_FLGS_TX_BNDL_PAD_EN,
+ .max_rxmsg_sz = WMI_MAX_TX_DATA_FRAME_LENGTH,
+ },
+ {
+ .svc_id = WMI_DATA_VI_SVC,
+ .conn_flags = HTC_CONN_FLGS_REDUCE_CRED_DRIB |
+ HTC_CONN_FLGS_THRESH_LVL_HALF,
+ .ep_cb = {
+ .tx_comp_multi = ath6kl_tx_complete,
+ .rx = ath6kl_rx,
+ .rx_refill = ath6kl_rx_refill,
+ .tx_full = ath6kl_tx_queue_full,
+ .rx_refill_thresh = ATH6KL_MAX_RX_BUFFERS / 4,
+ .rx_alloc_thresh = ATH6KL_BUFFER_SIZE,
+ .rx_allocthresh = ath6kl_alloc_amsdu_rxbuf,
+ },
+ .max_txq_depth = MAX_DEFAULT_SEND_QUEUE_DEPTH,
+ .flags = HTC_FLGS_TX_BNDL_PAD_EN,
+ .max_rxmsg_sz = WMI_MAX_TX_DATA_FRAME_LENGTH,
+ },
+ /* VO service, this is currently not mapped to a WMI
+ * priority stream due to historical reasons. WMI originally
+ * defined 3 priorities over 3 mailboxes We can change this when
+ * WMI is reworked so that priorities are not dependent on
+ * mailboxes.
+ */
+ {
+ .svc_id = WMI_DATA_VO_SVC,
+ .conn_flags = HTC_CONN_FLGS_REDUCE_CRED_DRIB |
+ HTC_CONN_FLGS_THRESH_LVL_HALF,
+ .ep_cb = {
+ .tx_comp_multi = ath6kl_tx_complete,
+ .rx = ath6kl_rx,
+ .rx_refill = ath6kl_rx_refill,
+ .tx_full = ath6kl_tx_queue_full,
+ .rx_refill_thresh = ATH6KL_MAX_RX_BUFFERS / 4,
+ .rx_alloc_thresh = ATH6KL_BUFFER_SIZE,
+ .rx_allocthresh = ath6kl_alloc_amsdu_rxbuf,
+ },
+ .max_txq_depth = MAX_DEFAULT_SEND_QUEUE_DEPTH,
+ .flags = HTC_FLGS_TX_BNDL_PAD_EN,
+ .max_rxmsg_sz = WMI_MAX_TX_DATA_FRAME_LENGTH,
+ },
+};
+
static const struct ath6kl_hw hw_list[] = {
{
.id = AR6003_HW_2_0_VERSION,
@@ -57,6 +145,8 @@ static const struct ath6kl_hw hw_list[] = {
.fw_board = AR6003_HW_2_0_BOARD_DATA_FILE,
.fw_default_board = AR6003_HW_2_0_DEFAULT_BOARD_DATA_FILE,
+ .services = ar600x_services,
+ .service_count = ARRAY_SIZE(ar600x_services),
},
{
.id = AR6003_HW_2_1_1_VERSION,
@@ -82,6 +172,8 @@ static const struct ath6kl_hw hw_list[] = {
.fw_board = AR6003_HW_2_1_1_BOARD_DATA_FILE,
.fw_default_board = AR6003_HW_2_1_1_DEFAULT_BOARD_DATA_FILE,
+ .services = ar600x_services,
+ .service_count = ARRAY_SIZE(ar600x_services),
},
{
.id = AR6004_HW_1_0_VERSION,
@@ -102,6 +194,8 @@ static const struct ath6kl_hw hw_list[] = {
.fw_board = AR6004_HW_1_0_BOARD_DATA_FILE,
.fw_default_board = AR6004_HW_1_0_DEFAULT_BOARD_DATA_FILE,
+ .services = ar600x_services,
+ .service_count = ARRAY_SIZE(ar600x_services),
},
{
.id = AR6004_HW_1_1_VERSION,
@@ -121,6 +215,8 @@ static const struct ath6kl_hw hw_list[] = {
.fw_board = AR6004_HW_1_1_BOARD_DATA_FILE,
.fw_default_board = AR6004_HW_1_1_DEFAULT_BOARD_DATA_FILE,
+ .services = ar600x_services,
+ .service_count = ARRAY_SIZE(ar600x_services),
},
{
.id = AR6004_HW_1_2_VERSION,
@@ -140,6 +236,8 @@ static const struct ath6kl_hw hw_list[] = {
},
.fw_board = AR6004_HW_1_2_BOARD_DATA_FILE,
.fw_default_board = AR6004_HW_1_2_DEFAULT_BOARD_DATA_FILE,
+ .services = ar600x_services,
+ .service_count = ARRAY_SIZE(ar600x_services),
},
{
.id = AR6004_HW_1_3_VERSION,
@@ -163,6 +261,8 @@ static const struct ath6kl_hw hw_list[] = {
.fw_board = AR6004_HW_1_3_BOARD_DATA_FILE,
.fw_default_board = AR6004_HW_1_3_DEFAULT_BOARD_DATA_FILE,
+ .services = ar600x_services,
+ .service_count = ARRAY_SIZE(ar600x_services),
},
{
.id = AR6004_HW_3_0_VERSION,
@@ -186,6 +286,8 @@ static const struct ath6kl_hw hw_list[] = {
.fw_board = AR6004_HW_3_0_BOARD_DATA_FILE,
.fw_default_board = AR6004_HW_3_0_DEFAULT_BOARD_DATA_FILE,
+ .services = ar600x_services,
+ .service_count = ARRAY_SIZE(ar600x_services),
},
};
@@ -280,8 +382,7 @@ static inline void set_ac2_ep_map(struct ath6kl *ar,
/* connect to a service */
static int ath6kl_connectservice(struct ath6kl *ar,
- struct htc_service_connect_req *con_req,
- char *desc)
+ const struct htc_service_connect_req *con_req)
{
int status;
struct htc_service_connect_resp response;
@@ -290,8 +391,8 @@ static int ath6kl_connectservice(struct ath6kl *ar,
status = ath6kl_htc_conn_service(ar->htc_target, con_req, &response);
if (status) {
- ath6kl_err("failed to connect to %s service status:%d\n",
- desc, status);
+ ath6kl_err("failed to connect to %x service status: %d\n",
+ con_req->svc_id, status);
return status;
}
@@ -323,80 +424,12 @@ static int ath6kl_connectservice(struct ath6kl *ar,
static int ath6kl_init_service_ep(struct ath6kl *ar)
{
- struct htc_service_connect_req connect;
-
- memset(&connect, 0, sizeof(connect));
-
- /* these fields are the same for all service endpoints */
- connect.ep_cb.tx_comp_multi = ath6kl_tx_complete;
- connect.ep_cb.rx = ath6kl_rx;
- connect.ep_cb.rx_refill = ath6kl_rx_refill;
- connect.ep_cb.tx_full = ath6kl_tx_queue_full;
-
- /*
- * Set the max queue depth so that our ath6kl_tx_queue_full handler
- * gets called.
- */
- connect.max_txq_depth = MAX_DEFAULT_SEND_QUEUE_DEPTH;
- connect.ep_cb.rx_refill_thresh = ATH6KL_MAX_RX_BUFFERS / 4;
- if (!connect.ep_cb.rx_refill_thresh)
- connect.ep_cb.rx_refill_thresh++;
-
- /* connect to control service */
- connect.svc_id = WMI_CONTROL_SVC;
- if (ath6kl_connectservice(ar, &connect, "WMI CONTROL"))
- return -EIO;
-
- connect.flags |= HTC_FLGS_TX_BNDL_PAD_EN;
-
- /*
- * Limit the HTC message size on the send path, although e can
- * receive A-MSDU frames of 4K, we will only send ethernet-sized
- * (802.3) frames on the send path.
- */
- connect.max_rxmsg_sz = WMI_MAX_TX_DATA_FRAME_LENGTH;
-
- /*
- * To reduce the amount of committed memory for larger A_MSDU
- * frames, use the recv-alloc threshold mechanism for larger
- * packets.
- */
- connect.ep_cb.rx_alloc_thresh = ATH6KL_BUFFER_SIZE;
- connect.ep_cb.rx_allocthresh = ath6kl_alloc_amsdu_rxbuf;
-
- /*
- * For the remaining data services set the connection flag to
- * reduce dribbling, if configured to do so.
- */
- connect.conn_flags |= HTC_CONN_FLGS_REDUCE_CRED_DRIB;
- connect.conn_flags &= ~HTC_CONN_FLGS_THRESH_MASK;
- connect.conn_flags |= HTC_CONN_FLGS_THRESH_LVL_HALF;
-
- connect.svc_id = WMI_DATA_BE_SVC;
-
- if (ath6kl_connectservice(ar, &connect, "WMI DATA BE"))
- return -EIO;
-
- /* connect to back-ground map this to WMI LOW_PRI */
- connect.svc_id = WMI_DATA_BK_SVC;
- if (ath6kl_connectservice(ar, &connect, "WMI DATA BK"))
- return -EIO;
-
- /* connect to Video service, map this to HI PRI */
- connect.svc_id = WMI_DATA_VI_SVC;
- if (ath6kl_connectservice(ar, &connect, "WMI DATA VI"))
- return -EIO;
+ int i;
- /*
- * Connect to VO service, this is currently not mapped to a WMI
- * priority stream due to historical reasons. WMI originally
- * defined 3 priorities over 3 mailboxes We can change this when
- * WMI is reworked so that priorities are not dependent on
- * mailboxes.
- */
- connect.svc_id = WMI_DATA_VO_SVC;
- if (ath6kl_connectservice(ar, &connect, "WMI DATA VO"))
- return -EIO;
+ for (i = 0; i < ar->hw.service_count; i++) {
+ if (ath6kl_connectservice(ar, &ar->hw.services[i]))
+ return -EIO;
+ }
return 0;
}
--
2.1.4
^ permalink raw reply related
* [RFC 3/5] ath6kl: Added disable credit flow ctrl for mbox
From: Erik Stromdahl @ 2016-10-13 16:39 UTC (permalink / raw)
To: kvalo, linux-wireless; +Cc: Erik Stromdahl
In-Reply-To: <1476376769-4708-1-git-send-email-erik.stromdahl@gmail.com>
Added support for disabling credit flow control for htc_mbox
in a similar way as htc_pipe.
The tx_credit_flow_enabled member was moved out from the pipe
struct in struct htc_endpoint since it is now used by htc_mbox
as well.
Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>
---
drivers/net/wireless/ath/ath6kl/htc.h | 2 +-
drivers/net/wireless/ath/ath6kl/htc_mbox.c | 18 ++++++++++++++++--
drivers/net/wireless/ath/ath6kl/htc_pipe.c | 14 +++++++-------
3 files changed, 24 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/ath/ath6kl/htc.h b/drivers/net/wireless/ath/ath6kl/htc.h
index 112d8a9..532b13b 100644
--- a/drivers/net/wireless/ath/ath6kl/htc.h
+++ b/drivers/net/wireless/ath/ath6kl/htc.h
@@ -521,12 +521,12 @@ struct htc_endpoint {
u32 conn_flags;
struct htc_endpoint_stats ep_st;
u16 tx_drop_packet_threshold;
+ bool tx_credit_flow_enabled;
struct {
u8 pipeid_ul;
u8 pipeid_dl;
struct list_head tx_lookup_queue;
- bool tx_credit_flow_enabled;
} pipe;
};
diff --git a/drivers/net/wireless/ath/ath6kl/htc_mbox.c b/drivers/net/wireless/ath/ath6kl/htc_mbox.c
index 6e8c493..2c4477d 100644
--- a/drivers/net/wireless/ath/ath6kl/htc_mbox.c
+++ b/drivers/net/wireless/ath/ath6kl/htc_mbox.c
@@ -603,7 +603,7 @@ static void ath6kl_htc_tx_pkts_get(struct htc_target *target,
struct htc_endpoint *endpoint,
struct list_head *queue)
{
- int req_cred;
+ int req_cred = 0;
u8 flags;
struct htc_packet *packet;
unsigned int len;
@@ -623,7 +623,8 @@ static void ath6kl_htc_tx_pkts_get(struct htc_target *target,
len = CALC_TXRX_PADDED_LEN(target,
packet->act_len + HTC_HDR_LENGTH);
- if (htc_check_credits(target, endpoint, &flags,
+ if (endpoint->tx_credit_flow_enabled &&
+ htc_check_credits(target, endpoint, &flags,
packet->endpoint, len, &req_cred))
break;
@@ -2434,6 +2435,7 @@ static int ath6kl_htc_mbox_conn_service(struct htc_target *target,
struct htc_conn_service_msg *conn_msg;
struct htc_endpoint *endpoint;
enum htc_endpoint_id assigned_ep = ENDPOINT_MAX;
+ bool disable_credit_flowctrl = false;
unsigned int max_msg_sz = 0;
int status = 0;
u16 msg_id;
@@ -2459,6 +2461,10 @@ static int ath6kl_htc_mbox_conn_service(struct htc_target *target,
conn_msg->svc_id = cpu_to_le16(conn_req->svc_id);
conn_msg->conn_flags = cpu_to_le16(conn_req->conn_flags);
+ if (conn_req->conn_flags &
+ HTC_CONN_FLGS_DISABLE_CRED_FLOW_CTRL)
+ disable_credit_flowctrl = true;
+
set_htc_pkt_info(tx_pkt, NULL, (u8 *) conn_msg,
sizeof(*conn_msg) + conn_msg->svc_meta_len,
ENDPOINT_0, HTC_SERVICE_TX_PACKET_TAG);
@@ -2562,6 +2568,13 @@ static int ath6kl_htc_mbox_conn_service(struct htc_target *target,
/* save local connection flags */
endpoint->conn_flags = conn_req->flags;
+ if (disable_credit_flowctrl && endpoint->tx_credit_flow_enabled) {
+ endpoint->tx_credit_flow_enabled = false;
+ ath6kl_dbg(ATH6KL_DBG_HTC,
+ "SVC: 0x%4.4X ep:%d TX flow control off\n",
+ endpoint->svc_id, assigned_ep);
+ }
+
fail_tx:
if (tx_pkt)
htc_reclaim_txctrl_buf(target, tx_pkt);
@@ -2590,6 +2603,7 @@ static void reset_ep_state(struct htc_target *target)
INIT_LIST_HEAD(&endpoint->rx_bufq);
INIT_LIST_HEAD(&endpoint->txq);
endpoint->target = target;
+ endpoint->tx_credit_flow_enabled = true;
}
/* reset distribution list */
diff --git a/drivers/net/wireless/ath/ath6kl/htc_pipe.c b/drivers/net/wireless/ath/ath6kl/htc_pipe.c
index ca1a18c..93aac63 100644
--- a/drivers/net/wireless/ath/ath6kl/htc_pipe.c
+++ b/drivers/net/wireless/ath/ath6kl/htc_pipe.c
@@ -408,7 +408,7 @@ static enum htc_send_queue_result htc_try_send(struct htc_target *target,
}
}
- if (!ep->pipe.tx_credit_flow_enabled) {
+ if (!ep->tx_credit_flow_enabled) {
tx_resources =
ath6kl_hif_pipe_get_free_queue_number(ar,
ep->pipe.pipeid_ul);
@@ -452,7 +452,7 @@ static enum htc_send_queue_result htc_try_send(struct htc_target *target,
if (get_queue_depth(&ep->txq) == 0)
break;
- if (ep->pipe.tx_credit_flow_enabled) {
+ if (ep->tx_credit_flow_enabled) {
/*
* Credit based mechanism provides flow control
* based on target transmit resource availability,
@@ -482,7 +482,7 @@ static enum htc_send_queue_result htc_try_send(struct htc_target *target,
/* send what we can */
htc_issue_packets(target, ep, &send_queue);
- if (!ep->pipe.tx_credit_flow_enabled) {
+ if (!ep->tx_credit_flow_enabled) {
pipeid = ep->pipe.pipeid_ul;
tx_resources =
ath6kl_hif_pipe_get_free_queue_number(ar, pipeid);
@@ -768,7 +768,7 @@ static int ath6kl_htc_pipe_tx_complete(struct ath6kl *ar, struct sk_buff *skb)
}
skb = NULL;
- if (!ep->pipe.tx_credit_flow_enabled) {
+ if (!ep->tx_credit_flow_enabled) {
/*
* note: when using TX credit flow, the re-checking of queues
* happens when credits flow back from the target. in the
@@ -1194,7 +1194,7 @@ static void reset_endpoint_states(struct htc_target *target)
INIT_LIST_HEAD(&ep->pipe.tx_lookup_queue);
INIT_LIST_HEAD(&ep->rx_bufq);
ep->target = target;
- ep->pipe.tx_credit_flow_enabled = true;
+ ep->tx_credit_flow_enabled = true;
}
}
@@ -1399,8 +1399,8 @@ static int ath6kl_htc_pipe_conn_service(struct htc_target *target,
ep->svc_id, ep->pipe.pipeid_ul,
ep->pipe.pipeid_dl, ep->eid);
- if (disable_credit_flowctrl && ep->pipe.tx_credit_flow_enabled) {
- ep->pipe.tx_credit_flow_enabled = false;
+ if (disable_credit_flowctrl && ep->tx_credit_flow_enabled) {
+ ep->tx_credit_flow_enabled = false;
ath6kl_dbg(ATH6KL_DBG_HTC,
"SVC: 0x%4.4X ep:%d TX flow control off\n",
ep->svc_id, assigned_epid);
--
2.1.4
^ permalink raw reply related
* [RFC 4/5] ath6kl: Updated credit setup
From: Erik Stromdahl @ 2016-10-13 16:39 UTC (permalink / raw)
To: kvalo, linux-wireless; +Cc: Erik Stromdahl
In-Reply-To: <1476376769-4708-1-git-send-email-erik.stromdahl@gmail.com>
This patch simplifies the credit setup and removes a dependency
from htc_mbox.c.
The service priority (the order in which the endpoint credits are
added in target->cred_dist_list) is now determined by the sequence
in which the host connects to services.
The HTC control endpoint will have highest prio (just as before) since
it is the first endpoint that is connected (done in htc_wait_target).
The remaining service prio's will be prioritized in the order in
which they are connected.
The rationale behind this patch is to remove the service
dependecies (the prio list in ath6kl_htc_mbox_credit_setup) from
htc_mbox.c.
Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>
---
drivers/net/wireless/ath/ath6kl/htc_mbox.c | 50 ++++++------------------------
1 file changed, 9 insertions(+), 41 deletions(-)
diff --git a/drivers/net/wireless/ath/ath6kl/htc_mbox.c b/drivers/net/wireless/ath/ath6kl/htc_mbox.c
index 2c4477d..eed3939 100644
--- a/drivers/net/wireless/ath/ath6kl/htc_mbox.c
+++ b/drivers/net/wireless/ath/ath6kl/htc_mbox.c
@@ -29,9 +29,6 @@ static void ath6kl_htc_mbox_cleanup(struct htc_target *target);
static void ath6kl_htc_mbox_stop(struct htc_target *target);
static int ath6kl_htc_mbox_add_rxbuf_multiple(struct htc_target *target,
struct list_head *pkt_queue);
-static void ath6kl_htc_set_credit_dist(struct htc_target *target,
- struct ath6kl_htc_credit_info *cred_info,
- u16 svc_pri_order[], int len);
/* threshold to re-enable Tx bundling for an AC*/
#define TX_RESUME_BUNDLE_THRESHOLD 1500
@@ -146,18 +143,9 @@ static void ath6kl_credit_init(struct ath6kl_htc_credit_info *cred_info,
static int ath6kl_htc_mbox_credit_setup(struct htc_target *htc_target,
struct ath6kl_htc_credit_info *cred_info)
{
- u16 servicepriority[5];
-
memset(cred_info, 0, sizeof(struct ath6kl_htc_credit_info));
- servicepriority[0] = WMI_CONTROL_SVC; /* highest */
- servicepriority[1] = WMI_DATA_VO_SVC;
- servicepriority[2] = WMI_DATA_VI_SVC;
- servicepriority[3] = WMI_DATA_BE_SVC;
- servicepriority[4] = WMI_DATA_BK_SVC; /* lowest */
-
- /* set priority list */
- ath6kl_htc_set_credit_dist(htc_target, cred_info, servicepriority, 5);
+ htc_target->credit_info = cred_info;
return 0;
}
@@ -1094,34 +1082,6 @@ static int htc_setup_tx_complete(struct htc_target *target)
return status;
}
-static void ath6kl_htc_set_credit_dist(struct htc_target *target,
- struct ath6kl_htc_credit_info *credit_info,
- u16 srvc_pri_order[], int list_len)
-{
- struct htc_endpoint *endpoint;
- int i, ep;
-
- target->credit_info = credit_info;
-
- list_add_tail(&target->endpoint[ENDPOINT_0].cred_dist.list,
- &target->cred_dist_list);
-
- for (i = 0; i < list_len; i++) {
- for (ep = ENDPOINT_1; ep < ENDPOINT_MAX; ep++) {
- endpoint = &target->endpoint[ep];
- if (endpoint->svc_id == srvc_pri_order[i]) {
- list_add_tail(&endpoint->cred_dist.list,
- &target->cred_dist_list);
- break;
- }
- }
- if (ep >= ENDPOINT_MAX) {
- WARN_ON(1);
- return;
- }
- }
-}
-
static int ath6kl_htc_mbox_tx(struct htc_target *target,
struct htc_packet *packet)
{
@@ -2575,6 +2535,14 @@ static int ath6kl_htc_mbox_conn_service(struct htc_target *target,
endpoint->svc_id, assigned_ep);
}
+ /* Add the credit distribution list of the current endpoint
+ * to target->cred_dist_list.
+ * The order in which this function is called will determine
+ * the priority of the services.
+ */
+ list_add_tail(&endpoint->cred_dist.list,
+ &target->cred_dist_list);
+
fail_tx:
if (tx_pkt)
htc_reclaim_txctrl_buf(target, tx_pkt);
--
2.1.4
^ permalink raw reply related
* [RFC 2/5] ath6kl: Updated TARG_VTOP macro with default value
From: Erik Stromdahl @ 2016-10-13 16:39 UTC (permalink / raw)
To: kvalo, linux-wireless; +Cc: Erik Stromdahl
In-Reply-To: <1476376769-4708-1-git-send-email-erik.stromdahl@gmail.com>
A minor modification of the TARG_VTOP macro.
The AR6004 VTOP macro is used as default (for all
chip's except AR6003)
Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>
---
drivers/net/wireless/ath/ath6kl/target.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath6kl/target.h b/drivers/net/wireless/ath/ath6kl/target.h
index d5eeeae..c6c49b0 100644
--- a/drivers/net/wireless/ath/ath6kl/target.h
+++ b/drivers/net/wireless/ath/ath6kl/target.h
@@ -331,11 +331,11 @@ struct host_interest {
/* Convert a Target virtual address into a Target physical address */
#define AR6003_VTOP(vaddr) ((vaddr) & 0x001fffff)
-#define AR6004_VTOP(vaddr) (vaddr)
+#define DEFAULT_VTOP(vaddr) (vaddr)
#define TARG_VTOP(target_type, vaddr) \
(((target_type) == TARGET_TYPE_AR6003) ? AR6003_VTOP(vaddr) : \
- (((target_type) == TARGET_TYPE_AR6004) ? AR6004_VTOP(vaddr) : 0))
+ DEFAULT_VTOP(vaddr))
#define ATH6KL_FWLOG_PAYLOAD_SIZE 1500
--
2.1.4
^ permalink raw reply related
* [RFC 1/5] ath6kl: HTC mbox tx complete cb support
From: Erik Stromdahl @ 2016-10-13 16:39 UTC (permalink / raw)
To: kvalo, linux-wireless; +Cc: Erik Stromdahl
In-Reply-To: <1476376769-4708-1-git-send-email-erik.stromdahl@gmail.com>
The current implementation always call ath6kl_tx_complete
regardless if a tx_complete callback has been associated with the
endpoint or not.
This patch fixes this by calling the associated callback in case
it is present.
Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>
---
drivers/net/wireless/ath/ath6kl/htc_mbox.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath6kl/htc_mbox.c b/drivers/net/wireless/ath/ath6kl/htc_mbox.c
index 65c31da..6e8c493 100644
--- a/drivers/net/wireless/ath/ath6kl/htc_mbox.c
+++ b/drivers/net/wireless/ath/ath6kl/htc_mbox.c
@@ -445,7 +445,10 @@ static void htc_tx_complete(struct htc_endpoint *endpoint,
"htc tx complete ep %d pkts %d\n",
endpoint->eid, get_queue_depth(txq));
- ath6kl_tx_complete(endpoint->target, txq);
+ if (endpoint->ep_cb.tx_comp_multi)
+ endpoint->ep_cb.tx_comp_multi(endpoint->target, txq);
+ else
+ ath6kl_tx_complete(endpoint->target, txq);
}
static void htc_tx_comp_handler(struct htc_target *target,
--
2.1.4
^ permalink raw reply related
* [RFC 0/5] ath6kl: non WMI data service support
From: Erik Stromdahl @ 2016-10-13 16:39 UTC (permalink / raw)
To: kvalo, linux-wireless; +Cc: Erik Stromdahl
This patch series is intended to prepare the ath6kl driver
for newer chipsets that doesn't use the current WMI data
endpoints for data traffic.
The chipset I have been working with (and used for testing)
is QCA6584. It is SDIO based (at least the variant I have
been using) with 802.11p WAVE DSRC capabilities.
This chipset is different from the AR600X family in that
it does not use the WMI data services (service id's 0x101
to 0x104 ) for data traffic.
Instead it uses the HTT data service for data and wmi unified
for control messages.
It is also different when it comes to mailbox addresses
and HTC header format as well, but these differences are not
part of this patch series.
Erik Stromdahl (5):
ath6kl: HTC mbox tx complete cb support
ath6kl: Updated TARG_VTOP macro with default value
ath6kl: Added disable credit flow ctrl for mbox
ath6kl: Updated credit setup
ath6kl: service connect rewrite
drivers/net/wireless/ath/ath6kl/core.h | 3 +
drivers/net/wireless/ath/ath6kl/htc-ops.h | 2 +-
drivers/net/wireless/ath/ath6kl/htc.h | 4 +-
drivers/net/wireless/ath/ath6kl/htc_mbox.c | 75 +++++-------
drivers/net/wireless/ath/ath6kl/htc_pipe.c | 16 +--
drivers/net/wireless/ath/ath6kl/init.c | 187 +++++++++++++++++------------
drivers/net/wireless/ath/ath6kl/target.h | 4 +-
7 files changed, 156 insertions(+), 135 deletions(-)
--
2.1.4
^ permalink raw reply
* [PATCH] cfg80211: Add support to update connection parameters
From: Jouni Malinen @ 2016-10-13 15:39 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, vamsi krishna, Jouni Malinen
From: vamsi krishna <vamsin@qti.qualcomm.com>
Add functionality to update the connection parameters when in connected
state, so that driver/firmware uses the updated parameters for
subsequent roaming. This is for drivers that support internal BSS
selection and roaming. The new command does not change the current
association state, i.e., it can be used to update IE contents for future
(re)associations without causing an immediate disassociation or
reassociation with the current BSS.
This commit implements the required functionality for updating IEs for
(Re)Association Request frame only. Other parameters can be added in
future when required.
Signed-off-by: vamsi krishna <vamsin@qti.qualcomm.com>
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
---
include/net/cfg80211.h | 22 ++++++++++++++++++++++
include/uapi/linux/nl80211.h | 7 +++++++
net/wireless/core.h | 4 ++++
net/wireless/nl80211.c | 33 +++++++++++++++++++++++++++++++++
net/wireless/rdev-ops.h | 13 +++++++++++++
net/wireless/sme.c | 10 ++++++++++
net/wireless/trace.h | 19 +++++++++++++++++++
7 files changed, 108 insertions(+)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 5000ec7..a4fc28a 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -2044,6 +2044,18 @@ struct cfg80211_connect_params {
};
/**
+ * struct cfg80211_connect_params_valid - Connection parameters to be updated
+ *
+ * This structure provides information of all connect parameters that
+ * have to be updated as part of update_connect_params() call.
+ *
+ * @assoc_ies_valid: Indicates whether association request IEs are updated
+ */
+struct cfg80211_connect_params_valid {
+ bool assoc_ies_valid;
+};
+
+/**
* enum wiphy_params_flags - set_wiphy_params bitfield values
* @WIPHY_PARAM_RETRY_SHORT: wiphy->retry_short has changed
* @WIPHY_PARAM_RETRY_LONG: wiphy->retry_long has changed
@@ -2564,6 +2576,12 @@ struct cfg80211_nan_func {
* cases, the result of roaming is indicated with a call to
* cfg80211_roamed() or cfg80211_roamed_bss().
* (invoked with the wireless_dev mutex held)
+ * @update_connect_params: Update the connect parameters while connected to a
+ * BSS. The updated parameters can be used by driver/firmware for
+ * subsequent BSS selection (roaming) decisions and to form the
+ * Authentication/(Re)Association Request frames. This call does not
+ * request an immediate disassociation or reassociation with the current
+ * BSS, i.e., this impacts only subsequence (re)associations.
* @disconnect: Disconnect from the BSS/ESS. Once done, call
* cfg80211_disconnected().
* (invoked with the wireless_dev mutex held)
@@ -2848,6 +2866,10 @@ struct cfg80211_ops {
int (*connect)(struct wiphy *wiphy, struct net_device *dev,
struct cfg80211_connect_params *sme);
+ int (*update_connect_params)(struct wiphy *wiphy,
+ struct net_device *dev,
+ struct cfg80211_connect_params *sme,
+ struct cfg80211_connect_params_valid *cpv);
int (*disconnect)(struct wiphy *wiphy, struct net_device *dev,
u16 reason_code);
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 1362d24..ee85ce1 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -874,6 +874,11 @@
* This will contain a %NL80211_ATTR_NAN_MATCH nested attribute and
* %NL80211_ATTR_COOKIE.
*
+ * @NL80211_CMD_UPDATE_CONNECT_PARAMS: Update one or more connect parameters
+ * for subsequent roaming cases if the driver or firmware uses internal
+ * BSS selection. This command can be issued only while connected and it
+ * does not result in a change for the current association.
+ *
* @NL80211_CMD_MAX: highest used command number
* @__NL80211_CMD_AFTER_LAST: internal use
*/
@@ -1069,6 +1074,8 @@ enum nl80211_commands {
NL80211_CMD_CHANGE_NAN_CONFIG,
NL80211_CMD_NAN_MATCH,
+ NL80211_CMD_UPDATE_CONNECT_PARAMS,
+
/* add new commands above here */
/* used to define NL80211_CMD_MAX below */
diff --git a/net/wireless/core.h b/net/wireless/core.h
index 21e3188..7b8c8d1 100644
--- a/net/wireless/core.h
+++ b/net/wireless/core.h
@@ -383,6 +383,10 @@ int cfg80211_connect(struct cfg80211_registered_device *rdev,
struct cfg80211_connect_params *connect,
struct cfg80211_cached_keys *connkeys,
const u8 *prev_bssid);
+int cfg80211_update_connect_params(struct cfg80211_registered_device *rdev,
+ struct net_device *dev,
+ struct cfg80211_connect_params *connect,
+ struct cfg80211_connect_params_valid *cpv);
void __cfg80211_connect_result(struct net_device *dev, const u8 *bssid,
const u8 *req_ie, size_t req_ie_len,
const u8 *resp_ie, size_t resp_ie_len,
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 903cd5a..a3c5f5a 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -8732,6 +8732,31 @@ static int nl80211_connect(struct sk_buff *skb, struct genl_info *info)
return err;
}
+static int nl80211_update_connect_params(struct sk_buff *skb,
+ struct genl_info *info)
+{
+ struct cfg80211_connect_params connect;
+ struct cfg80211_connect_params_valid cpv;
+ struct cfg80211_registered_device *rdev = info->user_ptr[0];
+ struct net_device *dev = info->user_ptr[1];
+ struct wireless_dev *wdev = dev->ieee80211_ptr;
+
+ memset(&connect, 0, sizeof(connect));
+ memset(&cpv, 0, sizeof(cpv));
+
+ if (!wdev->current_bss)
+ return -ENOLINK;
+
+ if (info->attrs[NL80211_ATTR_IE]) {
+ if (!is_valid_ie_attr(info->attrs[NL80211_ATTR_IE]))
+ return -EINVAL;
+ connect.ie = nla_data(info->attrs[NL80211_ATTR_IE]);
+ connect.ie_len = nla_len(info->attrs[NL80211_ATTR_IE]);
+ cpv.assoc_ies_valid = true;
+ }
+ return cfg80211_update_connect_params(rdev, dev, &connect, &cpv);
+}
+
static int nl80211_disconnect(struct sk_buff *skb, struct genl_info *info)
{
struct cfg80211_registered_device *rdev = info->user_ptr[0];
@@ -12187,6 +12212,14 @@ static void nl80211_post_doit(const struct genl_ops *ops, struct sk_buff *skb,
NL80211_FLAG_NEED_RTNL,
},
{
+ .cmd = NL80211_CMD_UPDATE_CONNECT_PARAMS,
+ .doit = nl80211_update_connect_params,
+ .policy = nl80211_policy,
+ .flags = GENL_ADMIN_PERM,
+ .internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
+ NL80211_FLAG_NEED_RTNL,
+ },
+ {
.cmd = NL80211_CMD_DISCONNECT,
.doit = nl80211_disconnect,
.policy = nl80211_policy,
diff --git a/net/wireless/rdev-ops.h b/net/wireless/rdev-ops.h
index 11cf83c..9ad3b2c 100644
--- a/net/wireless/rdev-ops.h
+++ b/net/wireless/rdev-ops.h
@@ -490,6 +490,19 @@ static inline int rdev_connect(struct cfg80211_registered_device *rdev,
return ret;
}
+static inline int
+rdev_update_connect_params(struct cfg80211_registered_device *rdev,
+ struct net_device *dev,
+ struct cfg80211_connect_params *sme,
+ struct cfg80211_connect_params_valid *cpv)
+{
+ int ret;
+ trace_rdev_update_connect_params(&rdev->wiphy, dev, sme, cpv);
+ ret = rdev->ops->update_connect_params(&rdev->wiphy, dev, sme, cpv);
+ trace_rdev_return_int(&rdev->wiphy, ret);
+ return ret;
+}
+
static inline int rdev_disconnect(struct cfg80211_registered_device *rdev,
struct net_device *dev, u16 reason_code)
{
diff --git a/net/wireless/sme.c b/net/wireless/sme.c
index a77db33..93106da 100644
--- a/net/wireless/sme.c
+++ b/net/wireless/sme.c
@@ -1073,6 +1073,16 @@ int cfg80211_connect(struct cfg80211_registered_device *rdev,
return 0;
}
+int cfg80211_update_connect_params(struct cfg80211_registered_device *rdev,
+ struct net_device *dev,
+ struct cfg80211_connect_params *connect,
+ struct cfg80211_connect_params_valid *cpv)
+{
+ if (rdev->ops->update_connect_params)
+ return rdev_update_connect_params(rdev, dev, connect, cpv);
+ return 0;
+}
+
int cfg80211_disconnect(struct cfg80211_registered_device *rdev,
struct net_device *dev, u16 reason, bool wextev)
{
diff --git a/net/wireless/trace.h b/net/wireless/trace.h
index a3d0a91b..b53d72b 100644
--- a/net/wireless/trace.h
+++ b/net/wireless/trace.h
@@ -1281,6 +1281,25 @@
__entry->wpa_versions, __entry->flags, MAC_PR_ARG(prev_bssid))
);
+TRACE_EVENT(rdev_update_connect_params,
+ TP_PROTO(struct wiphy *wiphy, struct net_device *netdev,
+ struct cfg80211_connect_params *sme,
+ struct cfg80211_connect_params_valid *cpv),
+ TP_ARGS(wiphy, netdev, sme, cpv),
+ TP_STRUCT__entry(
+ WIPHY_ENTRY
+ NETDEV_ENTRY
+ __field(bool, assoc_ies_valid)
+ ),
+ TP_fast_assign(
+ WIPHY_ASSIGN;
+ NETDEV_ASSIGN;
+ __entry->assoc_ies_valid = cpv->assoc_ies_valid;
+ ),
+ TP_printk(WIPHY_PR_FMT ", " NETDEV_PR_FMT ", assoc_ies_valid: %d",
+ WIPHY_PR_ARG, NETDEV_PR_ARG, __entry->assoc_ies_valid)
+);
+
TRACE_EVENT(rdev_set_cqm_rssi_config,
TP_PROTO(struct wiphy *wiphy,
struct net_device *netdev, s32 rssi_thold,
--
1.9.1
^ permalink raw reply related
* Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)
From: Sergey Senozhatsky @ 2016-10-13 15:04 UTC (permalink / raw)
To: Sergey Senozhatsky
Cc: Johannes Berg, Andy Lutomirski, Andy Lutomirski, David S. Miller,
Linux Wireless List, Network Development,
linux-kernel@vger.kernel.org, Sergey Senozhatsky,
linux-next@vger.kernel.org, Stephen Rothwell, Herbert Xu
In-Reply-To: <20161013150011.GA437@swordfish>
On (10/14/16 00:00), Sergey Senozhatsky wrote:
> kernel: [<ffffffff8145c405>] ieee80211_crypto_ccmp_decrypt+0x204/0x298
> kernel: [<ffffffff81476cd8>] ieee80211_rx_handlers+0x7df/0x1c1d
> kernel: [<ffffffff814790c8>] ieee80211_prepare_and_rx_handle+0xdc2/0xe79
> kernel: [<ffffffff814792e7>] ? ieee80211_rx_napi+0x168/0x7b6
> kernel: [<ffffffff8147960a>] ieee80211_rx_napi+0x48b/0x7b6
> kernel: [<ffffffff8123729e>] ? debug_smp_processor_id+0x17/0x19
> kernel: [<ffffffffa01cfe3b>] iwl_mvm_rx_rx_mpdu+0x6e6/0x751 [iwlmvm]
> kernel: [<ffffffffa01c9c49>] iwl_mvm_rx+0x7e/0x98 [iwlmvm]
> kernel: [<ffffffffa0131bca>] iwl_pcie_rx_handle+0x523/0x698 [iwlwifi]
> kernel: [<ffffffffa0133027>] iwl_pcie_irq_handler+0x46f/0x65f [iwlwifi]
> kernel: [<ffffffff810893d0>] ? irq_finalize_oneshot+0xd4/0xd4
> kernel: [<ffffffff810893ed>] irq_thread_fn+0x1d/0x34
> kernel: [<ffffffff81089661>] irq_thread+0xe6/0x1bb
> kernel: [<ffffffff810894e6>] ? wake_threads_waitq+0x2c/0x2c
> kernel: [<ffffffff8108957b>] ? irq_thread_dtor+0x95/0x95
> kernel: [<ffffffff8105d762>] kthread+0xfc/0x104
> kernel: [<ffffffff8107d36c>] ? put_lock_stats.isra.9+0xe/0x20
> kernel: [<ffffffff8105d666>] ? kthread_create_on_node+0x3f/0x3f
> kernel: [<ffffffff814b2852>] ret_from_fork+0x22/0x30
> kernel: Code: 01 ca 49 89 d1 48 89 d1 48 c1 ea 23 48 8b 14 d5 80 23 63 82 49 c1 e9 0c 48 c1 e9 1b 48 85 d2 74 0a 0f b6 c9 48 c1 e1 04 48 01 ca <48> 8b 12 49 c1 e1 06 b9 00 00 00 80 89 7d 80 89 75 84 48 8b 3d
> kernel: RIP [<ffffffff8146d2f4>] ieee80211_aes_ccm_decrypt+0x107/0x27f
ffffffff8146d1ed <ieee80211_aes_ccm_decrypt>:
ffffffff8146d1ed: e8 9e 67 04 00 callq ffffffff814b3990 <__fentry__>
ffffffff8146d1f2: 55 push %rbp
ffffffff8146d1f3: 48 89 e5 mov %rsp,%rbp
ffffffff8146d1f6: 41 57 push %r15
ffffffff8146d1f8: 41 56 push %r14
ffffffff8146d1fa: 49 89 ce mov %rcx,%r14
ffffffff8146d1fd: 41 55 push %r13
ffffffff8146d1ff: 41 54 push %r12
ffffffff8146d201: 53 push %rbx
ffffffff8146d202: 48 83 c4 80 add $0xffffffffffffff80,%rsp
ffffffff8146d206: 8b 47 04 mov 0x4(%rdi),%eax
ffffffff8146d209: 48 8d 48 50 lea 0x50(%rax),%rcx
ffffffff8146d20d: 48 83 c0 5e add $0x5e,%rax
ffffffff8146d211: 48 c1 e8 03 shr $0x3,%rax
ffffffff8146d215: 48 c1 e0 03 shl $0x3,%rax
ffffffff8146d219: 48 29 c4 sub %rax,%rsp
ffffffff8146d21c: 4c 8d 7c 24 07 lea 0x7(%rsp),%r15
ffffffff8146d221: 49 c1 ef 03 shr $0x3,%r15
ffffffff8146d225: 4d 85 c0 test %r8,%r8
ffffffff8146d228: 4a 8d 04 fd 00 00 00 lea 0x0(,%r15,8),%rax
ffffffff8146d22f: 00
ffffffff8146d230: 48 89 85 70 ff ff ff mov %rax,-0x90(%rbp)
ffffffff8146d237: 75 0a jne ffffffff8146d243 <ieee80211_aes_ccm_decrypt+0x56>
ffffffff8146d239: b8 ea ff ff ff mov $0xffffffea,%eax
ffffffff8146d23e: e9 1a 02 00 00 jmpq ffffffff8146d45d <ieee80211_aes_ccm_decrypt+0x270>
ffffffff8146d243: 31 c0 xor %eax,%eax
ffffffff8146d245: 49 89 fc mov %rdi,%r12
ffffffff8146d248: 49 89 f5 mov %rsi,%r13
ffffffff8146d24b: 4c 89 85 58 ff ff ff mov %r8,-0xa8(%rbp)
ffffffff8146d252: 4a 8d 3c fd 00 00 00 lea 0x0(,%r15,8),%rdi
ffffffff8146d259: 00
ffffffff8146d25a: be 03 00 00 00 mov $0x3,%esi
ffffffff8146d25f: 4c 89 cb mov %r9,%rbx
ffffffff8146d262: 48 89 95 60 ff ff ff mov %rdx,-0xa0(%rbp)
ffffffff8146d269: f3 aa rep stos %al,%es:(%rdi)
ffffffff8146d26b: 48 8d 85 78 ff ff ff lea -0x88(%rbp),%rax
ffffffff8146d272: 48 89 c7 mov %rax,%rdi
ffffffff8146d275: 48 89 85 68 ff ff ff mov %rax,-0x98(%rbp)
ffffffff8146d27c: e8 46 06 dc ff callq ffffffff8122d8c7 <sg_init_table>
ffffffff8146d281: 48 8b 95 60 ff ff ff mov -0xa0(%rbp),%rdx
ffffffff8146d288: 41 b9 00 00 00 80 mov $0x80000000,%r9d
ffffffff8146d28e: 48 8b 0d 7b cd 39 00 mov 0x39cd7b(%rip),%rcx # ffffffff8180a010 <phys_base>
ffffffff8146d295: 48 8b 85 68 ff ff ff mov -0x98(%rbp),%rax
ffffffff8146d29c: 4c 8b 85 58 ff ff ff mov -0xa8(%rbp),%r8
ffffffff8146d2a3: 0f b7 32 movzwl (%rdx),%esi
ffffffff8146d2a6: 48 83 c2 02 add $0x2,%rdx
ffffffff8146d2aa: 89 d7 mov %edx,%edi
ffffffff8146d2ac: 81 e7 ff 0f 00 00 and $0xfff,%edi
ffffffff8146d2b2: 66 c1 c6 08 rol $0x8,%si
ffffffff8146d2b6: 4c 01 ca add %r9,%rdx
ffffffff8146d2b9: 0f b7 f6 movzwl %si,%esi
ffffffff8146d2bc: 72 0a jb ffffffff8146d2c8 <ieee80211_aes_ccm_decrypt+0xdb>
ffffffff8146d2be: 48 b9 00 00 00 80 ff movabs $0x77ff80000000,%rcx
ffffffff8146d2c5: 77 00 00
ffffffff8146d2c8: 48 01 ca add %rcx,%rdx
ffffffff8146d2cb: 49 89 d1 mov %rdx,%r9
ffffffff8146d2ce: 48 89 d1 mov %rdx,%rcx
ffffffff8146d2d1: 48 c1 ea 23 shr $0x23,%rdx
ffffffff8146d2d5: 48 8b 14 d5 80 23 63 mov -0x7d9cdc80(,%rdx,8),%rdx
ffffffff8146d2dc: 82
ffffffff8146d2dd: 49 c1 e9 0c shr $0xc,%r9
ffffffff8146d2e1: 48 c1 e9 1b shr $0x1b,%rcx
ffffffff8146d2e5: 48 85 d2 test %rdx,%rdx
ffffffff8146d2e8: 74 0a je ffffffff8146d2f4 <ieee80211_aes_ccm_decrypt+0x107>
ffffffff8146d2ea: 0f b6 c9 movzbl %cl,%ecx
ffffffff8146d2ed: 48 c1 e1 04 shl $0x4,%rcx
ffffffff8146d2f1: 48 01 ca add %rcx,%rdx
ffffffff8146d2f4: 48 8b 12 mov (%rdx),%rdx
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ffffffff8146d2f7: 49 c1 e1 06 shl $0x6,%r9
ffffffff8146d2fb: b9 00 00 00 80 mov $0x80000000,%ecx
ffffffff8146d300: 89 7d 80 mov %edi,-0x80(%rbp)
ffffffff8146d303: 89 75 84 mov %esi,-0x7c(%rbp)
ffffffff8146d306: 48 8b 3d 03 cd 39 00 mov 0x39cd03(%rip),%rdi # ffffffff8180a010 <phys_base>
ffffffff8146d30d: 48 83 e2 fc and $0xfffffffffffffffc,%rdx
ffffffff8146d311: 49 01 d1 add %rdx,%r9
ffffffff8146d314: 48 8b 95 78 ff ff ff mov -0x88(%rbp),%rdx
-ss
^ permalink raw reply
* [PATCH v3] cfg80211: Check radar_detect and num_different_channels with beacon interface combinations.
From: Purushottam Kushwaha @ 2016-10-13 15:15 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".
Move calculation of GCD for all beaconing interfaces to "cfg80211_iter_combinations".
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>
---
include/net/cfg80211.h | 3 --
net/wireless/core.h | 7 ++--
net/wireless/mesh.c | 7 ++++
net/wireless/nl80211.c | 32 ++++++++----------
net/wireless/util.c | 91 +++++++++++++++++++++++++++++++++++++++-----------
5 files changed, 97 insertions(+), 43 deletions(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 5000ec7..f5e076c 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -788,15 +788,12 @@ struct cfg80211_csa_settings {
* the GCD of a single value is considered the value itself, so for
* a single interface this should be set to that interface's beacon
* interval
- * @beacon_int_different: a flag indicating whether or not all beacon
- * intervals (of beaconing interfaces) are different or not.
*/
struct iface_combination_params {
int num_different_channels;
u8 radar_detect;
int iftype_num[NUM_NL80211_IFTYPES];
u32 beacon_int_gcd;
- bool beacon_int_different;
};
/**
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 d2ea1f1..eb89cb9 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -1558,44 +1558,67 @@ 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)
{
+ int res, i;
struct wireless_dev *wdev;
+ 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 = 1,
.beacon_int_gcd = beacon_int, /* GCD(n) = n */
};
if (beacon_int < 10 || beacon_int > 10000)
return -EINVAL;
+ used_channels[0] = chandef->chan;
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]++;
- }
+ 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) {
- u32 bi_prev = wdev->beacon_interval;
-
if (!wdev->beacon_interval)
continue;
- /* slight optimisation - skip identical BIs */
- if (wdev->beacon_interval == beacon_int)
- continue;
+ mutex_lock_nested(&wdev->mtx, 1);
+ __acquire(wdev->mtx);
+ cfg80211_get_chan_state(wdev, &ch, &chmode,
+ ¶ms.radar_detect);
+ wdev_unlock(wdev);
- params.beacon_int_different = true;
+ 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;
- /* Get the GCD */
- while (bi_prev != 0) {
- u32 tmp_bi = bi_prev;
+ if (i == CFG80211_MAX_NUM_DIFFERENT_CHANNELS)
+ return -EBUSY;
- bi_prev = params.beacon_int_gcd % bi_prev;
- params.beacon_int_gcd = tmp_bi;
+ 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]++;
}
return cfg80211_check_combinations(&rdev->wiphy, ¶ms);
@@ -1612,6 +1635,35 @@ int cfg80211_iter_combinations(struct wiphy *wiphy,
int i, j, iftype;
int num_interfaces = 0;
u32 used_iftypes = 0;
+ struct wireless_dev *wdev;
+ bool beacon_int_different = false;
+
+ list_for_each_entry(wdev, &wiphy->wdev_list, list) {
+ u32 curr_bi = wdev->beacon_interval;
+
+ if (!curr_bi)
+ continue;
+
+ /* set first beacon_int as GCD if beacon_int_gcd = 0 */
+ if (!params->beacon_int_gcd) {
+ params->beacon_int_gcd = curr_bi;
+ continue;
+ }
+
+ /* slight optimisation - skip identical BIs */
+ if (curr_bi == params->beacon_int_gcd)
+ continue;
+
+ beacon_int_different = true;
+
+ /* Get the GCD */
+ while (curr_bi != 0) {
+ u32 tmp_bi = curr_bi;
+
+ curr_bi = params->beacon_int_gcd % curr_bi;
+ params->beacon_int_gcd = tmp_bi;
+ }
+ }
if (params->radar_detect) {
rcu_read_lock();
@@ -1678,8 +1730,7 @@ int cfg80211_iter_combinations(struct wiphy *wiphy,
if (c->beacon_int_min_gcd &&
params->beacon_int_gcd < c->beacon_int_min_gcd)
return -EINVAL;
- if (!c->beacon_int_min_gcd &&
- params->beacon_int_different)
+ if (!c->beacon_int_min_gcd && beacon_int_different)
goto cont;
}
--
1.9.1
^ permalink raw reply related
* Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)
From: Sergey Senozhatsky @ 2016-10-13 15:00 UTC (permalink / raw)
To: Johannes Berg
Cc: Sergey Senozhatsky, Andy Lutomirski, Andy Lutomirski,
David S. Miller, Linux Wireless List, Network Development,
linux-kernel@vger.kernel.org, Sergey Senozhatsky,
linux-next@vger.kernel.org, Stephen Rothwell, Herbert Xu
In-Reply-To: <1476366354.4904.31.camel@sipsolutions.net>
On (10/13/16 15:45), Johannes Berg wrote:
> On Thu, 2016-10-13 at 22:42 +0900, Sergey Senozhatsky wrote:
> >
> > > > https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commi
> > > > t/?h=x86/vmap_stack&id=0a39cfa6fbb5d5635c85253cc7d6b44b54822afd
> > > > https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commi
> > > > t/?h=x86/vmap_stack&id=bf8cfa200b5a01383ea39fc8ce2f32909767baa8
> > >
> > > That truly sounds like something we'd rather avoid in the TX/RX
> > > paths though, which should perform well.
> >
> > didn't fix.
>
> It couldn't, since the new helpers weren't used in mac80211 in those
> patches yet.
indeed. I thought they were.
> > FAIL: 00004100002cba02 > ffffc900802cba02 || 1 -> (00004100002cba02
> > >> 39) == 130
>
> The question, though, is why precisely that fails in the crypto code.
> Can you send the Oops report itself?
kernel: BUG: unable to handle kernel NULL pointer dereference at (null)
kernel: IP: [<ffffffff8146d2f4>] ieee80211_aes_ccm_decrypt+0x107/0x27f
kernel: PGD 0
kernel:
kernel: Oops: 0000 [#1] PREEMPT SMP
kernel: Modules linked in: nls_iso8859_1 nls_cp437 vfat fat mousedev psmouse serio_raw atkbd libps2 i915 coretemp i2c_algo_bit hwmon crc32c_intel mxm_wmi drm_kms_helper cfbfillrect syscopyarea cfbimgblt sysfillrect iwlmvm sysimgblt fb_sys_fops i2c_i801 cfbcopyarea ie31200_edac drm iwlwifi i2c
kernel: CPU: 3 PID: 245 Comm: irq/28-iwlwifi Not tainted 4.8.0-next-20161013-dbg-00002-ge789862-dirty #112
kernel: task: ffff88041bf01800 task.stack: ffffc900002d0000
kernel: RIP: 0010:[<ffffffff8146d2f4>] [<ffffffff8146d2f4>] ieee80211_aes_ccm_decrypt+0x107/0x27f
kernel: RSP: 0018:ffffc900002d3770 EFLAGS: 00010246
kernel: RAX: ffffc900002d3930 RBX: ffff8804133cf606 RCX: 0000000000082000
kernel: RDX: 0000000000000000 RSI: 0000000000000018 RDI: 0000000000000a02
kernel: RBP: ffffc900002d39b8 R08: 00000000000005e4 R09: 00000004100002d3
kernel: R10: 000000000000001c R11: ffff8803e66d2d20 R12: ffff8804191c2780
kernel: R13: ffffc900002d39f0 R14: ffff8804133cf022 R15: 1ffff9200005a6ee
kernel: FS: 0000000000000000(0000) GS:ffff88041ea00000(0000) knlGS:0000000000000000
kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
kernel: CR2: 0000000000000000 CR3: 0000000001805000 CR4: 00000000001406e0
kernel: Stack:
kernel: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
kernel: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
kernel: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
kernel: Call Trace:
kernel: [<ffffffff8145c405>] ieee80211_crypto_ccmp_decrypt+0x204/0x298
kernel: [<ffffffff81476cd8>] ieee80211_rx_handlers+0x7df/0x1c1d
kernel: [<ffffffff814790c8>] ieee80211_prepare_and_rx_handle+0xdc2/0xe79
kernel: [<ffffffff814792e7>] ? ieee80211_rx_napi+0x168/0x7b6
kernel: [<ffffffff8147960a>] ieee80211_rx_napi+0x48b/0x7b6
kernel: [<ffffffff8123729e>] ? debug_smp_processor_id+0x17/0x19
kernel: [<ffffffffa01cfe3b>] iwl_mvm_rx_rx_mpdu+0x6e6/0x751 [iwlmvm]
kernel: [<ffffffffa01c9c49>] iwl_mvm_rx+0x7e/0x98 [iwlmvm]
kernel: [<ffffffffa0131bca>] iwl_pcie_rx_handle+0x523/0x698 [iwlwifi]
kernel: [<ffffffffa0133027>] iwl_pcie_irq_handler+0x46f/0x65f [iwlwifi]
kernel: [<ffffffff810893d0>] ? irq_finalize_oneshot+0xd4/0xd4
kernel: [<ffffffff810893ed>] irq_thread_fn+0x1d/0x34
kernel: [<ffffffff81089661>] irq_thread+0xe6/0x1bb
kernel: [<ffffffff810894e6>] ? wake_threads_waitq+0x2c/0x2c
kernel: [<ffffffff8108957b>] ? irq_thread_dtor+0x95/0x95
kernel: [<ffffffff8105d762>] kthread+0xfc/0x104
kernel: [<ffffffff8107d36c>] ? put_lock_stats.isra.9+0xe/0x20
kernel: [<ffffffff8105d666>] ? kthread_create_on_node+0x3f/0x3f
kernel: [<ffffffff814b2852>] ret_from_fork+0x22/0x30
kernel: Code: 01 ca 49 89 d1 48 89 d1 48 c1 ea 23 48 8b 14 d5 80 23 63 82 49 c1 e9 0c 48 c1 e9 1b 48 85 d2 74 0a 0f b6 c9 48 c1 e1 04 48 01 ca <48> 8b 12 49 c1 e1 06 b9 00 00 00 80 89 7d 80 89 75 84 48 8b 3d
kernel: RIP [<ffffffff8146d2f4>] ieee80211_aes_ccm_decrypt+0x107/0x27f
kernel: RSP <ffffc900002d3770>
kernel: CR2: 0000000000000000
kernel: ---[ end trace 3cd1fcd496516f72 ]---
-ss
^ permalink raw reply
* Re: [PATCH] iwlwifi: pcie: fix SPLC structure parsing
From: Luca Coelho @ 2016-10-13 14:30 UTC (permalink / raw)
To: Chris Rorvick
Cc: linux-wireless, linuxwifi, emmanuel.grumbach, johannes, kvalo,
oren.givon, netdev, linux-kernel, Paul Bolle
In-Reply-To: <CAEUsAPaqyxA1=3ktisBO3Vrw9ygi7PSrk32Rw+iyHVe_WB1oyg@mail.gmail.com>
On Thu, 2016-10-13 at 08:56 -0500, Chris Rorvick wrote:
> Hi Luca,
>
> > On Thu, 2016-10-13 at 13:21 +0300, Luca Coelho wrote:
> > Could you please give this a spin? I have tested it with some handmade
> > ACPI tables in QEMU and it seems to work fine now.
>
>
> Tested-by: Chris Rorvick <chris@rorvick.com>
>
> I think the debug output looks as expected, see below for the first 20
> lines or so. And, more importantly, everything seems to be working!
> :-)
Yes, you got exactly what was expected. Thanks for testing!
--
Luca.
^ permalink raw reply
* Re: [PATCH 1/3] rsi: Fix memory leak in module unload
From: Kalle Valo @ 2016-10-13 14:26 UTC (permalink / raw)
To: Prameela Rani Garnepudi
Cc: linux-wireless, johannes.berg, hofrat, xypron.glpk,
prameela.garnepudi
In-Reply-To: <87inswcs1j.fsf@kamboji.qca.qualcomm.com>
Kalle Valo <kvalo@codeaurora.org> writes:
> Prameela Rani Garnepudi <prameela.j04cs@gmail.com> writes:
>
>> Observed crash when module is unloaded if CONFIG_RSI_DEBUGSFS is not set.
>> Fix: Debugfs entry removal moved inside CONFIG_RSI_DEBUGSFS flag in
>> function rsi_mac80211_detach()
>> Memory leak found and fixed for below structures in function rsi_mac80211_detach()
>> * channel list for each supported band
>> * rsi debugfs info
>>
>> Signed-off-by: Prameela Rani Garnepudi <prameela.j04cs@gmail.com>
>
> BTW, I don't see patch 2 in patchwork nor in linux-wireless, but I do
> see it on my inbox. Either it's slow or there was a problem with the
> delivery.
It was just slow, I see it now:
https://patchwork.kernel.org/patch/9374987/
--
Kalle Valo
^ permalink raw reply
* Re: [1/2] ath9k: change entropy formula for easier understanding
From: Kalle Valo @ 2016-10-13 14:23 UTC (permalink / raw)
To: miaoqing pan
Cc: linux-wireless, ath9k-devel, linux-crypto, smueller, jason,
pouyans, Miaoqing Pan
In-Reply-To: <1470726147-30095-1-git-send-email-miaoqing@codeaurora.org>
miaoqing pan <miaoqing@codeaurora.org> wrote:
> From: Miaoqing Pan <miaoqing@codeaurora.org>
>
> The quality of ADC entropy is 10 bits of min-entropy for
> a 32-bit value, change '(((x) * 8 * 320) >> 10)' to
> '(((x) * 8 * 10) >> 5)' for easier understanding.
>
> Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
e463139a7262 ath9k: change entropy formula for easier understanding
--
https://patchwork.kernel.org/patch/9270463/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: ath10k: Fix kernel panic due to race in accessing arvif list
From: Kalle Valo @ 2016-10-13 14:21 UTC (permalink / raw)
To: Vasanthakumar Thiagarajan
Cc: ath10k, Vasanthakumar Thiagarajan, linux-wireless
In-Reply-To: <1476109278-7957-1-git-send-email-vthiagar@qti.qualcomm.com>
Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com> wrote:
> arvifs list is traversed within data_lock spin_lock in tasklet
> context to fill channel information from the corresponding vif.
> This means any access to arvifs list for add/del operations
> should also be protected with the same spin_lock to avoid the
> race. Fix this by performing list add/del on arvfis within the
> data_lock. This could fix kernel panic something like the below.
>
> LR is at ath10k_htt_rx_pktlog_completion_handler+0x100/0xb6c [ath10k_core]
> PC is at ath10k_htt_rx_pktlog_completion_handler+0x1c0/0xb6c [ath10k_core]
> Internal error: Oops: 17 [#1] PREEMPT SMP ARM
> [<bf4857f4>] (ath10k_htt_rx_pktlog_completion_handler+0x2f4/0xb6c [ath10k_core])
> [<bf487540>] (ath10k_htt_txrx_compl_task+0x8b4/0x1188 [ath10k_core])
> [<c00312d4>] (tasklet_action+0x8c/0xec)
> [<c00309a8>] (__do_softirq+0xdc/0x208)
> [<c0030d6c>] (irq_exit+0x84/0xe0)
> [<c005db04>] (__handle_domain_irq+0x80/0xa0)
> [<c00085c4>] (gic_handle_irq+0x38/0x5c)
> [<c0009640>] (__irq_svc+0x40/0x74)
>
> (gdb) list *(ath10k_htt_rx_pktlog_completion_handler+0x1c0)
> 0x136c0 is in ath10k_htt_rx_h_channel (drivers/net/wireless/ath/ath10k/htt_rx.c:769)
> 764 struct cfg80211_chan_def def;
> 765
> 766 lockdep_assert_held(&ar->data_lock);
> 767
> 768 list_for_each_entry(arvif, &ar->arvifs, list) {
> 769 if (arvif->vdev_id == vdev_id &&
> 770 ath10k_mac_vif_chan(arvif->vif, &def) == 0)
> 771 return def.chan;
> 772 }
> 773
>
> Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
Patch applied to ath-next branch of ath.git, thanks.
ebaa4b1620bf ath10k: fix kernel panic due to race in accessing arvif list
--
https://patchwork.kernel.org/patch/9369573/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)
From: Johannes Berg @ 2016-10-13 13:45 UTC (permalink / raw)
To: Sergey Senozhatsky, Andy Lutomirski
Cc: Andy Lutomirski, David S. Miller, Linux Wireless List,
Network Development, linux-kernel@vger.kernel.org,
Sergey Senozhatsky, linux-next@vger.kernel.org, Stephen Rothwell,
Herbert Xu
In-Reply-To: <20161013134252.GA583@swordfish>
On Thu, 2016-10-13 at 22:42 +0900, Sergey Senozhatsky wrote:
>
> > > https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commi
> > > t/?h=x86/vmap_stack&id=0a39cfa6fbb5d5635c85253cc7d6b44b54822afd
> > > https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commi
> > > t/?h=x86/vmap_stack&id=bf8cfa200b5a01383ea39fc8ce2f32909767baa8
> >
> > That truly sounds like something we'd rather avoid in the TX/RX
> > paths though, which should perform well.
>
> didn't fix.
It couldn't, since the new helpers weren't used in mac80211 in those
patches yet.
> so I finally had some time to do a better bug-reporter job.
>
> I added a bunch of printk-s and several virt_addr_valid()-s
> to ieee80211_aes_ccm_encrypt().
>
> and right befoe the Oops I see the following report from
> virt_addr_valid()
>
>
> FAIL: 00004100002cba02 > ffffc900802cba02 || 1 -> (00004100002cba02
> >> 39) == 130
Yeah, we already know that in this function the aad variable is on the
stack, it explicitly is.
The question, though, is why precisely that fails in the crypto code.
Can you send the Oops report itself?
johannes
^ permalink raw reply
* Re: [PATCH v2] ath10k: Cleanup calling ath10k_htt_rx_h_unchain
From: Valo, Kalle @ 2016-10-13 14:06 UTC (permalink / raw)
To: Shajakhan, Mohammed Shafi (Mohammed Shafi)
Cc: ath10k@lists.infradead.org, mohammed@codeaurora.org,
linux-wireless@vger.kernel.org
In-Reply-To: <1475596199-4563-1-git-send-email-mohammed@qca.qualcomm.com>
Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> writes:
> From: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
>
> 'ath10k_htt_rx_h_unchain' needs to be called only if the return
> value from 'ath10k_htt_rx_amsdu_pop' is 1('chained msdu's'), this
> change makes it more explicit and avoids doing a skb_peek, fetching
> rx descriptor pointer, checking rx msdu decap format for the case of
> ret =3D 0 (unchained msdus). Found this change during code walk through,
> not sure if this addresses any issue.
>
> Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Applied to ath-next, thanks.
(The SMTP server failed, needed to send this manually)
--=20
Kalle Valo=
^ permalink raw reply
* Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)
From: Sergey Senozhatsky @ 2016-10-13 13:45 UTC (permalink / raw)
To: Sergey Senozhatsky
Cc: Andy Lutomirski, Johannes Berg, Andy Lutomirski, David S. Miller,
Linux Wireless List, Network Development,
linux-kernel@vger.kernel.org, Sergey Senozhatsky,
linux-next@vger.kernel.org, Stephen Rothwell, Herbert Xu
In-Reply-To: <20161013134252.GA583@swordfish>
On (10/13/16 22:42), Sergey Senozhatsky wrote:
>
> On (10/13/16 08:02), Johannes Berg wrote:
> > On Wed, 2016-10-12 at 22:39 -0700, Andy Lutomirski wrote:
> >
> > > In a pinch, I have these patches sitting around:
> > >
> > > https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=x86/vmap_stack&id=0a39cfa6fbb5d5635c85253cc7d6b44b54822afd
> > > https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=x86/vmap_stack&id=bf8cfa200b5a01383ea39fc8ce2f32909767baa8
> >
> > That truly sounds like something we'd rather avoid in the TX/RX paths
> > though, which should perform well.
>
> didn't fix.
>
> so I finally had some time to do a better bug-reporter job.
>
> I added a bunch of printk-s and several virt_addr_valid()-s
> to ieee80211_aes_ccm_encrypt().
>
> and right befoe the Oops I see the following report from
> virt_addr_valid()
>
>
> FAIL: 00004100002cba02 > ffffc900802cba02 || 1 -> (00004100002cba02 >> 39) == 130
that `(00004100002cba02 >> 39) == 130' part is
phys_addr_valid()
{
(addr >> boot_cpu_data.x86_phys_bits)
}
-ss
^ permalink raw reply
* Re: [PATCH] iwlwifi: pcie: fix SPLC structure parsing
From: Chris Rorvick @ 2016-10-13 13:56 UTC (permalink / raw)
To: Luca Coelho
Cc: linux-wireless, linuxwifi, emmanuel.grumbach, johannes, kvalo,
oren.givon, netdev, linux-kernel, Paul Bolle
In-Reply-To: <1476358075.1999.5.camel@tiscali.nl>
Hi Luca,
> On Thu, 2016-10-13 at 13:21 +0300, Luca Coelho wrote:
> Could you please give this a spin? I have tested it with some handmade
> ACPI tables in QEMU and it seems to work fine now.
Tested-by: Chris Rorvick <chris@rorvick.com>
I think the debug output looks as expected, see below for the first 20
lines or so. And, more importantly, everything seems to be working!
:-)
Thanks!
Chris
==========
iwlwifi 0000:3a:00.0: L1 Enabled - LTR Disabled
iwlwifi: module verification failed: signature and/or required key
missing - tainting kernel
Intel(R) Wireless WiFi driver for Linux
Copyright(c) 2003- 2015 Intel Corporation
iwlwifi 0000:3a:00.0: U iwl_pcie_prepare_card_hw iwl_trans_prepare_card_hw enter
iwlwifi 0000:3a:00.0: U iwl_pcie_set_hw_ready hardware ready
iwlwifi 0000:3a:00.0: U iwl_request_firmware attempting to load
firmware 'iwlwifi-8000C-24.ucode'
iwlwifi 0000:3a:00.0: Direct firmware load for iwlwifi-8000C-24.ucode
failed with error -2
iwlwifi 0000:3a:00.0: U iwl_request_firmware attempting to load
firmware 'iwlwifi-8000C-23.ucode'
iwlwifi 0000:3a:00.0: Direct firmware load for iwlwifi-8000C-23.ucode
failed with error -2
iwlwifi 0000:3a:00.0: U iwl_request_firmware attempting to load
firmware 'iwlwifi-8000C-22.ucode'
iwlwifi 0000:3a:00.0: Direct firmware load for iwlwifi-8000C-22.ucode
failed with error -2
iwlwifi 0000:3a:00.0: U iwl_request_firmware attempting to load
firmware 'iwlwifi-8000C-21.ucode'
iwlwifi 0000:3a:00.0: U iwl_req_fw_callback Loaded firmware file
'iwlwifi-8000C-21.ucode' (2394060 bytes).
iwlwifi 0000:3a:00.0: U iwl_parse_tlv_firmware unknown TLV: 48
iwlwifi 0000:3a:00.0: U iwl_parse_tlv_firmware GSCAN is supported but
capabilities TLV is unavailable
iwlwifi 0000:3a:00.0: U splc_get_pwr_limit No element for the WiFi
domain returned by the SPLC method.
iwlwifi 0000:3a:00.0: U set_dflt_pwr_limit Default power limit set to 0
iwlwifi 0000:3a:00.0: loaded firmware version 21.302800.0 op_mode iwlmvm
iwlwifi 0000:3a:00.0: Detected Intel(R) Dual Band Wireless AC 8260, REV=0x208
^ permalink raw reply
* Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)
From: Sergey Senozhatsky @ 2016-10-13 13:42 UTC (permalink / raw)
To: Andy Lutomirski, Johannes Berg
Cc: Sergey Senozhatsky, Andy Lutomirski, David S. Miller,
Linux Wireless List, Network Development,
linux-kernel@vger.kernel.org, Sergey Senozhatsky,
linux-next@vger.kernel.org, Stephen Rothwell, Herbert Xu
In-Reply-To: <1476338524.4904.1.camel@sipsolutions.net>
On (10/13/16 08:02), Johannes Berg wrote:
> On Wed, 2016-10-12 at 22:39 -0700, Andy Lutomirski wrote:
>
> > In a pinch, I have these patches sitting around:
> >
> > https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=x86/vmap_stack&id=0a39cfa6fbb5d5635c85253cc7d6b44b54822afd
> > https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=x86/vmap_stack&id=bf8cfa200b5a01383ea39fc8ce2f32909767baa8
>
> That truly sounds like something we'd rather avoid in the TX/RX paths
> though, which should perform well.
didn't fix.
so I finally had some time to do a better bug-reporter job.
I added a bunch of printk-s and several virt_addr_valid()-s
to ieee80211_aes_ccm_encrypt().
and right befoe the Oops I see the following report from
virt_addr_valid()
FAIL: 00004100002cba02 > ffffc900802cba02 || 1 -> (00004100002cba02 >> 39) == 130
which is basically failed '!phys_addr_valid(x)' in __virt_addr_valid()
/* carry flag will be set if starting x was >= PAGE_OFFSET */
if ((x > y) || !phys_addr_valid(x))
return false;
backtrace
------------[ cut here ]------------
WARNING: CPU: 7 PID: 246 at arch/x86/mm/physaddr.c:68 __virt_addr_valid+0xab/0xed
ffffc900002cb6f0 ffffffff8122168c 0000000000000000 0000000000000000
ffffc900002cb730 ffffffff810428d8 0000004400000198 ffff88041bd21022
ffffc900002cba02 1ffff920000596ed ffff88041932d1e0 ffffc900002cba00
Call Trace:
[<ffffffff8122168c>] dump_stack+0x4f/0x65
[<ffffffff810428d8>] __warn+0xc2/0xdd
[<ffffffff81042963>] warn_slowpath_null+0x1d/0x1f
[<ffffffff8103c226>] __virt_addr_valid+0xab/0xed
[<ffffffff8146d31a>] ieee80211_aes_ccm_decrypt+0x8f/0x2da
[<ffffffff812372de>] ? debug_smp_processor_id+0x17/0x19
[<ffffffff810fb7e1>] ? __put_page+0x3c/0x3f
[<ffffffff8145b879>] ? ccmp_special_blocks.isra.1+0x51/0x12d
[<ffffffff8145c445>] ieee80211_crypto_ccmp_decrypt+0x204/0x298
[<ffffffff81476dd1>] ieee80211_rx_handlers+0x7df/0x1c1d
[<ffffffff814791c1>] ieee80211_prepare_and_rx_handle+0xdc2/0xe79
[<ffffffff814793cc>] ? ieee80211_rx_napi+0x154/0x7a5
[<ffffffff814796ec>] ieee80211_rx_napi+0x474/0x7a5
[<ffffffffa01fce3b>] iwl_mvm_rx_rx_mpdu+0x6e6/0x751 [iwlmvm]
[<ffffffffa01f6c49>] iwl_mvm_rx+0x7e/0x98 [iwlmvm]
[<ffffffffa01c0bca>] iwl_pcie_rx_handle+0x523/0x698 [iwlwifi]
[<ffffffffa01c2015>] iwl_pcie_irq_handler+0x45d/0x64d [iwlwifi]
[<ffffffff81089411>] ? irq_finalize_oneshot+0xd4/0xd4
[<ffffffff8108942e>] irq_thread_fn+0x1d/0x34
[<ffffffff810896a2>] irq_thread+0xe6/0x1bb
[<ffffffff81089527>] ? wake_threads_waitq+0x2c/0x2c
[<ffffffff810895bc>] ? irq_thread_dtor+0x95/0x95
[<ffffffff8105d7a3>] kthread+0xfc/0x104
[<ffffffff8107d3ad>] ? put_lock_stats.isra.9+0xe/0x20
[<ffffffff8105d6a7>] ? kthread_create_on_node+0x3f/0x3f
[<ffffffff8105d6a7>] ? kthread_create_on_node+0x3f/0x3f
[<ffffffff8105d6a7>] ? kthread_create_on_node+0x3f/0x3f
[<ffffffff814b2952>] ret_from_fork+0x22/0x30
-ss
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox