* Re: [PATCH] fixed hwsim beacon delta calculation
From: Johannes Berg @ 2016-11-15 13:42 UTC (permalink / raw)
To: Benjamin Beichler, linux-wireless
In-Reply-To: <980aa1f8-42c3-4fe4-a930-d930474ad2eb@MAIL1.uni-rostock.de>
On Fri, 2016-11-11 at 17:37 +0100, Benjamin Beichler wrote:
> Due to the cast from uint32_t to int64_t, a wrong next beacon timing
> is
> calculated and effectively the beacon timer stops to work. This is
> especially bad for 802.11s mesh networks, because discovery breaks
> without beacons.
>
Applied. Please note how I changed the commit subject, and use that
scheme in the future.
johannes
^ permalink raw reply
* Re: [OpenWrt-Devel] ATH10K VLAN firmware issue
From: Valo, Kalle @ 2016-11-15 13:43 UTC (permalink / raw)
To: Bruno Antunes
Cc: OpenWrt Development List, linux-wireless, voncken,
ath10k@lists.infradead.org
In-Reply-To: <CABUTiXV8eFsW4MJET4spvjVQvFgi66NV7hLLxFC6Ttqs1znxjA@mail.gmail.com>
Bruno Antunes <baantunes@gmail.com> writes:
> On 7 November 2016 at 18:06, Valo, Kalle <kvalo@qca.qualcomm.com> wrote:
>> Bruno Antunes <baantunes@gmail.com> writes:
>>
>>> On 4 November 2016 at 21:17, Valo, Kalle <kvalo@qca.qualcomm.com> wrote=
:
>>>
>>>> Can someone file a bug to bugzilla about this so that all the info is
>>>> properly stored? The more comprehensive the report is the better.
>>>>
>>>> https://bugzilla.kernel.org/
>>>
>>> I will file a bug report.
>>
>> Thanks, it's good to store all in one place so that it's easier to find
>> the relevant info.
>
> Just file the bug with the ID 187241 - VLAN support in ATH10k Feel
> free to ask for adicional info. I did not mention any names in the bug
> report fell free to take credit if wanted.
Thanks. I'll report it to the firmware team, let's see what happens. If
there's more information which might help to fix this feel free to
update that to the bug report.
https://bugzilla.kernel.org/show_bug.cgi?id=3D187241
--=20
Kalle Valo=
^ permalink raw reply
* Re: [PATCH] broadcom/brcm80211/brcmfmac/cfg80211 driver, bad regulatory domain frequency value
From: Kalle Valo @ 2016-11-15 13:52 UTC (permalink / raw)
To: Gianfranco Costamagna
Cc: Arend Van Spriel, brcm80211-dev-list@broadcom.com,
linux-wireless@vger.kernel.org, nsmaldone@tierratelematics.com,
Marco.Arlone@roj.com
In-Reply-To: <1967239621.630327.1479215628178@mail.yahoo.com>
Gianfranco Costamagna <locutusofborg@debian.org> writes:
>> Signed-off-by: Nicola Smaldone <nicola.smaldone@tierraservice.com>
>
>> Signed-off-by: Arlone Marco <marco.arlone@roj.com>
>
>>Please note that you cannot add Signed-off-by for other people without
>>their explicit approval (see Documentation/SubmittingPatches). I don't
>>know if they did it in this case or not, but wanted to point out this
>>anyway.
>
>
> The first signoff is myself, with the company email, the other two signoffs
> are from: the author, and Nicola, who did work with me to test it
> (even if a typo fix is not "testable").
>
> Nicola, Marco, is it ok to add your two names in the signoff part?
> (that was a verbal talk, I don't have anything written)
Good, so we got now approvals from both of them. Thanks.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCHv2,1/2] ath10k: add per peer htt tx stats support for 10.4
From: Kalle Valo @ 2016-11-15 14:36 UTC (permalink / raw)
To: akolli; +Cc: ath10k, Anilkumar Kolli, akolli, linux-wireless
In-Reply-To: <1476783085-10724-2-git-send-email-akolli@qti.qualcomm.com>
akolli@qti.qualcomm.com wrote:
> From: Anilkumar Kolli <akolli@qti.qualcomm.com>
>
> Per peer tx stats are part of 'HTT_10_4_T2H_MSG_TYPE_PEER_STATS'
> event, Firmware sends one HTT event for every four PPDUs.
> HTT payload has success pkts/bytes, failed pkts/bytes, retry
> pkts/bytes and rate info per ppdu.
> Peer stats are enabled through 'WMI_SERVICE_PEER_STATS',
> which are nowadays enabled by default.
>
> Parse peer stats and update the tx rate information per STA.
>
> tx rate, Peer stats are tested on QCA4019 with Firmware version
> 10.4-3.2.1-00028.
>
> Signed-off-by: Anilkumar Kolli <akolli@qti.qualcomm.com>
I see a new sparse warning:
drivers/net/wireless/ath/ath10k/htt_rx.c:2290:17: warning: incorrect type in assignment (different base types)
drivers/net/wireless/ath/ath10k/htt_rx.c:2290:17: expected int [signed] peer_id
drivers/net/wireless/ath/ath10k/htt_rx.c:2290:17: got restricted __le16 [usertype] peer_id
2 patches set to Changes Requested.
9381691 [PATCHv2,1/2] ath10k: add per peer htt tx stats support for 10.4
9381693 [PATCHv2,2/2] ath10k: add support for per sta tx bitrate
--
https://patchwork.kernel.org/patch/9381691/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] ath9k: Move generic entries below specific ones in ath_pci_id_table.
From: Valo, Kalle @ 2016-11-15 14:49 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: <8d77a285e16cdd9f3b79c9e8d8800d72@vittgam.net>
"Vittorio Gambaletta (VittGam)" <linux-wireless@vittgam.net> writes:
> Hello,
>
> On 12/10/2016 17:01:08 CEST, Valo, Kalle wrote:
>
>> So to tell the full story I'll change the commit log to something like
>> below. Does it look ok to you?
>
> Yes; but I'd change "So" to "This turned out to be wrong", and add a note
> about changing the order for 0x002A too:
>
> ----------------------------------------------------------------------
> 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.
>
> This turned out to be wrong: 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.
>
> While I'm at it, let's fix 0x002A too by also moving its generic definiti=
on
> below its specific ones.
>
> Fixes: 0f9edcdd88a9 ("ath9k: Fix LED polarity for some Mini PCI AR9220 MB=
92 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 discussion=
s]
> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
> ----------------------------------------------------------------------
Thanks, I updated the commit with your changes.
--=20
Kalle Valo=
^ permalink raw reply
* Re: [OpenWrt-Devel] ATH10K VLAN firmware issue
From: Bruno Antunes @ 2016-11-15 14:53 UTC (permalink / raw)
To: Valo, Kalle
Cc: OpenWrt Development List, linux-wireless, voncken,
ath10k@lists.infradead.org, Ben Greear
In-Reply-To: <87polwq2nq.fsf@kamboji.qca.qualcomm.com>
On 15 November 2016 at 13:43, Valo, Kalle <kvalo@qca.qualcomm.com> wrote:
> Bruno Antunes <baantunes@gmail.com> writes:
>
>> On 7 November 2016 at 18:06, Valo, Kalle <kvalo@qca.qualcomm.com> wrote:
>>> Bruno Antunes <baantunes@gmail.com> writes:
>>>
>>>> On 4 November 2016 at 21:17, Valo, Kalle <kvalo@qca.qualcomm.com> wrote:
>>>>
>>>>> Can someone file a bug to bugzilla about this so that all the info is
>>>>> properly stored? The more comprehensive the report is the better.
>>>>>
>>>>> https://bugzilla.kernel.org/
>>>>
>>>> I will file a bug report.
>>>
>>> Thanks, it's good to store all in one place so that it's easier to find
>>> the relevant info.
>>
>> Just file the bug with the ID 187241 - VLAN support in ATH10k Feel
>> free to ask for adicional info. I did not mention any names in the bug
>> report fell free to take credit if wanted.
>
> Thanks. I'll report it to the firmware team, let's see what happens. If
> there's more information which might help to fix this feel free to
> update that to the bug report.
I'm finishing my tests and will update the bug report ASAP.
Turns out the bad throughput was the result of a failure in the switch port.
With Ben's firmware the VLAN support is working fine with security.
Thanks,
Bruno
>
> https://bugzilla.kernel.org/show_bug.cgi?id=187241
>
> --
> Kalle Valo
^ permalink raw reply
* Re: ath9k: Move generic entries below specific ones in ath_pci_id_table.
From: Kalle Valo @ 2016-11-15 14:53 UTC (permalink / raw)
To: Vittorio Gambaletta (VittGam); +Cc: kvalo, linux-wireless
In-Reply-To: <ath9k-patch-20161003@vittgam.net>
"Vittorio Gambaletta \(VittGam\)" <linux-wireless@vittgam.net> wrote:
> 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>
> Signed-off-by: Vittorio Gambaletta <linuxbugs@vittgam.net>
> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
> Signed-off-by: Vittorio Gambaletta <linuxbugs@vittgam.net>
> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
>
> --- a/drivers/net/wireless/ath/ath9k/pci.c
> +++ b/drivers/net/wireless/ath/ath9k/pci.c
> @@ -26,7 +26,6 @@
> { PCI_VDEVICE(ATHEROS, 0x0023) }, /* PCI */
> { PCI_VDEVICE(ATHEROS, 0x0024) }, /* PCI-E */
> { PCI_VDEVICE(ATHEROS, 0x0027) }, /* PCI */
> - { PCI_VDEVICE(ATHEROS, 0x0029) }, /* PCI */
>
> #ifdef CONFIG_ATH9K_PCOEM
> /* Mini PCI AR9220 MB92 cards: Compex WLM200NX, Wistron DNMA-92 */
> @@ -37,7 +36,7 @@
> .driver_data = ATH9K_PCI_LED_ACT_HI },
> #endif
>
> - { PCI_VDEVICE(ATHEROS, 0x002A) }, /* PCI-E */
> + { PCI_VDEVICE(ATHEROS, 0x0029) }, /* PCI */
>
> #ifdef CONFIG_ATH9K_PCOEM
> { PCI_DEVICE_SUB(PCI_VENDOR_ID_ATHEROS,
> @@ -85,7 +84,11 @@
> 0x10CF, /* Fujitsu */
> 0x1536),
> .driver_data = ATH9K_PCI_D3_L1_WAR },
> +#endif
>
> + { PCI_VDEVICE(ATHEROS, 0x002A) }, /* PCI-E */
> +
> +#ifdef CONFIG_ATH9K_PCOEM
> /* AR9285 card for Asus */
> { PCI_DEVICE_SUB(PCI_VENDOR_ID_ATHEROS,
> 0x002B,
Patch applied to ath-next branch of ath.git, thanks.
79e57dd113d3 ath9k: Really fix LED polarity for some Mini PCI AR9220 MB92 cards.
--
https://patchwork.kernel.org/patch/9360361/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [OpenWrt-Devel] ATH10K VLAN firmware issue
From: Ben Greear @ 2016-11-15 14:55 UTC (permalink / raw)
To: voncken; +Cc: linux-wireless, 'OpenWrt Development List', ath10k
In-Reply-To: <001a01d23f4d$cd1df550$6759dff0$@acksys.fr>
The beta-18 release on my web page has the fix and should work fine.
Probably soon I will promote the beta-18 to final release
status. Any help in testing and verifying the beta works well
is welcome.
Thanks,
Ben
On 11/15/2016 06:37 AM, voncken wrote:
> Hi Ben,
>
> Do you plan to release a candelatech firmware with this fix?
>
> Regards.
>
> Cedric Voncken.
>> -----Message d'origine-----
>> De : linux-wireless-owner@vger.kernel.org [mailto:linux-wireless-
>> owner@vger.kernel.org] De la part de Ben Greear
>> Envoyé : samedi 5 novembre 2016 15:35
>> À : Sebastian Gottschall; yu-chieh kung; Bruno Antunes
>> Cc : Mauro Mozzarelli; linux-wireless@vger.kernel.org; OpenWrt
>> Development List; ath10k@lists.infradead.org
>> Objet : Re: [OpenWrt-Devel] ATH10K VLAN firmware issue
>>
>> Looks to me like 10.4 defaults to the right value, but possibly there
>> are other issues with it. I tested my CT 10.4 and it worked OK with
>> vlans for me.
>>
>> Thanks,
>> Ben
>>
>> On 11/05/2016 01:05 AM, Sebastian Gottschall wrote:
>>> would be good if qca can fix this bug finally in all available
>>> firmwares. its a very annoying issue since a long time
>>>
>>> Sebastian
>>>
>>>
>>> Am 04.11.2016 um 23:23 schrieb Ben Greear:
>>>> The bug appears that vlan-tx-stripping is unconditionally enabled in
>>>> at least my firmware. I have re-compiled w/out that flag set, and
>> it
>>>> appears to work for me.
>>>>
>>>> Please download this firmware, rename it firmware-2.bin, make sure
>>>> you remove/rename any firmware-5.bin (etc) so mine will load, and
>> see if that fixes your problem.
>>>>
>>>> Please note that it is very likely you will have to use same MAC
>>>> address for the VLAN devices that the underlying station uses in
>> order for this to work.
>>>>
>>>> https://www.candelatech.com/downloads/tmp/firmware-2-full-
>> community.b
>>>> in
>>>>
>>>>
>>>> Thanks,
>>>> Ben
>>>>
>>>>
>>>> On 11/04/2016 02:50 PM, Ben Greear wrote:
>>>>> I can reproduce this in my CT firmware. I'll see if I can fix it,
>>>>> but for stock firmware, it might be that changing the driver to use
>>>>> Ethernet packet type of native-wifi would make .1q vlans work.
>>>>>
>>>>> Thanks,
>>>>> Ben
>>>>>
>>>>> On 11/04/2016 10:28 AM, yu-chieh kung wrote:
>>>>>> I met the same problem before,
>>>>>> if i modify the 1q header to other value (0xaa00) before go into
>> firmware.
>>>>>> I can capture the packet in the air I think the vlan packet is
>>>>>> dropped in firmware.
>>>>>>
>>>>>> 2016-11-04 22:41 GMT+08:00 Bruno Antunes <baantunes@gmail.com>:
>>>>>>> On 4 November 2016 at 14:18, Mauro Mozzarelli
>> <openwrt@ezplanet.net> wrote:
>>>>>>>> Since the capability is implemented in software you might be
>>>>>>>> testing the limit of your router's CPU i/o speed.
>>>>>>>
>>>>>>> By loading the module in rawmode?
>>>>>>>
>>>>>>> The AP is an APU and Sta is an APU2.
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 04/11/16 14:13, Bruno Antunes wrote:
>>>>>>>>>
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> Old thread but I think the issue is still present.
>>>>>>>>>
>>>>>>>>> I'm running a setup with VLANs with WDS and ath10k cards.
>>>>>>>>>
>>>>>>>>> To make it work both cards must be loaded in rawmode, AP and
>>>>>>>>> Sta, and with no security.
>>>>>>>>>
>>>>>>>>> I'm using a OpenWrt trunk r49941 and the most recent firmware,
>>>>>>>>> 10.2.4.70.58, from Kalle ath10k firmware tree.
>>>>>>>>>
>>>>>>>>> Although it works the throughput is very bad.
>>>>>>>>> Are there any alternatives to improve the throughput.
>>>>>>>>>
>>>>>>>>> Best Regards,
>>>>>>>>> Bruno
>>>>>>>>>
>>>>>>>>> On 9 December 2015 at 17:24, voncken <cedric.voncken@acksys.fr>
>> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> -----Message d'origine-----
>>>>>>>>>>> De : Ben Greear [mailto:greearb@candelatech.com] Envoyé :
>>>>>>>>>>> mercredi 9 décembre 2015 16:34 À : Cedric VONCKEN;
>>>>>>>>>>> ath10k@lists.infradead.org; linux-wireless Objet : Re: ATH10K
>>>>>>>>>>> VLAN firmware issue
>>>>>>>>>>>
>>>>>>>>>>> This only happens when you use STA + WDS, or is .1q broken
>>>>>>>>>>> for you in other cases as well?
>>>>>>>>>>
>>>>>>>>>> No, this issue occurs in all modes (STA, STA + WDS, AP).
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>>
>>>>>>>>>> Cedric.
>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Ben
>>>>>>>>>>>
>>>>>>>>>>> On 12/08/2015 06:29 AM, Cedric VONCKEN wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> I'm testing to transmit frame with 802.1q tag (VLAN).
>>>>>>>>>>>>
>>>>>>>>>>>> My client is set in STA + WDS and the netdev is bridged
>> with eth0.
>>>>>>>>>>>> I have a computer with vlan configuration set connected
>>>>>>>>>>>> to the STA eth0.
>>>>>>>>>>>>
>>>>>>>>>>>> If I try to transmit frames with 802.1q tag, the frames
>>>>>>>>>>>> are not
>>>>>>>>>>
>>>>>>>>>> sent.
>>>>>>>>>>>>
>>>>>>>>>>>> I checked with wireless sniffer, and I don't see the
>>>>>>>>>>>> frame with VLAN tag (the frames without VLAN tag are sent).
>>>>>>>>>>>>
>>>>>>>>>>>> I tested with firmware 10.2.4.70.14-2 from kale github,
>>>>>>>>>>>> 10.1.467-ct-com-full-015 from candelatech and 10.2.4.70-2
>>>>>>>>>>>> from openwrt, and in all cases I have the same issue.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks for your help.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> To unsubscribe from this list: send the line "unsubscribe
>>>>>>>>>>>> linux-wireless" in the body of a message to
>>>>>>>>>>>> majordomo@vger.kernel.org More majordomo info at
>>>>>>>>>>>> http://vger.kernel.org/majordomo-info.html
>>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Ben Greear <greearb@candelatech.com> Candela Technologies Inc
>>>>>>>>>>> http://www.candelatech.com
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> To unsubscribe from this list: send the line "unsubscribe
>> linux-wireless"
>>>>>>>>>> in
>>>>>>>>>> the body of a message to majordomo@vger.kernel.org More
>>>>>>>>>> majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> openwrt-devel mailing list
>>>>>>>>> openwrt-devel@lists.openwrt.org
>>>>>>>>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-
>> devel
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> openwrt-devel mailing list
>>>>>>>> openwrt-devel@lists.openwrt.org
>>>>>>>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> ath10k mailing list
>>>>>>> ath10k@lists.infradead.org
>>>>>>> http://lists.infradead.org/mailman/listinfo/ath10k
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>> --
>> Ben Greear <greearb@candelatech.com>
>> Candela Technologies Inc http://www.candelatech.com
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [v8, 1/3] Documentation: dt: net: add ath9k wireless device binding
From: Kalle Valo @ 2016-11-15 14:56 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: ath9k-devel, devicetree, linux-wireless, ath9k-devel, robh+dt,
mcgrof, mark.rutland, kvalo, chunkeey, arend.vanspriel,
julian.calaby, bjorn, linux, nbd, Martin Blumenstingl
In-Reply-To: <20161016205907.19927-2-martin.blumenstingl@googlemail.com>
Martin Blumenstingl <martin.blumenstingl@googlemail.com> wrote:
> Add documentation how devicetree can be used to configure ath9k based
> devices.
>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> Acked-by: Rob Herring <robh@kernel.org>
3 patches applied to ath-next branch of ath.git, thanks.
fc383ffdb91a Documentation: dt: net: add ath9k wireless device binding
b40ded2ad75c ath9k: add a helper to get the string representation of ath_bus_type
138b41253d9c ath9k: parse the device configuration from an OF node
--
https://patchwork.kernel.org/patch/9378317/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: ath9k_htc: fix minor mistakes in dev_err messages
From: Kalle Valo @ 2016-11-15 14:58 UTC (permalink / raw)
To: Colin Ian King
Cc: QCA ath9k Development, Kalle Valo, linux-wireless, ath9k-devel,
netdev, linux-kernel
In-Reply-To: <20161031151247.18127-1-colin.king@canonical.com>
Colin Ian King <colin.king@canonical.com> wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Add missing space in a dev_err message and join wrapped text so
> it does not span multiple lines. Fix spelling mistake on "unknown".
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Patch applied to ath-next branch of ath.git, thanks.
14acebc33e6d ath9k_htc: fix minor mistakes in dev_err messages
--
https://patchwork.kernel.org/patch/9405663/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [OpenWrt-Devel] ATH10K VLAN firmware issue
From: Bruno Antunes @ 2016-11-15 15:00 UTC (permalink / raw)
To: Ben Greear
Cc: voncken, OpenWrt Development List, linux-wireless@vger.kernel.org,
ath10k@lists.infradead.org
In-Reply-To: <582B21DD.6000306@candelatech.com>
On 15 November 2016 at 14:55, Ben Greear <greearb@candelatech.com> wrote:
> The beta-18 release on my web page has the fix and should work fine.
>
> Probably soon I will promote the beta-18 to final release
> status. Any help in testing and verifying the beta works well
> is welcome.
I will also do testing with that version.
For clarity can I refer you and your firmware releases in the bug report?
Thanks,
Bruno
>
> Thanks,
> Ben
>
> On 11/15/2016 06:37 AM, voncken wrote:
>>
>> Hi Ben,
>>
>> Do you plan to release a candelatech firmware with this fix?
>>
>> Regards.
>>
>> Cedric Voncken.
>>>
>>> -----Message d'origine-----
>>> De : linux-wireless-owner@vger.kernel.org [mailto:linux-wireless-
>>> owner@vger.kernel.org] De la part de Ben Greear
>>> Envoy=C3=A9 : samedi 5 novembre 2016 15:35
>>> =C3=80 : Sebastian Gottschall; yu-chieh kung; Bruno Antunes
>>> Cc : Mauro Mozzarelli; linux-wireless@vger.kernel.org; OpenWrt
>>> Development List; ath10k@lists.infradead.org
>>> Objet : Re: [OpenWrt-Devel] ATH10K VLAN firmware issue
>>>
>>>
>>> Looks to me like 10.4 defaults to the right value, but possibly there
>>> are other issues with it. I tested my CT 10.4 and it worked OK with
>>> vlans for me.
>>>
>>> Thanks,
>>> Ben
>>>
>>> On 11/05/2016 01:05 AM, Sebastian Gottschall wrote:
>>>>
>>>> would be good if qca can fix this bug finally in all available
>>>> firmwares. its a very annoying issue since a long time
>>>>
>>>> Sebastian
>>>>
>>>>
>>>> Am 04.11.2016 um 23:23 schrieb Ben Greear:
>>>>>
>>>>> The bug appears that vlan-tx-stripping is unconditionally enabled in
>>>>> at least my firmware. I have re-compiled w/out that flag set, and
>>>
>>> it
>>>>>
>>>>> appears to work for me.
>>>>>
>>>>> Please download this firmware, rename it firmware-2.bin, make sure
>>>>> you remove/rename any firmware-5.bin (etc) so mine will load, and
>>>
>>> see if that fixes your problem.
>>>>>
>>>>>
>>>>> Please note that it is very likely you will have to use same MAC
>>>>> address for the VLAN devices that the underlying station uses in
>>>
>>> order for this to work.
>>>>>
>>>>>
>>>>> https://www.candelatech.com/downloads/tmp/firmware-2-full-
>>>
>>> community.b
>>>>>
>>>>> in
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Ben
>>>>>
>>>>>
>>>>> On 11/04/2016 02:50 PM, Ben Greear wrote:
>>>>>>
>>>>>> I can reproduce this in my CT firmware. I'll see if I can fix it,
>>>>>> but for stock firmware, it might be that changing the driver to use
>>>>>> Ethernet packet type of native-wifi would make .1q vlans work.
>>>>>>
>>>>>> Thanks,
>>>>>> Ben
>>>>>>
>>>>>> On 11/04/2016 10:28 AM, yu-chieh kung wrote:
>>>>>>>
>>>>>>> I met the same problem before,
>>>>>>> if i modify the 1q header to other value (0xaa00) before go into
>>>
>>> firmware.
>>>>>>>
>>>>>>> I can capture the packet in the air I think the vlan packet is
>>>>>>> dropped in firmware.
>>>>>>>
>>>>>>> 2016-11-04 22:41 GMT+08:00 Bruno Antunes <baantunes@gmail.com>:
>>>>>>>>
>>>>>>>> On 4 November 2016 at 14:18, Mauro Mozzarelli
>>>
>>> <openwrt@ezplanet.net> wrote:
>>>>>>>>>
>>>>>>>>> Since the capability is implemented in software you might be
>>>>>>>>> testing the limit of your router's CPU i/o speed.
>>>>>>>>
>>>>>>>>
>>>>>>>> By loading the module in rawmode?
>>>>>>>>
>>>>>>>> The AP is an APU and Sta is an APU2.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 04/11/16 14:13, Bruno Antunes wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hi all,
>>>>>>>>>>
>>>>>>>>>> Old thread but I think the issue is still present.
>>>>>>>>>>
>>>>>>>>>> I'm running a setup with VLANs with WDS and ath10k cards.
>>>>>>>>>>
>>>>>>>>>> To make it work both cards must be loaded in rawmode, AP and
>>>>>>>>>> Sta, and with no security.
>>>>>>>>>>
>>>>>>>>>> I'm using a OpenWrt trunk r49941 and the most recent firmware,
>>>>>>>>>> 10.2.4.70.58, from Kalle ath10k firmware tree.
>>>>>>>>>>
>>>>>>>>>> Although it works the throughput is very bad.
>>>>>>>>>> Are there any alternatives to improve the throughput.
>>>>>>>>>>
>>>>>>>>>> Best Regards,
>>>>>>>>>> Bruno
>>>>>>>>>>
>>>>>>>>>> On 9 December 2015 at 17:24, voncken <cedric.voncken@acksys.fr>
>>>
>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> -----Message d'origine-----
>>>>>>>>>>>> De : Ben Greear [mailto:greearb@candelatech.com] Envoy=C3=A9 :
>>>>>>>>>>>> mercredi 9 d=C3=A9cembre 2015 16:34 =C3=80 : Cedric VONCKEN;
>>>>>>>>>>>> ath10k@lists.infradead.org; linux-wireless Objet : Re: ATH10K
>>>>>>>>>>>> VLAN firmware issue
>>>>>>>>>>>>
>>>>>>>>>>>> This only happens when you use STA + WDS, or is .1q broken
>>>>>>>>>>>> for you in other cases as well?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> No, this issue occurs in all modes (STA, STA + WDS, AP).
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>>
>>>>>>>>>>> Cedric.
>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Ben
>>>>>>>>>>>>
>>>>>>>>>>>> On 12/08/2015 06:29 AM, Cedric VONCKEN wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'm testing to transmit frame with 802.1q tag (VLAN).
>>>>>>>>>>>>>
>>>>>>>>>>>>> My client is set in STA + WDS and the netdev is bridged
>>>
>>> with eth0.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I have a computer with vlan configuration set connected
>>>>>>>>>>>>> to the STA eth0.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If I try to transmit frames with 802.1q tag, the frames
>>>>>>>>>>>>> are not
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> sent.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I checked with wireless sniffer, and I don't see the
>>>>>>>>>>>>> frame with VLAN tag (the frames without VLAN tag are sent).
>>>>>>>>>>>>>
>>>>>>>>>>>>> I tested with firmware 10.2.4.70.14-2 from kale github,
>>>>>>>>>>>>> 10.1.467-ct-com-full-015 from candelatech and 10.2.4.70-2
>>>>>>>>>>>>> from openwrt, and in all cases I have the same issue.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks for your help.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> To unsubscribe from this list: send the line "unsubscribe
>>>>>>>>>>>>> linux-wireless" in the body of a message to
>>>>>>>>>>>>> majordomo@vger.kernel.org More majordomo info at
>>>>>>>>>>>>> http://vger.kernel.org/majordomo-info.html
>>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Ben Greear <greearb@candelatech.com> Candela Technologies Inc
>>>>>>>>>>>> http://www.candelatech.com
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> To unsubscribe from this list: send the line "unsubscribe
>>>
>>> linux-wireless"
>>>>>>>>>>>
>>>>>>>>>>> in
>>>>>>>>>>> the body of a message to majordomo@vger.kernel.org More
>>>>>>>>>>> majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> openwrt-devel mailing list
>>>>>>>>>> openwrt-devel@lists.openwrt.org
>>>>>>>>>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-
>>>
>>> devel
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> openwrt-devel mailing list
>>>>>>>>> openwrt-devel@lists.openwrt.org
>>>>>>>>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> ath10k mailing list
>>>>>>>> ath10k@lists.infradead.org
>>>>>>>> http://lists.infradead.org/mailman/listinfo/ath10k
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>> --
>>> Ben Greear <greearb@candelatech.com>
>>> Candela Technologies Inc http://www.candelatech.com
>>
>>
>
> --
> Ben Greear <greearb@candelatech.com>
> Candela Technologies Inc http://www.candelatech.com
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
^ permalink raw reply
* Re: [v6] ath9k: Switch to using mac80211 intermediate software queues.
From: Kalle Valo @ 2016-11-15 15:00 UTC (permalink / raw)
To: Toke Høiland-Jørgensen
Cc: make-wifi-fast, linux-wireless, Toke Høiland-Jørgensen,
Tim Shepard, Felix Fietkau
In-Reply-To: <20161109113149.5724-1-toke@toke.dk>
Toke Høiland-Jørgensen wrote:
> This switches ath9k over to using the mac80211 intermediate software
> queueing mechanism for data packets. It removes the queueing inside the
> driver, except for the retry queue, and instead pulls from mac80211 when
> a packet is needed. The retry queue is used to store a packet that was
> pulled but can't be sent immediately.
>
> The old code path in ath_tx_start that would queue packets has been
> removed completely, as has the qlen limit tunables (since there's no
> longer a queue in the driver to limit).
>
> The mac80211 intermediate software queues offer significant latency
> reductions, and this patch allows ath9k to realise them. The exact gains
> from this varies with the test scenario, but in an access point scenario
> we have seen latency reductions ranging from 1/3 to as much as an order
> of magnitude. We also achieve slightly better aggregation.
>
> Median latency (ping) figures with this patch applied at the access point,
> with two high-rate stations and one low-rate station (HT20 5Ghz), running
> a Flent rtt_fair_var_up test with one TCP flow and one ping flow going to
> each station:
>
> Fast station Slow station
> Default pfifo_fast qdisc: 430.4 ms 638.7 ms
> fq_codel qdisc on iface: 35.5 ms 211.8 ms
> This patch set: 22.4 ms 38.2 ms
>
> Median aggregation sizes over the same test:
>
> Default pfifo_fast qdisc: 9.5 pkts 1.9 pkts
> fq_codel qdisc on iface: 11.2 pkts 1.9 pkts
> This patch set: 13.9 pkts 1.9 pkts
>
> This patch is based on Tim's original patch set, but reworked quite
> thoroughly.
>
> Cc: Tim Shepard <shep@alum.mit.edu>
> Cc: Felix Fietkau <nbd@nbd.name>
> Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk>
Patch applied to ath-next branch of ath.git, thanks.
50f08edf9809 ath9k: Switch to using mac80211 intermediate software queues.
--
https://patchwork.kernel.org/patch/9419029/
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 failure to send NULL func frame for 10.4
From: Kalle Valo @ 2016-11-15 15:04 UTC (permalink / raw)
To: Mohammed Shafi Shajakhan
Cc: ath10k, mohammed, linux-wireless, Mohammed Shafi Shajakhan
In-Reply-To: <1476257342-3241-1-git-send-email-mohammed@qca.qualcomm.com>
Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> wrote:
> From: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
>
> This partially reverts 'commit 2cdce425aa33
> ("ath10k: Fix broken NULL func data frame status for 10.4")'
> Unfortunately this breaks sending NULL func and the existing
> issue of obtaining proper tx status for NULL function will be
> fixed. Also update the comments for feature flag added to be
> useless and not working
>
> Fixes: 2cdce425aa33 "ath10k: Fix broken NULL func data frame status for
> 10.4"
> Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Patch applied to ath-next branch of ath.git, thanks.
fcf7cf1551ca ath10k: fix failure to send NULL func frame for 10.4
--
https://patchwork.kernel.org/patch/9372171/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [v3,1/2] ath10k: clean up HTT tx buffer allocation and free
From: Kalle Valo @ 2016-11-15 15:06 UTC (permalink / raw)
To: Mohammed Shafi Shajakhan
Cc: ath10k, mohammed, linux-wireless, Mohammed Shafi Shajakhan
In-Reply-To: <1476278778-4253-1-git-send-email-mohammed@qca.qualcomm.com>
Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> wrote:
> 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>
2 patches applied to ath-next branch of ath.git, thanks.
19f338c6eb0c ath10k: clean up HTT tx buffer allocation and free
f004e532a80a ath10k: remove extraneous error message in tx alloc
--
https://patchwork.kernel.org/patch/9373055/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [OpenWrt-Devel] ATH10K VLAN firmware issue
From: Ben Greear @ 2016-11-15 15:06 UTC (permalink / raw)
To: Bruno Antunes
Cc: voncken, OpenWrt Development List, linux-wireless@vger.kernel.org,
ath10k@lists.infradead.org
In-Reply-To: <CABUTiXWRkzyV_ic02pUTHG8TbzQUOOYj0L35wMYFcBRgssG0eA@mail.gmail.com>
On 11/15/2016 07:00 AM, Bruno Antunes wrote:
> On 15 November 2016 at 14:55, Ben Greear <greearb@candelatech.com> wrote:
>> The beta-18 release on my web page has the fix and should work fine.
>>
>> Probably soon I will promote the beta-18 to final release
>> status. Any help in testing and verifying the beta works well
>> is welcome.
>
> I will also do testing with that version.
>
> For clarity can I refer you and your firmware releases in the bug report?
It is fine by me. It is a one-line patch to fix the firmware...QCA
can ask me as well if they don't figure it out on their own.
Thanks,
Ben
>
> Thanks,
> Bruno
>>
>> Thanks,
>> Ben
>>
>> On 11/15/2016 06:37 AM, voncken wrote:
>>>
>>> Hi Ben,
>>>
>>> Do you plan to release a candelatech firmware with this fix?
>>>
>>> Regards.
>>>
>>> Cedric Voncken.
>>>>
>>>> -----Message d'origine-----
>>>> De : linux-wireless-owner@vger.kernel.org [mailto:linux-wireless-
>>>> owner@vger.kernel.org] De la part de Ben Greear
>>>> Envoyé : samedi 5 novembre 2016 15:35
>>>> À : Sebastian Gottschall; yu-chieh kung; Bruno Antunes
>>>> Cc : Mauro Mozzarelli; linux-wireless@vger.kernel.org; OpenWrt
>>>> Development List; ath10k@lists.infradead.org
>>>> Objet : Re: [OpenWrt-Devel] ATH10K VLAN firmware issue
>>>>
>>>>
>>>> Looks to me like 10.4 defaults to the right value, but possibly there
>>>> are other issues with it. I tested my CT 10.4 and it worked OK with
>>>> vlans for me.
>>>>
>>>> Thanks,
>>>> Ben
>>>>
>>>> On 11/05/2016 01:05 AM, Sebastian Gottschall wrote:
>>>>>
>>>>> would be good if qca can fix this bug finally in all available
>>>>> firmwares. its a very annoying issue since a long time
>>>>>
>>>>> Sebastian
>>>>>
>>>>>
>>>>> Am 04.11.2016 um 23:23 schrieb Ben Greear:
>>>>>>
>>>>>> The bug appears that vlan-tx-stripping is unconditionally enabled in
>>>>>> at least my firmware. I have re-compiled w/out that flag set, and
>>>>
>>>> it
>>>>>>
>>>>>> appears to work for me.
>>>>>>
>>>>>> Please download this firmware, rename it firmware-2.bin, make sure
>>>>>> you remove/rename any firmware-5.bin (etc) so mine will load, and
>>>>
>>>> see if that fixes your problem.
>>>>>>
>>>>>>
>>>>>> Please note that it is very likely you will have to use same MAC
>>>>>> address for the VLAN devices that the underlying station uses in
>>>>
>>>> order for this to work.
>>>>>>
>>>>>>
>>>>>> https://www.candelatech.com/downloads/tmp/firmware-2-full-
>>>>
>>>> community.b
>>>>>>
>>>>>> in
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Ben
>>>>>>
>>>>>>
>>>>>> On 11/04/2016 02:50 PM, Ben Greear wrote:
>>>>>>>
>>>>>>> I can reproduce this in my CT firmware. I'll see if I can fix it,
>>>>>>> but for stock firmware, it might be that changing the driver to use
>>>>>>> Ethernet packet type of native-wifi would make .1q vlans work.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Ben
>>>>>>>
>>>>>>> On 11/04/2016 10:28 AM, yu-chieh kung wrote:
>>>>>>>>
>>>>>>>> I met the same problem before,
>>>>>>>> if i modify the 1q header to other value (0xaa00) before go into
>>>>
>>>> firmware.
>>>>>>>>
>>>>>>>> I can capture the packet in the air I think the vlan packet is
>>>>>>>> dropped in firmware.
>>>>>>>>
>>>>>>>> 2016-11-04 22:41 GMT+08:00 Bruno Antunes <baantunes@gmail.com>:
>>>>>>>>>
>>>>>>>>> On 4 November 2016 at 14:18, Mauro Mozzarelli
>>>>
>>>> <openwrt@ezplanet.net> wrote:
>>>>>>>>>>
>>>>>>>>>> Since the capability is implemented in software you might be
>>>>>>>>>> testing the limit of your router's CPU i/o speed.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> By loading the module in rawmode?
>>>>>>>>>
>>>>>>>>> The AP is an APU and Sta is an APU2.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 04/11/16 14:13, Bruno Antunes wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Hi all,
>>>>>>>>>>>
>>>>>>>>>>> Old thread but I think the issue is still present.
>>>>>>>>>>>
>>>>>>>>>>> I'm running a setup with VLANs with WDS and ath10k cards.
>>>>>>>>>>>
>>>>>>>>>>> To make it work both cards must be loaded in rawmode, AP and
>>>>>>>>>>> Sta, and with no security.
>>>>>>>>>>>
>>>>>>>>>>> I'm using a OpenWrt trunk r49941 and the most recent firmware,
>>>>>>>>>>> 10.2.4.70.58, from Kalle ath10k firmware tree.
>>>>>>>>>>>
>>>>>>>>>>> Although it works the throughput is very bad.
>>>>>>>>>>> Are there any alternatives to improve the throughput.
>>>>>>>>>>>
>>>>>>>>>>> Best Regards,
>>>>>>>>>>> Bruno
>>>>>>>>>>>
>>>>>>>>>>> On 9 December 2015 at 17:24, voncken <cedric.voncken@acksys.fr>
>>>>
>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> -----Message d'origine-----
>>>>>>>>>>>>> De : Ben Greear [mailto:greearb@candelatech.com] Envoyé :
>>>>>>>>>>>>> mercredi 9 décembre 2015 16:34 À : Cedric VONCKEN;
>>>>>>>>>>>>> ath10k@lists.infradead.org; linux-wireless Objet : Re: ATH10K
>>>>>>>>>>>>> VLAN firmware issue
>>>>>>>>>>>>>
>>>>>>>>>>>>> This only happens when you use STA + WDS, or is .1q broken
>>>>>>>>>>>>> for you in other cases as well?
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> No, this issue occurs in all modes (STA, STA + WDS, AP).
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>>
>>>>>>>>>>>> Cedric.
>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Ben
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 12/08/2015 06:29 AM, Cedric VONCKEN wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'm testing to transmit frame with 802.1q tag (VLAN).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> My client is set in STA + WDS and the netdev is bridged
>>>>
>>>> with eth0.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I have a computer with vlan configuration set connected
>>>>>>>>>>>>>> to the STA eth0.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If I try to transmit frames with 802.1q tag, the frames
>>>>>>>>>>>>>> are not
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> sent.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I checked with wireless sniffer, and I don't see the
>>>>>>>>>>>>>> frame with VLAN tag (the frames without VLAN tag are sent).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I tested with firmware 10.2.4.70.14-2 from kale github,
>>>>>>>>>>>>>> 10.1.467-ct-com-full-015 from candelatech and 10.2.4.70-2
>>>>>>>>>>>>>> from openwrt, and in all cases I have the same issue.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks for your help.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> To unsubscribe from this list: send the line "unsubscribe
>>>>>>>>>>>>>> linux-wireless" in the body of a message to
>>>>>>>>>>>>>> majordomo@vger.kernel.org More majordomo info at
>>>>>>>>>>>>>> http://vger.kernel.org/majordomo-info.html
>>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Ben Greear <greearb@candelatech.com> Candela Technologies Inc
>>>>>>>>>>>>> http://www.candelatech.com
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> To unsubscribe from this list: send the line "unsubscribe
>>>>
>>>> linux-wireless"
>>>>>>>>>>>>
>>>>>>>>>>>> in
>>>>>>>>>>>> the body of a message to majordomo@vger.kernel.org More
>>>>>>>>>>>> majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> openwrt-devel mailing list
>>>>>>>>>>> openwrt-devel@lists.openwrt.org
>>>>>>>>>>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-
>>>>
>>>> devel
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> openwrt-devel mailing list
>>>>>>>>>> openwrt-devel@lists.openwrt.org
>>>>>>>>>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> ath10k mailing list
>>>>>>>>> ath10k@lists.infradead.org
>>>>>>>>> http://lists.infradead.org/mailman/listinfo/ath10k
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Ben Greear <greearb@candelatech.com>
>>>> Candela Technologies Inc http://www.candelatech.com
>>>
>>>
>>
>> --
>> Ben Greear <greearb@candelatech.com>
>> Candela Technologies Inc http://www.candelatech.com
>> _______________________________________________
>> openwrt-devel mailing list
>> openwrt-devel@lists.openwrt.org
>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [1/1] ath10k: use the right length of "background"
From: Kalle Valo @ 2016-11-15 15:07 UTC (permalink / raw)
To: Nicolas Iooss; +Cc: ath10k, netdev, linux-wireless, linux-kernel, Nicolas Iooss
In-Reply-To: <20161029111737.19034-1-nicolas.iooss_linux@m4x.org>
Nicolas Iooss <nicolas.iooss_linux@m4x.org> wrote:
> The word "background" contains 10 characters so the third argument of
> strncmp() need to be 10 in order to match this prefix correctly.
>
> Signed-off-by: Nicolas Iooss <nicolas.iooss_linux@m4x.org>
> Fixes: 855aed1220d2 ("ath10k: add spectral scan feature")
Patch applied to ath-next branch of ath.git, thanks.
31b239824ece ath10k: use the right length of "background"
--
https://patchwork.kernel.org/patch/9403561/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] rtl8xxxu: Fix for agressive power saving by rtl8723bu wireless IC
From: Jes Sorensen @ 2016-11-15 15:13 UTC (permalink / raw)
To: Barry Day; +Cc: John Heenan, Kalle Valo, linux-wireless
In-Reply-To: <20161031234706.GA15054@testbox>
Barry Day <briselec@gmail.com> writes:
> On Mon, Oct 31, 2016 at 06:41:30PM -0400, Jes Sorensen wrote:
>> Barry Day <briselec@gmail.com> writes:
>> > On Mon, Oct 31, 2016 at 05:25:12PM -0400, Jes Sorensen wrote:
>> >> As mentioned previously, if this is to be changed here, it has to be
>> >> matched in the _stop section too. It also has to be investigated exactly
>> >> why this matters for 8723bu. It is possible this matters for other
>> >> devices, but we need to find out exactly what causes this not moving a
>> >> major block of init code around like this.
>> >
>> > I've tested this on the 8192e and 8192c. The same problems occurs with the
>> > 8192e but not the 8192c. Stopping and restarting wpa_supplicant had
>> > no affect on the 8192c ability to connect to an AP.
>>
>> Which version of the driver? I did push in some changes for 8192eu
>> recently that fixed the issue with 8192eu driver reloading, and I would
>> be interested in knowing if this didn't fix the problem for you?
>>
>> Second, could we please keep this on the linux-wireless list where it
>> belongs. Everybody else doesn't necessarily want to receive a copy via
>> netdev and linux-kernel
>
> The tests were done with the latest version of rtl8xxxu-devel. I haven't
> noticed any occurence of the previous issue with the 8192eu.
OK, I am back from my trip, but still burried alive catching up on
things. This is very much on the list of things I want to investigate.
Jes
^ permalink raw reply
* Re: Avery's notes from LPC2016 wireless track (Santa Fe)
From: Jes Sorensen @ 2016-11-15 15:16 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Barry Day, linux-wireless
In-Reply-To: <CAHqTa-3TnBdAhtuoVkU5nSCQM4f1pE=d=K0F7xMCZUSAdk6wvA@mail.gmail.com>
Avery Pennarun <apenwarr@gmail.com> writes:
> On Thu, Nov 3, 2016 at 5:55 PM, Barry Day <briselec@gmail.com> wrote:
>> Thanks for that. Can I take this as meaning there won't be any videos?
>> I would like to have seen Jes Sorensen's talk on rtl8xxxu
>
> As far as I know, no talks at this LPC were recorded.
They weren't but my slides should be available from the Plumbers site.
https://www.linuxplumbersconf.org/2016/ocw/proposals/4089
Cheers,
Jes
^ permalink raw reply
* [PATCHv3 1/2] ath10k: add per peer htt tx stats support for 10.4
From: akolli @ 2016-11-15 16:37 UTC (permalink / raw)
To: ath10k; +Cc: akolli, linux-wireless, Anilkumar Kolli
From: Anilkumar Kolli <akolli@qti.qualcomm.com>
Per peer tx stats are part of 'HTT_10_4_T2H_MSG_TYPE_PEER_STATS'
event, Firmware sends one HTT event for every four PPDUs.
HTT payload has success pkts/bytes, failed pkts/bytes, retry
pkts/bytes and rate info per ppdu.
Peer stats are enabled through 'WMI_SERVICE_PEER_STATS',
which are nowadays enabled by default.
Parse peer stats and update the tx rate information per STA.
tx rate, Peer stats are tested on QCA4019 with Firmware version
10.4-3.2.1-00028.
Signed-off-by: Anilkumar Kolli <akolli@qti.qualcomm.com>
---
v2:
* address Kalle's comments
* fix compilation warnings
v3:
* fix compilation warnings (kvalo)
drivers/net/wireless/ath/ath10k/core.h | 17 ++++
drivers/net/wireless/ath/ath10k/htt.c | 2 +
drivers/net/wireless/ath/ath10k/htt.h | 25 ++++++
drivers/net/wireless/ath/ath10k/htt_rx.c | 125 ++++++++++++++++++++++++++++++
drivers/net/wireless/ath/ath10k/wmi.h | 10 ++-
5 files changed, 178 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index e8decfaba5b6..2f324a115b18 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -337,6 +337,7 @@ struct ath10k_sta {
u32 nss;
u32 smps;
u16 peer_id;
+ struct rate_info txrate;
struct work_struct update_wk;
@@ -693,6 +694,21 @@ struct ath10k_fw_components {
struct ath10k_fw_file fw_file;
};
+struct ath10k_per_peer_tx_stats {
+ u32 succ_bytes;
+ u32 retry_bytes;
+ u32 failed_bytes;
+ u8 ratecode;
+ u8 flags;
+ u16 peer_id;
+ u16 succ_pkts;
+ u16 retry_pkts;
+ u16 failed_pkts;
+ u16 duration;
+ u32 reserved1;
+ u32 reserved2;
+};
+
struct ath10k {
struct ath_common ath_common;
struct ieee80211_hw *hw;
@@ -906,6 +922,7 @@ struct ath10k {
struct ath10k_thermal thermal;
struct ath10k_wow wow;
+ struct ath10k_per_peer_tx_stats peer_tx_stats;
/* NAPI */
struct net_device napi_dev;
diff --git a/drivers/net/wireless/ath/ath10k/htt.c b/drivers/net/wireless/ath/ath10k/htt.c
index 130cd9502021..cd160b16db1e 100644
--- a/drivers/net/wireless/ath/ath10k/htt.c
+++ b/drivers/net/wireless/ath/ath10k/htt.c
@@ -137,6 +137,8 @@
HTT_T2H_MSG_TYPE_STATS_NOUPLOAD,
[HTT_10_4_T2H_MSG_TYPE_TX_MODE_SWITCH_IND] =
HTT_T2H_MSG_TYPE_TX_MODE_SWITCH_IND,
+ [HTT_10_4_T2H_MSG_TYPE_PEER_STATS] =
+ HTT_T2H_MSG_TYPE_PEER_STATS,
};
int ath10k_htt_connect(struct ath10k_htt *htt)
diff --git a/drivers/net/wireless/ath/ath10k/htt.h b/drivers/net/wireless/ath/ath10k/htt.h
index 0d2ed09f202b..164eb3a10566 100644
--- a/drivers/net/wireless/ath/ath10k/htt.h
+++ b/drivers/net/wireless/ath/ath10k/htt.h
@@ -419,6 +419,7 @@ enum htt_10_4_t2h_msg_type {
HTT_10_4_T2H_MSG_TYPE_STATS_NOUPLOAD = 0x18,
/* 0x19 to 0x2f are reserved */
HTT_10_4_T2H_MSG_TYPE_TX_MODE_SWITCH_IND = 0x30,
+ HTT_10_4_T2H_MSG_TYPE_PEER_STATS = 0x31,
/* keep this last */
HTT_10_4_T2H_NUM_MSGS
};
@@ -453,6 +454,7 @@ enum htt_t2h_msg_type {
HTT_T2H_MSG_TYPE_TX_FETCH_IND,
HTT_T2H_MSG_TYPE_TX_FETCH_CONFIRM,
HTT_T2H_MSG_TYPE_TX_MODE_SWITCH_IND,
+ HTT_T2H_MSG_TYPE_PEER_STATS,
/* keep this last */
HTT_T2H_NUM_MSGS
};
@@ -1470,6 +1472,28 @@ struct htt_channel_change {
__le32 phymode;
} __packed;
+struct htt_per_peer_tx_stats_ind {
+ __le32 succ_bytes;
+ __le32 retry_bytes;
+ __le32 failed_bytes;
+ u8 ratecode;
+ u8 flags;
+ __le16 peer_id;
+ __le16 succ_pkts;
+ __le16 retry_pkts;
+ __le16 failed_pkts;
+ __le16 tx_duration;
+ __le32 reserved1;
+ __le32 reserved2;
+} __packed;
+
+struct htt_peer_tx_stats {
+ u8 num_ppdu;
+ u8 ppdu_len;
+ u8 version;
+ u8 payload[0];
+} __packed;
+
union htt_rx_pn_t {
/* WEP: 24-bit PN */
u32 pn24;
@@ -1521,6 +1545,7 @@ struct htt_resp {
struct htt_tx_fetch_confirm tx_fetch_confirm;
struct htt_tx_mode_switch_ind tx_mode_switch_ind;
struct htt_channel_change chan_change;
+ struct htt_peer_tx_stats peer_tx_stats;
};
} __packed;
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
index 285b235268d7..86d082cf4eef 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -2194,6 +2194,128 @@ void ath10k_htt_htc_t2h_msg_handler(struct ath10k *ar, struct sk_buff *skb)
dev_kfree_skb_any(skb);
}
+static inline bool is_valid_legacy_rate(u8 rate)
+{
+ static const u8 legacy_rates[] = {1, 2, 5, 11, 6, 9, 12,
+ 18, 24, 36, 48, 54};
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(legacy_rates); i++) {
+ if (rate == legacy_rates[i])
+ return true;
+ }
+
+ return false;
+}
+
+static void
+ath10k_update_per_peer_tx_stats(struct ath10k *ar,
+ struct ieee80211_sta *sta,
+ struct ath10k_per_peer_tx_stats *peer_stats)
+{
+ struct ath10k_sta *arsta = (struct ath10k_sta *)sta->drv_priv;
+ u8 rate = 0, sgi;
+ struct rate_info txrate;
+
+ lockdep_assert_held(&ar->data_lock);
+
+ txrate.flags = ATH10K_HW_PREAMBLE(peer_stats->ratecode);
+ txrate.bw = ATH10K_HW_BW(peer_stats->flags);
+ txrate.nss = ATH10K_HW_NSS(peer_stats->ratecode);
+ txrate.mcs = ATH10K_HW_MCS_RATE(peer_stats->ratecode);
+ sgi = ATH10K_HW_GI(peer_stats->flags);
+
+ if (((txrate.flags == WMI_RATE_PREAMBLE_HT) ||
+ (txrate.flags == WMI_RATE_PREAMBLE_VHT)) && txrate.mcs > 9) {
+ ath10k_warn(ar, "Invalid mcs %hhd peer stats", txrate.mcs);
+ return;
+ }
+
+ if (txrate.flags == WMI_RATE_PREAMBLE_CCK ||
+ txrate.flags == WMI_RATE_PREAMBLE_OFDM) {
+ rate = ATH10K_HW_LEGACY_RATE(peer_stats->ratecode);
+
+ if (!is_valid_legacy_rate(rate)) {
+ ath10k_warn(ar, "Invalid legacy rate %hhd peer stats",
+ rate);
+ return;
+ }
+
+ /* This is hacky, FW sends CCK rate 5.5Mbps as 6 */
+ rate *= 10;
+ if (rate == 60 && txrate.flags == WMI_RATE_PREAMBLE_CCK)
+ rate = rate - 5;
+ arsta->txrate.legacy = rate * 10;
+ } else if (txrate.flags == WMI_RATE_PREAMBLE_HT) {
+ arsta->txrate.flags = RATE_INFO_FLAGS_MCS;
+ arsta->txrate.mcs = txrate.mcs;
+ } else {
+ arsta->txrate.flags = RATE_INFO_FLAGS_VHT_MCS;
+ arsta->txrate.mcs = txrate.mcs;
+ }
+
+ if (sgi)
+ arsta->txrate.flags |= RATE_INFO_FLAGS_SHORT_GI;
+
+ arsta->txrate.nss = txrate.nss;
+ arsta->txrate.bw = txrate.bw + RATE_INFO_BW_20;
+}
+
+static void ath10k_htt_fetch_peer_stats(struct ath10k *ar,
+ struct sk_buff *skb)
+{
+ struct htt_resp *resp = (struct htt_resp *)skb->data;
+ struct ath10k_per_peer_tx_stats *p_tx_stats = &ar->peer_tx_stats;
+ struct htt_per_peer_tx_stats_ind *tx_stats;
+ struct ieee80211_sta *sta;
+ struct ath10k_peer *peer;
+ int peer_id, i;
+ u8 ppdu_len, num_ppdu;
+
+ num_ppdu = resp->peer_tx_stats.num_ppdu;
+ ppdu_len = resp->peer_tx_stats.ppdu_len * sizeof(__le32);
+
+ if (skb->len < sizeof(struct htt_resp_hdr) + num_ppdu * ppdu_len) {
+ ath10k_warn(ar, "Invalid peer stats buf length %d\n", skb->len);
+ return;
+ }
+
+ tx_stats = (struct htt_per_peer_tx_stats_ind *)
+ (resp->peer_tx_stats.payload);
+ peer_id = __le16_to_cpu(tx_stats->peer_id);
+
+ rcu_read_lock();
+ spin_lock_bh(&ar->data_lock);
+ peer = ath10k_peer_find_by_id(ar, peer_id);
+ if (!peer) {
+ ath10k_warn(ar, "Invalid peer id %d peer stats buffer\n",
+ peer_id);
+ goto out;
+ }
+
+ sta = peer->sta;
+ for (i = 0; i < num_ppdu; i++) {
+ tx_stats = (struct htt_per_peer_tx_stats_ind *)
+ (resp->peer_tx_stats.payload + i * ppdu_len);
+
+ p_tx_stats->succ_bytes = __le32_to_cpu(tx_stats->succ_bytes);
+ p_tx_stats->retry_bytes = __le32_to_cpu(tx_stats->retry_bytes);
+ p_tx_stats->failed_bytes =
+ __le32_to_cpu(tx_stats->failed_bytes);
+ p_tx_stats->ratecode = tx_stats->ratecode;
+ p_tx_stats->flags = tx_stats->flags;
+ p_tx_stats->succ_pkts = __le16_to_cpu(tx_stats->succ_pkts);
+ p_tx_stats->retry_pkts = __le16_to_cpu(tx_stats->retry_pkts);
+ p_tx_stats->failed_pkts = __le16_to_cpu(tx_stats->failed_pkts);
+
+ ath10k_update_per_peer_tx_stats(ar, sta, p_tx_stats);
+ }
+
+out:
+ spin_unlock_bh(&ar->data_lock);
+ rcu_read_unlock();
+}
+
bool ath10k_htt_t2h_msg_handler(struct ath10k *ar, struct sk_buff *skb)
{
struct ath10k_htt *htt = &ar->htt;
@@ -2354,6 +2476,9 @@ bool ath10k_htt_t2h_msg_handler(struct ath10k *ar, struct sk_buff *skb)
case HTT_T2H_MSG_TYPE_TX_MODE_SWITCH_IND:
ath10k_htt_rx_tx_mode_switch_ind(ar, skb);
break;
+ case HTT_T2H_MSG_TYPE_PEER_STATS:
+ ath10k_htt_fetch_peer_stats(ar, skb);
+ break;
case HTT_T2H_MSG_TYPE_EN_STATS:
default:
ath10k_warn(ar, "htt event (%d) not handled\n",
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
index 1b243c899bef..e108d49998c3 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -4603,9 +4603,17 @@ enum wmi_rate_preamble {
#define ATH10K_HW_NSS(rate) (1 + (((rate) >> 4) & 0x3))
#define ATH10K_HW_PREAMBLE(rate) (((rate) >> 6) & 0x3)
-#define ATH10K_HW_RATECODE(rate, nss, preamble) \
+#define ATH10K_HW_MCS_RATE(rate) ((rate) & 0xf)
+#define ATH10K_HW_LEGACY_RATE(rate) ((rate) & 0x3f)
+#define ATH10K_HW_BW(flags) (((flags) >> 3) & 0x3)
+#define ATH10K_HW_GI(flags) (((flags) >> 5) & 0x1)
+#define ATH10K_HW_RATECODE(rate, nss, preamble) \
(((preamble) << 6) | ((nss) << 4) | (rate))
+#define VHT_MCS_NUM 10
+#define VHT_BW_NUM 4
+#define VHT_NSS_NUM 4
+
/* Value to disable fixed rate setting */
#define WMI_FIXED_RATE_NONE (0xff)
--
1.7.9.5
^ permalink raw reply related
* [PATCHv3 2/2] ath10k: add support for per sta tx bitrate
From: akolli @ 2016-11-15 16:38 UTC (permalink / raw)
To: ath10k; +Cc: akolli, linux-wireless, Anilkumar Kolli
From: Anilkumar Kolli <akolli@qti.qualcomm.com>
Per STA tx bitrate info is filled from peer stats.
Export per sta txrate info to cfg80211/nl80211
Signed-off-by: Anilkumar Kolli <akolli@qti.qualcomm.com>
---
v2:
* address Kalle's comments
drivers/net/wireless/ath/ath10k/debugfs_sta.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/debugfs_sta.c b/drivers/net/wireless/ath/ath10k/debugfs_sta.c
index 9955fea0802a..fce6f8137d33 100644
--- a/drivers/net/wireless/ath/ath10k/debugfs_sta.c
+++ b/drivers/net/wireless/ath/ath10k/debugfs_sta.c
@@ -77,6 +77,19 @@ void ath10k_sta_statistics(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
sinfo->rx_duration = arsta->rx_duration;
sinfo->filled |= 1ULL << NL80211_STA_INFO_RX_DURATION;
+
+ if (!arsta->txrate.legacy && !arsta->txrate.nss)
+ return;
+
+ if (arsta->txrate.legacy) {
+ sinfo->txrate.legacy = arsta->txrate.legacy;
+ } else {
+ sinfo->txrate.mcs = arsta->txrate.mcs;
+ sinfo->txrate.nss = arsta->txrate.nss;
+ sinfo->txrate.bw = arsta->txrate.bw;
+ }
+ sinfo->txrate.flags = arsta->txrate.flags;
+ sinfo->filled |= 1ULL << NL80211_STA_INFO_TX_BITRATE;
}
static ssize_t ath10k_dbg_sta_read_aggr_mode(struct file *file,
--
1.7.9.5
^ permalink raw reply related
* Re: [RFC 03/12] ath10k: htc: Changed order of wait target and ep connect
From: Erik Stromdahl @ 2016-11-15 17:07 UTC (permalink / raw)
To: Michal Kazior; +Cc: Kalle Valo, linux-wireless, ath10k@lists.infradead.org
In-Reply-To: <CA+BoTQmA0E+N46E3XkpqVPXSVkQNyZj2Qzrizk8iLdYzVthNQg@mail.gmail.com>
On 11/15/2016 11:13 AM, Michal Kazior wrote:
> On 14 November 2016 at 17:33, Erik Stromdahl <erik.stromdahl@gmail.com> wrote:
>> This patch changes the order in which the driver waits for the
>> target to become ready and the service connect of the HTC
>> control service.
>>
>> The HTC control service is connected before the driver starts
>> waiting for the HTC ready control message.
>>
>> The reason for this is that the HTC ready control message is
>> transmitted on EP 0 and that sdio/mbox based systems will ignore
>> messages received on unconnected endpoints.
>>
>> Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>
>> ---
>> drivers/net/wireless/ath/ath10k/htc.c | 32 ++++++++++++++++----------------
>> 1 file changed, 16 insertions(+), 16 deletions(-)
>>
>> diff --git a/drivers/net/wireless/ath/ath10k/htc.c b/drivers/net/wireless/ath/ath10k/htc.c
>> index e3f7bf4..7257366 100644
>> --- a/drivers/net/wireless/ath/ath10k/htc.c
>> +++ b/drivers/net/wireless/ath/ath10k/htc.c
>> @@ -606,6 +606,22 @@ int ath10k_htc_wait_target(struct ath10k_htc *htc)
>> u16 credit_count;
>> u16 credit_size;
>>
>> + /* setup our pseudo HTC control endpoint connection */
>> + memset(&conn_req, 0, sizeof(conn_req));
>> + memset(&conn_resp, 0, sizeof(conn_resp));
>> + conn_req.ep_ops.ep_tx_complete = ath10k_htc_control_tx_complete;
>> + conn_req.ep_ops.ep_rx_complete = ath10k_htc_control_rx_complete;
>> + conn_req.max_send_queue_depth = ATH10K_NUM_CONTROL_TX_BUFFERS;
>> + conn_req.service_id = ATH10K_HTC_SVC_ID_RSVD_CTRL;
>> +
>> + /* connect fake service */
>> + status = ath10k_htc_connect_service(htc, &conn_req, &conn_resp);
>> + if (status) {
>> + ath10k_err(ar, "could not connect to htc service (%d)\n",
>> + status);
>> + return status;
>> + }
>> +
>
> How is this supposed to work? ath10k_htc_connect_service() requires
> htc->target_credit_size to compute tx_credits_per_max_message. Or am I
> missing something? Applying this patch alone results in:
>
> [ 6.680101] divide error: 0000 [#1] SMP
> [ 6.681342] Modules linked in: ath10k_pci(O) ath10k_core(O) ath
> mac80211 cfg80211
> [ 6.684876] CPU: 3 PID: 823 Comm: kworker/u8:2 Tainted: G W
> O 4.9.0-rc4-wt-ath+ #79
> [ 6.688051] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
> BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
> [ 6.691644] Workqueue: ath10k_wq ath10k_core_register_work [ath10k_core]
> [ 6.694309] task: ffff88000a190000 task.stack: ffffc900006d4000
> [ 6.695458] RIP: 0010:[<ffffffffa01ae46b>] [<ffffffffa01ae46b>]
> ath10k_htc_connect_service+0x21b/0x420 [ath10k_core]
>
>
> Michał
>
You're right. I have totally missed this. What is strange is that my
compiler (ARM linaro) seems to optimize the code in a way that removes
the tx_credits_per_max_message value.
If I add a printk in ath10k_htc_connect_service (printing the value) I
get a similar oops.
I think it has to do with the fact the this value isn't really used at
all. grepping the code reveals that tx_credits_per_max_message is only
used inside ath10k_htc_connect_service (only written, never read).
Removing it doesn't seem to break anything, so perhaps it should be removed?
Or is there something I have missed?
/Erik
^ permalink raw reply
* Re: [RFC 06/12] ath10k: bmi: Added SOC reg read/write functions
From: Erik Stromdahl @ 2016-11-15 17:11 UTC (permalink / raw)
To: Michal Kazior; +Cc: Kalle Valo, linux-wireless, ath10k@lists.infradead.org
In-Reply-To: <CA+BoTQ=jSun0Je6sVsZz-SaiDA6+nZxSTJF_5OH0unPkjm1gvw@mail.gmail.com>
On 11/15/2016 11:28 AM, Michal Kazior wrote:
> On 14 November 2016 at 17:33, Erik Stromdahl <erik.stromdahl@gmail.com> wrote:
>> Added functions implementing the following BMI commands:
>>
>> BMI_READ_SOC_REGISTER
>> BMI_WRITE_SOC_REGISTER
>>
>> Reading and writing BMI registers is sometimes needed for
>> SDIO chipsets.
>
> I didn't see ath10k_bmi_write_soc_reg nor ath10k_bmi_read_soc_reg
> being used in your Patch 12. Is this patch really necessary?
>
>
You are right, these functions are not used in patch 12. They are used
in some other patches that was not included in this series (needs more
cleanup before I can publish). I will remove them from the series.
> [...]
>> diff --git a/drivers/net/wireless/ath/ath10k/bmi.c b/drivers/net/wireless/ath/ath10k/bmi.c
>> index 2872d34..1c378a2 100644
>> --- a/drivers/net/wireless/ath/ath10k/bmi.c
>> +++ b/drivers/net/wireless/ath/ath10k/bmi.c
>> @@ -97,7 +97,8 @@ int ath10k_bmi_read_memory(struct ath10k *ar,
>> u32 rxlen;
>> int ret;
>>
>> - ath10k_dbg(ar, ATH10K_DBG_BMI, "bmi read address 0x%x length %d\n",
>> + ath10k_dbg(ar, ATH10K_DBG_BMI,
>> + "bmi read memory address 0x%x length %d\n",
>> address, length);
>>
>> if (ar->bmi.done_sent) {
>> @@ -137,7 +138,8 @@ int ath10k_bmi_write_memory(struct ath10k *ar,
>> u32 txlen;
>> int ret;
>>
>> - ath10k_dbg(ar, ATH10K_DBG_BMI, "bmi write address 0x%x length %d\n",
>> + ath10k_dbg(ar, ATH10K_DBG_BMI,
>> + "bmi write memory address 0x%x length %d\n",
>> address, length);
>>
>
> These 2 hunks shouldn't be modified in this patch. If you want to do a
> clean up this warrants a separate patch :)
>
>
> Michał
>
Ok
/Erik
^ permalink raw reply
* Re: [RFC 02/12] ath10k: htc: rx trailer lookahead support
From: Erik Stromdahl @ 2016-11-15 17:31 UTC (permalink / raw)
To: Michal Kazior; +Cc: Kalle Valo, linux-wireless, ath10k@lists.infradead.org
In-Reply-To: <CA+BoTQkJqv28=Mg1ncmyznRo-CLh6Y_OW-mJ+YTyqaREaqp39Q@mail.gmail.com>
On 11/15/2016 10:57 AM, Michal Kazior wrote:
> On 14 November 2016 at 17:33, Erik Stromdahl <erik.stromdahl@gmail.com> wrote:
>> The RX trailer parsing is now capable of parsing lookahead reports.
>> This is needed by SDIO/mbox.
>
> It'd be useful to know what exactly lookahead will be used for. What
> payload does it carry.
>
It carries the 4 first bytes of the next RX message, i.e. the first 4
bytes of an HTC header.
It is used by the sdio interrupt handler to know if the next packet is a
part of an RX bundle, which endpoint it belongs to and how long it is
(so we know how many bytes to allocate).
>
>> Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>
>> ---
>> drivers/net/wireless/ath/ath10k/htc.c | 91 ++++++++++++++++++++++++++++++++-
>> drivers/net/wireless/ath/ath10k/htc.h | 30 +++++++++--
>> 2 files changed, 116 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/net/wireless/ath/ath10k/htc.c b/drivers/net/wireless/ath/ath10k/htc.c
>> index 26b1e15..e3f7bf4 100644
>> --- a/drivers/net/wireless/ath/ath10k/htc.c
>> +++ b/drivers/net/wireless/ath/ath10k/htc.c
>> @@ -228,10 +228,74 @@ void ath10k_htc_tx_completion_handler(struct ath10k *ar, struct sk_buff *skb)
>> spin_unlock_bh(&htc->tx_lock);
>> }
>>
>> +static int
>> +ath10k_htc_process_lookahead(struct ath10k_htc *htc,
>> + const struct ath10k_htc_lookahead_report *report,
>> + int len,
>> + enum ath10k_htc_ep_id eid,
>> + u32 *next_lk_ahds,
>
> next_lk_ahds should be u8 or void. From what I understand by glancing
> through the code it is an agnostic buffer that carries payload which
> is later interpreted either as eid or htc header, right? void is
> probably most suitable in this case for passing around and u8 for
> inline-based storage.
>
Sounds reasonable, I'll change to void pointer.
> I'd also avoid silly abbreviations. Probably "lookahead" alone is enough.
>
Ok, this abbreviation was actually taken from the ath6kl code. I think
the intention was to reduce line lengths.
>> + int *next_lk_ahds_len)
>> +{
>> + struct ath10k *ar = htc->ar;
>> +
>> + if (report->pre_valid != ((~report->post_valid) & 0xFF))
>> + /* Invalid lookahead flags are actually transmitted by
>> + * the target in the HTC control message.
>> + * Since this will happen at every boot we silently ignore
>> + * the lookahead in this case
>> + */
>
> I'd put this comment before the if().
Ok
>
>
>> + return 0;
>> +
>> + if (next_lk_ahds && next_lk_ahds_len) {
>> + ath10k_dbg(ar, ATH10K_DBG_HTC,
>> + "htc rx lk_ahd found pre_valid 0x%x post_valid 0x%x\n",
>> + report->pre_valid, report->post_valid);
>> +
>> + /* look ahead bytes are valid, copy them over */
>> + memcpy((u8 *)&next_lk_ahds[0], report->lk_ahd, 4);
>> +
>> + *next_lk_ahds_len = 1;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static int
>> +ath10k_htc_process_lookahead_bundle(struct ath10k_htc *htc,
>> + const struct ath10k_htc_lookahead_report_bundle *report,
>> + int len,
>> + enum ath10k_htc_ep_id eid,
>> + u32 *next_lk_ahds,
>
> Ditto. void.
>
>
>> + int *next_lk_ahds_len)
>> +{
>> + int bundle_cnt = len / sizeof(*report);
>> +
>> + if (!bundle_cnt || (bundle_cnt > HTC_HOST_MAX_MSG_PER_BUNDLE)) {
>> + WARN_ON(1);
>
> This should be ath10k_warn() instead. This isn't internal driver flow
> assertion. It is possible firmware bug or revision misalignment
> instead.
>
Ok
>
>> + return -EINVAL;
>> + }
>> +
>> + if (next_lk_ahds && next_lk_ahds_len) {
>> + int i;
>> +
>> + for (i = 0; i < bundle_cnt; i++) {
>> + memcpy((u8 *)&next_lk_ahds[i], report->lk_ahd,
>> + sizeof(u32));
>
> You'll need to re-adjust the &x[i] to maintain proper offset with void pointer.
>
>
> Michał
>
^ permalink raw reply
* Re: [PATCH v4 3/3] mwifiex: Enable WoWLAN for both sdio and pcie
From: Dmitry Torokhov @ 2016-11-15 17:35 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: linux-wireless, Cathy Luo, Nishant Sarmukadam, rajatja,
briannorris
In-Reply-To: <1479216964-3328-3-git-send-email-akarwar@marvell.com>
On Tue, Nov 15, 2016 at 07:06:04PM +0530, Amitkumar Karwar wrote:
> From: Rajat Jain <rajatja@google.com>
>
> Commit ce4f6f0c353b ("mwifiex: add platform specific wakeup interrupt
> support") added WoWLAN feature only for sdio. This patch moves that
> code to the common module so that all the interface drivers can use
> it for free. It enables pcie and sdio for its use currently.
>
> Signed-off-by: Rajat Jain <rajatja@google.com>
> ---
> v2: v1 doesn't apply smoothly on latest code due to recently merged
> patch "mwifiex: report error to PCIe for suspend failure". Minor
> conflict is resolved in v2
> v4: Same as v2, v3
> ---
> drivers/net/wireless/marvell/mwifiex/main.c | 41 ++++++++++++++++
> drivers/net/wireless/marvell/mwifiex/main.h | 25 ++++++++++
> drivers/net/wireless/marvell/mwifiex/pcie.c | 2 +
> drivers/net/wireless/marvell/mwifiex/sdio.c | 72 ++---------------------------
> drivers/net/wireless/marvell/mwifiex/sdio.h | 8 ----
> 5 files changed, 73 insertions(+), 75 deletions(-)
>
> diff --git a/drivers/net/wireless/marvell/mwifiex/main.c b/drivers/net/wireless/marvell/mwifiex/main.c
> index 835d330..948f5c2 100644
> --- a/drivers/net/wireless/marvell/mwifiex/main.c
> +++ b/drivers/net/wireless/marvell/mwifiex/main.c
> @@ -1552,14 +1552,55 @@ void mwifiex_do_flr(struct mwifiex_adapter *adapter, bool prepare)
> }
> EXPORT_SYMBOL_GPL(mwifiex_do_flr);
>
> +static irqreturn_t mwifiex_irq_wakeup_handler(int irq, void *priv)
> +{
> + struct mwifiex_adapter *adapter = priv;
> +
> + if (adapter->irq_wakeup >= 0) {
> + dev_dbg(adapter->dev, "%s: wake by wifi", __func__);
> + adapter->wake_by_wifi = true;
> + disable_irq_nosync(irq);
> + }
> +
> + /* Notify PM core we are wakeup source */
> + pm_wakeup_event(adapter->dev, 0);
> +
> + return IRQ_HANDLED;
> +}
> +
> static void mwifiex_probe_of(struct mwifiex_adapter *adapter)
> {
> + int ret;
> struct device *dev = adapter->dev;
>
> if (!dev->of_node)
> return;
>
> adapter->dt_node = dev->of_node;
> + adapter->irq_wakeup = irq_of_parse_and_map(adapter->dt_node, 0);
> + if (!adapter->irq_wakeup) {
> + dev_info(dev, "fail to parse irq_wakeup from device tree\n");
> + return;
> + }
I'd rather we used of_irq_get() here, because ti allows handling
deferrals. of_irq_get_byname() would be even better, but I guess we
already have bindings in the wild...
> +
> + ret = devm_request_irq(dev, adapter->irq_wakeup,
> + mwifiex_irq_wakeup_handler, IRQF_TRIGGER_LOW,
irq_of_parse_and_map() (and of_irq_get()) will set trigger flags,
why do we override them?
> + "wifi_wake", adapter);
> + if (ret) {
> + dev_err(dev, "Failed to request irq_wakeup %d (%d)\n",
> + adapter->irq_wakeup, ret);
> + goto err_exit;
> + }
> +
> + disable_irq(adapter->irq_wakeup);
> + if (device_init_wakeup(dev, true)) {
> + dev_err(dev, "fail to init wakeup for mwifiex\n");
> + goto err_exit;
Leaking interrupt (not forever, but if we are not using wakeup irq there
is no need to have it claimed).
> + }
> + return;
> +
> +err_exit:
> + adapter->irq_wakeup = 0;
> }
I also do not see anyone actually calling mwifiex_probe_of() in this
patch?
>
> /*
> diff --git a/drivers/net/wireless/marvell/mwifiex/main.h b/drivers/net/wireless/marvell/mwifiex/main.h
> index 549e1ba..ae5afe5 100644
> --- a/drivers/net/wireless/marvell/mwifiex/main.h
> +++ b/drivers/net/wireless/marvell/mwifiex/main.h
> @@ -1011,6 +1011,10 @@ struct mwifiex_adapter {
> bool usb_mc_setup;
> struct cfg80211_wowlan_nd_info *nd_info;
> struct ieee80211_regdomain *regd;
> +
> + /* Wake-on-WLAN (WoWLAN) */
> + int irq_wakeup;
> + bool wake_by_wifi;
> };
>
> void mwifiex_process_tx_queue(struct mwifiex_adapter *adapter);
> @@ -1410,6 +1414,27 @@ static inline u8 mwifiex_is_tdls_link_setup(u8 status)
> return false;
> }
>
> +/* Disable platform specific wakeup interrupt */
> +static inline void mwifiex_disable_wake(struct mwifiex_adapter *adapter)
> +{
> + if (adapter->irq_wakeup >= 0) {
> + disable_irq_wake(adapter->irq_wakeup);
> + if (!adapter->wake_by_wifi)
> + disable_irq(adapter->irq_wakeup);
> + }
> +}
> +
> +/* Enable platform specific wakeup interrupt */
> +static inline void mwifiex_enable_wake(struct mwifiex_adapter *adapter)
> +{
> + /* Enable platform specific wakeup interrupt */
> + if (adapter->irq_wakeup >= 0) {
> + adapter->wake_by_wifi = false;
> + enable_irq(adapter->irq_wakeup);
> + enable_irq_wake(adapter->irq_wakeup);
> + }
> +}
> +
> int mwifiex_init_shutdown_fw(struct mwifiex_private *priv,
> u32 func_init_shutdown);
> int mwifiex_add_card(void *card, struct semaphore *sem,
> diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c
> index 745ecd6..e8f4f90 100644
> --- a/drivers/net/wireless/marvell/mwifiex/pcie.c
> +++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
> @@ -131,6 +131,7 @@ static int mwifiex_pcie_suspend(struct device *dev)
> }
>
> adapter = card->adapter;
> + mwifiex_enable_wake(adapter);
>
> /* Enable the Host Sleep */
> if (!mwifiex_enable_hs(adapter)) {
> @@ -186,6 +187,7 @@ static int mwifiex_pcie_resume(struct device *dev)
>
> mwifiex_cancel_hs(mwifiex_get_priv(adapter, MWIFIEX_BSS_ROLE_STA),
> MWIFIEX_ASYNC_CMD);
> + mwifiex_disable_wake(adapter);
>
> return 0;
> }
> diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c b/drivers/net/wireless/marvell/mwifiex/sdio.c
> index c95f41f..7055282 100644
> --- a/drivers/net/wireless/marvell/mwifiex/sdio.c
> +++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
> @@ -79,67 +79,18 @@
> { }
> };
>
> -static irqreturn_t mwifiex_wake_irq_wifi(int irq, void *priv)
> -{
> - struct mwifiex_plt_wake_cfg *cfg = priv;
> -
> - if (cfg->irq_wifi >= 0) {
> - pr_info("%s: wake by wifi", __func__);
> - cfg->wake_by_wifi = true;
> - disable_irq_nosync(irq);
> - }
> -
> - /* Notify PM core we are wakeup source */
> - pm_wakeup_event(cfg->dev, 0);
> -
> - return IRQ_HANDLED;
> -}
> -
> /* This function parse device tree node using mmc subnode devicetree API.
> * The device node is saved in card->plt_of_node.
> * if the device tree node exist and include interrupts attributes, this
> * function will also request platform specific wakeup interrupt.
> */
> -static int mwifiex_sdio_probe_of(struct device *dev, struct sdio_mmc_card *card)
> +static int mwifiex_sdio_probe_of(struct device *dev)
> {
> - struct mwifiex_plt_wake_cfg *cfg;
> - int ret;
> -
> if (!of_match_node(mwifiex_sdio_of_match_table, dev->of_node)) {
> dev_err(dev, "required compatible string missing\n");
> return -EINVAL;
> }
>
> - card->plt_of_node = dev->of_node;
> - card->plt_wake_cfg = devm_kzalloc(dev, sizeof(*card->plt_wake_cfg),
> - GFP_KERNEL);
> - cfg = card->plt_wake_cfg;
> - if (cfg && card->plt_of_node) {
> - cfg->dev = dev;
> - cfg->irq_wifi = irq_of_parse_and_map(card->plt_of_node, 0);
> - if (!cfg->irq_wifi) {
> - dev_dbg(dev,
> - "fail to parse irq_wifi from device tree\n");
> - } else {
> - ret = devm_request_irq(dev, cfg->irq_wifi,
> - mwifiex_wake_irq_wifi,
> - IRQF_TRIGGER_LOW,
> - "wifi_wake", cfg);
> - if (ret) {
> - dev_dbg(dev,
> - "Failed to request irq_wifi %d (%d)\n",
> - cfg->irq_wifi, ret);
> - card->plt_wake_cfg = NULL;
> - return 0;
> - }
> - disable_irq(cfg->irq_wifi);
> - }
> - }
> -
> - ret = device_init_wakeup(dev, true);
> - if (ret)
> - dev_err(dev, "fail to init wakeup for mwifiex");
> -
> return 0;
> }
>
> @@ -198,11 +149,9 @@ static int mwifiex_sdio_probe_of(struct device *dev, struct sdio_mmc_card *card)
>
> /* device tree node parsing and platform specific configuration*/
> if (func->dev.of_node) {
> - ret = mwifiex_sdio_probe_of(&func->dev, card);
> - if (ret) {
> - dev_err(&func->dev, "SDIO dt node parse failed\n");
> + ret = mwifiex_sdio_probe_of(&func->dev);
> + if (ret)
> goto err_disable;
> - }
> }
>
> ret = mwifiex_add_card(card, &add_remove_card_sem, &sdio_ops,
> @@ -267,12 +216,7 @@ static int mwifiex_sdio_resume(struct device *dev)
> mwifiex_cancel_hs(mwifiex_get_priv(adapter, MWIFIEX_BSS_ROLE_STA),
> MWIFIEX_SYNC_CMD);
>
> - /* Disable platform specific wakeup interrupt */
> - if (card->plt_wake_cfg && card->plt_wake_cfg->irq_wifi >= 0) {
> - disable_irq_wake(card->plt_wake_cfg->irq_wifi);
> - if (!card->plt_wake_cfg->wake_by_wifi)
> - disable_irq(card->plt_wake_cfg->irq_wifi);
> - }
> + mwifiex_disable_wake(adapter);
>
> return 0;
> }
> @@ -352,13 +296,7 @@ static int mwifiex_sdio_suspend(struct device *dev)
> }
>
> adapter = card->adapter;
> -
> - /* Enable platform specific wakeup interrupt */
> - if (card->plt_wake_cfg && card->plt_wake_cfg->irq_wifi >= 0) {
> - card->plt_wake_cfg->wake_by_wifi = false;
> - enable_irq(card->plt_wake_cfg->irq_wifi);
> - enable_irq_wake(card->plt_wake_cfg->irq_wifi);
> - }
> + mwifiex_enable_wake(adapter);
>
> /* Enable the Host Sleep */
> if (!mwifiex_enable_hs(adapter)) {
> diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.h b/drivers/net/wireless/marvell/mwifiex/sdio.h
> index 07cdd23..b9fbc5c 100644
> --- a/drivers/net/wireless/marvell/mwifiex/sdio.h
> +++ b/drivers/net/wireless/marvell/mwifiex/sdio.h
> @@ -154,12 +154,6 @@
> a->mpa_rx.start_port = 0; \
> } while (0)
>
> -struct mwifiex_plt_wake_cfg {
> - struct device *dev;
> - int irq_wifi;
> - bool wake_by_wifi;
> -};
> -
> /* data structure for SDIO MPA TX */
> struct mwifiex_sdio_mpa_tx {
> /* multiport tx aggregation buffer pointer */
> @@ -243,8 +237,6 @@ struct mwifiex_sdio_card_reg {
> struct sdio_mmc_card {
> struct sdio_func *func;
> struct mwifiex_adapter *adapter;
> - struct device_node *plt_of_node;
> - struct mwifiex_plt_wake_cfg *plt_wake_cfg;
>
> const char *firmware;
> const struct mwifiex_sdio_card_reg *reg;
> --
> 1.9.1
>
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH] ath9k: fix ath9k_hw_gpio_get() to return 0 or 1 on success
From: Matthias Schiffer @ 2016-11-15 17:47 UTC (permalink / raw)
To: kvalo; +Cc: ath9k-devel, linux-wireless, ath9k-devel, miaoqing
Commit b2d70d4944c1 ("ath9k: make GPIO API to support both of WMAC and
SOC") refactored ath9k_hw_gpio_get() to support both WMAC and SOC GPIOs,
changing the return on success from 1 to BIT(gpio). This broke some callers
like ath_is_rfkill_set().
Instead of fixing all callers, change ath9k_hw_gpio_get() back to only
return 0 or 1.
Fixes: b2d70d4944c1 ("ath9k: make GPIO API to support both of WMAC and SOC")
Cc: <stable@vger.kernel.org> # v4.7+
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
---
drivers/net/wireless/ath/ath9k/hw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index 14b13f0..a35f78b 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -2792,7 +2792,7 @@ u32 ath9k_hw_gpio_get(struct ath_hw *ah, u32 gpio)
WARN_ON(1);
}
- return val;
+ return !!val;
}
EXPORT_SYMBOL(ath9k_hw_gpio_get);
--
2.10.2
^ 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