* Re: ath10k stuck on 6Mbps and spam syslog
From: Matteo Grandi @ 2016-09-30 7:23 UTC (permalink / raw)
To: Ben Greear; +Cc: LinuxWireless Mailing List
In-Reply-To: <57ED2982.4020002@candelatech.com>
Dear Ben,
Thank you for your reply.
The fact that stock ath10k firmware does not report tx-rate explains
why the station dump shows 6Mbps but the iperf test reach 14.6 (even
if it is really under the expected data rate...).
About the syslog spam, this is the code of the function that seems to
cause the error (I put a comment at line 2621 side). (The warning
start to spam as soon as I assign the channel "iw dev <if_name> set
channel <ch_number>)
/**
* ieee80211_calculate_rx_timestamp - calculate timestamp in frame
* @local: mac80211 hw info struct
* @status: RX status
* @mpdu_len: total MPDU length (including FCS)
* @mpdu_offset: offset into MPDU to calculate timestamp at
*
* This function calculates the RX timestamp at the given MPDU offset, taking
* into account what the RX timestamp was. An offset of 0 will just normalize
* the timestamp to TSF at beginning of MPDU reception.
*/
u64 ieee80211_calculate_rx_timestamp(struct ieee80211_local *local,
struct ieee80211_rx_status *status,
unsigned int mpdu_len,
unsigned int mpdu_offset)
{
u64 ts = status->mactime;
struct rate_info ri;
u16 rate;
if (WARN_ON(!ieee80211_have_rx_timestamp(status))) //this is the
line 2621 reported in the warning
return 0;
memset(&ri, 0, sizeof(ri));
/* Fill cfg80211 rate info */
if (status->flag & RX_FLAG_HT) {
ri.mcs = status->rate_idx;
ri.flags |= RATE_INFO_FLAGS_MCS;
if (status->flag & RX_FLAG_40MHZ)
ri.bw = RATE_INFO_BW_40;
else
ri.bw = RATE_INFO_BW_20;
if (status->flag & RX_FLAG_SHORT_GI)
ri.flags |= RATE_INFO_FLAGS_SHORT_GI;
} else if (status->flag & RX_FLAG_VHT) {
ri.flags |= RATE_INFO_FLAGS_VHT_MCS;
ri.mcs = status->rate_idx;
ri.nss = status->vht_nss;
if (status->flag & RX_FLAG_40MHZ)
ri.bw = RATE_INFO_BW_40;
else if (status->vht_flag & RX_VHT_FLAG_80MHZ)
ri.bw = RATE_INFO_BW_80;
else if (status->vht_flag & RX_VHT_FLAG_160MHZ)
ri.bw = RATE_INFO_BW_160;
else
ri.bw = RATE_INFO_BW_20;
if (status->flag & RX_FLAG_SHORT_GI)
ri.flags |= RATE_INFO_FLAGS_SHORT_GI;
} else {
struct ieee80211_supported_band *sband;
int shift = 0;
int bitrate;
if (status->flag & RX_FLAG_10MHZ) {
shift = 1;
ri.bw = RATE_INFO_BW_10;
} else if (status->flag & RX_FLAG_5MHZ) {
shift = 2;
ri.bw = RATE_INFO_BW_5;
} else {
ri.bw = RATE_INFO_BW_20;
}
sband = local->hw.wiphy->bands[status->band];
bitrate = sband->bitrates[status->rate_idx].bitrate;
ri.legacy = DIV_ROUND_UP(bitrate, (1 << shift));
}
rate = cfg80211_calculate_bitrate(&ri);
if (WARN_ONCE(!rate,
"Invalid bitrate: flags=0x%x, idx=%d, vht_nss=%d\n",
status->flag, status->rate_idx, status->vht_nss))
return 0;
/* rewind from end of MPDU */
if (status->flag & RX_FLAG_MACTIME_END)
ts -= mpdu_len * 8 * 10 / rate;
ts += mpdu_offset * 8 * 10 / rate;
/* [SESAME] I2CAT. dbg*/
//printk(KERN_DEBUG "calculate_rx_timestamp: ts = %lu;\t rate =
%lu;\tmpdu_offset = %lu;\tmpdu_len = %lu\n",
// (long unsigned int) ts, (long unsigned int) rate, (long unsigned
int) mpdu_offset, (long unsigned int) mpdu_len );
return ts;
}
Thank you so much!
All the best
Matteo
2016-09-29 16:47 GMT+02:00 Ben Greear <greearb@candelatech.com>:
> stock ath10k firmware does not report tx-rate so the kernel always sees
> 6Mbps.
>
> I don't know about the splat..maybe post the function
> that is causing that?
>
> /home/matteo/linux-imx6/backports4.4.2-i2CAT/net/mac80211/util.c:2621
>
> Thanks,
> Ben
>
>
> On 09/29/2016 06:39 AM, Matteo Grandi wrote:
>>
>> Hello all,
>>
>> I'm struggling with a problem related on ath10k drivers:
>> I'm using a Compex WLE600V5-27 (802.11ac) miniPCIe card for some HT
>> tests needed for my thesis.
>> I'm using ath10k drivers for this card, and backports-4.4.2, in
>> particular the firmware-5.bin_10.2.4.70.54 because it seem to be the
>> more recent.
>> I've connected in mesh mode the WLE600V5 card with an 802.11n card
>> (using ath9k drivers) but looking at the station dump, the tx bitrate
>> is stuck on 6.0 Mbit/s for the ath10k. The ath9k one works well and
>> watch -n1 iw <interfacename> station dump
>> let me see changes of the tx rate and MCS on the ath9k during iperf
>> tests, but the ath10k stucks on 6.0 Mbit/s.
>>
>> Then something misterious (for me) happen while the channel
>> assignment: the syslog is spammed by this message:
>>
>> [17554.919459] ------------[ cut here ]------------
>> [17554.919839] WARNING: CPU: 0 PID: 0 at
>> /home/matteo/linux-imx6/backports4.4.2-i2CAT/net/mac80211/util.c:2621
>> ieee80211_calculate_rx_timestamp+0x204/0x278 [mac80211]()
>> [17554.919855] Modules linked in: arc4 sky2 ath10k_pci(O)
>> ath10k_core(O) ath(O) mac80211(O) cfg80211(O) compat(O)
>> [17554.919926] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W O
>> 3.14.48-g408ccb9 #4
>> [17554.919990] [<80015050>] (unwind_backtrace) from [<80011330>]
>> (show_stack+0x10/0x14)
>> [17554.920038] [<80011330>] (show_stack) from [<806537dc>]
>> (dump_stack+0x80/0x90)
>> [17554.920074] [<806537dc>] (dump_stack) from [<8002c578>]
>> (warn_slowpath_common+0x6c/0x88)
>> [17554.920103] [<8002c578>] (warn_slowpath_common) from [<8002c630>]
>> (warn_slowpath_null+0x1c/0x24)
>> [17554.920377] [<8002c630>] (warn_slowpath_null) from [<7f089c74>]
>> (ieee80211_calculate_rx_timestamp+0x204/0x278 [mac80211])
>> [17554.920826] [<7f089c74>] (ieee80211_calculate_rx_timestamp
>> [mac80211]) from [<7f07d724>] (ieee80211_rx_napi+0xcc/0x8d4
>> [mac80211])
>> [17554.921259] [<7f07d724>] (ieee80211_rx_napi [mac80211]) from
>> [<7f117fd0>] (ath10k_wmi_event_mgmt_rx+0x1f4/0x35c [ath10k_core])
>> [17554.921540] [<7f117fd0>] (ath10k_wmi_event_mgmt_rx [ath10k_core])
>> from [<7f10d844>] (ath10k_htc_rx_completion_handler+0x1cc/0x464
>> [ath10k_core])
>> [17554.921706] [<7f10d844>] (ath10k_htc_rx_completion_handler
>> [ath10k_core]) from [<7f157b4c>] (ath10k_pci_process_rx_cb+0x1ac/0x1fc
>> [ath10k_pci])
>> [17554.921773] [<7f157b4c>] (ath10k_pci_process_rx_cb [ath10k_pci])
>> from [<7f15b3ac>] (ath10k_ce_per_engine_service+0x5c/0x94
>> [ath10k_pci])
>> [17554.921835] [<7f15b3ac>] (ath10k_ce_per_engine_service
>> [ath10k_pci]) from [<7f15b464>]
>> (ath10k_ce_per_engine_service_any+0x80/0x88 [ath10k_pci])
>> [17554.921892] [<7f15b464>] (ath10k_ce_per_engine_service_any
>> [ath10k_pci]) from [<7f15a6d8>] (ath10k_pci_tasklet+0x24/0x5c
>> [ath10k_pci])
>> [17554.921946] [<7f15a6d8>] (ath10k_pci_tasklet [ath10k_pci]) from
>> [<800304c8>] (tasklet_action+0x80/0x110)
>> [17554.921979] [<800304c8>] (tasklet_action) from [<800306b8>]
>> (__do_softirq+0x10c/0x248)
>> [17554.922009] [<800306b8>] (__do_softirq) from [<80030a6c>]
>> (irq_exit+0xac/0xf4)
>> [17554.922042] [<80030a6c>] (irq_exit) from [<8000e904>]
>> (handle_IRQ+0x44/0x90)
>> [17554.922072] [<8000e904>] (handle_IRQ) from [<800084f8>]
>> (gic_handle_irq+0x2c/0x5c)
>> [17554.922105] [<800084f8>] (gic_handle_irq) from [<80011e00>]
>> (__irq_svc+0x40/0x50)
>> [17554.922122] Exception stack(0x80917f18 to 0x80917f60)
>> [17554.922141] 7f00:
>> 80917f60 000d3334
>> [17554.922166] 7f20: 5221e106 00000ff7 4d693c44 00000ff7 a7705010
>> 80924060 00000001 a7705014
>> [17554.922190] 7f40: 8096243d 80916000 00000017 80917f60 a6aaaaab
>> 80492940 60000013 ffffffff
>> [17554.922224] [<80011e00>] (__irq_svc) from [<80492940>]
>> (cpuidle_enter_state+0x50/0xe0)
>> [17554.922252] [<80492940>] (cpuidle_enter_state) from [<80492ac8>]
>> (cpuidle_idle_call+0xf8/0x148)
>> [17554.922281] [<80492ac8>] (cpuidle_idle_call) from [<8000ec48>]
>> (arch_cpu_idle+0x8/0x44)
>> [17554.922322] [<8000ec48>] (arch_cpu_idle) from [<80066648>]
>> (cpu_startup_entry+0xfc/0x140)
>> [17554.922362] [<80066648>] (cpu_startup_entry) from [<808c5b08>]
>> (start_kernel+0x360/0x36c)
>> [17554.922379] ---[ end trace 87d4775146813aed ]---
>> [17555.943454] ------------[ cut here ]------------
>>
>> that repeat continuously...
>> Forcing legacy bitrates doesn't change the situation.
>>
>> I made some measurements using iperf, please find it in attachment.
>>
>> Other info:
>>
>> root@Yazi:~# modinfo ath10k_pci
>> filename:
>>
>> /lib/modules/3.14.48-g408ccb9/kernel/drivers/net/wireless/ath/ath10k/ath10k_pci.ko
>> firmware: ath10k/QCA9377/hw1.0/board.bin
>> firmware: ath10k/QCA9377/hw1.0/firmware-5.bin
>> firmware: ath10k/QCA6174/hw3.0/board-2.bin
>> firmware: ath10k/QCA6174/hw3.0/board.bin
>> firmware: ath10k/QCA6174/hw3.0/firmware-5.bin
>> firmware: ath10k/QCA6174/hw3.0/firmware-4.bin
>> firmware: ath10k/QCA6174/hw2.1/board-2.bin
>> firmware: ath10k/QCA6174/hw2.1/board.bin
>> firmware: ath10k/QCA6174/hw2.1/firmware-5.bin
>> firmware: ath10k/QCA6174/hw2.1/firmware-4.bin
>> firmware: ath10k/QCA988X/hw2.0/board-2.bin
>> firmware: ath10k/QCA988X/hw2.0/board.bin
>> firmware: ath10k/QCA988X/hw2.0/firmware-5.bin
>> firmware: ath10k/QCA988X/hw2.0/firmware-4.bin
>> firmware: ath10k/QCA988X/hw2.0/firmware-3.bin
>> firmware: ath10k/QCA988X/hw2.0/firmware-2.bin
>> firmware: ath10k/QCA988X/hw2.0/firmware.bin
>> license: Dual BSD/GPL
>> description: Driver support for Atheros QCA988X PCIe devices
>> author: Qualcomm Atheros
>> version: backported from Linux (v4.4.2-0-g1cb8570) using
>> backports v4.4.2-1-0-gbec4037
>> srcversion: EBB3D4E36DE49B7EC8057D0
>> alias: pci:v0000168Cd00000042sv*sd*bc*sc*i*
>> alias: pci:v0000168Cd00000040sv*sd*bc*sc*i*
>> alias: pci:v0000168Cd0000003Esv*sd*bc*sc*i*
>> alias: pci:v0000168Cd00000041sv*sd*bc*sc*i*
>> alias: pci:v0000168Cd0000003Csv*sd*bc*sc*i*
>> depends: ath10k_core,compat
>> vermagic: 3.14.48-g408ccb9 SMP mod_unload modversions ARMv7 p2v8
>> parm: irq_mode:0: auto, 1: legacy, 2: msi (default: 0) (uint)
>> parm: reset_mode:0: auto, 1: warm only (default: 0) (uint)
>>
>> I don't know if it's only a problem of iw station dump that can't show
>> the tx rate, but the spammed syslog honestly warn me...
>>
>> How shall I check what's wrong and see the HT work?
>>
>> Thanks a lot!
>>
>> Matteo
>>
>
> --
> Ben Greear <greearb@candelatech.com>
> Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH 1/3] mac80211: filter multicast data packets on AP / AP_VLAN
From: Johannes Berg @ 2016-09-30 7:20 UTC (permalink / raw)
To: Michael Braun; +Cc: linux-wireless
In-Reply-To: <1474821596-12155-2-git-send-email-michael-dev@fami-braun.de>
[snip]
I think this makes sense, but it's not clear to me why you add two
counters and keep the old one? It seems to me that it would be
sufficient to have a single counter per AP/VLAN interface?
The usage in __ieee80211_request_smps_ap() can just be removed since it
goes to iterate the stations next. That should be a separate, first,
patch in the series, but after that I don't see a need to keep
num_mcast_sta, or rather, I see no reason not to remove the VLAN
stations from the AP's num_mcast_sta, and add a new per-VLAN
num_mcast_sta.
> +/**
> + * @returns number of multicast stations connected
> + * -1 if unsupported (no-AP, 4addr mode)
> + */
> +static inline int
> +ieee80211_vif_get_num_mcast_if(struct ieee80211_sub_if_data *sdata)
That's not a valid kernel-doc comment, but you've tagged it as one with
the /** - please fix by removing the /** and the @, and writing a real
sentence out of that, or by making it a real kernel-doc comment.
johannes
^ permalink raw reply
* Re: ath10k mesh mode issue
From: Matteo Grandi @ 2016-09-30 6:55 UTC (permalink / raw)
To: Yeoh Chun-Yeow; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <CAEFj984FqjgqJJCB=b8tZkaAudGRNjwJAw=RtmqP56x89iOZtg@mail.gmail.com>
Hi Chun-Yeoh,
These https://wireless.wiki.kernel.org/en/users/drivers/ath10k/mesh
are the staeps that i followed to set-up the mesh.
Thanks!
Matteo
2016-09-29 17:10 GMT+02:00 Yeoh Chun-Yeow <yeohchunyeow@gmail.com>:
> Try refer the following for latest mesh setup using ath10k:
> https://wireless.wiki.kernel.org/en/users/drivers/ath10k/mesh
>
> ---
> Chun-Yeow
^ permalink raw reply
* Re: pull-request: wireless-drivers-next 2016-09-29
From: David Miller @ 2016-09-30 5:32 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <87ponmve2v.fsf@kamboji.qca.qualcomm.com>
From: Kalle Valo <kvalo@codeaurora.org>
Date: Thu, 29 Sep 2016 19:57:28 +0300
> this should be the last wireless-drivers-next pull request for 4.9, from
> now on only important bugfixes. Nothing really special stands out,
> iwlwifi being most active but other drivers also getting attention. More
> details in the signed tag. Please let me know if there are any problems.
Pulled, thanks Kalle.
> Or actually I had one problem. While doing a test merge I noticed that
> net-next fails to compile for me, but I don't think this is anything
> wireless related:
>
> CC net/netfilter/core.o
> net/netfilter/core.c: In function 'nf_set_hooks_head':
> net/netfilter/core.c:96:149: error: 'struct net_device' has no member named 'nf_hooks_ingress'
Yes, I am aware of this build issue and will tackle it myself if someone
doesn't beat me to it.
Thanks again.
^ permalink raw reply
* Re: [PATCH v3 1/3] Documentation: dt: net: add mt76 wireless device binding
From: Arnd Bergmann @ 2016-09-29 22:41 UTC (permalink / raw)
To: Felix Fietkau; +Cc: Kalle Valo, linux-wireless, devicetree
In-Reply-To: <e7d435b2-6b59-45af-07eb-b10789d61a9c@nbd.name>
On Thursday 29 September 2016, Felix Fietkau wrote:
> On 2016-09-08 12:54, Kalle Valo wrote:
> > Felix Fietkau <nbd@nbd.name> writes:
> >
> >> Signed-off-by: Felix Fietkau <nbd@nbd.name>
> >> ---
> >> .../bindings/net/wireless/mediatek,mt76.txt | 26 ++++++++++++++++++++++
> >> 1 file changed, 26 insertions(+)
> >> create mode 100644 Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
> >> new file mode 100644
> >> index 0000000..d51c35f
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
> >> @@ -0,0 +1,26 @@
> >> +* MediaTek mt76xx devices
> >> +
> >> +This node provides properties for configuring the MediaTek mt76xx wireless
> >> +device. The node is expected to be specified as a child node of the PCI
> >> +controller to which the wireless chip is connected.
> >> +
> >> +Optional properties:
> >> +
> >> +- mac-address: See ethernet.txt in the parent directory
> >> +- local-mac-address: See ethernet.txt in the parent directory
> >> +- mediatek,2ghz: Override the 2.4 GHz band capability from EEPROM
> >> +- mediatek,5ghz: Override the 5 GHz band capability from EEPROM
> >> +- mediatek,mtd-eeprom: Specify a MTD partition + offset containing EEPROM data
> >> +
> >> +&pcie {
> >> + status = "okay";
> >> +
> >> + pcie0 {
> >> + mt76@0,0 {
> >> + reg = <0x0000 0 0 0 0>;
Maybe have an examplep of a real register address other than zero?
> >> + device_type = "pci";
> >> + mediatek,mtd-eeprom = <&factory 0x8000>;
> >> + mediatek,2ghz = <0>;
It's not clear what the possible values for the 2ghz property are,
can you be more verbose in the description? How is <0> different
from no property?
Arnd
^ permalink raw reply
* Re: [PATCH] brcmfmac: implement more accurate skb tracking
From: Rafał Miłecki @ 2016-09-29 21:57 UTC (permalink / raw)
To: Arend Van Spriel
Cc: Kalle Valo, Franky Lin, Hante Meuleman, Pieter-Paul Giesberts,
Franky Lin, linux-wireless@vger.kernel.org,
open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
Network Development, Linux Kernel Mailing List,
Rafał Miłecki
In-Reply-To: <0a070079-e3af-ab5c-0485-744bec8b3d86@broadcom.com>
On 27 September 2016 at 11:24, Arend Van Spriel
<arend.vanspriel@broadcom.com> wrote:
> On 26-9-2016 14:38, Rafa=C5=82 Mi=C5=82ecki wrote:
>> On 26 September 2016 at 14:13, Rafa=C5=82 Mi=C5=82ecki <zajec5@gmail.com=
> wrote:
>>> On 26 September 2016 at 13:46, Arend Van Spriel
>>> <arend.vanspriel@broadcom.com> wrote:
>>>> On 26-9-2016 12:23, Rafa=C5=82 Mi=C5=82ecki wrote:
>>>>> From: Rafa=C5=82 Mi=C5=82ecki <rafal@milecki.pl>
>>>>>
>>>>> We need to track 802.1x packets to know if there are any pending ones
>>>>> for transmission. This is required for performing key update in the
>>>>> firmware.
>>>>
>>>> The problem we are trying to solve is a pretty old one. The problem is
>>>> that wpa_supplicant uses two separate code paths: EAPOL messaging
>>>> through data path and key configuration though nl80211.
>>>
>>> Can I find it described/reported somewhere?
>>>
>>>
>>>>> Unfortunately our old tracking code wasn't very accurate. It was
>>>>> treating skb as pending as soon as it was passed by the netif. Actual
>>>>> handling packet to the firmware was happening later as brcmfmac
>>>>> internally queues them and uses its own worker(s).
>>>>
>>>> That does not seem right. As soon as we get a 1x packet we need to wai=
t
>>>> with key configuration regardless whether it is still in the driver or
>>>> handed over to firmware already.
>>>
>>> OK, thanks.
>>
>> Actually, it's not OK. I was trying to report/describe/discuss this
>> problem for over a week. I couldn't get much of answer from you.
>>
>> I had to come with a patch I worked on for quite some time. Only then
>> you decided to react and reply with a reason for a nack. I see this
>> patch may be wrong (but it's still hard to know what's going wrong
>> without a proper hostapd bug report). I'd expect you to somehow work &
>> communicate with open source community.
>
> We do or at least make an honest attempt, but there is more on our plate
> so responses may be delayed. It also does not help when you get anal and
> preachy when we do respond. Also not OK. In this case the delay is
> caused because I had to pick up the thread(s) as Hante is on vacation
> (he needed a break :-p ). However, you started sending patches so I
> decided to look at and respond to those. Sorry if you felt like we left
> you hanging to dry.
I believe I get easily irritated due to my communication experience I
got so far :(
Over a year ago I reported brcmfmac can't recover from failed
register_netdev(ice). This bug remains unfixed.
In 2014 I reported problem with 80 MHz support. I didn't have hardware
to fix & test it on my own (you weren't able/allowed to send me one of
your PCIe cards). In remained broken until I fixed it year later.
You missed my crash bug report about caused by missing eth_type_trans
and came with patch on your own a month later.
Earlier this year I reported you problem with BCM4366 and multiple
interfaces. I didn't get much help. 3 months later I came with patch
to workaround the problem but you said there's a better way to do
this. It took me 2 weeks to figure out a new wlioctl API for that
while all I needed was a simple hint on "interface_remove".
Right now I'm waiting to get any answer from you about 4366c0
firmware. It's still less than 2 weeks since I asked for it, but a
simple ETA would be nice. I'm actually not sure if I should report
more problems to you to don't distract you from pending things.
Problems with brcmf_netdev_wait_pend8021x were reported multiples
times for last few months. When I finally got time for that it took me
a week to debug them.
As you can see, it takes me months to get help on some things. And in
few cases I never got much help at all. Yes, I was hoping to have you
more involved into brcmfmac development and problems solving. I guess
things didn't meet my expectations and I got grumpy & preachy.
--=20
Rafa=C5=82
^ permalink raw reply
* [PATCH 1/2] rtl8xxxu: Fix memory leak in handling rxdesc16 packets
From: Jes.Sorensen @ 2016-09-29 19:40 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo, Larry.Finger, stable, Jes Sorensen
In-Reply-To: <1475178055-16924-1-git-send-email-Jes.Sorensen@redhat.com>
From: Jes Sorensen <Jes.Sorensen@redhat.com>
A device running without RX package aggregation could return more data
in the USB packet than the actual network packet. In this case the
could would clone the skb but then determine that that there was no
packet to handle and exit without freeing the cloned skb first.
This has so far only been observed with 8188eu devices, but could
affect others.
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
---
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index b2d7f6e..a96ff17 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -5197,7 +5197,12 @@ int rtl8xxxu_parse_rxdesc16(struct rtl8xxxu_priv *priv, struct sk_buff *skb)
pkt_offset = roundup(pkt_len + drvinfo_sz + desc_shift +
sizeof(struct rtl8xxxu_rxdesc16), 128);
- if (pkt_cnt > 1)
+ /*
+ * Only clone the skb if there's enough data at the end to
+ * at least cover the rx descriptor
+ */
+ if (pkt_cnt > 1 &&
+ urb_len > (pkt_offset + sizeof(struct rtl8xxxu_rxdesc16)))
next_skb = skb_clone(skb, GFP_ATOMIC);
rx_status = IEEE80211_SKB_RXCB(skb);
--
2.7.4
^ permalink raw reply related
* [PATCH 2/2] rtl8xxxu: Fix big-endian problem reporting mactime
From: Jes.Sorensen @ 2016-09-29 19:40 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo, Larry.Finger, stable, Jes Sorensen
In-Reply-To: <1475178055-16924-1-git-send-email-Jes.Sorensen@redhat.com>
From: Jes Sorensen <Jes.Sorensen@redhat.com>
The full RX descriptor is converted so converting tsfl again would
return it to it's original endian value.
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
---
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h | 4 ++--
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
index 10166289..08d587a 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
@@ -238,7 +238,7 @@ struct rtl8xxxu_rxdesc16 {
u32 pattern1match:1;
u32 pattern0match:1;
#endif
- __le32 tsfl;
+ u32 tsfl;
#if 0
u32 bassn:12;
u32 bavld:1;
@@ -368,7 +368,7 @@ struct rtl8xxxu_rxdesc24 {
u32 ldcp:1;
u32 splcp:1;
#endif
- __le32 tsfl;
+ u32 tsfl;
};
struct rtl8xxxu_txdesc32 {
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index a96ff17..a5e6ec2 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -5220,7 +5220,7 @@ int rtl8xxxu_parse_rxdesc16(struct rtl8xxxu_priv *priv, struct sk_buff *skb)
rtl8xxxu_rx_parse_phystats(priv, rx_status, phy_stats,
rx_desc->rxmcs);
- rx_status->mactime = le32_to_cpu(rx_desc->tsfl);
+ rx_status->mactime = rx_desc->tsfl;
rx_status->flag |= RX_FLAG_MACTIME_START;
if (!rx_desc->swdec)
@@ -5290,7 +5290,7 @@ int rtl8xxxu_parse_rxdesc24(struct rtl8xxxu_priv *priv, struct sk_buff *skb)
rtl8xxxu_rx_parse_phystats(priv, rx_status, phy_stats,
rx_desc->rxmcs);
- rx_status->mactime = le32_to_cpu(rx_desc->tsfl);
+ rx_status->mactime = rx_desc->tsfl;
rx_status->flag |= RX_FLAG_MACTIME_START;
if (!rx_desc->swdec)
--
2.7.4
^ permalink raw reply related
* [PATCH 0/2] rtl8xxxu: Fix memory leak and big endian bug
From: Jes.Sorensen @ 2016-09-29 19:40 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo, Larry.Finger, stable, Jes Sorensen
From: Jes Sorensen <Jes.Sorensen@redhat.com>
Hi,
These two patches for 4.9 fix a potential memory leak for gen1 parts
and a big endian problem reporting mactime.
While I have only seen it trigger for 8188eu devices, in code which
has not yet been submitted, it could potentially hit other parts such
as 8723au, 8188cu, 8192cu. I prefer to get it fixed asap.
The second bug is a double byte-swap of the mactime read from the RX
packet descriptor.
Both fixes should be applicable to stable-4.8.
Cheers,
Jes
Jes Sorensen (2):
rtl8xxxu: Fix memory leak in handling rxdesc16 packets
rtl8xxxu: Fix big-endian problem reporting mactime
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h | 4 ++--
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 11 ++++++++---
2 files changed, 10 insertions(+), 5 deletions(-)
--
2.7.4
^ permalink raw reply
* Re: [PATCH v3 1/3] Documentation: dt: net: add mt76 wireless device binding
From: Felix Fietkau @ 2016-09-29 18:31 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, devicetree
In-Reply-To: <87eg4uu0f3.fsf@kamboji.qca.qualcomm.com>
On 2016-09-08 12:54, Kalle Valo wrote:
> Felix Fietkau <nbd@nbd.name> writes:
>
>> Signed-off-by: Felix Fietkau <nbd@nbd.name>
>> ---
>> .../bindings/net/wireless/mediatek,mt76.txt | 26 ++++++++++++++++++++++
>> 1 file changed, 26 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
>>
>> diff --git a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
>> new file mode 100644
>> index 0000000..d51c35f
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
>> @@ -0,0 +1,26 @@
>> +* MediaTek mt76xx devices
>> +
>> +This node provides properties for configuring the MediaTek mt76xx wireless
>> +device. The node is expected to be specified as a child node of the PCI
>> +controller to which the wireless chip is connected.
>> +
>> +Optional properties:
>> +
>> +- mac-address: See ethernet.txt in the parent directory
>> +- local-mac-address: See ethernet.txt in the parent directory
>> +- mediatek,2ghz: Override the 2.4 GHz band capability from EEPROM
>> +- mediatek,5ghz: Override the 5 GHz band capability from EEPROM
>> +- mediatek,mtd-eeprom: Specify a MTD partition + offset containing EEPROM data
>> +
>> +&pcie {
>> + status = "okay";
>> +
>> + pcie0 {
>> + mt76@0,0 {
>> + reg = <0x0000 0 0 0 0>;
>> + device_type = "pci";
>> + mediatek,mtd-eeprom = <&factory 0x8000>;
>> + mediatek,2ghz = <0>;
>> + };
>> + };
>> +};
>
> I need an ack from device tree maintainers, CCing the devicetree list.
> Do we need to resend or this ok?
>
> Patchwork link:
>
> https://patchwork.kernel.org/patch/9313309/
Ping?
- Felix
^ permalink raw reply
* Re: pull-request: wireless-drivers-next 2016-09-29
From: Pablo Neira Ayuso @ 2016-09-29 18:21 UTC (permalink / raw)
To: Kalle Valo; +Cc: David Miller, linux-wireless, netdev, linux-kernel
In-Reply-To: <87ponmve2v.fsf@kamboji.qca.qualcomm.com>
On Thu, Sep 29, 2016 at 07:57:28PM +0300, Kalle Valo wrote:
> Hi Dave,
>
> this should be the last wireless-drivers-next pull request for 4.9, from
> now on only important bugfixes. Nothing really special stands out,
> iwlwifi being most active but other drivers also getting attention. More
> details in the signed tag. Please let me know if there are any problems.
>
> Or actually I had one problem. While doing a test merge I noticed that
> net-next fails to compile for me, but I don't think this is anything
> wireless related:
>
> CC net/netfilter/core.o
> net/netfilter/core.c: In function 'nf_set_hooks_head':
> net/netfilter/core.c:96:149: error: 'struct net_device' has no member named 'nf_hooks_ingress'
That's my problem, will be sending a pull request to fix this asap,
thanks.
^ permalink raw reply
* pull-request: wireless-drivers-next 2016-09-29
From: Kalle Valo @ 2016-09-29 16:57 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, linux-kernel
Hi Dave,
this should be the last wireless-drivers-next pull request for 4.9, from
now on only important bugfixes. Nothing really special stands out,
iwlwifi being most active but other drivers also getting attention. More
details in the signed tag. Please let me know if there are any problems.
Or actually I had one problem. While doing a test merge I noticed that
net-next fails to compile for me, but I don't think this is anything
wireless related:
CC net/netfilter/core.o
net/netfilter/core.c: In function 'nf_set_hooks_head':
net/netfilter/core.c:96:149: error: 'struct net_device' has no member named=
'nf_hooks_ingress'
Kalle
The following changes since commit fd9527f404d51e50f40dac0d9a69f2eff3dac33e:
Merge branch 'ip_tunnel-collect_md' (2016-09-17 10:13:16 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next=
.git tags/wireless-drivers-next-for-davem-2016-09-29
for you to fetch changes up to 15b95a15950238eff4d7f24be1716086eea67835:
Merge ath-next from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/a=
th.git (2016-09-28 16:37:33 +0300)
----------------------------------------------------------------
wireless-drivers-next patches for 4.9
Major changes:
iwlwifi
* work for new hardware support continues
* dynamic queue allocation stabilization
* improvements in the MSIx code
* multiqueue support work continues
* new firmware version support (API 26)
* add 8275 series support
* add 9560 series support
* add support for MU-MIMO sniffer
* add support for RRM by scan
* add support for "reverse" rx packet injection faking hw descriptors
* migrate to devm memory allocation handling
* Remove support for older firmwares (API older than -17 and -22)
wl12xx
* support booting the same rootfs with both wl12xx and wl18xx
hostap
* mark the driver as obsolete
ath9k
* disable RNG by default
----------------------------------------------------------------
Amitkumar Karwar (1):
mwifiex: code rearrangement in mwifiex_usb_host_to_card()
Arend Van Spriel (4):
brcmfmac: rework pointer trickery in brcmf_proto_bcdc_query_dcmd()
brcmfmac: fix memory leak in brcmf_flowring_add_tdls_peer()
brcmfmac: initialize variable in brcmf_sdiod_regrl()
brcmfmac: remove worker from .ndo_set_mac_address() callback
Arik Nemtsov (1):
iwlwifi: move BIOS MCC retrieval to common code
Aviya Erenfeld (1):
iwlwifi: mvm: add support for MU-MIMO air sniffer
Avrahams Stern (1):
iwlwifi: mvm: Add support for RRM by scan
Ben Greear (3):
ath10k: fix typo in logging message
ath10k: document cycle count related counters
ath10k: support up to 64 vdevs
Bob Copeland (1):
mwifiex: fix error handling in mwifiex_create_custom_regdomain
Cathy Luo (2):
mwifiex: fix kernel crash for USB chipsets
mwifiex: fix race condition causing tx timeout
Chaehyun Lim (1):
ath6kl: fix return value in ath6kl_wmi_set_pvb_cmd
Colin Ian King (1):
mwifiex: fix null pointer deference when adapter is null
Emmanuel Grumbach (4):
iwlwifi: mvm: bump max API to 26
iwlwifi: don't export trace points that are used in iwlwifi only
iwlwifi: mvm: fix typo in TC_CMD_SEC_KEY_FROM_TABLE
iwlwifi: mvm: initialise ADD_STA before sending it to the firmware
Ganapathi Bhat (1):
mwifiex: cfg80211 set_default_mgmt_key handler
Haim Dreyfuss (4):
iwlwifi: pcie: Configure shared interrupt vector in MSIX mode
iwlwifi: pcie: Set affinity mask for rx interrupt vectors per cpu
iwlwifi: pcie: replace possible_cpus() with online_cpus() in MSIX mode
iwlwifi: check for valid ethernet address provided by OEM
Hante Meuleman (5):
brcmfmac: ignore 11d configuration errors
brcmfmac: remove unnecessary null pointer check
brcmfmac: fix clearing entry IPv6 address
brcmfmac: fix out of bound access on clearing wowl wake indicator
brcmfmac: simplify mapping of auth type
Ido Yariv (1):
iwlwifi: mvm: Add mem debugfs entry
Jes Sorensen (4):
rtl8xxxu: Implement 8192e specific power down sequence
rtl8xxxu: Fix off by one error calculating pubq
rtl8xxxu: Clean up llt_init() API
rtl8xxxu: Use a struct rtl8xxxu_fileops * in rtl8xxxu_init_device()
Joe Perches (2):
ath10k: spelling and miscellaneous neatening
rtlwifi: Add switch variable to 'switch case not processed' messages
Johannes Berg (11):
iwlwifi: mvm: make RSS RX more robust
iwlwifi: mvm: remove pointless _bh from spinlock in timer
iwlwifi: mvm: tighten BAID range check
iwlwifi: mvm: compare full command ID
iwlwifi: mvm: make iwl_mvm_update_sta() an inline
iwlwifi: mvm: document passing unexpected Block Ack Request frames
iwlwifi: mvm: move AP-specific code to right function
iwlwifi: mvm: use LIST_HEAD() macro
iwlwifi: pcie: use LIST_HEAD() macro
iwlwifi: pcie: avoid variable shadowing in TFD helpers
iwlwifi: mvm: correct rate_idx bounds-check
Jouni Malinen (1):
MAINTAINERS: hostap: Mark the Host AP driver obsolete
Kalle Valo (4):
Merge tag 'iwlwifi-next-for-kalle-2016-09-15-2' of git://git.kernel.o=
rg/.../iwlwifi/iwlwifi-next
Merge tag 'iwlwifi-next-for-kalle-2016-09-19-2' of git://git.kernel.o=
rg/.../iwlwifi/iwlwifi-next
Merge tag 'iwlwifi-next-for-kalle-2015-09-26' of git://git.kernel.org=
/.../iwlwifi/iwlwifi-next
Merge ath-next from git://git.kernel.org/.../kvalo/ath.git
Larry Finger (3):
rtl8xxxu: Stop log spam from each successful interrupt
rtlwifi: Add HAL_DEF_WOWLAN case to *_get_hw() routines
rtlwifi: Add explicit values to hw_variables enum
Liad Kaufman (4):
iwlwifi: mvm: don't free queue after delba in dqa
iwlwifi: mvm: fix pending frames tracking on tx resp
iwlwifi: mvm: free reserved queue on STA removal
iwlwifi: mvm: remove variable shadowing
Luca Coelho (2):
iwlwifi: mvm: bail out if CTDP start operation fails
iwlwifi: remove support for fw older than -17 and -22
Masahiro Yamada (3):
ath10k: use devm_clk_get() instead of clk_get()
ath10k: use devm_reset_control_get() instead of reset_control_get()
ath10k: do not check if reset is NULL
Miaoqing Pan (1):
ath9k: disable RNG by default
Mohammed Shafi Shajakhan (1):
ath10k: Ignore SWBA event for a vif if its marked for no beacon
Oren Givon (4):
iwlwifi: add the new 9560 series
iwlwifi: add the new 8275 series
iwlwifi: add new 8265 series PCI ID
iwlwifi: add two new 9560 series PCI IDs
Rafa=C5=82 Mi=C5=82ecki (4):
brcmfmac: fix memory leak in brcmf_fill_bss_param
brcmfmac: drop unused fields from struct brcmf_pub
brcmfmac: replace WARNING on timeout with a simple error message
brcmfmac: use correct skb freeing helper when deleting flowring
Rajkumar Manoharan (1):
ath10k: fix copy engine 5 destination ring stuck
Roee Zamir (1):
iwlwifi: mvm: Add debugfs function for clocks diff
Sara Sharon (22):
iwlwifi: mvm: call a different txq_enable function
iwlwifi: pcie: introduce new tfd and tb formats
iwlwifi: mvm: remove dump of locked registers
iwlwifi: mvm: support new shared memory config API
iwlwifi: introduce trans API to get byte count table
iwlwifi: pcie: assign and access a000 TFD & TBs
iwlwifi: change byte count table for a000 devices
iwlwifi: pcie: merge iwl_queue and iwl_txq
iwlwifi: mvm: support new BA notification response
iwlwifi: pcie: change indentation of iwl_pcie_set_interrupt_capa()
iwlwifi: pcie: fix typo in struct name for a000 devices
iwlwifi: mvm: cleanup skb queue functions use
iwlwifi: mvm: fix DQA AP mode station assumption
iwlwifi: mvm: support BAR in reorder buffer
iwlwifi: mvm: support packet injection
iwlwifi: pcie: log full command sequence
iwlwifi: move to wide ID for all commands
iwlwifi: mvm: disable P2P queue on mac context release
iwlwifi: mvm: set HCMD_NAME for PHY_DB as well
iwlwifi: mvm: cleanup redundant no_power_up_nic_in_init config
iwlwifi: mvm: cleanup usage of init_dbg parameter
iwlwifi: allow error table address new range
Sharon Dvir (2):
iwlwifi: unify iwl_get_ucode_image() implementations
iwlwifi: migrate to devm_* API
Tony Lindgren (5):
wlcore: Prepare family to fix nvs file handling
wlcore: sdio: Populate config firmware data
wlcore: spi: Populate config firmware data
wlcore: Fix config firmware loading issues
wlcore: wl18xx: Use chip specific configuration firmware
Vasanthakumar Thiagarajan (1):
ath10k: fix rfc1042 header retrieval in QCA4019 with eth decap mode
Wei Yongjun (2):
iwlwifi: mvm: use setup_timer instead of init_timer and data fields
ath10k: fix error return code in ahb
kbuild test robot (1):
iwlwifi: fix semicolon.cocci warnings
MAINTAINERS | 5 +-
drivers/net/wireless/ath/ath10k/ahb.c | 107 ++----
drivers/net/wireless/ath/ath10k/ce.c | 9 +-
drivers/net/wireless/ath/ath10k/core.c | 17 +-
drivers/net/wireless/ath/ath10k/core.h | 8 +-
drivers/net/wireless/ath/ath10k/htt.h | 8 +-
drivers/net/wireless/ath/ath10k/htt_rx.c | 5 +-
drivers/net/wireless/ath/ath10k/hw.c | 2 +-
drivers/net/wireless/ath/ath10k/hw.h | 5 +-
drivers/net/wireless/ath/ath10k/mac.c | 2 +-
drivers/net/wireless/ath/ath10k/targaddrs.h | 2 +-
drivers/net/wireless/ath/ath10k/wmi.c | 6 +
drivers/net/wireless/ath/ath10k/wmi.h | 32 +-
drivers/net/wireless/ath/ath6kl/wmi.c | 2 +-
drivers/net/wireless/ath/ath9k/Kconfig | 2 +-
.../wireless/broadcom/brcm80211/brcmfmac/bcdc.c | 2 +-
.../wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 2 +-
.../broadcom/brcm80211/brcmfmac/cfg80211.c | 46 +--
.../wireless/broadcom/brcm80211/brcmfmac/core.c | 55 ++-
.../wireless/broadcom/brcm80211/brcmfmac/core.h | 6 -
.../broadcom/brcm80211/brcmfmac/flowring.c | 17 +-
.../broadcom/brcm80211/brcmfmac/fwsignal.c | 2 -
drivers/net/wireless/intel/iwlwifi/dvm/ucode.c | 11 +-
drivers/net/wireless/intel/iwlwifi/iwl-7000.c | 10 +-
drivers/net/wireless/intel/iwlwifi/iwl-8000.c | 17 +-
drivers/net/wireless/intel/iwlwifi/iwl-9000.c | 15 +-
drivers/net/wireless/intel/iwlwifi/iwl-a000.c | 2 +-
drivers/net/wireless/intel/iwlwifi/iwl-config.h | 3 +-
drivers/net/wireless/intel/iwlwifi/iwl-csr.h | 2 +
drivers/net/wireless/intel/iwlwifi/iwl-devtrace.c | 3 -
drivers/net/wireless/intel/iwlwifi/iwl-fh.h | 57 ++-
drivers/net/wireless/intel/iwlwifi/iwl-fw-file.h | 29 +-
drivers/net/wireless/intel/iwlwifi/iwl-fw.h | 9 +
drivers/net/wireless/intel/iwlwifi/iwl-io.c | 2 +-
.../net/wireless/intel/iwlwifi/iwl-notif-wait.c | 8 +-
drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c | 104 ++++-
drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.h | 20 +-
drivers/net/wireless/intel/iwlwifi/iwl-phy-db.c | 2 +-
drivers/net/wireless/intel/iwlwifi/iwl-trans.c | 12 +-
drivers/net/wireless/intel/iwlwifi/iwl-trans.h | 20 +-
.../net/wireless/intel/iwlwifi/mvm/debugfs-vif.c | 29 +-
drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c | 184 +++++++++
.../net/wireless/intel/iwlwifi/mvm/fw-api-power.h | 21 +-
.../net/wireless/intel/iwlwifi/mvm/fw-api-scan.h | 20 +-
drivers/net/wireless/intel/iwlwifi/mvm/fw-api-tx.h | 85 ++++-
drivers/net/wireless/intel/iwlwifi/mvm/fw-api.h | 74 +++-
drivers/net/wireless/intel/iwlwifi/mvm/fw-dbg.c | 4 +-
drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 152 ++++----
drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c | 47 +--
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 42 ++-
drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 18 +-
drivers/net/wireless/intel/iwlwifi/mvm/nvm.c | 93 +----
drivers/net/wireless/intel/iwlwifi/mvm/ops.c | 80 ++--
drivers/net/wireless/intel/iwlwifi/mvm/power.c | 15 +-
drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c | 38 +-
drivers/net/wireless/intel/iwlwifi/mvm/scan.c | 88 +++--
drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 51 ++-
drivers/net/wireless/intel/iwlwifi/mvm/sta.h | 11 +-
drivers/net/wireless/intel/iwlwifi/mvm/tt.c | 10 +-
drivers/net/wireless/intel/iwlwifi/mvm/tx.c | 214 +++++++----
drivers/net/wireless/intel/iwlwifi/mvm/utils.c | 24 +-
drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 8 +
drivers/net/wireless/intel/iwlwifi/pcie/internal.h | 128 ++++---
drivers/net/wireless/intel/iwlwifi/pcie/rx.c | 25 +-
drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 325 +++++++++-------
drivers/net/wireless/intel/iwlwifi/pcie/tx.c | 397 ++++++++++++----=
----
drivers/net/wireless/marvell/mwifiex/cfg80211.c | 24 ++
drivers/net/wireless/marvell/mwifiex/fw.h | 1 +
drivers/net/wireless/marvell/mwifiex/ioctl.h | 1 +
drivers/net/wireless/marvell/mwifiex/main.c | 8 +-
drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 5 +
drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c | 13 +-
drivers/net/wireless/marvell/mwifiex/usb.c | 37 +-
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h | 7 +-
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c | 144 ++++++-
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 49 +--
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu_regs.h | 1 +
drivers/net/wireless/realtek/rtlwifi/core.c | 3 +-
drivers/net/wireless/realtek/rtlwifi/pci.c | 3 +-
drivers/net/wireless/realtek/rtlwifi/ps.c | 2 +-
.../net/wireless/realtek/rtlwifi/rtl8188ee/fw.c | 4 +-
.../net/wireless/realtek/rtlwifi/rtl8188ee/hw.c | 11 +-
.../net/wireless/realtek/rtlwifi/rtl8188ee/led.c | 4 +-
.../net/wireless/realtek/rtlwifi/rtl8188ee/phy.c | 10 +-
.../wireless/realtek/rtlwifi/rtl8192c/fw_common.c | 4 +-
.../wireless/realtek/rtlwifi/rtl8192c/phy_common.c | 8 +-
.../net/wireless/realtek/rtlwifi/rtl8192ce/hw.c | 9 +-
.../net/wireless/realtek/rtlwifi/rtl8192ce/led.c | 4 +-
.../net/wireless/realtek/rtlwifi/rtl8192ce/phy.c | 7 +-
.../net/wireless/realtek/rtlwifi/rtl8192cu/hw.c | 4 +-
.../net/wireless/realtek/rtlwifi/rtl8192cu/led.c | 4 +-
.../net/wireless/realtek/rtlwifi/rtl8192cu/phy.c | 7 +-
.../net/wireless/realtek/rtlwifi/rtl8192de/fw.c | 4 +-
.../net/wireless/realtek/rtlwifi/rtl8192de/hw.c | 11 +-
.../net/wireless/realtek/rtlwifi/rtl8192de/led.c | 4 +-
.../net/wireless/realtek/rtlwifi/rtl8192de/phy.c | 15 +-
.../net/wireless/realtek/rtlwifi/rtl8192ee/fw.c | 4 +-
.../net/wireless/realtek/rtlwifi/rtl8192ee/hw.c | 11 +-
.../net/wireless/realtek/rtlwifi/rtl8192ee/led.c | 4 +-
.../net/wireless/realtek/rtlwifi/rtl8192ee/phy.c | 10 +-
.../net/wireless/realtek/rtlwifi/rtl8192se/hw.c | 11 +-
.../net/wireless/realtek/rtlwifi/rtl8192se/led.c | 4 +-
.../net/wireless/realtek/rtlwifi/rtl8192se/phy.c | 5 +-
.../net/wireless/realtek/rtlwifi/rtl8723ae/fw.c | 4 +-
.../net/wireless/realtek/rtlwifi/rtl8723ae/hw.c | 11 +-
.../net/wireless/realtek/rtlwifi/rtl8723ae/led.c | 4 +-
.../net/wireless/realtek/rtlwifi/rtl8723ae/phy.c | 10 +-
.../net/wireless/realtek/rtlwifi/rtl8723be/fw.c | 4 +-
.../net/wireless/realtek/rtlwifi/rtl8723be/hw.c | 12 +-
.../net/wireless/realtek/rtlwifi/rtl8723be/led.c | 4 +-
.../net/wireless/realtek/rtlwifi/rtl8723be/phy.c | 12 +-
.../net/wireless/realtek/rtlwifi/rtl8821ae/fw.c | 4 +-
.../net/wireless/realtek/rtlwifi/rtl8821ae/hw.c | 9 +-
.../net/wireless/realtek/rtlwifi/rtl8821ae/led.c | 4 +-
.../net/wireless/realtek/rtlwifi/rtl8821ae/phy.c | 20 +-
drivers/net/wireless/realtek/rtlwifi/wifi.h | 208 +++++-----
drivers/net/wireless/ti/wl18xx/main.c | 19 +-
drivers/net/wireless/ti/wlcore/boot.c | 15 +-
drivers/net/wireless/ti/wlcore/main.c | 36 +-
drivers/net/wireless/ti/wlcore/sdio.c | 76 ++--
drivers/net/wireless/ti/wlcore/spi.c | 48 +--
drivers/net/wireless/ti/wlcore/wlcore_i.h | 12 +-
122 files changed, 2383 insertions(+), 1437 deletions(-)
^ permalink raw reply
* Re: [PATCH RESEND v3] mwifiex: parse device tree node for PCIe
From: Rajat Jain @ 2016-09-29 16:54 UTC (permalink / raw)
To: Amitkumar Karwar; +Cc: linux-wireless, devicetree, Xinming Hu, Brian Norris
In-Reply-To: <1475167183-18376-1-git-send-email-akarwar@marvell.com>
[+brian]
On Thu, Sep 29, 2016 at 9:39 AM, Amitkumar Karwar <akarwar@marvell.com> wrote:
> From: Xinming Hu <huxm@marvell.com>
>
> This patch derives device tree node from pcie bus layer framework.
> Device tree bindings file has been renamed(marvell-sd8xxx.txt ->
> marvell-8xxx.txt) to accomodate PCIe changes.
>
> Signed-off-by: Xinming Hu <huxm@marvell.com>
> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
> ---
> v2: Included vendor and product IDs in compatible strings for PCIe
> chipsets(Rob Herring)
> v3: Patch is created using -M option so that it will only include diff of
> original and renamed files(Rob Herring)
> Resend v3: Resending the patch because I missed to include device tree mailing
> while sending v3.
> ---
> .../{marvell-sd8xxx.txt => marvell-8xxx.txt} | 8 +++++---
> drivers/net/wireless/marvell/mwifiex/pcie.c | 20 ++++++++++++++++++++
> drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 3 ++-
> 3 files changed, 27 insertions(+), 4 deletions(-)
> rename Documentation/devicetree/bindings/net/wireless/{marvell-sd8xxx.txt => marvell-8xxx.txt} (91%)
>
> diff --git a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
> similarity index 91%
> rename from Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
> rename to Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
> index c421aba..dfe5f8e 100644
> --- a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
> +++ b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
> @@ -1,8 +1,8 @@
> -Marvell 8897/8997 (sd8897/sd8997) SDIO devices
> +Marvell 8897/8997 (sd8897/sd8997/pcie8997) SDIO/PCIE devices
> ------
>
> -This node provides properties for controlling the marvell sdio wireless device.
> -The node is expected to be specified as a child node to the SDIO controller that
> +This node provides properties for controlling the marvell sdio/pcie wireless device.
> +The node is expected to be specified as a child node to the SDIO/PCIE controller that
> connects the device to the system.
>
> Required properties:
> @@ -10,6 +10,8 @@ Required properties:
> - compatible : should be one of the following:
> * "marvell,sd8897"
> * "marvell,sd8997"
> + * "pci11ab,2b42"
> + * "pci1b4b,2b42"
>
> Optional properties:
>
> diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c
> index 063c707..f1eeb73 100644
> --- a/drivers/net/wireless/marvell/mwifiex/pcie.c
> +++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
> @@ -37,6 +37,23 @@ static struct mwifiex_if_ops pcie_ops;
>
> static struct semaphore add_remove_card_sem;
>
> +static const struct of_device_id mwifiex_pcie_of_match_table[] = {
> + { .compatible = "pci11ab,2b42" },
> + { .compatible = "pci1b4b,2b42" },
> + { }
> +};
> +
> +static int mwifiex_pcie_probe_of(struct device *dev)
> +{
> + if (!dev->of_node ||
> + !of_match_node(mwifiex_pcie_of_match_table, dev->of_node)) {
> + pr_err("pcie device node not available");
> + return -1;
> + }
> +
> + return 0;
> +}
> +
> static int
> mwifiex_map_pci_memory(struct mwifiex_adapter *adapter, struct sk_buff *skb,
> size_t size, int flags)
> @@ -206,6 +223,9 @@ static int mwifiex_pcie_probe(struct pci_dev *pdev,
> card->pcie.can_ext_scan = data->can_ext_scan;
> }
>
> + /* device tree node parsing and platform specific configuration*/
> + mwifiex_pcie_probe_of(&pdev->dev);
> +
> if (mwifiex_add_card(card, &add_remove_card_sem, &pcie_ops,
> MWIFIEX_PCIE)) {
> pr_err("%s failed\n", __func__);
> diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> index 638d30a..f2a7a13 100644
> --- a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> +++ b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> @@ -2218,7 +2218,8 @@ int mwifiex_sta_init_cmd(struct mwifiex_private *priv, u8 first_sta, bool init)
> * The cal-data can be read from device tree and/or
> * a configuration file and downloaded to firmware.
> */
> - if (priv->adapter->iface_type == MWIFIEX_SDIO &&
> + if ((priv->adapter->iface_type == MWIFIEX_SDIO ||
> + priv->adapter->iface_type == MWIFIEX_PCIE) &&
> adapter->dev->of_node) {
> adapter->dt_node = adapter->dev->of_node;
> if (of_property_read_u32(adapter->dt_node,
> --
> 1.9.1
>
^ permalink raw reply
* [PATCH RESEND v3] mwifiex: parse device tree node for PCIe
From: Amitkumar Karwar @ 2016-09-29 16:39 UTC (permalink / raw)
To: linux-wireless, devicetree; +Cc: rajatja, Xinming Hu, Amitkumar Karwar
From: Xinming Hu <huxm@marvell.com>
This patch derives device tree node from pcie bus layer framework.
Device tree bindings file has been renamed(marvell-sd8xxx.txt ->
marvell-8xxx.txt) to accomodate PCIe changes.
Signed-off-by: Xinming Hu <huxm@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
v2: Included vendor and product IDs in compatible strings for PCIe
chipsets(Rob Herring)
v3: Patch is created using -M option so that it will only include diff of
original and renamed files(Rob Herring)
Resend v3: Resending the patch because I missed to include device tree mailing
while sending v3.
---
.../{marvell-sd8xxx.txt => marvell-8xxx.txt} | 8 +++++---
drivers/net/wireless/marvell/mwifiex/pcie.c | 20 ++++++++++++++++++++
drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 3 ++-
3 files changed, 27 insertions(+), 4 deletions(-)
rename Documentation/devicetree/bindings/net/wireless/{marvell-sd8xxx.txt => marvell-8xxx.txt} (91%)
diff --git a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
similarity index 91%
rename from Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
rename to Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
index c421aba..dfe5f8e 100644
--- a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
+++ b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
@@ -1,8 +1,8 @@
-Marvell 8897/8997 (sd8897/sd8997) SDIO devices
+Marvell 8897/8997 (sd8897/sd8997/pcie8997) SDIO/PCIE devices
------
-This node provides properties for controlling the marvell sdio wireless device.
-The node is expected to be specified as a child node to the SDIO controller that
+This node provides properties for controlling the marvell sdio/pcie wireless device.
+The node is expected to be specified as a child node to the SDIO/PCIE controller that
connects the device to the system.
Required properties:
@@ -10,6 +10,8 @@ Required properties:
- compatible : should be one of the following:
* "marvell,sd8897"
* "marvell,sd8997"
+ * "pci11ab,2b42"
+ * "pci1b4b,2b42"
Optional properties:
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c
index 063c707..f1eeb73 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -37,6 +37,23 @@ static struct mwifiex_if_ops pcie_ops;
static struct semaphore add_remove_card_sem;
+static const struct of_device_id mwifiex_pcie_of_match_table[] = {
+ { .compatible = "pci11ab,2b42" },
+ { .compatible = "pci1b4b,2b42" },
+ { }
+};
+
+static int mwifiex_pcie_probe_of(struct device *dev)
+{
+ if (!dev->of_node ||
+ !of_match_node(mwifiex_pcie_of_match_table, dev->of_node)) {
+ pr_err("pcie device node not available");
+ return -1;
+ }
+
+ return 0;
+}
+
static int
mwifiex_map_pci_memory(struct mwifiex_adapter *adapter, struct sk_buff *skb,
size_t size, int flags)
@@ -206,6 +223,9 @@ static int mwifiex_pcie_probe(struct pci_dev *pdev,
card->pcie.can_ext_scan = data->can_ext_scan;
}
+ /* device tree node parsing and platform specific configuration*/
+ mwifiex_pcie_probe_of(&pdev->dev);
+
if (mwifiex_add_card(card, &add_remove_card_sem, &pcie_ops,
MWIFIEX_PCIE)) {
pr_err("%s failed\n", __func__);
diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
index 638d30a..f2a7a13 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
@@ -2218,7 +2218,8 @@ int mwifiex_sta_init_cmd(struct mwifiex_private *priv, u8 first_sta, bool init)
* The cal-data can be read from device tree and/or
* a configuration file and downloaded to firmware.
*/
- if (priv->adapter->iface_type == MWIFIEX_SDIO &&
+ if ((priv->adapter->iface_type == MWIFIEX_SDIO ||
+ priv->adapter->iface_type == MWIFIEX_PCIE) &&
adapter->dev->of_node) {
adapter->dt_node = adapter->dev->of_node;
if (of_property_read_u32(adapter->dt_node,
--
1.9.1
^ permalink raw reply related
* Re: ath10k mesh mode issue
From: Yeoh Chun-Yeow @ 2016-09-29 15:10 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
Try refer the following for latest mesh setup using ath10k:
https://wireless.wiki.kernel.org/en/users/drivers/ath10k/mesh
---
Chun-Yeow
^ permalink raw reply
* [PATCH -next] mwifiex: fix missing destroy_workqueue() on error in mwifiex_add_virtual_intf()
From: Wei Yongjun @ 2016-09-29 14:57 UTC (permalink / raw)
To: Amitkumar Karwar, Nishant Sarmukadam, Kalle Valo
Cc: Wei Yongjun, linux-wireless
From: Wei Yongjun <weiyongjun1@huawei.com>
Add the missing destroy_workqueue() before return from
mwifiex_add_virtual_intf() in the error handling case.
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
drivers/net/wireless/marvell/mwifiex/cfg80211.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
index 39ce76a..5fd5876 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
@@ -3016,6 +3016,8 @@ struct wireless_dev *mwifiex_add_virtual_intf(struct wiphy *wiphy,
priv->netdev = NULL;
memset(&priv->wdev, 0, sizeof(priv->wdev));
priv->wdev.iftype = NL80211_IFTYPE_UNSPECIFIED;
+ destroy_workqueue(priv->dfs_cac_workqueue);
+ priv->dfs_cac_workqueue = NULL;
return ERR_PTR(-ENOMEM);
}
^ permalink raw reply related
* Re: ath10k stuck on 6Mbps and spam syslog
From: Ben Greear @ 2016-09-29 14:47 UTC (permalink / raw)
To: Matteo Grandi, LinuxWireless Mailing List
In-Reply-To: <CAHdg3xa-mJpxZiDHC0NbaZT1PwnhnCbs2zjZiQbKdSCpHepcSw@mail.gmail.com>
stock ath10k firmware does not report tx-rate so the kernel always sees 6Mbps.
I don't know about the splat..maybe post the function
that is causing that?
/home/matteo/linux-imx6/backports4.4.2-i2CAT/net/mac80211/util.c:2621
Thanks,
Ben
On 09/29/2016 06:39 AM, Matteo Grandi wrote:
> Hello all,
>
> I'm struggling with a problem related on ath10k drivers:
> I'm using a Compex WLE600V5-27 (802.11ac) miniPCIe card for some HT
> tests needed for my thesis.
> I'm using ath10k drivers for this card, and backports-4.4.2, in
> particular the firmware-5.bin_10.2.4.70.54 because it seem to be the
> more recent.
> I've connected in mesh mode the WLE600V5 card with an 802.11n card
> (using ath9k drivers) but looking at the station dump, the tx bitrate
> is stuck on 6.0 Mbit/s for the ath10k. The ath9k one works well and
> watch -n1 iw <interfacename> station dump
> let me see changes of the tx rate and MCS on the ath9k during iperf
> tests, but the ath10k stucks on 6.0 Mbit/s.
>
> Then something misterious (for me) happen while the channel
> assignment: the syslog is spammed by this message:
>
> [17554.919459] ------------[ cut here ]------------
> [17554.919839] WARNING: CPU: 0 PID: 0 at
> /home/matteo/linux-imx6/backports4.4.2-i2CAT/net/mac80211/util.c:2621
> ieee80211_calculate_rx_timestamp+0x204/0x278 [mac80211]()
> [17554.919855] Modules linked in: arc4 sky2 ath10k_pci(O)
> ath10k_core(O) ath(O) mac80211(O) cfg80211(O) compat(O)
> [17554.919926] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W O
> 3.14.48-g408ccb9 #4
> [17554.919990] [<80015050>] (unwind_backtrace) from [<80011330>]
> (show_stack+0x10/0x14)
> [17554.920038] [<80011330>] (show_stack) from [<806537dc>]
> (dump_stack+0x80/0x90)
> [17554.920074] [<806537dc>] (dump_stack) from [<8002c578>]
> (warn_slowpath_common+0x6c/0x88)
> [17554.920103] [<8002c578>] (warn_slowpath_common) from [<8002c630>]
> (warn_slowpath_null+0x1c/0x24)
> [17554.920377] [<8002c630>] (warn_slowpath_null) from [<7f089c74>]
> (ieee80211_calculate_rx_timestamp+0x204/0x278 [mac80211])
> [17554.920826] [<7f089c74>] (ieee80211_calculate_rx_timestamp
> [mac80211]) from [<7f07d724>] (ieee80211_rx_napi+0xcc/0x8d4
> [mac80211])
> [17554.921259] [<7f07d724>] (ieee80211_rx_napi [mac80211]) from
> [<7f117fd0>] (ath10k_wmi_event_mgmt_rx+0x1f4/0x35c [ath10k_core])
> [17554.921540] [<7f117fd0>] (ath10k_wmi_event_mgmt_rx [ath10k_core])
> from [<7f10d844>] (ath10k_htc_rx_completion_handler+0x1cc/0x464
> [ath10k_core])
> [17554.921706] [<7f10d844>] (ath10k_htc_rx_completion_handler
> [ath10k_core]) from [<7f157b4c>] (ath10k_pci_process_rx_cb+0x1ac/0x1fc
> [ath10k_pci])
> [17554.921773] [<7f157b4c>] (ath10k_pci_process_rx_cb [ath10k_pci])
> from [<7f15b3ac>] (ath10k_ce_per_engine_service+0x5c/0x94
> [ath10k_pci])
> [17554.921835] [<7f15b3ac>] (ath10k_ce_per_engine_service
> [ath10k_pci]) from [<7f15b464>]
> (ath10k_ce_per_engine_service_any+0x80/0x88 [ath10k_pci])
> [17554.921892] [<7f15b464>] (ath10k_ce_per_engine_service_any
> [ath10k_pci]) from [<7f15a6d8>] (ath10k_pci_tasklet+0x24/0x5c
> [ath10k_pci])
> [17554.921946] [<7f15a6d8>] (ath10k_pci_tasklet [ath10k_pci]) from
> [<800304c8>] (tasklet_action+0x80/0x110)
> [17554.921979] [<800304c8>] (tasklet_action) from [<800306b8>]
> (__do_softirq+0x10c/0x248)
> [17554.922009] [<800306b8>] (__do_softirq) from [<80030a6c>]
> (irq_exit+0xac/0xf4)
> [17554.922042] [<80030a6c>] (irq_exit) from [<8000e904>] (handle_IRQ+0x44/0x90)
> [17554.922072] [<8000e904>] (handle_IRQ) from [<800084f8>]
> (gic_handle_irq+0x2c/0x5c)
> [17554.922105] [<800084f8>] (gic_handle_irq) from [<80011e00>]
> (__irq_svc+0x40/0x50)
> [17554.922122] Exception stack(0x80917f18 to 0x80917f60)
> [17554.922141] 7f00:
> 80917f60 000d3334
> [17554.922166] 7f20: 5221e106 00000ff7 4d693c44 00000ff7 a7705010
> 80924060 00000001 a7705014
> [17554.922190] 7f40: 8096243d 80916000 00000017 80917f60 a6aaaaab
> 80492940 60000013 ffffffff
> [17554.922224] [<80011e00>] (__irq_svc) from [<80492940>]
> (cpuidle_enter_state+0x50/0xe0)
> [17554.922252] [<80492940>] (cpuidle_enter_state) from [<80492ac8>]
> (cpuidle_idle_call+0xf8/0x148)
> [17554.922281] [<80492ac8>] (cpuidle_idle_call) from [<8000ec48>]
> (arch_cpu_idle+0x8/0x44)
> [17554.922322] [<8000ec48>] (arch_cpu_idle) from [<80066648>]
> (cpu_startup_entry+0xfc/0x140)
> [17554.922362] [<80066648>] (cpu_startup_entry) from [<808c5b08>]
> (start_kernel+0x360/0x36c)
> [17554.922379] ---[ end trace 87d4775146813aed ]---
> [17555.943454] ------------[ cut here ]------------
>
> that repeat continuously...
> Forcing legacy bitrates doesn't change the situation.
>
> I made some measurements using iperf, please find it in attachment.
>
> Other info:
>
> root@Yazi:~# modinfo ath10k_pci
> filename:
> /lib/modules/3.14.48-g408ccb9/kernel/drivers/net/wireless/ath/ath10k/ath10k_pci.ko
> firmware: ath10k/QCA9377/hw1.0/board.bin
> firmware: ath10k/QCA9377/hw1.0/firmware-5.bin
> firmware: ath10k/QCA6174/hw3.0/board-2.bin
> firmware: ath10k/QCA6174/hw3.0/board.bin
> firmware: ath10k/QCA6174/hw3.0/firmware-5.bin
> firmware: ath10k/QCA6174/hw3.0/firmware-4.bin
> firmware: ath10k/QCA6174/hw2.1/board-2.bin
> firmware: ath10k/QCA6174/hw2.1/board.bin
> firmware: ath10k/QCA6174/hw2.1/firmware-5.bin
> firmware: ath10k/QCA6174/hw2.1/firmware-4.bin
> firmware: ath10k/QCA988X/hw2.0/board-2.bin
> firmware: ath10k/QCA988X/hw2.0/board.bin
> firmware: ath10k/QCA988X/hw2.0/firmware-5.bin
> firmware: ath10k/QCA988X/hw2.0/firmware-4.bin
> firmware: ath10k/QCA988X/hw2.0/firmware-3.bin
> firmware: ath10k/QCA988X/hw2.0/firmware-2.bin
> firmware: ath10k/QCA988X/hw2.0/firmware.bin
> license: Dual BSD/GPL
> description: Driver support for Atheros QCA988X PCIe devices
> author: Qualcomm Atheros
> version: backported from Linux (v4.4.2-0-g1cb8570) using
> backports v4.4.2-1-0-gbec4037
> srcversion: EBB3D4E36DE49B7EC8057D0
> alias: pci:v0000168Cd00000042sv*sd*bc*sc*i*
> alias: pci:v0000168Cd00000040sv*sd*bc*sc*i*
> alias: pci:v0000168Cd0000003Esv*sd*bc*sc*i*
> alias: pci:v0000168Cd00000041sv*sd*bc*sc*i*
> alias: pci:v0000168Cd0000003Csv*sd*bc*sc*i*
> depends: ath10k_core,compat
> vermagic: 3.14.48-g408ccb9 SMP mod_unload modversions ARMv7 p2v8
> parm: irq_mode:0: auto, 1: legacy, 2: msi (default: 0) (uint)
> parm: reset_mode:0: auto, 1: warm only (default: 0) (uint)
>
> I don't know if it's only a problem of iw station dump that can't show
> the tx rate, but the spammed syslog honestly warn me...
>
> How shall I check what's wrong and see the HT work?
>
> Thanks a lot!
>
> Matteo
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* RE: [PATCH] mwifiex: parse device tree node for PCIe
From: Amitkumar Karwar @ 2016-09-29 13:58 UTC (permalink / raw)
To: Rob Herring
Cc: linux-wireless@vger.kernel.org, Cathy Luo, Nishant Sarmukadam,
devicetree@vger.kernel.org, Wei-Ning Huang, Xinming Hu
In-Reply-To: <20160919212753.GA16598@rob-hp-laptop>
Hi Rob,
> From: Rob Herring [mailto:robh@kernel.org]
> Sent: Tuesday, September 20, 2016 2:58 AM
> To: Amitkumar Karwar
> Cc: linux-wireless@vger.kernel.org; Cathy Luo; Nishant Sarmukadam;
> devicetree@vger.kernel.org; Wei-Ning Huang; Xinming Hu
> Subject: Re: [PATCH] mwifiex: parse device tree node for PCIe
>
> On Fri, Sep 09, 2016 at 08:47:34PM +0530, Amitkumar Karwar wrote:
> > From: Xinming Hu <huxm@marvell.com>
> >
> > This patch derives device tree node from pcie bus layer framework.
> > Device tree bindings file has been renamed(marvell-sd8xxx.txt ->
> > marvell-8xxx.txt) to accomodate PCIe changes.
> >
> > Signed-off-by: Xinming Hu <huxm@marvell.com>
> > Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
> > ---
> > .../bindings/net/wireless/marvell-8xxx.txt | 64
> ++++++++++++++++++++++
> > .../bindings/net/wireless/marvell-sd8xxx.txt | 63 -------------
> --------
>
> Resend using -M option so I do have to figure out if you added 1 line or
> changed a bunch.
>
> > drivers/net/wireless/marvell/mwifiex/pcie.c | 19 +++++++
> > drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 3 +-
> > 4 files changed, 85 insertions(+), 64 deletions(-) create mode
> > 100644 Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
> > delete mode 100644
> > Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
> >
> > diff --git
> > a/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
> > b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
> > new file mode 100644
> > index 0000000..a8a95aa
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
> > @@ -0,0 +1,64 @@
> > +Marvell 8897/8997 (sd8897/sd8997/pcie8997) SDIO/PCIE devices
> > +------
> > +
> > +This node provides properties for controlling the marvell sdio/pcie
> wireless device.
> > +The node is expected to be specified as a child node to the SDIO/PCIE
> > +controller that connects the device to the system.
> > +
> > +Required properties:
> > +
> > + - compatible : should be one of the following:
> > + * "marvell,sd8897"
> > + * "marvell,sd8997"
> > + * "marvell,pcie8997"
>
> PCIe uses vendor and product IDs for compatible strings. Please read the
> OF PCI bus bindings doc.
>
Thanks for review. I have submitted updated version(V3) with this change.
Regards,
Amitkumar Karwar
^ permalink raw reply
* [PATCH v3] mwifiex: parse device tree node for PCIe
From: Amitkumar Karwar @ 2016-09-29 13:56 UTC (permalink / raw)
To: linux-wireless; +Cc: rajatja, Xinming Hu, Amitkumar Karwar
From: Xinming Hu <huxm@marvell.com>
This patch derives device tree node from pcie bus layer framework.
Device tree bindings file has been renamed(marvell-sd8xxx.txt ->
marvell-8xxx.txt) to accomodate PCIe changes.
Signed-off-by: Xinming Hu <huxm@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
v2: Included vendor and product IDs in compatible strings for PCIe
chipsets(Rob Herring)
v3: Patch is created using -M option so that it will only include diff of
original and renamed files(Rob Herring)
---
.../{marvell-sd8xxx.txt => marvell-8xxx.txt} | 8 +++++---
drivers/net/wireless/marvell/mwifiex/pcie.c | 20 ++++++++++++++++++++
drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 3 ++-
3 files changed, 27 insertions(+), 4 deletions(-)
rename Documentation/devicetree/bindings/net/wireless/{marvell-sd8xxx.txt => marvell-8xxx.txt} (91%)
diff --git a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
similarity index 91%
rename from Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
rename to Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
index c421aba..dfe5f8e 100644
--- a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
+++ b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
@@ -1,8 +1,8 @@
-Marvell 8897/8997 (sd8897/sd8997) SDIO devices
+Marvell 8897/8997 (sd8897/sd8997/pcie8997) SDIO/PCIE devices
------
-This node provides properties for controlling the marvell sdio wireless device.
-The node is expected to be specified as a child node to the SDIO controller that
+This node provides properties for controlling the marvell sdio/pcie wireless device.
+The node is expected to be specified as a child node to the SDIO/PCIE controller that
connects the device to the system.
Required properties:
@@ -10,6 +10,8 @@ Required properties:
- compatible : should be one of the following:
* "marvell,sd8897"
* "marvell,sd8997"
+ * "pci11ab,2b42"
+ * "pci1b4b,2b42"
Optional properties:
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c
index 063c707..f1eeb73 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -37,6 +37,23 @@ static struct mwifiex_if_ops pcie_ops;
static struct semaphore add_remove_card_sem;
+static const struct of_device_id mwifiex_pcie_of_match_table[] = {
+ { .compatible = "pci11ab,2b42" },
+ { .compatible = "pci1b4b,2b42" },
+ { }
+};
+
+static int mwifiex_pcie_probe_of(struct device *dev)
+{
+ if (!dev->of_node ||
+ !of_match_node(mwifiex_pcie_of_match_table, dev->of_node)) {
+ pr_err("pcie device node not available");
+ return -1;
+ }
+
+ return 0;
+}
+
static int
mwifiex_map_pci_memory(struct mwifiex_adapter *adapter, struct sk_buff *skb,
size_t size, int flags)
@@ -206,6 +223,9 @@ static int mwifiex_pcie_probe(struct pci_dev *pdev,
card->pcie.can_ext_scan = data->can_ext_scan;
}
+ /* device tree node parsing and platform specific configuration*/
+ mwifiex_pcie_probe_of(&pdev->dev);
+
if (mwifiex_add_card(card, &add_remove_card_sem, &pcie_ops,
MWIFIEX_PCIE)) {
pr_err("%s failed\n", __func__);
diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
index 638d30a..f2a7a13 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
@@ -2218,7 +2218,8 @@ int mwifiex_sta_init_cmd(struct mwifiex_private *priv, u8 first_sta, bool init)
* The cal-data can be read from device tree and/or
* a configuration file and downloaded to firmware.
*/
- if (priv->adapter->iface_type == MWIFIEX_SDIO &&
+ if ((priv->adapter->iface_type == MWIFIEX_SDIO ||
+ priv->adapter->iface_type == MWIFIEX_PCIE) &&
adapter->dev->of_node) {
adapter->dt_node = adapter->dev->of_node;
if (of_property_read_u32(adapter->dt_node,
--
1.9.1
^ permalink raw reply related
* Re: [v2] rt2x00: add support for mac addr from device tree
From: Kalle Valo @ 2016-09-29 13:51 UTC (permalink / raw)
To: Mathias Kresin; +Cc: linux-wireless
In-Reply-To: <87shskwaxh.fsf@kamboji.qca.qualcomm.com>
Kalle Valo <kvalo@codeaurora.org> writes:
>> was it intentional not to CC the linux-wireless list?
>
> No, that was a bug in my script. Thanks for noticing it! Please always
> report back if my script does something strange.
The bug is now fixed, it was just a matter of a loop being in wrong
indentation level. Python is awesome but sometimes I just hate it...
Let me know if the problem still happens. And thanks again for pointing
this out.
--
Kalle Valo
^ permalink raw reply
* ath10k stuck on 6Mbps and spam syslog
From: Matteo Grandi @ 2016-09-29 13:39 UTC (permalink / raw)
To: LinuxWireless Mailing List
[-- Attachment #1: Type: text/plain, Size: 6185 bytes --]
Hello all,
I'm struggling with a problem related on ath10k drivers:
I'm using a Compex WLE600V5-27 (802.11ac) miniPCIe card for some HT
tests needed for my thesis.
I'm using ath10k drivers for this card, and backports-4.4.2, in
particular the firmware-5.bin_10.2.4.70.54 because it seem to be the
more recent.
I've connected in mesh mode the WLE600V5 card with an 802.11n card
(using ath9k drivers) but looking at the station dump, the tx bitrate
is stuck on 6.0 Mbit/s for the ath10k. The ath9k one works well and
watch -n1 iw <interfacename> station dump
let me see changes of the tx rate and MCS on the ath9k during iperf
tests, but the ath10k stucks on 6.0 Mbit/s.
Then something misterious (for me) happen while the channel
assignment: the syslog is spammed by this message:
[17554.919459] ------------[ cut here ]------------
[17554.919839] WARNING: CPU: 0 PID: 0 at
/home/matteo/linux-imx6/backports4.4.2-i2CAT/net/mac80211/util.c:2621
ieee80211_calculate_rx_timestamp+0x204/0x278 [mac80211]()
[17554.919855] Modules linked in: arc4 sky2 ath10k_pci(O)
ath10k_core(O) ath(O) mac80211(O) cfg80211(O) compat(O)
[17554.919926] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W O
3.14.48-g408ccb9 #4
[17554.919990] [<80015050>] (unwind_backtrace) from [<80011330>]
(show_stack+0x10/0x14)
[17554.920038] [<80011330>] (show_stack) from [<806537dc>]
(dump_stack+0x80/0x90)
[17554.920074] [<806537dc>] (dump_stack) from [<8002c578>]
(warn_slowpath_common+0x6c/0x88)
[17554.920103] [<8002c578>] (warn_slowpath_common) from [<8002c630>]
(warn_slowpath_null+0x1c/0x24)
[17554.920377] [<8002c630>] (warn_slowpath_null) from [<7f089c74>]
(ieee80211_calculate_rx_timestamp+0x204/0x278 [mac80211])
[17554.920826] [<7f089c74>] (ieee80211_calculate_rx_timestamp
[mac80211]) from [<7f07d724>] (ieee80211_rx_napi+0xcc/0x8d4
[mac80211])
[17554.921259] [<7f07d724>] (ieee80211_rx_napi [mac80211]) from
[<7f117fd0>] (ath10k_wmi_event_mgmt_rx+0x1f4/0x35c [ath10k_core])
[17554.921540] [<7f117fd0>] (ath10k_wmi_event_mgmt_rx [ath10k_core])
from [<7f10d844>] (ath10k_htc_rx_completion_handler+0x1cc/0x464
[ath10k_core])
[17554.921706] [<7f10d844>] (ath10k_htc_rx_completion_handler
[ath10k_core]) from [<7f157b4c>] (ath10k_pci_process_rx_cb+0x1ac/0x1fc
[ath10k_pci])
[17554.921773] [<7f157b4c>] (ath10k_pci_process_rx_cb [ath10k_pci])
from [<7f15b3ac>] (ath10k_ce_per_engine_service+0x5c/0x94
[ath10k_pci])
[17554.921835] [<7f15b3ac>] (ath10k_ce_per_engine_service
[ath10k_pci]) from [<7f15b464>]
(ath10k_ce_per_engine_service_any+0x80/0x88 [ath10k_pci])
[17554.921892] [<7f15b464>] (ath10k_ce_per_engine_service_any
[ath10k_pci]) from [<7f15a6d8>] (ath10k_pci_tasklet+0x24/0x5c
[ath10k_pci])
[17554.921946] [<7f15a6d8>] (ath10k_pci_tasklet [ath10k_pci]) from
[<800304c8>] (tasklet_action+0x80/0x110)
[17554.921979] [<800304c8>] (tasklet_action) from [<800306b8>]
(__do_softirq+0x10c/0x248)
[17554.922009] [<800306b8>] (__do_softirq) from [<80030a6c>]
(irq_exit+0xac/0xf4)
[17554.922042] [<80030a6c>] (irq_exit) from [<8000e904>] (handle_IRQ+0x44/0x90)
[17554.922072] [<8000e904>] (handle_IRQ) from [<800084f8>]
(gic_handle_irq+0x2c/0x5c)
[17554.922105] [<800084f8>] (gic_handle_irq) from [<80011e00>]
(__irq_svc+0x40/0x50)
[17554.922122] Exception stack(0x80917f18 to 0x80917f60)
[17554.922141] 7f00:
80917f60 000d3334
[17554.922166] 7f20: 5221e106 00000ff7 4d693c44 00000ff7 a7705010
80924060 00000001 a7705014
[17554.922190] 7f40: 8096243d 80916000 00000017 80917f60 a6aaaaab
80492940 60000013 ffffffff
[17554.922224] [<80011e00>] (__irq_svc) from [<80492940>]
(cpuidle_enter_state+0x50/0xe0)
[17554.922252] [<80492940>] (cpuidle_enter_state) from [<80492ac8>]
(cpuidle_idle_call+0xf8/0x148)
[17554.922281] [<80492ac8>] (cpuidle_idle_call) from [<8000ec48>]
(arch_cpu_idle+0x8/0x44)
[17554.922322] [<8000ec48>] (arch_cpu_idle) from [<80066648>]
(cpu_startup_entry+0xfc/0x140)
[17554.922362] [<80066648>] (cpu_startup_entry) from [<808c5b08>]
(start_kernel+0x360/0x36c)
[17554.922379] ---[ end trace 87d4775146813aed ]---
[17555.943454] ------------[ cut here ]------------
that repeat continuously...
Forcing legacy bitrates doesn't change the situation.
I made some measurements using iperf, please find it in attachment.
Other info:
root@Yazi:~# modinfo ath10k_pci
filename:
/lib/modules/3.14.48-g408ccb9/kernel/drivers/net/wireless/ath/ath10k/ath10k_pci.ko
firmware: ath10k/QCA9377/hw1.0/board.bin
firmware: ath10k/QCA9377/hw1.0/firmware-5.bin
firmware: ath10k/QCA6174/hw3.0/board-2.bin
firmware: ath10k/QCA6174/hw3.0/board.bin
firmware: ath10k/QCA6174/hw3.0/firmware-5.bin
firmware: ath10k/QCA6174/hw3.0/firmware-4.bin
firmware: ath10k/QCA6174/hw2.1/board-2.bin
firmware: ath10k/QCA6174/hw2.1/board.bin
firmware: ath10k/QCA6174/hw2.1/firmware-5.bin
firmware: ath10k/QCA6174/hw2.1/firmware-4.bin
firmware: ath10k/QCA988X/hw2.0/board-2.bin
firmware: ath10k/QCA988X/hw2.0/board.bin
firmware: ath10k/QCA988X/hw2.0/firmware-5.bin
firmware: ath10k/QCA988X/hw2.0/firmware-4.bin
firmware: ath10k/QCA988X/hw2.0/firmware-3.bin
firmware: ath10k/QCA988X/hw2.0/firmware-2.bin
firmware: ath10k/QCA988X/hw2.0/firmware.bin
license: Dual BSD/GPL
description: Driver support for Atheros QCA988X PCIe devices
author: Qualcomm Atheros
version: backported from Linux (v4.4.2-0-g1cb8570) using
backports v4.4.2-1-0-gbec4037
srcversion: EBB3D4E36DE49B7EC8057D0
alias: pci:v0000168Cd00000042sv*sd*bc*sc*i*
alias: pci:v0000168Cd00000040sv*sd*bc*sc*i*
alias: pci:v0000168Cd0000003Esv*sd*bc*sc*i*
alias: pci:v0000168Cd00000041sv*sd*bc*sc*i*
alias: pci:v0000168Cd0000003Csv*sd*bc*sc*i*
depends: ath10k_core,compat
vermagic: 3.14.48-g408ccb9 SMP mod_unload modversions ARMv7 p2v8
parm: irq_mode:0: auto, 1: legacy, 2: msi (default: 0) (uint)
parm: reset_mode:0: auto, 1: warm only (default: 0) (uint)
I don't know if it's only a problem of iw station dump that can't show
the tx rate, but the spammed syslog honestly warn me...
How shall I check what's wrong and see the HT work?
Thanks a lot!
Matteo
[-- Attachment #2: ath10kIssue.txt --]
[-- Type: text/plain, Size: 16132 bytes --]
+++++++++++++++++++
#CONFIGUTRATION#
+++++++++++++++++++
##### HOST YAZI 192.168.149.87 with ath10k #####
root@Yazi:~# iw dev wlan1 interface add mp1 type mp
root@Yazi:~# iw dev mp1 set channel 149 HT40+
root@Yazi:~# ifconfig mp1 192.168.149.87
root@Yazi:~# iw dev mp1 mesh join m149h
root@Yazi:~# iw mp1 station dump
Station 04:f0:21:0a:61:eb (on mp1)
inactive time: 870 ms
rx bytes: 4635
rx packets: 75
tx bytes: 302
tx packets: 3
tx retries: 0
tx failed: 0
signal: -66 dBm
signal avg: -68 dBm
tx bitrate: 6.0 MBit/s
mesh llid: 33894
mesh plid: 35428
mesh plink: ESTAB
authorized: yes
authenticated: yes
preamble: long
WMM/WME: yes
MFP: no
TDLS peer: no
#### HOST GATEWORKS 192.168.149.54 with ath9k ####
root@gateworks:~# iw dev wlan0 interface add mp0 type mp
root@gateworks:~# iw dev mp0 set channel 149 HT40+
root@gateworks:~# ifconfig mp0 192.168.149.54
root@gateworks:~# iw dev mp0 mesh join m149h
root@gateworks:~# iw mp0 station dump
Station 04:f0:21:15:ac:77 (on mp0)
inactive time: 1000 ms
rx bytes: 1709
rx packets: 22
tx bytes: 260
tx packets: 3
tx retries: 23
tx failed: 3
signal: -80 dBm
signal avg: -77 dBm
tx bitrate: 19.5 MBit/s MCS 2
mesh llid: 35428
mesh plid: 33894
mesh plink: ESTAB
authorized: yes
authenticated: yes
preamble: long
WMM/WME: yes
MFP: no
TDLS peer: no
###CAPTURE BROADCAST POLL MESSAGES -> file BroadcastPoll149###
++++++++++++++++++++++++++++++++++
###IPERF WITHOUT ANY HT OPTOPNS###
++++++++++++++++++++++++++++++++++
###DELETED BOTH INTERFACES AND CREATED NEW TWO WITHOUT THE HT40+ OPTION###
Used wlan1 instead wlan0 on the host Gateworks
Iperf+Capture
.87 client
.54 server
file Iperf149_3
.54 change its bitrates from 6 to 18, .87 stuck on 6
#On .54 (server)
Server listening on UDP port 5001
Receiving 1470 byte datagrams
UDP buffer size: 160 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.149.54 port 5001 connected with 192.168.149.87 port 53471
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 3] 0.0-10.0 sec 17.9 MBytes 14.9 Mbits/sec 0.193 ms 3/12762 (0.024%)
[ 3] 0.0-10.0 sec 4 datagrams received out-of-order
#On .87 (client)
Client connecting to 192.168.149.54, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size: 160 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.149.87 port 53471 connected with 192.168.149.54 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 17.9 MBytes 15.0 Mbits/sec
[ 3] Sent 12763 datagrams
[ 3] Server Report:
[ 3] 0.0-10.0 sec 17.9 MBytes 14.9 Mbits/sec 0.192 ms 3/12762 (0.024%)
[ 3] 0.0-10.0 sec 4 datagrams received out-of-order
++++++++++++++++++++++++++++++++++++++++++++++++++++++
.87 Server
.54 Client
file Iperf149_4
.54 change its bitrates from 6 to 18 and then 36, .87 stuck on 6
#On .87 (Server)
Server listening on UDP port 5001
Receiving 1470 byte datagrams
UDP buffer size: 160 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.149.87 port 5001 connected with 192.168.149.54 port 52418
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 3] 0.0-10.0 sec 16.4 MBytes 13.7 Mbits/sec 2.684 ms 6/11686 (0.051%)
[ 3] 0.0-10.0 sec 7 datagrams received out-of-order
#On .54 (Client)
------------------------------------------------------------
Client connecting to 192.168.149.87, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size: 160 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.149.54 port 52418 connected with 192.168.149.87 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 16.4 MBytes 13.7 Mbits/sec
[ 3] Sent 11687 datagrams
[ 3] Server Report:
[ 3] 0.0-10.0 sec 16.4 MBytes 13.7 Mbits/sec 2.683 ms 6/11686 (0.051%)
[ 3] 0.0-10.0 sec 7 datagrams received out-of-order
++++++++++++++++++++++++++++++++++
###IPERF WITH HT20 OPTOPNS###
++++++++++++++++++++++++++++++++++
###DELETED AND REBUILTED TWO INTERFACES WITH HT20 OPTION###
in iw <interfacename> station dump .54 shows the bitrates with the MCS,
.87 doesn't do the same, and bitrate is always 6Mbps
Again Iperf with capture
.54 Server
.87 Client
file Iperf149_5
.54 changes its bitrates in 19.5, 13 and 65MCS7
.87 stuck on 6Mbps
#On .54 (Server)
Server listening on UDP port 5001
Receiving 1470 byte datagrams
UDP buffer size: 160 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.149.54 port 5001 connected with 192.168.149.87 port 58654
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 3] 0.0- 9.9 sec 23.7 MBytes 20.2 Mbits/sec 0.433 ms 0/16936 (0%)
[ 3] 0.0- 9.9 sec 1 datagrams received out-of-order
#On .87 (Client)
Client connecting to 192.168.149.54, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size: 160 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.149.87 port 58654 connected with 192.168.149.54 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 23.7 MBytes 19.9 Mbits/sec
[ 3] Sent 16937 datagrams
[ 3] Server Report:
[ 3] 0.0- 9.9 sec 23.7 MBytes 20.2 Mbits/sec 0.433 ms 0/16936 (0%)
[ 3] 0.0- 9.9 sec 1 datagrams received out-of-order
++++++++++++++++++++++++++++++++++++++++++++++++++
.87 Server
.54 Client
file Iperf149_6
.54 changes bitrates 26MCS3, 65 MCS7
.87 6Mbps
#On .87 (Server)
[ 4] local 192.168.149.87 port 5001 connected with 192.168.149.54 port 37926
[ 4] 0.0-10.1 sec 14.8 MBytes 12.3 Mbits/sec 4.649 ms 723/11288 (6.4%)
[ 4] 0.0-10.1 sec 4 datagrams received out-of-order
#On .54 (Client)
Client connecting to 192.168.149.87, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size: 160 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.149.54 port 37926 connected with 192.168.149.87 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 15.8 MBytes 13.3 Mbits/sec
[ 3] Sent 11289 datagrams
[ 3] Server Report:
[ 3] 0.0-10.1 sec 14.8 MBytes 12.3 Mbits/sec 4.649 ms 723/11288 (6.4%)
[ 3] 0.0-10.1 sec 4 datagrams received out-of-order
++++++++++++++++++++
###FORCE TEST###
++++++++++++++++++++
10 secs 50M
.87 Server
.54 Client
file Iperf149_7
#On .87 (Server)
[ 3] local 192.168.149.87 port 5001 connected with 192.168.149.54 port 48708
[ 3] 0.0-10.5 sec 15.6 MBytes 12.4 Mbits/sec 32.743 ms 197/11300 (1.7%)
[ 3] 0.0-10.5 sec 6 datagrams received out-of-order
#On .54 (Client)
Client connecting to 192.168.149.87, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size: 160 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.149.54 port 48708 connected with 192.168.149.87 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.4 sec 15.8 MBytes 12.8 Mbits/sec
[ 3] Sent 11301 datagrams
[ 3] Server Report:
[ 3] 0.0-10.5 sec 15.6 MBytes 12.4 Mbits/sec 32.742 ms 197/11300 (1.7%)
[ 3] 0.0-10.5 sec 6 datagrams received out-of-order
++++++++++++++++++++++++++++++++++++++++++++
10 secs 50M
.54 Server
.87 Client
file Iperf149_8
#On .54 (Server)
[ 3] local 192.168.149.54 port 5001 connected with 192.168.149.87 port 48488
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 3] 0.0-10.0 sec 29.5 MBytes 24.7 Mbits/sec 1.435 ms 8/21055 (0.038%)
[ 3] 0.0-10.0 sec 1 datagrams received out-of-order
#On .87 (Client)
[ 3] local 192.168.149.87 port 48488 connected with 192.168.149.54 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 29.5 MBytes 24.7 Mbits/sec
[ 3] Sent 21056 datagrams
[ 3] Server Report:
[ 3] 0.0-10.0 sec 29.5 MBytes 24.7 Mbits/sec 1.434 ms 8/21055 (0.038%)
[ 3] 0.0-10.0 sec 1 datagrams received out-of-order
++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++
10 secs 100M
.54 Server
.87 Client
file Iperf149_9
#On .54 (Server)
[ 4] local 192.168.149.54 port 5001 connected with 192.168.149.87 port 52895
[ 4] 0.0-10.0 sec 40.3 MBytes 33.8 Mbits/sec 1.108 ms 26/28784 (0.09%)
[ 4] 0.0-10.0 sec 11 datagrams received out-of-order
#On .87 (Client)
[ 3] local 192.168.149.87 port 52895 connected with 192.168.149.54 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 40.4 MBytes 33.8 Mbits/sec
[ 3] Sent 28785 datagrams
[ 3] Server Report:
[ 3] 0.0-10.0 sec 40.3 MBytes 33.8 Mbits/sec 1.107 ms 26/28784 (0.09%)
[ 3] 0.0-10.0 sec 11 datagrams received out-of-order
+++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++++++++
10 secs 150M
.54 Server
.87 Client
file Iperf149_10
#On .54 (Server)
[ 3] local 192.168.149.54 port 5001 connected with 192.168.149.87 port 43174
[ 3] 0.0-10.0 sec 40.6 MBytes 34.1 Mbits/sec 1.108 ms 48/29026 (0.17%)
[ 3] 0.0-10.0 sec 11 datagrams received out-of-order
#On .87 (Client)
[ 3] local 192.168.149.87 port 43174 connected with 192.168.149.54 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 40.7 MBytes 34.1 Mbits/sec
[ 3] Sent 29027 datagrams
[ 3] Server Report:
[ 3] 0.0-10.0 sec 40.6 MBytes 34.1 Mbits/sec 1.108 ms 48/29026 (0.17%)
[ 3] 0.0-10.0 sec 11 datagrams received out-of-order
34.1Mbps seems to be the max in HT20; looking the station dump .87 shows 6Mbps, .54 26MCS3
(that's ok for HT20 without the SGI), however the max nominal throughput for HT20 nonSGI
and 1 spatial stream is 65M (using a 64QAM).
.54 seems to stuch on MCS3 (watch -n<timeinterval> iw <interfacename> station dump)
+++++++++++++++++++++++++++++++++++++++++
###IPERF WITH HT40+ OPTION###
+++++++++++++++++++++++++++++++++++++++++
###DELETED AND REBUILTED TWO INTERFACES WITH HT40+ OPTION###
.54 Server
.87 Client
file Iperf149_11
#On the .87 (Client)
root@Yazi:~# iperf -c 192.168.149.54 -u -t10 -b150M
------------------------------------------------------------
Client connecting to 192.168.149.54, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size: 160 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.149.87 port 59120 connected with 192.168.149.54 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 54.2 MBytes 45.4 Mbits/sec
[ 3] Sent 38647 datagrams
[ 3] Server Report:
[ 3] 0.0- 9.9 sec 54.1 MBytes 46.0 Mbits/sec 0.887 ms 46/38646 (0.12%)
[ 3] 0.0- 9.9 sec 29 datagrams received out-of-order
root@Yazi:~# iperf -c 192.168.149.54 -u -t10 -b250M
------------------------------------------------------------
Client connecting to 192.168.149.54, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size: 160 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.149.87 port 54305 connected with 192.168.149.54 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 56.5 MBytes 47.4 Mbits/sec
[ 3] Sent 40289 datagrams
[ 3] Server Report:
[ 3] 0.0-10.0 sec 56.4 MBytes 47.3 Mbits/sec 0.659 ms 80/40288 (0.2%)
[ 3] 0.0-10.0 sec 1 datagrams received out-of-order
root@Yazi:~# iperf -c 192.168.149.54 -u -t10 -b250M
------------------------------------------------------------
Client connecting to 192.168.149.54, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size: 160 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.149.87 port 42853 connected with 192.168.149.54 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 56.3 MBytes 47.2 Mbits/sec
[ 3] Sent 40154 datagrams
[ 3] Server Report:
[ 3] 0.0-10.0 sec 56.2 MBytes 47.1 Mbits/sec 0.666 ms 81/40153 (0.2%)
[ 3] 0.0-10.0 sec 1 datagrams received out-of-order
#47.4 seems to be the limit, but .54 changes the bit rates, the MCS and even the GI
#.87 stuck on 6
+++++++++++++++++++++++++++++++++++++++++++
###Change roles with the same parameters###
.87 Server
.54 Client
[ 3] local 192.168.149.54 port 59978 connected with 192.168.149.87 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 15.4 MBytes 12.9 Mbits/sec
[ 3] Sent 11013 datagrams
[ 3] Server Report:
[ 3] 0.0-10.3 sec 13.3 MBytes 10.9 Mbits/sec 5.268 ms 1514/11012 (14%)
[ 3] 0.0-10.3 sec 19 datagrams received out-of-order
By setting the channel
iw dev <interfacename> set channel <channel> [HT20|HT40-|HT40+]
the syslog is spammed with the repetition of
[17554.919459] ------------[ cut here ]------------
[17554.919839] WARNING: CPU: 0 PID: 0 at /home/matteo/linux-imx6/backports4.4.2-i2CAT/net/mac80211/util.c:2621 ieee80211_calculate_rx_timestamp+0x204/0x278 [mac80211]()
[17554.919855] Modules linked in: arc4 sky2 ath10k_pci(O) ath10k_core(O) ath(O) mac80211(O) cfg80211(O) compat(O)
[17554.919926] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W O 3.14.48-g408ccb9 #4
[17554.919990] [<80015050>] (unwind_backtrace) from [<80011330>] (show_stack+0x10/0x14)
[17554.920038] [<80011330>] (show_stack) from [<806537dc>] (dump_stack+0x80/0x90)
[17554.920074] [<806537dc>] (dump_stack) from [<8002c578>] (warn_slowpath_common+0x6c/0x88)
[17554.920103] [<8002c578>] (warn_slowpath_common) from [<8002c630>] (warn_slowpath_null+0x1c/0x24)
[17554.920377] [<8002c630>] (warn_slowpath_null) from [<7f089c74>] (ieee80211_calculate_rx_timestamp+0x204/0x278 [mac80211])
[17554.920826] [<7f089c74>] (ieee80211_calculate_rx_timestamp [mac80211]) from [<7f07d724>] (ieee80211_rx_napi+0xcc/0x8d4 [mac80211])
[17554.921259] [<7f07d724>] (ieee80211_rx_napi [mac80211]) from [<7f117fd0>] (ath10k_wmi_event_mgmt_rx+0x1f4/0x35c [ath10k_core])
[17554.921540] [<7f117fd0>] (ath10k_wmi_event_mgmt_rx [ath10k_core]) from [<7f10d844>] (ath10k_htc_rx_completion_handler+0x1cc/0x464 [ath10k_core])
[17554.921706] [<7f10d844>] (ath10k_htc_rx_completion_handler [ath10k_core]) from [<7f157b4c>] (ath10k_pci_process_rx_cb+0x1ac/0x1fc [ath10k_pci])
[17554.921773] [<7f157b4c>] (ath10k_pci_process_rx_cb [ath10k_pci]) from [<7f15b3ac>] (ath10k_ce_per_engine_service+0x5c/0x94 [ath10k_pci])
[17554.921835] [<7f15b3ac>] (ath10k_ce_per_engine_service [ath10k_pci]) from [<7f15b464>] (ath10k_ce_per_engine_service_any+0x80/0x88 [ath10k_pci])
[17554.921892] [<7f15b464>] (ath10k_ce_per_engine_service_any [ath10k_pci]) from [<7f15a6d8>] (ath10k_pci_tasklet+0x24/0x5c [ath10k_pci])
[17554.921946] [<7f15a6d8>] (ath10k_pci_tasklet [ath10k_pci]) from [<800304c8>] (tasklet_action+0x80/0x110)
[17554.921979] [<800304c8>] (tasklet_action) from [<800306b8>] (__do_softirq+0x10c/0x248)
[17554.922009] [<800306b8>] (__do_softirq) from [<80030a6c>] (irq_exit+0xac/0xf4)
[17554.922042] [<80030a6c>] (irq_exit) from [<8000e904>] (handle_IRQ+0x44/0x90)
[17554.922072] [<8000e904>] (handle_IRQ) from [<800084f8>] (gic_handle_irq+0x2c/0x5c)
[17554.922105] [<800084f8>] (gic_handle_irq) from [<80011e00>] (__irq_svc+0x40/0x50)
[17554.922122] Exception stack(0x80917f18 to 0x80917f60)
[17554.922141] 7f00: 80917f60 000d3334
[17554.922166] 7f20: 5221e106 00000ff7 4d693c44 00000ff7 a7705010 80924060 00000001 a7705014
[17554.922190] 7f40: 8096243d 80916000 00000017 80917f60 a6aaaaab 80492940 60000013 ffffffff
[17554.922224] [<80011e00>] (__irq_svc) from [<80492940>] (cpuidle_enter_state+0x50/0xe0)
[17554.922252] [<80492940>] (cpuidle_enter_state) from [<80492ac8>] (cpuidle_idle_call+0xf8/0x148)
[17554.922281] [<80492ac8>] (cpuidle_idle_call) from [<8000ec48>] (arch_cpu_idle+0x8/0x44)
[17554.922322] [<8000ec48>] (arch_cpu_idle) from [<80066648>] (cpu_startup_entry+0xfc/0x140)
[17554.922362] [<80066648>] (cpu_startup_entry) from [<808c5b08>] (start_kernel+0x360/0x36c)
[17554.922379] ---[ end trace 87d4775146813aed ]---
[17555.943454] ------------[ cut here ]------------
As soon as the HT40+ interface is deleted , it stops
^ permalink raw reply
* [PATCH v2] mwifiex: parse device tree node for PCIe
From: Amitkumar Karwar @ 2016-09-29 13:38 UTC (permalink / raw)
To: linux-wireless
Cc: Cathy Luo, Nishant Sarmukadam, Xinming Hu, Amitkumar Karwar
From: Xinming Hu <huxm@marvell.com>
This patch derives device tree node from pcie bus layer framework.
Device tree bindings file has been renamed(marvell-sd8xxx.txt ->
marvell-8xxx.txt) to accomodate PCIe changes.
Signed-off-by: Xinming Hu <huxm@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
v2: Included vendor and product IDs in compatible strings for PCIe
chipsets(Rob Herring)
---
.../bindings/net/wireless/marvell-8xxx.txt | 65 ++++++++++++++++++++++
.../bindings/net/wireless/marvell-sd8xxx.txt | 63 ---------------------
drivers/net/wireless/marvell/mwifiex/pcie.c | 20 +++++++
drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 3 +-
4 files changed, 87 insertions(+), 64 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
delete mode 100644 Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
diff --git a/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
new file mode 100644
index 0000000..dfe5f8e
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
@@ -0,0 +1,65 @@
+Marvell 8897/8997 (sd8897/sd8997/pcie8997) SDIO/PCIE devices
+------
+
+This node provides properties for controlling the marvell sdio/pcie wireless device.
+The node is expected to be specified as a child node to the SDIO/PCIE controller that
+connects the device to the system.
+
+Required properties:
+
+ - compatible : should be one of the following:
+ * "marvell,sd8897"
+ * "marvell,sd8997"
+ * "pci11ab,2b42"
+ * "pci1b4b,2b42"
+
+Optional properties:
+
+ - marvell,caldata* : A series of properties with marvell,caldata prefix,
+ represent calibration data downloaded to the device during
+ initialization. This is an array of unsigned 8-bit values.
+ the properties should follow below property name and
+ corresponding array length:
+ "marvell,caldata-txpwrlimit-2g" (length = 566).
+ "marvell,caldata-txpwrlimit-5g-sub0" (length = 502).
+ "marvell,caldata-txpwrlimit-5g-sub1" (length = 688).
+ "marvell,caldata-txpwrlimit-5g-sub2" (length = 750).
+ "marvell,caldata-txpwrlimit-5g-sub3" (length = 502).
+ - marvell,wakeup-pin : a wakeup pin number of wifi chip which will be configured
+ to firmware. Firmware will wakeup the host using this pin
+ during suspend/resume.
+ - interrupt-parent: phandle of the parent interrupt controller
+ - interrupts : interrupt pin number to the cpu. driver will request an irq based on
+ this interrupt number. during system suspend, the irq will be enabled
+ so that the wifi chip can wakeup host platform under certain condition.
+ during system resume, the irq will be disabled to make sure
+ unnecessary interrupt is not received.
+
+Example:
+
+Tx power limit calibration data is configured in below example.
+The calibration data is an array of unsigned values, the length
+can vary between hw versions.
+IRQ pin 38 is used as system wakeup source interrupt. wakeup pin 3 is configured
+so that firmware can wakeup host using this device side pin.
+
+&mmc3 {
+ status = "okay";
+ vmmc-supply = <&wlan_en_reg>;
+ bus-width = <4>;
+ cap-power-off-card;
+ keep-power-in-suspend;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+ mwifiex: wifi@1 {
+ compatible = "marvell,sd8897";
+ reg = <1>;
+ interrupt-parent = <&pio>;
+ interrupts = <38 IRQ_TYPE_LEVEL_LOW>;
+
+ marvell,caldata_00_txpwrlimit_2g_cfg_set = /bits/ 8 <
+ 0x01 0x00 0x06 0x00 0x08 0x02 0x89 0x01>;
+ marvell,wakeup-pin = <3>;
+ };
+};
diff --git a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt b/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
deleted file mode 100644
index c421aba..0000000
--- a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
+++ /dev/null
@@ -1,63 +0,0 @@
-Marvell 8897/8997 (sd8897/sd8997) SDIO devices
-------
-
-This node provides properties for controlling the marvell sdio wireless device.
-The node is expected to be specified as a child node to the SDIO controller that
-connects the device to the system.
-
-Required properties:
-
- - compatible : should be one of the following:
- * "marvell,sd8897"
- * "marvell,sd8997"
-
-Optional properties:
-
- - marvell,caldata* : A series of properties with marvell,caldata prefix,
- represent calibration data downloaded to the device during
- initialization. This is an array of unsigned 8-bit values.
- the properties should follow below property name and
- corresponding array length:
- "marvell,caldata-txpwrlimit-2g" (length = 566).
- "marvell,caldata-txpwrlimit-5g-sub0" (length = 502).
- "marvell,caldata-txpwrlimit-5g-sub1" (length = 688).
- "marvell,caldata-txpwrlimit-5g-sub2" (length = 750).
- "marvell,caldata-txpwrlimit-5g-sub3" (length = 502).
- - marvell,wakeup-pin : a wakeup pin number of wifi chip which will be configured
- to firmware. Firmware will wakeup the host using this pin
- during suspend/resume.
- - interrupt-parent: phandle of the parent interrupt controller
- - interrupts : interrupt pin number to the cpu. driver will request an irq based on
- this interrupt number. during system suspend, the irq will be enabled
- so that the wifi chip can wakeup host platform under certain condition.
- during system resume, the irq will be disabled to make sure
- unnecessary interrupt is not received.
-
-Example:
-
-Tx power limit calibration data is configured in below example.
-The calibration data is an array of unsigned values, the length
-can vary between hw versions.
-IRQ pin 38 is used as system wakeup source interrupt. wakeup pin 3 is configured
-so that firmware can wakeup host using this device side pin.
-
-&mmc3 {
- status = "okay";
- vmmc-supply = <&wlan_en_reg>;
- bus-width = <4>;
- cap-power-off-card;
- keep-power-in-suspend;
-
- #address-cells = <1>;
- #size-cells = <0>;
- mwifiex: wifi@1 {
- compatible = "marvell,sd8897";
- reg = <1>;
- interrupt-parent = <&pio>;
- interrupts = <38 IRQ_TYPE_LEVEL_LOW>;
-
- marvell,caldata_00_txpwrlimit_2g_cfg_set = /bits/ 8 <
- 0x01 0x00 0x06 0x00 0x08 0x02 0x89 0x01>;
- marvell,wakeup-pin = <3>;
- };
-};
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c
index 063c707..f1eeb73 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -37,6 +37,23 @@ static struct mwifiex_if_ops pcie_ops;
static struct semaphore add_remove_card_sem;
+static const struct of_device_id mwifiex_pcie_of_match_table[] = {
+ { .compatible = "pci11ab,2b42" },
+ { .compatible = "pci1b4b,2b42" },
+ { }
+};
+
+static int mwifiex_pcie_probe_of(struct device *dev)
+{
+ if (!dev->of_node ||
+ !of_match_node(mwifiex_pcie_of_match_table, dev->of_node)) {
+ pr_err("pcie device node not available");
+ return -1;
+ }
+
+ return 0;
+}
+
static int
mwifiex_map_pci_memory(struct mwifiex_adapter *adapter, struct sk_buff *skb,
size_t size, int flags)
@@ -206,6 +223,9 @@ static int mwifiex_pcie_probe(struct pci_dev *pdev,
card->pcie.can_ext_scan = data->can_ext_scan;
}
+ /* device tree node parsing and platform specific configuration*/
+ mwifiex_pcie_probe_of(&pdev->dev);
+
if (mwifiex_add_card(card, &add_remove_card_sem, &pcie_ops,
MWIFIEX_PCIE)) {
pr_err("%s failed\n", __func__);
diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
index 638d30a..f2a7a13 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
@@ -2218,7 +2218,8 @@ int mwifiex_sta_init_cmd(struct mwifiex_private *priv, u8 first_sta, bool init)
* The cal-data can be read from device tree and/or
* a configuration file and downloaded to firmware.
*/
- if (priv->adapter->iface_type == MWIFIEX_SDIO &&
+ if ((priv->adapter->iface_type == MWIFIEX_SDIO ||
+ priv->adapter->iface_type == MWIFIEX_PCIE) &&
adapter->dev->of_node) {
adapter->dt_node = adapter->dev->of_node;
if (of_property_read_u32(adapter->dt_node,
--
1.9.1
^ permalink raw reply related
* [NetDev] [ANNOUNCE] Netdev 1.2 program announced
From: Hajime Tazaki @ 2016-09-29 13:35 UTC (permalink / raw)
To: netdev, netfilter-devel, linux-wireless, people, lwn
Hello,
The program of Linux netdev 1.2 is now online !
http://netdevconf.org/1.2/schedule.html
As we stated, all of registered people is now in the mailing
list, people at netdevconf.org. If you wish to communicate
with the attendees of netdev 1.2, feel free to exchange
messages.
-- Hajime
^ permalink raw reply
* Re: bcmdhd: Strange Power Save messages
From: Gucea Doru @ 2016-09-29 11:32 UTC (permalink / raw)
To: Arend van Spriel; +Cc: Andra Paraschiv, linux-wireless
In-Reply-To: <CANfLQrY6AVJoh8PW+5Ev0seKqnNRxRhK-N735q6Aa4KvdUVEcg@mail.gmail.com>
On Tue, Sep 27, 2016 at 12:03 PM, Gucea Doru <gucea.doru@gmail.com> wrote:
> What is the decision triggering the exit from the PS mode immediately
> after the ping request? I am asking this because 802.11 PS legacy
> specifies that the client should wait for a beacon with TIM set in
> order to wake up: in my case, there is no beacon between the ping
> request message and the Null frame that announces the exit from the PS
> mode.
Any help would be highly appreciated :)
IEEE Std 802.11-2012, section 10.2.1.8 specifies that "when the STA
detects that the bit corresponding to its AID is 1 i the TIM, the STA
shall issue a PS Poll". In my capture there are cases when the STA
exits the PS mode without waiting for a beacon.
Thanks!
^ permalink raw reply
* Re: rfkill guidance
From: Johannes Berg @ 2016-09-29 11:22 UTC (permalink / raw)
To: Jonathan Richardson
Cc: linux-wireless, devicetree, Marek Belisko, Mark Rutland
In-Reply-To: <fc993a0d-25cc-fb1c-3d96-86b12d1140d2@broadcom.com>
> This clarifies the issue, thanks. Basically the reason is history -
> this user space code has been around for a while. It turns out the
> HCI BT driver doesn't exist as it should. If it did, then the
> regulator could be tied to the driver. Now I see what's missing.
So like what Marcel wrote over in his email, but with regulator vs.
GPIO. Seems completely reasonable for the BT HCI driver to support
that, if you ask me.
> We will push on the team responsible for the BT drivers but all I
> need to know right now is that an rfkill driver isn't necessary.
And indeed, that would get rid of the need for anything rfkill.
> There might be some need for this but for our purpose I think the
> right path is to have a BT driver doing what this user space app is
> doing and then integrate whatever is missing with this HCI User
> Channel.
>
Sounds good to me, even if I have no idea (and don't really need to
know) what all that is :)
I'll look at killing the rfkill-regulator driver entirely though,
since, afaict, nothing uses it.
johannes
^ 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