* Re: [PATCHv4] mac80211: fix A-MSDU outer SA/DA
From: Johannes Berg @ 2016-10-13 7:23 UTC (permalink / raw)
To: Felix Fietkau, Michael Braun; +Cc: linux-wireless, projekt-wlan
In-Reply-To: <fc2ae46b-f049-41de-3eec-465e83b5ecef@nbd.name>
> > + /* h_80211_src/dst is addr* field within hdr */
> > + h_80211_src = data + fast_tx->sa_offs;
> > + h_80211_dst = data + fast_tx->da_offs;
[...]
> > + if (bssid && ieee80211_has_fromds(hdr->frame_control))
> > + memcpy(h_80211_src, bssid, ETH_ALEN);
> > +
> > + if (bssid && ieee80211_has_tods(hdr->frame_control))
> > + memcpy(h_80211_dst, bssid, ETH_ALEN);
> I think this is probably wrong for 4-addr, since there both FromDS
> and ToDS are set. Maybe you should use !ieee80211_has_tods instead of
> ieee80211_has_fromds and vice versa.
It helps to look at the spec ;-)
For 4-addr frames, dest/src are addr 3/4 respectively, and in the spec
both *should* actually be set to the BSSID.
It's kinda pointless to be doing that and using a 4-addr frame here,
but I suppose it would be expected by the receiver in 4-addr mode, so
makes some sense.
johannes
^ permalink raw reply
* Re: [PATCHv4] mac80211: fix A-MSDU outer SA/DA
From: Felix Fietkau @ 2016-10-13 7:19 UTC (permalink / raw)
To: Michael Braun, johannes; +Cc: linux-wireless, projekt-wlan
In-Reply-To: <1476337315-26845-1-git-send-email-michael-dev@fami-braun.de>
On 2016-10-13 07:41, Michael Braun wrote:
> According to IEEE 802.11-2012 section 8.3.2 table 8-19, the outer SA/DA
> of A-MSDU frames need to be changed depending on FromDS/ToDS values.
>
> Signed-off-by: Michael Braun <michael-dev@fami-braun.de>
>
> --
> v4:
> - h_80211_src/dst has been memmove'd and thus needs to be fixed
> v3:
> - write to outer 802.11 header instead of inner amsdu subframe header
> v2:
> - avoid the extra write to amsdu_hdr
> - avoid copy of asmdu_hdr into skb, use ptr instead
> ---
> net/mac80211/tx.c | 46 ++++++++++++++++++++++++++++++++++++----------
> 1 file changed, 36 insertions(+), 10 deletions(-)
>
> diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
> index 5023966..5f80b94 100644
> --- a/net/mac80211/tx.c
> +++ b/net/mac80211/tx.c
> @@ -3058,19 +3059,44 @@ static bool ieee80211_amsdu_prepare_head(struct ieee80211_sub_if_data *sdata,
> if (info->control.flags & IEEE80211_TX_CTRL_AMSDU)
> return true;
>
> - if (!ieee80211_amsdu_realloc_pad(local, skb, sizeof(amsdu_hdr),
> + if (!ieee80211_amsdu_realloc_pad(local, skb, sizeof(*amsdu_hdr),
> &subframe_len))
> return false;
>
> - amsdu_hdr.h_proto = cpu_to_be16(subframe_len);
> - memcpy(amsdu_hdr.h_source, skb->data + fast_tx->sa_offs, ETH_ALEN);
> - memcpy(amsdu_hdr.h_dest, skb->data + fast_tx->da_offs, ETH_ALEN);
> + data = skb_push(skb, sizeof(*amsdu_hdr));
> + memmove(data, data + sizeof(*amsdu_hdr), hdr_len);
> + hdr = data;
> + amsdu_hdr = data + hdr_len;
> + /* h_80211_src/dst is addr* field within hdr */
> + h_80211_src = data + fast_tx->sa_offs;
> + h_80211_dst = data + fast_tx->da_offs;
> +
> + amsdu_hdr->h_proto = cpu_to_be16(subframe_len);
> + memcpy(amsdu_hdr->h_source, h_80211_src, ETH_ALEN);
> + memcpy(amsdu_hdr->h_dest, h_80211_dst, ETH_ALEN);
> +
> + /* according to IEEE 802.11-2012 8.3.2 table 8-19, the outer SA/DA
> + * fields needs to be changed to BSSID for A-MSDU frames depending
> + * on FromDS/ToDS values.
> + */
> + switch (sdata->vif.type) {
> + case NL80211_IFTYPE_STATION:
> + bssid = sdata->u.mgd.bssid;
> + break;
> + case NL80211_IFTYPE_AP:
> + case NL80211_IFTYPE_AP_VLAN:
> + bssid = sdata->vif.addr;
> + break;
> + default:
> + bssid = NULL;
> + }
>
> - data = skb_push(skb, sizeof(amsdu_hdr));
> - memmove(data, data + sizeof(amsdu_hdr), hdr_len);
> - memcpy(data + hdr_len, &amsdu_hdr, sizeof(amsdu_hdr));
> + if (bssid && ieee80211_has_fromds(hdr->frame_control))
> + memcpy(h_80211_src, bssid, ETH_ALEN);
> +
> + if (bssid && ieee80211_has_tods(hdr->frame_control))
> + memcpy(h_80211_dst, bssid, ETH_ALEN);
I think this is probably wrong for 4-addr, since there both FromDS and
ToDS are set. Maybe you should use !ieee80211_has_tods instead of
ieee80211_has_fromds and vice versa.
- Felix
^ permalink raw reply
* Re: [PATCHv4] mac80211: fix A-MSDU outer SA/DA
From: Johannes Berg @ 2016-10-13 6:56 UTC (permalink / raw)
To: Michael Braun; +Cc: linux-wireless, projekt-wlan, Felix Fietkau
In-Reply-To: <1476337315-26845-1-git-send-email-michael-dev@fami-braun.de>
Hi,
I think this looks good now. I'd prefer, however, doing the reorg that
gets rid of the memcpy() separately, that's now more or less orthogonal
to the changes you're making. I suspect it's due to you having just
edited the original, rather than starting from scratch, but I think it
makes sense to split it.
> + memcpy(amsdu_hdr->h_source, h_80211_src, ETH_ALEN);
> + memcpy(amsdu_hdr->h_dest, h_80211_dst, ETH_ALEN);
ether_addr_copy()? Alignment should be OK here.
johannes
^ permalink raw reply
* Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)
From: Johannes Berg @ 2016-10-13 6:02 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Sergey Senozhatsky, Andy Lutomirski, David S. Miller,
Linux Wireless List, Network Development,
linux-kernel@vger.kernel.org, Sergey Senozhatsky,
linux-next@vger.kernel.org, Stephen Rothwell, Herbert Xu
In-Reply-To: <CALCETrXg9-OpJx5Rqz8afyaug+0DjzxvpdbOV9q6i01=zCZbcQ@mail.gmail.com>
On Wed, 2016-10-12 at 22:39 -0700, Andy Lutomirski wrote:
> In a pinch, I have these patches sitting around:
>
> https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=x86/vmap_stack&id=0a39cfa6fbb5d5635c85253cc7d6b44b54822afd
> https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=x86/vmap_stack&id=bf8cfa200b5a01383ea39fc8ce2f32909767baa8
That truly sounds like something we'd rather avoid in the TX/RX paths
though, which should perform well.
> I don't like them, though. I think it's rather silly that we can't
> just pass virtual addresses to the crypto code.
I don't really understand it either, hence my question about the actual
crash. I'll try to reproduce it in a VM.
johannes
^ permalink raw reply
* Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)
From: Andy Lutomirski @ 2016-10-13 5:39 UTC (permalink / raw)
To: Johannes Berg
Cc: Sergey Senozhatsky, Andy Lutomirski, David S. Miller,
Linux Wireless List, Network Development,
linux-kernel@vger.kernel.org, Sergey Senozhatsky,
linux-next@vger.kernel.org, Stephen Rothwell, Herbert Xu
In-Reply-To: <1476282127.5271.30.camel@sipsolutions.net>
On Wed, Oct 12, 2016 at 7:22 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
>
>> > Can you elaborate on how exactly it kills your system?
>>
>> the last time I saw it it was a NULL deref at
>> ieee80211_aes_ccm_decrypt.
>
> Hm. I was expecting something within the crypto code would cause the
> crash, this seems strange.
>
> Anyway, I'm surely out of my depth wrt. the actual cause. Something
> like the patch below probably works around it, but it's horribly
> inefficient due to the locking and doesn't cover CMAC/GMAC either.
In a pinch, I have these patches sitting around:
https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=x86/vmap_stack&id=0a39cfa6fbb5d5635c85253cc7d6b44b54822afd
https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=x86/vmap_stack&id=bf8cfa200b5a01383ea39fc8ce2f32909767baa8
I don't like them, though. I think it's rather silly that we can't
just pass virtual addresses to the crypto code.
^ permalink raw reply
* [PATCHv4] mac80211: fix A-MSDU outer SA/DA
From: Michael Braun @ 2016-10-13 5:41 UTC (permalink / raw)
To: johannes; +Cc: Michael Braun, linux-wireless, projekt-wlan, Felix Fietkau
According to IEEE 802.11-2012 section 8.3.2 table 8-19, the outer SA/DA
of A-MSDU frames need to be changed depending on FromDS/ToDS values.
Signed-off-by: Michael Braun <michael-dev@fami-braun.de>
--
v4:
- h_80211_src/dst has been memmove'd and thus needs to be fixed
v3:
- write to outer 802.11 header instead of inner amsdu subframe header
v2:
- avoid the extra write to amsdu_hdr
- avoid copy of asmdu_hdr into skb, use ptr instead
---
net/mac80211/tx.c | 46 ++++++++++++++++++++++++++++++++++++----------
1 file changed, 36 insertions(+), 10 deletions(-)
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 5023966..5f80b94 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -3046,11 +3046,12 @@ static bool ieee80211_amsdu_prepare_head(struct ieee80211_sub_if_data *sdata,
struct ieee80211_local *local = sdata->local;
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
struct ieee80211_hdr *hdr;
- struct ethhdr amsdu_hdr;
+ struct ethhdr *amsdu_hdr;
int hdr_len = fast_tx->hdr_len - sizeof(rfc1042_header);
int subframe_len = skb->len - hdr_len;
void *data;
- u8 *qc;
+ u8 *qc, *h_80211_src, *h_80211_dst;
+ const u8 *bssid;
if (info->flags & IEEE80211_TX_CTL_RATE_CTRL_PROBE)
return false;
@@ -3058,19 +3059,44 @@ static bool ieee80211_amsdu_prepare_head(struct ieee80211_sub_if_data *sdata,
if (info->control.flags & IEEE80211_TX_CTRL_AMSDU)
return true;
- if (!ieee80211_amsdu_realloc_pad(local, skb, sizeof(amsdu_hdr),
+ if (!ieee80211_amsdu_realloc_pad(local, skb, sizeof(*amsdu_hdr),
&subframe_len))
return false;
- amsdu_hdr.h_proto = cpu_to_be16(subframe_len);
- memcpy(amsdu_hdr.h_source, skb->data + fast_tx->sa_offs, ETH_ALEN);
- memcpy(amsdu_hdr.h_dest, skb->data + fast_tx->da_offs, ETH_ALEN);
+ data = skb_push(skb, sizeof(*amsdu_hdr));
+ memmove(data, data + sizeof(*amsdu_hdr), hdr_len);
+ hdr = data;
+ amsdu_hdr = data + hdr_len;
+ /* h_80211_src/dst is addr* field within hdr */
+ h_80211_src = data + fast_tx->sa_offs;
+ h_80211_dst = data + fast_tx->da_offs;
+
+ amsdu_hdr->h_proto = cpu_to_be16(subframe_len);
+ memcpy(amsdu_hdr->h_source, h_80211_src, ETH_ALEN);
+ memcpy(amsdu_hdr->h_dest, h_80211_dst, ETH_ALEN);
+
+ /* according to IEEE 802.11-2012 8.3.2 table 8-19, the outer SA/DA
+ * fields needs to be changed to BSSID for A-MSDU frames depending
+ * on FromDS/ToDS values.
+ */
+ switch (sdata->vif.type) {
+ case NL80211_IFTYPE_STATION:
+ bssid = sdata->u.mgd.bssid;
+ break;
+ case NL80211_IFTYPE_AP:
+ case NL80211_IFTYPE_AP_VLAN:
+ bssid = sdata->vif.addr;
+ break;
+ default:
+ bssid = NULL;
+ }
- data = skb_push(skb, sizeof(amsdu_hdr));
- memmove(data, data + sizeof(amsdu_hdr), hdr_len);
- memcpy(data + hdr_len, &amsdu_hdr, sizeof(amsdu_hdr));
+ if (bssid && ieee80211_has_fromds(hdr->frame_control))
+ memcpy(h_80211_src, bssid, ETH_ALEN);
+
+ if (bssid && ieee80211_has_tods(hdr->frame_control))
+ memcpy(h_80211_dst, bssid, ETH_ALEN);
- hdr = data;
qc = ieee80211_get_qos_ctl(hdr);
*qc |= IEEE80211_QOS_CTL_A_MSDU_PRESENT;
--
2.1.4
^ permalink raw reply related
* Re: [PATCH] ath6k1: add Dell OEM SDIO I/O for the Venue 8 Pro
From: Kalle Valo @ 2016-10-13 4:50 UTC (permalink / raw)
To: Steve deRosier; +Cc: Alan, linux-wireless
In-Reply-To: <CALupW3D2dsTeixs3z+e9JC_D2D_Bd_AHquHKttCf17OhMqEFUg@mail.gmail.com>
Steve deRosier <derosier@gmail.com> writes:
> Sorry to quibble, but the subsystem label on the commit subject line
> should be "ath6kl:" it's a lower-case "L", not a one.
Heh, I missed that :) I can fix it before I commit.
>> --- a/drivers/net/wireless/ath/ath6kl/sdio.c
>> +++ b/drivers/net/wireless/ath/ath6kl/sdio.c
>> @@ -1401,6 +1401,7 @@ static const struct sdio_device_id ath6kl_sdio_devices[] = {
>> {SDIO_DEVICE(MANUFACTURER_CODE, (MANUFACTURER_ID_AR6004_BASE | 0x0))},
>> {SDIO_DEVICE(MANUFACTURER_CODE, (MANUFACTURER_ID_AR6004_BASE | 0x1))},
>> {SDIO_DEVICE(MANUFACTURER_CODE, (MANUFACTURER_ID_AR6004_BASE | 0x2))},
>> + {SDIO_DEVICE(MANUFACTURER_CODE, (MANUFACTURER_ID_AR6004_BASE | 0x18))},
>> {},
>> };
>>
>>
>
> I see nothing wrong with this if the chip does indeed identify itself
> this way. So please fix the subject and you can add:
>
> Reviewed-by: Steve deRosier <steve.derosier@lairdtech.com>
Thanks.
--
Kalle Valo
^ permalink raw reply
* Re: TCP data throughput for BCM43362
From: Jörg Krause @ 2016-10-12 22:50 UTC (permalink / raw)
To: Arend Van Spriel
Cc: brcm80211-dev-list, Brett Rudley, Franky Lin, Hante Meuleman,
linux-wireless, Franky Lin, Arend van Spriel
In-Reply-To: <CAF7Mx6pD5VZ57PHy5DSj8yLOLY4vir2JhEdEL8SB3kr91OqFsQ@mail.gmail.com>
On Thu, 2016-10-13 at 00:25 +0200, Arend Van Spriel wrote:
> Op 12 okt. 2016 23:19 schreef "Jörg Krause" <joerg.krause@embedded.ro
> cks>:
> >
> > On Wed, 2016-10-12 at 23:08 +0200, Arend Van Spriel wrote:
> > > Op 12 okt. 2016 21:30 schreef "Jörg Krause" <joerg.krause@embedde
> > > d.ro
> > > cks>:
> > > >
> > > > On Mi, 2016-10-12 at 21:08 +0200, Arend van Spriel wrote:
> > > >
> > > > [snip]
> > > >
> > > > > On 12-10-16 16:27, Jörg Krause wrote:
> > > > > >
> > > > > > It is running the iperf server. It is running in station
> > > > > > mode
> > > > > > as
> > > > > > well
> > > > > > as in AP mode, depending on the use case. The wireshark
> > > > > > dump
> > > > > > was
> > > > > > taken
> > > > > > when the bcm43362 is operating in AP mode.
> > > > > >
> > > > > > >
> > > > > > > What specs does the ARM on your custom board have?
> > > > > >
> > > > > > Which specs do you mean?
> > > > > >
> > > > > > >
> > > > > > > The trace shows that it does not do
> > > > > > > aggregation. What it does not show is whether A-MPDU was
> > > > > > > setup,
> > > > > > > ie.
> > > > > > > ADDBA message exchange. So could you create a similar
> > > > > > > capture
> > > > > > > including
> > > > > > > connection setup, ie. AUTH/ASSOC, etc.
> > > > > >
> > > > > > Yes, I can do that. Note, that I am using wpa_supplicant
> > > > > > 2.5
> > > > > > for AP
> > > > > > mode operation (not hostapd).
> > > > >
> > > > > ok. unchartered territory for me. In the beacon frame I see
> > > > >
> > > > > .... ..01 = Maximum Rx A-MPDU Length: 0x1 (16383[Bytes])
> > > > > ...1 10.. = MPDU Density: 8 [usec] (0x6)
> > > > >
> > > > > In the trace it is only ~1500 bytes so no A-MPDU.
> > > >
> > > > The issue is not only valid for operating the BCM43362 in AP
> > > > mode,
> > > > but
> > > > also in station mode. The TCP throughput is the same for both
> > > > modes.
> > > >
> > > > > What device is in the notebook?
> > > >
> > > > It is a Broadcom 43225. However, the low TCP throughput is not
> > > > specific
> > > > to this device but with all kind of devices including
> > > > Smartphones,
> > > > Notebooks, PCs running the iperf client.
> > > >
> > > > > Can you use 'iw list' there to obtain info.
> > > >
> > > > $ iw list
> > > > Wiphy phy0
> > > > max # scan SSIDs: 4
> > > > max scan IEs length: 2257 bytes
> > > > max # sched scan SSIDs: 0
> > > > max # match sets: 0
> > > > max # scan plans: 1
> > > > max scan plan interval: -1
> > > > max scan plan iterations: 0
> > > > Retry short limit: 7
> > > > Retry long limit: 4
> > > > Coverage class: 0 (up to 0m)
> > > > Device supports RSN-IBSS.
> > > > Supported Ciphers:
> > > > * WEP40 (00-0f-ac:1)
> > > > * WEP104 (00-0f-ac:5)
> > > > * TKIP (00-0f-ac:2)
> > > > * CCMP (00-0f-ac:4)
> > > > * 00-0f-ac:10
> > > > * GCMP (00-0f-ac:8)
> > > > * 00-0f-ac:9
> > > > Available Antennas: TX 0 RX 0
> > > > Supported interface modes:
> > > > * IBSS
> > > > * managed
> > > > * AP
> > > > * AP/VLAN
> > > > * monitor
> > > > Band 1:
> > > > Capabilities: 0x70
> > > > HT20
> > > > Static SM Power Save
> > > > RX Greenfield
> > > > RX HT20 SGI
> > > > RX HT40 SGI
> > > > No RX STBC
> > > > Max AMSDU length: 3839 bytes
> > > > No DSSS/CCK HT40
> > > > Maximum RX AMPDU length 65535 bytes
> > > > (exponent:
> > > > 0x003)
> > > > Minimum RX AMPDU time spacing: 8 usec
> > > > (0x06)
> > > > HT Max RX data rate: 500 Mbps
> > > > HT TX/RX MCS rate indexes supported: 0-15
> > > > Bitrates (non-HT):
> > > > * 1.0 Mbps
> > > > * 2.0 Mbps (short preamble
> > > > supported)
> > > > * 5.5 Mbps (short preamble
> > > > supported)
> > > > * 11.0 Mbps (short preamble
> > > > supported)
> > > > * 6.0 Mbps
> > > > * 9.0 Mbps
> > > > * 12.0 Mbps
> > > > * 18.0 Mbps
> > > > * 24.0 Mbps
> > > > * 36.0 Mbps
> > > > * 48.0 Mbps
> > > > * 54.0 Mbps
> > > > Frequencies:
> > > > * 2412 MHz [1] (19.0 dBm)
> > > > * 2417 MHz [2] (19.0 dBm)
> > > > * 2422 MHz [3] (19.0 dBm)
> > > > * 2427 MHz [4] (19.0 dBm)
> > > > * 2432 MHz [5] (19.0 dBm)
> > > > * 2437 MHz [6] (19.0 dBm)
> > > > * 2442 MHz [7] (19.0 dBm)
> > > > * 2447 MHz [8] (19.0 dBm)
> > > > * 2452 MHz [9] (19.0 dBm)
> > > > * 2457 MHz [10] (19.0 dBm)
> > > > * 2462 MHz [11] (19.0 dBm)
> > > > * 2467 MHz [12] (19.0 dBm) (no IR)
> > > > * 2472 MHz [13] (19.0 dBm) (no IR)
> > > > * 2484 MHz [14] (disabled)
> > > > Supported commands:
> > > > * new_interface
> > > > * set_interface
> > > > * new_key
> > > > * start_ap
> > > > * new_station
> > > > * new_mpath
> > > > * set_mesh_config
> > > > * set_bss
> > > > * authenticate
> > > > * associate
> > > > * deauthenticate
> > > > * disassociate
> > > > * join_ibss
> > > > * join_mesh
> > > > * set_tx_bitrate_mask
> > > > * frame
> > > > * frame_wait_cancel
> > > > * set_wiphy_netns
> > > > * set_channel
> > > > * set_wds_peer
> > > > * probe_client
> > > > * set_noack_map
> > > > * register_beacons
> > > > * start_p2p_device
> > > > * set_mcast_rate
> > > > * set_qos_map
> > > > * connect
> > > > * disconnect
> > > > Supported TX frame types:
> > > > * IBSS: 0x00 0x10 0x20 0x30 0x40 0x50 0x60
> > > > 0x70 0x80
> > > > 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
> > > > * managed: 0x00 0x10 0x20 0x30 0x40 0x50
> > > > 0x60
> > > > 0x70
> > > > 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
> > > > * AP: 0x00 0x10 0x20 0x30 0x40 0x50 0x60
> > > > 0x70
> > > > 0x80
> > > > 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
> > > > * AP/VLAN: 0x00 0x10 0x20 0x30 0x40 0x50
> > > > 0x60
> > > > 0x70
> > > > 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
> > > > * mesh point: 0x00 0x10 0x20 0x30 0x40
> > > > 0x50
> > > > 0x60 0x70
> > > > 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
> > > > * P2P-client: 0x00 0x10 0x20 0x30 0x40
> > > > 0x50
> > > > 0x60 0x70
> > > > 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
> > > > * P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50
> > > > 0x60
> > > > 0x70
> > >
> > > 0x80
> > > > 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
> > > > * P2P-device: 0x00 0x10 0x20 0x30 0x40
> > > > 0x50
> > > > 0x60 0x70
> > > > 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
> > > > Supported RX frame types:
> > > > * IBSS: 0x40 0xb0 0xc0 0xd0
> > > > * managed: 0x40 0xd0
> > > > * AP: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
> > > > * AP/VLAN: 0x00 0x20 0x40 0xa0 0xb0 0xc0
> > > > 0xd0
> > > > * mesh point: 0xb0 0xc0 0xd0
> > > > * P2P-client: 0x40 0xd0
> > > > * P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0
> > > > 0xd0
> > > > * P2P-device: 0x40 0xd0
> > > > software interface modes (can always be added):
> > > > * AP/VLAN
> > > > * monitor
> > > > interface combinations are not supported
> > > > HT Capability overrides:
> > > > * MCS: ff ff ff ff ff ff ff ff ff ff
> > > > * maximum A-MSDU length
> > > > * supported channel width
> > > > * short GI for 40 MHz
> > > > * max A-MPDU length exponent
> > > > * min MPDU start spacing
> > > > Device supports TX status socket option.
> > > > Device supports HT-IBSS.
> > > > Device supports SAE with AUTHENTICATE command
> > > > Device supports low priority scan.
> > > > Device supports scan flush.
> > > > Device supports AP scan.
> > > > Device supports per-vif TX power setting
> > > > Driver supports a userspace MPM
> > > > Device supports configuring vdev MAC-addr on
> > > > create.
> > > >
> > > > > >
> > > > > > >
> > > > > > > Just to confirm. You are using the firmware from linux-
> > > > > > > firmware,
> > > > > > > right?
> > > > > >
> > > > > > Right.
> > > > > >
> > > > > > >
> > > > > > > Or are you using firmware from the wiced dev kit?
> > > > > >
> > > > > > No. I guess you mean bcmdhd?
> > > > >
> > > > > You referred to 20 Mbps claim on wiced dev kit page at mouser
> > > > > so
> > > > > I
> > > > > assumed you were using that and it includes firmware. As you
> > > > > confirmed
> > > > > using firmware from linux-firmware repo this question does
> > > > > not
> > > > > matter.
> > > >
> > > > I see! Note, that I measured >20MB throughput on the
> > > > Cubietruck,
> > > > which
> > > > is using the AP6210, but also the brcmfmac driver.
> > >
> > > So does your custom ARM board have an Ethernet socket, ie. run
> > > iperf
> > > server
> > > on another device hooked up to the AP over Ethernet.
> >
> > Yes, it does have Ethernet. I hope that I have understand you
> > correctly, so I run an iperf server an my PC and on my ARM board
> > the
> > iperf client. Both devices are connected via Ethernet to the Router
> > (using a Powerline adaptor):
> >
> > # iperf3 -c 192.168.178.41 -i 1 -t 10
> > Connecting to host 192.168.178.41, port 5201
> > [ 4] local 192.168.178.40 port 36130 connected to 192.168.178.41
> > port
> > 5201
> > [ ID] Interval Transfer Bandwidth Retr Cwnd
> > [ 4] 0.00-1.09 sec 2.50 MBytes 19.2 Mbits/sec 0 14.1
> > KBytes
> > [ 4] 1.09-2.21 sec 2.50 MBytes 18.8 Mbits/sec 0 14.1
> > KBytes
> > [ 4] 2.21-3.30 sec 2.50 MBytes 19.2 Mbits/sec 0 14.1
> > KBytes
> > [ 4] 3.30-4.39 sec 2.50 MBytes 19.3 Mbits/sec 0 14.1
> > KBytes
> > [ 4] 4.39-5.48 sec 2.50 MBytes 19.2 Mbits/sec 0 14.1
> > KBytes
> > [ 4] 5.48-6.02 sec 1.25 MBytes 19.3 Mbits/sec 0 14.1
> > KBytes
> > [ 4] 6.02-7.11 sec 2.50 MBytes 19.3 Mbits/sec 0 14.1
> > KBytes
> > [ 4] 7.11-8.20 sec 2.50 MBytes 19.3 Mbits/sec 0 14.1
> > KBytes
> > [ 4] 8.20-9.43 sec 2.50 MBytes 17.1 Mbits/sec 0 14.1
> > KBytes
> > [ 4] 9.43-10.51 sec 2.50 MBytes 19.4 Mbits/sec 0 14.1
> > KBytes
> > - - - - - - - - - - - - - - - - - - - - - - - - -
> > [ ID] Interval Transfer Bandwidth Retr
> > [ 4] 0.00-10.51 sec 23.8 MBytes 19.0
> > Mbits/sec 0 sender
> > [ 4] 0.00-10.51 sec 23.8 MBytes 19.0
> > Mbits/sec receiver
> >
> > iperf Done.
>
> Sorry. I meant not running iperf server nor client on AP. A bit more
> graphic:
>
> Notebook --> AP --> PC
>
> Iperf client on notebook and iperf server on PC. Notebook to AP is
> wireless, AP to PC is wired.
I see! Howver, this needs routing on the AP, which I have not done yet.
What do you expect from this test?
I compared the values from the Ethernet test with an Application Note
[1] I found at NXP for the i.MX28. Running iperf shows an throughput of
>60 MBits/sec. I run the test cases again without Powerline adapter by
connecting both devices directly to the Router and even installed iperf
(instead of iperf3). Nevertheless, I am stuck with 20 MBits/sec. Note,
that the Application Note was done with a legacy Linux Kernel 2.6
whereas I use mainline Linux Kernel 4.7. Maybe something is missing in
mainline?
For now, I will consider that brcmfmac is not responsible for the low
throughput and I will move this issue to the ARM linux mailing list.
Many thanks so far for the support! I will keep you in the loop.
[1] http://cache.freescale.com/files/32bit/doc/app_note/AN4544.pdf
Best regards
Jörg Krause
^ permalink raw reply
* Re: [PATCH] ath6k1: add Dell OEM SDIO I/O for the Venue 8 Pro
From: Steve deRosier @ 2016-10-12 21:32 UTC (permalink / raw)
To: Alan; +Cc: linux-wireless
In-Reply-To: <147629570687.26062.4786752681864367162.stgit@localhost.localdomain>
Hi Alan,
Sorry to quibble, but the subsystem label on the commit subject line
should be "ath6kl:" it's a lower-case "L", not a one.
On Wed, Oct 12, 2016 at 11:08 AM, Alan <alan@linux.intel.com> wrote:
> From: Adam Williamson <adamw@happyassassin.net>
>
> SDIO ID 0271:0418
>
> Signed-off-by: Alan Cox <alan@linux.intel.com>
> Bugzilla-ID: https://bugzilla.kernel.org/show_bug.cgi?id=67921
>
> diff --git a/drivers/net/wireless/ath/ath6kl/sdio.c b/drivers/net/wireless/ath/ath6kl/sdio.c
> index eab0ab9..76eb336 100644
> --- a/drivers/net/wireless/ath/ath6kl/sdio.c
> +++ b/drivers/net/wireless/ath/ath6kl/sdio.c
> @@ -1401,6 +1401,7 @@ static const struct sdio_device_id ath6kl_sdio_devices[] = {
> {SDIO_DEVICE(MANUFACTURER_CODE, (MANUFACTURER_ID_AR6004_BASE | 0x0))},
> {SDIO_DEVICE(MANUFACTURER_CODE, (MANUFACTURER_ID_AR6004_BASE | 0x1))},
> {SDIO_DEVICE(MANUFACTURER_CODE, (MANUFACTURER_ID_AR6004_BASE | 0x2))},
> + {SDIO_DEVICE(MANUFACTURER_CODE, (MANUFACTURER_ID_AR6004_BASE | 0x18))},
> {},
> };
>
>
I see nothing wrong with this if the chip does indeed identify itself
this way. So please fix the subject and you can add:
Reviewed-by: Steve deRosier <steve.derosier@lairdtech.com>
- Steve
^ permalink raw reply
* Re: TCP data throughput for BCM43362
From: Jörg Krause @ 2016-10-12 21:19 UTC (permalink / raw)
To: Arend Van Spriel
Cc: Franky Lin, Brett Rudley, brcm80211-dev-list, Hante Meuleman,
Franky Lin, linux-wireless, Arend van Spriel
In-Reply-To: <CAF7Mx6rqfbhDL-MRZ93vzCdSskgqi_bVNn=1SGb_WKV=DZZ+YQ@mail.gmail.com>
On Wed, 2016-10-12 at 23:08 +0200, Arend Van Spriel wrote:
> Op 12 okt. 2016 21:30 schreef "Jörg Krause" <joerg.krause@embedded.ro
> cks>:
> >
> > On Mi, 2016-10-12 at 21:08 +0200, Arend van Spriel wrote:
> >
> > [snip]
> >
> > > On 12-10-16 16:27, Jörg Krause wrote:
> > > >
> > > > It is running the iperf server. It is running in station mode
> > > > as
> > > > well
> > > > as in AP mode, depending on the use case. The wireshark dump
> > > > was
> > > > taken
> > > > when the bcm43362 is operating in AP mode.
> > > >
> > > > >
> > > > > What specs does the ARM on your custom board have?
> > > >
> > > > Which specs do you mean?
> > > >
> > > > >
> > > > > The trace shows that it does not do
> > > > > aggregation. What it does not show is whether A-MPDU was
> > > > > setup,
> > > > > ie.
> > > > > ADDBA message exchange. So could you create a similar capture
> > > > > including
> > > > > connection setup, ie. AUTH/ASSOC, etc.
> > > >
> > > > Yes, I can do that. Note, that I am using wpa_supplicant 2.5
> > > > for AP
> > > > mode operation (not hostapd).
> > >
> > > ok. unchartered territory for me. In the beacon frame I see
> > >
> > > .... ..01 = Maximum Rx A-MPDU Length: 0x1 (16383[Bytes])
> > > ...1 10.. = MPDU Density: 8 [usec] (0x6)
> > >
> > > In the trace it is only ~1500 bytes so no A-MPDU.
> >
> > The issue is not only valid for operating the BCM43362 in AP mode,
> > but
> > also in station mode. The TCP throughput is the same for both
> > modes.
> >
> > > What device is in the notebook?
> >
> > It is a Broadcom 43225. However, the low TCP throughput is not
> > specific
> > to this device but with all kind of devices including Smartphones,
> > Notebooks, PCs running the iperf client.
> >
> > > Can you use 'iw list' there to obtain info.
> >
> > $ iw list
> > Wiphy phy0
> > max # scan SSIDs: 4
> > max scan IEs length: 2257 bytes
> > max # sched scan SSIDs: 0
> > max # match sets: 0
> > max # scan plans: 1
> > max scan plan interval: -1
> > max scan plan iterations: 0
> > Retry short limit: 7
> > Retry long limit: 4
> > Coverage class: 0 (up to 0m)
> > Device supports RSN-IBSS.
> > Supported Ciphers:
> > * WEP40 (00-0f-ac:1)
> > * WEP104 (00-0f-ac:5)
> > * TKIP (00-0f-ac:2)
> > * CCMP (00-0f-ac:4)
> > * 00-0f-ac:10
> > * GCMP (00-0f-ac:8)
> > * 00-0f-ac:9
> > Available Antennas: TX 0 RX 0
> > Supported interface modes:
> > * IBSS
> > * managed
> > * AP
> > * AP/VLAN
> > * monitor
> > Band 1:
> > Capabilities: 0x70
> > HT20
> > Static SM Power Save
> > RX Greenfield
> > RX HT20 SGI
> > RX HT40 SGI
> > No RX STBC
> > Max AMSDU length: 3839 bytes
> > No DSSS/CCK HT40
> > Maximum RX AMPDU length 65535 bytes (exponent:
> > 0x003)
> > Minimum RX AMPDU time spacing: 8 usec (0x06)
> > HT Max RX data rate: 500 Mbps
> > HT TX/RX MCS rate indexes supported: 0-15
> > Bitrates (non-HT):
> > * 1.0 Mbps
> > * 2.0 Mbps (short preamble supported)
> > * 5.5 Mbps (short preamble supported)
> > * 11.0 Mbps (short preamble supported)
> > * 6.0 Mbps
> > * 9.0 Mbps
> > * 12.0 Mbps
> > * 18.0 Mbps
> > * 24.0 Mbps
> > * 36.0 Mbps
> > * 48.0 Mbps
> > * 54.0 Mbps
> > Frequencies:
> > * 2412 MHz [1] (19.0 dBm)
> > * 2417 MHz [2] (19.0 dBm)
> > * 2422 MHz [3] (19.0 dBm)
> > * 2427 MHz [4] (19.0 dBm)
> > * 2432 MHz [5] (19.0 dBm)
> > * 2437 MHz [6] (19.0 dBm)
> > * 2442 MHz [7] (19.0 dBm)
> > * 2447 MHz [8] (19.0 dBm)
> > * 2452 MHz [9] (19.0 dBm)
> > * 2457 MHz [10] (19.0 dBm)
> > * 2462 MHz [11] (19.0 dBm)
> > * 2467 MHz [12] (19.0 dBm) (no IR)
> > * 2472 MHz [13] (19.0 dBm) (no IR)
> > * 2484 MHz [14] (disabled)
> > Supported commands:
> > * new_interface
> > * set_interface
> > * new_key
> > * start_ap
> > * new_station
> > * new_mpath
> > * set_mesh_config
> > * set_bss
> > * authenticate
> > * associate
> > * deauthenticate
> > * disassociate
> > * join_ibss
> > * join_mesh
> > * set_tx_bitrate_mask
> > * frame
> > * frame_wait_cancel
> > * set_wiphy_netns
> > * set_channel
> > * set_wds_peer
> > * probe_client
> > * set_noack_map
> > * register_beacons
> > * start_p2p_device
> > * set_mcast_rate
> > * set_qos_map
> > * connect
> > * disconnect
> > Supported TX frame types:
> > * IBSS: 0x00 0x10 0x20 0x30 0x40 0x50 0x60
> > 0x70 0x80
> > 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
> > * managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60
> > 0x70
> > 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
> > * AP: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70
> > 0x80
> > 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
> > * AP/VLAN: 0x00 0x10 0x20 0x30 0x40 0x50 0x60
> > 0x70
> > 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
> > * mesh point: 0x00 0x10 0x20 0x30 0x40 0x50
> > 0x60 0x70
> > 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
> > * P2P-client: 0x00 0x10 0x20 0x30 0x40 0x50
> > 0x60 0x70
> > 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
> > * P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 0x60
> > 0x70
>
> 0x80
> > 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
> > * P2P-device: 0x00 0x10 0x20 0x30 0x40 0x50
> > 0x60 0x70
> > 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
> > Supported RX frame types:
> > * IBSS: 0x40 0xb0 0xc0 0xd0
> > * managed: 0x40 0xd0
> > * AP: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
> > * AP/VLAN: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
> > * mesh point: 0xb0 0xc0 0xd0
> > * P2P-client: 0x40 0xd0
> > * P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
> > * P2P-device: 0x40 0xd0
> > software interface modes (can always be added):
> > * AP/VLAN
> > * monitor
> > interface combinations are not supported
> > HT Capability overrides:
> > * MCS: ff ff ff ff ff ff ff ff ff ff
> > * maximum A-MSDU length
> > * supported channel width
> > * short GI for 40 MHz
> > * max A-MPDU length exponent
> > * min MPDU start spacing
> > Device supports TX status socket option.
> > Device supports HT-IBSS.
> > Device supports SAE with AUTHENTICATE command
> > Device supports low priority scan.
> > Device supports scan flush.
> > Device supports AP scan.
> > Device supports per-vif TX power setting
> > Driver supports a userspace MPM
> > Device supports configuring vdev MAC-addr on create.
> >
> > > >
> > > > >
> > > > > Just to confirm. You are using the firmware from linux-
> > > > > firmware,
> > > > > right?
> > > >
> > > > Right.
> > > >
> > > > >
> > > > > Or are you using firmware from the wiced dev kit?
> > > >
> > > > No. I guess you mean bcmdhd?
> > >
> > > You referred to 20 Mbps claim on wiced dev kit page at mouser so
> > > I
> > > assumed you were using that and it includes firmware. As you
> > > confirmed
> > > using firmware from linux-firmware repo this question does not
> > > matter.
> >
> > I see! Note, that I measured >20MB throughput on the Cubietruck,
> > which
> > is using the AP6210, but also the brcmfmac driver.
>
> So does your custom ARM board have an Ethernet socket, ie. run iperf
> server
> on another device hooked up to the AP over Ethernet.
Yes, it does have Ethernet. I hope that I have understand you
correctly, so I run an iperf server an my PC and on my ARM board the
iperf client. Both devices are connected via Ethernet to the Router
(using a Powerline adaptor):
# iperf3 -c 192.168.178.41 -i 1 -t 10
Connecting to host 192.168.178.41, port 5201
[ 4] local 192.168.178.40 port 36130 connected to 192.168.178.41 port
5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.09 sec 2.50 MBytes 19.2 Mbits/sec 0 14.1
KBytes
[ 4] 1.09-2.21 sec 2.50 MBytes 18.8 Mbits/sec 0 14.1
KBytes
[ 4] 2.21-3.30 sec 2.50 MBytes 19.2 Mbits/sec 0 14.1
KBytes
[ 4] 3.30-4.39 sec 2.50 MBytes 19.3 Mbits/sec 0 14.1
KBytes
[ 4] 4.39-5.48 sec 2.50 MBytes 19.2 Mbits/sec 0 14.1
KBytes
[ 4] 5.48-6.02 sec 1.25 MBytes 19.3 Mbits/sec 0 14.1
KBytes
[ 4] 6.02-7.11 sec 2.50 MBytes 19.3 Mbits/sec 0 14.1
KBytes
[ 4] 7.11-8.20 sec 2.50 MBytes 19.3 Mbits/sec 0 14.1
KBytes
[ 4] 8.20-9.43 sec 2.50 MBytes 17.1 Mbits/sec 0 14.1
KBytes
[ 4] 9.43-10.51 sec 2.50 MBytes 19.4 Mbits/sec 0 14.1
KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.51 sec 23.8 MBytes 19.0
Mbits/sec 0 sender
[ 4] 0.00-10.51 sec 23.8 MBytes 19.0
Mbits/sec receiver
iperf Done.
Best regards
Jörg Krause
^ permalink raw reply
* Re: TCP data throughput for BCM43362
From: Jörg Krause @ 2016-10-12 20:48 UTC (permalink / raw)
To: Arend van Spriel
Cc: brcm80211-dev-list, Brett Rudley, Franky Lin, Hante Meuleman,
linux-wireless, Franky Lin, Arend van Spriel
In-Reply-To: <c571ac91-ccd1-5e98-317f-eb3e56ad6b58@broadcom.com>
On Wed, 2016-10-12 at 21:08 +0200, Arend van Spriel wrote:
[snip]
>
> You referred to 20 Mbps claim on wiced dev kit page at mouser so I
> assumed you were using that and it includes firmware. As you
> confirmed
> using firmware from linux-firmware repo this question does not
> matter.
Note, that a user reported "low" throughput on i.MX28 (same processor I
use with BCM43362) using Qualcom/Atheros QCA 6124 only seeing 20MB
using iperf [1].
[1] https://community.nxp.com/thread/353921
Best regards
Jörg Krause
^ permalink raw reply
* Re: TCP data throughput for BCM43362
From: Jörg Krause @ 2016-10-12 19:30 UTC (permalink / raw)
To: Arend van Spriel
Cc: brcm80211-dev-list, Brett Rudley, Franky Lin, Hante Meuleman,
linux-wireless, Franky Lin, Arend van Spriel
In-Reply-To: <c571ac91-ccd1-5e98-317f-eb3e56ad6b58@broadcom.com>
On Mi, 2016-10-12 at 21:08 +0200, Arend van Spriel wrote:
[snip]
> On 12-10-16 16:27, Jörg Krause wrote:
> >
> > It is running the iperf server. It is running in station mode as
> > well
> > as in AP mode, depending on the use case. The wireshark dump was
> > taken
> > when the bcm43362 is operating in AP mode.
> >
> > >
> > > What specs does the ARM on your custom board have?
> >
> > Which specs do you mean?
> >
> > >
> > > The trace shows that it does not do
> > > aggregation. What it does not show is whether A-MPDU was setup,
> > > ie.
> > > ADDBA message exchange. So could you create a similar capture
> > > including
> > > connection setup, ie. AUTH/ASSOC, etc.
> >
> > Yes, I can do that. Note, that I am using wpa_supplicant 2.5 for AP
> > mode operation (not hostapd).
>
> ok. unchartered territory for me. In the beacon frame I see
>
> .... ..01 = Maximum Rx A-MPDU Length: 0x1 (16383[Bytes])
> ...1 10.. = MPDU Density: 8 [usec] (0x6)
>
> In the trace it is only ~1500 bytes so no A-MPDU.
The issue is not only valid for operating the BCM43362 in AP mode, but
also in station mode. The TCP throughput is the same for both modes.
> What device is in the notebook?
It is a Broadcom 43225. However, the low TCP throughput is not specific
to this device but with all kind of devices including Smartphones,
Notebooks, PCs running the iperf client.
> Can you use 'iw list' there to obtain info.
$ iw list
Wiphy phy0
max # scan SSIDs: 4
max scan IEs length: 2257 bytes
max # sched scan SSIDs: 0
max # match sets: 0
max # scan plans: 1
max scan plan interval: -1
max scan plan iterations: 0
Retry short limit: 7
Retry long limit: 4
Coverage class: 0 (up to 0m)
Device supports RSN-IBSS.
Supported Ciphers:
* WEP40 (00-0f-ac:1)
* WEP104 (00-0f-ac:5)
* TKIP (00-0f-ac:2)
* CCMP (00-0f-ac:4)
* 00-0f-ac:10
* GCMP (00-0f-ac:8)
* 00-0f-ac:9
Available Antennas: TX 0 RX 0
Supported interface modes:
* IBSS
* managed
* AP
* AP/VLAN
* monitor
Band 1:
Capabilities: 0x70
HT20
Static SM Power Save
RX Greenfield
RX HT20 SGI
RX HT40 SGI
No RX STBC
Max AMSDU length: 3839 bytes
No DSSS/CCK HT40
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: 8 usec (0x06)
HT Max RX data rate: 500 Mbps
HT TX/RX MCS rate indexes supported: 0-15
Bitrates (non-HT):
* 1.0 Mbps
* 2.0 Mbps (short preamble supported)
* 5.5 Mbps (short preamble supported)
* 11.0 Mbps (short preamble supported)
* 6.0 Mbps
* 9.0 Mbps
* 12.0 Mbps
* 18.0 Mbps
* 24.0 Mbps
* 36.0 Mbps
* 48.0 Mbps
* 54.0 Mbps
Frequencies:
* 2412 MHz [1] (19.0 dBm)
* 2417 MHz [2] (19.0 dBm)
* 2422 MHz [3] (19.0 dBm)
* 2427 MHz [4] (19.0 dBm)
* 2432 MHz [5] (19.0 dBm)
* 2437 MHz [6] (19.0 dBm)
* 2442 MHz [7] (19.0 dBm)
* 2447 MHz [8] (19.0 dBm)
* 2452 MHz [9] (19.0 dBm)
* 2457 MHz [10] (19.0 dBm)
* 2462 MHz [11] (19.0 dBm)
* 2467 MHz [12] (19.0 dBm) (no IR)
* 2472 MHz [13] (19.0 dBm) (no IR)
* 2484 MHz [14] (disabled)
Supported commands:
* new_interface
* set_interface
* new_key
* start_ap
* new_station
* new_mpath
* set_mesh_config
* set_bss
* authenticate
* associate
* deauthenticate
* disassociate
* join_ibss
* join_mesh
* set_tx_bitrate_mask
* frame
* frame_wait_cancel
* set_wiphy_netns
* set_channel
* set_wds_peer
* probe_client
* set_noack_map
* register_beacons
* start_p2p_device
* set_mcast_rate
* set_qos_map
* connect
* disconnect
Supported TX frame types:
* IBSS: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80
0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70
0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* AP: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80
0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* AP/VLAN: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70
0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* mesh point: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70
0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* P2P-client: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70
0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80
0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* P2P-device: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70
0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
Supported RX frame types:
* IBSS: 0x40 0xb0 0xc0 0xd0
* managed: 0x40 0xd0
* AP: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
* AP/VLAN: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
* mesh point: 0xb0 0xc0 0xd0
* P2P-client: 0x40 0xd0
* P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
* P2P-device: 0x40 0xd0
software interface modes (can always be added):
* AP/VLAN
* monitor
interface combinations are not supported
HT Capability overrides:
* MCS: ff ff ff ff ff ff ff ff ff ff
* maximum A-MSDU length
* supported channel width
* short GI for 40 MHz
* max A-MPDU length exponent
* min MPDU start spacing
Device supports TX status socket option.
Device supports HT-IBSS.
Device supports SAE with AUTHENTICATE command
Device supports low priority scan.
Device supports scan flush.
Device supports AP scan.
Device supports per-vif TX power setting
Driver supports a userspace MPM
Device supports configuring vdev MAC-addr on create.
> >
> > >
> > > Just to confirm. You are using the firmware from linux-firmware,
> > > right?
> >
> > Right.
> >
> > >
> > > Or are you using firmware from the wiced dev kit?
> >
> > No. I guess you mean bcmdhd?
>
> You referred to 20 Mbps claim on wiced dev kit page at mouser so I
> assumed you were using that and it includes firmware. As you
> confirmed
> using firmware from linux-firmware repo this question does not
> matter.
I see! Note, that I measured >20MB throughput on the Cubietruck, which
is using the AP6210, but also the brcmfmac driver.
Best regards
Jörg Krause
^ permalink raw reply
* Re: TCP data throughput for BCM43362
From: Arend van Spriel @ 2016-10-12 19:08 UTC (permalink / raw)
To: Jörg Krause
Cc: brcm80211-dev-list, Brett Rudley, Franky Lin, Hante Meuleman,
linux-wireless, Franky Lin, Arend van Spriel
In-Reply-To: <1476282457.1492.8.camel@embedded.rocks>
On 12-10-16 16:27, Jörg Krause wrote:
> On Mi, 2016-10-12 at 10:11 +0200, Arend Van Spriel wrote:
>> On 11-10-2016 8:14, Jörg Krause wrote:
>>>
>>>
>>>
>>> Hi Arend,
>>>
>>> Am 22. September 2016 16:00:36 MESZ, schrieb Arend Van Spriel <aren
>>> d.vanspriel@broadcom.com>:
>>>>
>>>> Op 22 sep. 2016 14:52 schreef "Jörg Krause"
>>>> <joerg.krause@embedded.rocks>:
>>>>>
>>>>>
>>>>> On Do, 2016-09-22 at 10:09 +0200, Arend Van Spriel wrote:
>>>>>>
>>>>>> On 19-9-2016 8:36, Jörg Krause wrote:
>>>>>>>
>>>>>>>
>>>>>>> Hi Arend,
>>>>>>>
>>>>>>> On Wed, 2016-09-14 at 20:13 +0200, Arend Van Spriel wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 14-9-2016 15:41, Jörg Krause wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> On Mon, 2016-08-29 at 23:15 +0200, Jörg Krause wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Mi, 2016-08-24 at 20:35 +0200, Arend Van Spriel
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 22-8-2016 15:37, Jörg Krause wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>
>>>>>>>>>>>> I am back from vacation and I'd like to do more
>>>>>>>>>>>> investigations
>>>>>>>>>>>> about
>>>>>>>>>>>> this issue. Please see my comments below...
>>>>>>>>>>>>
>>>>>>>>>>>> On Sun, 2016-08-07 at 13:41 +0200, Arend van
>>>>>>>>>>>> Spriel
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 06-08-16 16:12, Jörg Krause wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>
>>>>>>>>>>>>> A bit weird email format making it a bit hard
>>>>>>>>>>>>> to
>>>>>>>>>>>>> determine
>>>>>>>>>>>>> where
>>>>>>>>>>>>> your
>>>>>>>>>>>>> last reply starts...
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Fr, 2016-08-05 at 17:56 -0700, Franky Lin
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Fri, Aug 5, 2016 at 2:29 PM, Jörg Krause
>>>>>>>>>>>>>> <joerg.krause
>>>>>>>>>>>>>> @emb
>>>>>>>>>>>>>> ed
>>>>>>>>>>>>>> ded.
>>>>>>>>>>>>>> ro
>>>>>>>>>>>>>> cks>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Am 5. August 2016 23:01:10 MESZ, schrieb
>>>>>>>>>>>>>> Arend Van
>>>>>>>>>>>>>> Spriel
>>>>>>>>>>>>>> <
>>>>>>>>>>>>>> arend.vanspriel@broadcom.com>:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Op 5 aug. 2016 22:46 schreef "Jörg Krause"
>>>>>>>>>>>>>> <joerg.krause@embedded.rocks>:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'm using a custom ARM board with an BCM43362
>>>>>>>>>>>>>> wifi
>>>>>>>>>>>>>> chip
>>>>>>>>>>>>>> from
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Broadcom.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The wifi chip is attached via SDIO to the
>>>> controller
>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> with
>>>>>>>>>>>>>> a
>>>>>>>>>>>>>> clock of
>>>>>>>>>>>>>> 48MHz. Linux kernel version is 4.7.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> When measuring the network bandwidth with
>>>>>>>>>>>>>> iperf3 I
>>>>>>>>>>>>>> get a
>>>>>>>>>>>>>> bandwith of
>>>>>>>>>>>>>> only around 5 Mbps. I found a similar thread
>>>>>>>>>>>>>> at the
>>>>>>>>>>>>>> Broadcom
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> community
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> [1] where the test was done with a M4 CPU +
>>>> BCM43362
>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>> an
>>>>>>>>>>>>>> average
>>>>>>>>>>>>>> result of 3.3 Mbps.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Interestingly, a BCM43362 Wi-Fi Dev Kit [2]
>>>>>>>>>>>>>> notes a
>>>>>>>>>>>>>> TCP
>>>>>>>>>>>>>> data
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> throughput
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> greater than 20 Mbps.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Why is the throughput I measured much lower?
>>>>>>>>>>>>>> Note
>>>>>>>>>>>>>> that I
>>>>>>>>>>>>>> measured
>>>>>>>>>>>>>> several times with almost no neighbor devices
>>>>>>>>>>>>>> or
>>>>>>>>>>>>>> networks.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This is a test sample measured with iperf3:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> $ iperf3 -c 192.168.2.1 -i 1 -t 10
>>>>>>>>>>>>>> Connecting to host 192.168.2.1, port 5201
>>>>>>>>>>>>>> [ 4] local 192.168.2.155 port 36442
>>>>>>>>>>>>>> connected
>>>> to
>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 192.168.2.1
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> port
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 5201
>>>>>>>>>>>>>> [ ID]
>>>>>>>>>>>>>> Interval Transfer Bandwidth
>>>>>>>>>>>>>>
>>>> Retr
>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Cwn
>>>>>>>>>>>>>> d
>>>>>>>>>>>>>> [ 4] 0.00-1.00 sec 615
>>>>>>>>>>>>>> KBytes 5.04
>>>>>>>>>>>>>> Mbits/sec 0 56.6
>>>>>>>>>>>>>> KBytes
>>>>>>>>>>>>>> [ 4] 1.00-2.00 sec 622
>>>>>>>>>>>>>> KBytes 5.10
>>>>>>>>>>>>>> Mbits/sec 0 84.8
>>>>>>>>>>>>>> KBytes
>>>>>>>>>>>>>> [ 4] 2.00-3.00 sec 625
>>>>>>>>>>>>>> KBytes 5.12
>>>>>>>>>>>>>> Mbits/sec 0 113
>>>>>>>>>>>>>> KBytes
>>>>>>>>>>>>>> [ 4] 3.00-4.00 sec 571
>>>>>>>>>>>>>> KBytes 4.68
>>>>>>>>>>>>>> Mbits/sec 0 140
>>>>>>>>>>>>>> KBytes
>>>>>>>>>>>>>> [ 4] 4.00-5.00 sec 594
>>>>>>>>>>>>>> KBytes 4.87
>>>>>>>>>>>>>> Mbits/sec 0 167
>>>>>>>>>>>>>> KBytes
>>>>>>>>>>>>>> [ 4] 5.00-6.00 sec 628
>>>>>>>>>>>>>> KBytes 5.14
>>>>>>>>>>>>>> Mbits/sec 0 195
>>>>>>>>>>>>>> KBytes
>>>>>>>>>>>>>> [ 4] 6.00-7.00 sec 619
>>>>>>>>>>>>>> KBytes 5.07
>>>>>>>>>>>>>> Mbits/sec 0 202
>>>>>>>>>>>>>> KBytes
>>>>>>>>>>>>>> [ 4] 7.00-8.00 sec 608
>>>>>>>>>>>>>> KBytes 4.98
>>>>>>>>>>>>>> Mbits/sec 0 202
>>>>>>>>>>>>>> KBytes
>>>>>>>>>>>>>> [ 4] 8.00-9.00 sec 602
>>>>>>>>>>>>>> KBytes 4.93
>>>>>>>>>>>>>> Mbits/sec 0 202
>>>>>>>>>>>>>> KBytes
>>>>>>>>>>>>>> [ 4] 9.00-10.00 sec 537
>>>>>>>>>>>>>> KBytes 4.40
>>>>>>>>>>>>>> Mbits/sec 0 202
>>>>>>>>>>>>>> KBytes
>>>>>>>>>>>>>> - - - - - - - - - - - - - - - - - - - - -
>>>>>>>>>>>>>> - - -
>>>> -
>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> [ ID]
>>>>>>>>>>>>>> Interval Transfer Bandwidth
>>>>>>>>>>>>>>
>>>> Retr
>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> [ 4] 0.00-10.00 sec 5.88
>>>>>>>>>>>>>> MBytes 4.93
>>>>>>>>>>>>>> Mbits/sec 0 sender
>>>>>>>>>>>>>> [ 4] 0.00-10.00 sec 5.68
>>>>>>>>>>>>>> MBytes 4.76
>>>>>>>>>>>>>> Mbits/sec receiver
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Not overly familiar with iperf3. Do these
>>>>>>>>>>>>>> lines
>>>> mean
>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> you
>>>>>>>>>>>>>> are
>>>>>>>>>>>>>> doing
>>>>>>>>>>>>>> bidirectional test, ie. upstream and
>>>>>>>>>>>>>> downstream at
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> same
>>>>>>>>>>>>>> time.
>>>>>>>>>>>>>> Another
>>>>>>>>>>>>>> thing affecting tput could be power-save.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> No, iperf3 does not support bidrectional
>>>>>>>>>>>>>> test.
>>>> Power-
>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> save
>>>>>>>>>>>>>> is
>>>>>>>>>>>>>> turned
>>>>>>>>>>>>>> off.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> What does iw link say?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> but I guess it starts here!
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I compared the results with a Cubietruck I
>>>>>>>>>>>>>> have:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> # iperf3 -s
>>>>>>>>>>>>>> -------------------------------------------
>>>>>>>>>>>>>> --------
>>>>>>>>>>>>>> ----
>>>>>>>>>>>>>> ----
>>>>>>>>>>>>>> Server listening on 5201
>>>>>>>>>>>>>> -------------------------------------------
>>>>>>>>>>>>>> --------
>>>>>>>>>>>>>> ----
>>>>>>>>>>>>>> ----
>>>>>>>>>>>>>> Accepted connection from 192.168.178.46, port
>>>>>>>>>>>>>> 42906
>>>>>>>>>>>>>> [ 5] local 192.168.178.38 port 5201
>>>>>>>>>>>>>> connected to
>>>>>>>>>>>>>> 192.168.178.46
>>>>>>>>>>>>>> port
>>>>>>>>>>>>>> 42908
>>>>>>>>>>>>>> [ ID]
>>>>>>>>>>>>>> Interval Transfer Bandwidth
>>>>>>>>>>>>>> [ 5] 0.00-1.00 sec 2.29 MBytes 19.2
>>>>>>>>>>>>>> Mbits/sec
>>>>>>>>>>>>>> [ 5] 1.00-2.00 sec 2.21 MBytes 18.5
>>>>>>>>>>>>>> Mbits/sec
>>>>>>>>>>>>>> [ 5] 2.00-3.00 sec 2.17 MBytes 18.2
>>>>>>>>>>>>>> Mbits/sec
>>>>>>>>>>>>>> [ 5] 3.00-4.00 sec 2.09 MBytes 17.6
>>>>>>>>>>>>>> Mbits/sec
>>>>>>>>>>>>>> [ 5] 4.00-5.00 sec 2.20 MBytes 18.5
>>>>>>>>>>>>>> Mbits/sec
>>>>>>>>>>>>>> [ 5] 5.00-6.00 sec 2.64 MBytes 22.1
>>>>>>>>>>>>>> Mbits/sec
>>>>>>>>>>>>>> [ 5] 6.00-7.00 sec 2.67 MBytes 22.4
>>>>>>>>>>>>>> Mbits/sec
>>>>>>>>>>>>>> [ 5] 7.00-8.00 sec 2.62 MBytes 22.0
>>>>>>>>>>>>>> Mbits/sec
>>>>>>>>>>>>>> [ 5] 8.00-9.00 sec 2.35 MBytes 19.8
>>>>>>>>>>>>>> Mbits/sec
>>>>>>>>>>>>>> [ 5] 9.00-10.00 sec 2.30 MBytes 19.3
>>>>>>>>>>>>>> Mbits/sec
>>>>>>>>>>>>>> [ 5] 10.00-10.03 sec 83.4 KBytes 23.5
>>>>>>>>>>>>>> Mbits/sec
>>>>>>>>>>>>>> - - - - - - - - - - - - - - - - - - - - - - -
>>>>>>>>>>>>>> - -
>>>>>>>>>>>>>> [ ID]
>>>>>>>>>>>>>> Interval Transfer Bandwidth
>>>>>>>>>>>>>>
>>>> Retr
>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> [ 5] 0.00-10.03 sec 23.9 MBytes 20.0
>>>>>>>>>>>>>> Mbits/sec 0 sender
>>>>>>>>>>>>>> [ 5] 0.00-10.03 sec 23.6 MBytes 19.8
>>>>>>>>>>>>>> Mbits/sec receiver
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> # iw dev wlan0 link
>>>>>>>>>>>>>> Connected to xx:xx:xx:xx:xx (on wlan0)
>>>>>>>>>>>>>> SSID: xxx
>>>>>>>>>>>>>> freq: 2437
>>>>>>>>>>>>>> tx bitrate: 65.0 MBit/s
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> bss flags: short-preamble short-
>>>>>>>>>>>>>> slot-
>>>>>>>>>>>>>> time
>>>>>>>>>>>>>> dtim period: 1
>>>>>>>>>>>>>> beacon int: 100
>>>>>>>>>>>>>
>>>>>>>>>>>>> Too bad RSSI is not in the output above. That
>>>>>>>>>>>>> may be
>>>>>>>>>>>>> due to
>>>>>>>>>>>>> a
>>>>>>>>>>>>> regression
>>>>>>>>>>>>> in our driver which has been fixed by commit
>>>>>>>>>>>>> 94abd778a7bb
>>>>>>>>>>>>> ("brcmfmac:
>>>>>>>>>>>>> add fallback for devices that do not report
>>>>>>>>>>>>> per-chain
>>>>>>>>>>>>> values").
>>>>>>>>>>>>> However,
>>>>>>>>>>>>> the tx bitrate seems within the same range as
>>>>>>>>>>>>> the
>>>> other
>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> platform.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The Cubietruck works also with the brcmfmac
>>>>>>>>>>>>>> driver.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> May it depend on the NVRAM file?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Not sure. Can you tell me a bit more about the
>>>>>>>>>>>>> custom
>>>>>>>>>>>>> ARM
>>>>>>>>>>>>> board.
>>>>>>>>>>>>> Does
>>>>>>>>>>>>> it
>>>>>>>>>>>>> use the same wifi module as Cubietruck, ie. the
>>>>>>>>>>>>> AMPAK
>>>>>>>>>>>>> AP6210?
>>>>>>>>>>>>> If
>>>>>>>>>>>>> you
>>>>>>>>>>>>> can
>>>>>>>>>>>>> make a wireshark sniff we can check the actual
>>>> bitrate
>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> and
>>>>>>>>>>>>> medium
>>>>>>>>>>>>> density in terms of packets. Another thing to
>>>>>>>>>>>>> look at
>>>>>>>>>>>>> is
>>>>>>>>>>>>> the
>>>>>>>>>>>>> SDIO
>>>>>>>>>>>>> host
>>>>>>>>>>>>> controller. In brcmf_sdiod_sgtable_alloc() some
>>>>>>>>>>>>> key
>>>>>>>>>>>>> values
>>>>>>>>>>>>> are
>>>>>>>>>>>>> used
>>>>>>>>>>>>> from
>>>>>>>>>>>>> the host controller. It only logs the number of
>>>> entries
>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> of
>>>>>>>>>>>>> the
>>>>>>>>>>>>> scatter-gather table, but could you add the
>>>>>>>>>>>>> other
>>>>>>>>>>>>> values in
>>>>>>>>>>>>> this
>>>>>>>>>>>>> function that are used to determine the number
>>>>>>>>>>>>> of
>>>>>>>>>>>>> entries.
>>>>>>>>>>>>
>>>>>>>>>>>> My board uses the BCM43362 chip solely (no
>>>>>>>>>>>> Bluetooth)
>>>>>>>>>>>> attached to
>>>>>>>>>>>> the
>>>>>>>>>>>> SDIO interface of a NXP i.MX28 processor.
>>>>>>>>>>>>
>>>>>>>>>>>> I added some additional printk() to
>>>>>>>>>>>> brcmf_sdiod_sgtable_alloc().
>>>>>>>>>>>> These
>>>>>>>>>>>> are the values printed after modprobe brcmfmac:
>>>>>>>>>>>>
>>>>>>>>>>>> [ 8.926657] sg_support=1
>>>>>>>>>>>> [ 8.929440] max_blocks=511
>>>>>>>>>>>> [ 8.932213] max_request_size=261632
>>>>>>>>>>>> [ 8.935741] max_segment_count=52
>>>>>>>>>>>> [ 8.939005] max_segment_size=65280
>>>>>>>>>>>> [ 8.946095] nents=35
>>>>>>>>>>>
>>>>>>>>>>> Thanks. That looks good.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Additionally I attached a xz compresses wireshark
>>>>>>>>>>>> sniff
>>>>>>>>>>>> while
>>>>>>>>>>>> running
>>>>>>>>>>>> iper3 between the BCM43362 running as in AP mode
>>>>>>>>>>>> with
>>>>>>>>>>>> iperf3
>>>>>>>>>>>> as a
>>>>>>>>>>>> server and a PC in station mode running iperf3 as
>>>>>>>>>>>> a
>>>>>>>>>>>> client.
>>>>>>>>>>>
>>>>>>>>>>> Looking at the sniff it seems you captured on the
>>>> ethernet
>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> side.
>>>>>>>>>>> That
>>>>>>>>>>> does not give me any 802.11 specific info. Can you
>>>>>>>>>>> make a
>>>>>>>>>>> wireless
>>>>>>>>>>> capture preferably without encryption.
>>>>>>>>>>
>>>>>>>>>> You,re right! Sorry for this mistake. I did a re-
>>>>>>>>>> capture on
>>>>>>>>>> the
>>>>>>>>>> wireless side now.
>>>>>>>>>
>>>>>>>>> Anything new about this? Anything I can do to help?
>>>>>>>>
>>>>>>>> I missed your previous email. Was already wondering
>>>>>>>> whether to
>>>>>>>> ping
>>>>>>>> you.
>>>>>>>> Digging around in my email folders I found it so will
>>>>>>>> take a
>>>> look
>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> at
>>>>>>>> it.
>>>>>>>
>>>>>>> Did you had some time to look at this?
>>>>>>
>>>>>> Ehm. I still only see TCP stuff. To capture 802.11 management
>>>> frames
>>>>>
>>>>>>
>>>>>> you
>>>>>> need preferably a dedicated device using monitor mode [1].
>>>>>
>>>>> Stupid me! Now I used a monitor interface on a desktop to
>>>>> monitor the
>>>>> traffic between the BCM43362 operating in soft-AP mode and a
>>>>> notebook
>>>>> operating in managed mode.
>>>>>
>>>>> The BCM43362 runs the iperf server, the notebook the iperf
>>>>> client.
>>>>
>>>> Thanks.
>>>>
>>>> Week almost through so might next week.
>>>
>>> Did you had some time to look at this?
>>
>> So the bcm43362 is your AP and running iperf server.
>
> It is running the iperf server. It is running in station mode as well
> as in AP mode, depending on the use case. The wireshark dump was taken
> when the bcm43362 is operating in AP mode.
>
>> What specs does the ARM on your custom board have?
>
> Which specs do you mean?
>
>> The trace shows that it does not do
>> aggregation. What it does not show is whether A-MPDU was setup, ie.
>> ADDBA message exchange. So could you create a similar capture
>> including
>> connection setup, ie. AUTH/ASSOC, etc.
>
> Yes, I can do that. Note, that I am using wpa_supplicant 2.5 for AP
> mode operation (not hostapd).
ok. unchartered territory for me. In the beacon frame I see
.... ..01 = Maximum Rx A-MPDU Length: 0x1 (16383[Bytes])
...1 10.. = MPDU Density: 8 [usec] (0x6)
In the trace it is only ~1500 bytes so no A-MPDU. What device is in the
notebook? Can you use 'iw list' there to obtain info.
>> Just to confirm. You are using the firmware from linux-firmware,
>> right?
>
> Right.
>
>> Or are you using firmware from the wiced dev kit?
>
> No. I guess you mean bcmdhd?
You referred to 20 Mbps claim on wiced dev kit page at mouser so I
assumed you were using that and it includes firmware. As you confirmed
using firmware from linux-firmware repo this question does not matter.
Regards,
Arend
> Best regards
> Jörg Krause
>
^ permalink raw reply
* [PATCH] ath6k1: add Dell OEM SDIO I/O for the Venue 8 Pro
From: Alan @ 2016-10-12 18:08 UTC (permalink / raw)
To: linux-wireless
From: Adam Williamson <adamw@happyassassin.net>
SDIO ID 0271:0418
Signed-off-by: Alan Cox <alan@linux.intel.com>
Bugzilla-ID: https://bugzilla.kernel.org/show_bug.cgi?id=67921
diff --git a/drivers/net/wireless/ath/ath6kl/sdio.c b/drivers/net/wireless/ath/ath6kl/sdio.c
index eab0ab9..76eb336 100644
--- a/drivers/net/wireless/ath/ath6kl/sdio.c
+++ b/drivers/net/wireless/ath/ath6kl/sdio.c
@@ -1401,6 +1401,7 @@ static const struct sdio_device_id ath6kl_sdio_devices[] = {
{SDIO_DEVICE(MANUFACTURER_CODE, (MANUFACTURER_ID_AR6004_BASE | 0x0))},
{SDIO_DEVICE(MANUFACTURER_CODE, (MANUFACTURER_ID_AR6004_BASE | 0x1))},
{SDIO_DEVICE(MANUFACTURER_CODE, (MANUFACTURER_ID_AR6004_BASE | 0x2))},
+ {SDIO_DEVICE(MANUFACTURER_CODE, (MANUFACTURER_ID_AR6004_BASE | 0x18))},
{},
};
^ permalink raw reply related
* [PATCH V2] rtlwifi: Fix regression caused by commit d86e64768859
From: Larry Finger @ 2016-10-12 18:54 UTC (permalink / raw)
To: kvalo; +Cc: devel, linux-wireless, Larry Finger, Stable, Julia Lawall
In commit d86e64768859 ("rtlwifi: rtl818x: constify local structures"),
the configuration struct for most of the drivers was changed to be
constant. The problem is that five of the modified drivers need to be
able to update the firmware name based on the exact model of the card.
As the file names were stored in one of the members of that struct,
these drivers would fail with a kernel BUG splat when they tried to
update the firmware name.
Rather than reverting the previous commit, I used a suggestion by
Johannes Berg and made the firmware file name pointers be local to
the routines that update the software variables.
The configuration struct of rtl8192cu, which was not touched in the
previous patch, is now constantfied.
Fixes: d86e64768859 ("rtlwifi: rtl818x: constify local structures")
Suggested-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org>
Cc: Julia Lawall <Julia.Lawall@lip6.fr>
---
V2 - Fix warnings that were generated for some compiler versions.
---
drivers/net/wireless/realtek/rtlwifi/core.c | 2 +-
drivers/net/wireless/realtek/rtlwifi/rtl8188ee/sw.c | 8 ++++----
drivers/net/wireless/realtek/rtlwifi/rtl8192ce/sw.c | 13 +++++--------
drivers/net/wireless/realtek/rtlwifi/rtl8192cu/sw.c | 12 ++++++------
drivers/net/wireless/realtek/rtlwifi/rtl8192de/sw.c | 6 +++---
drivers/net/wireless/realtek/rtlwifi/rtl8192ee/sw.c | 8 ++++----
drivers/net/wireless/realtek/rtlwifi/rtl8192se/sw.c | 9 +++++----
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/sw.c | 12 +++++-------
drivers/net/wireless/realtek/rtlwifi/rtl8723be/sw.c | 6 +++---
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/sw.c | 18 +++++++++---------
drivers/net/wireless/realtek/rtlwifi/wifi.h | 2 --
11 files changed, 45 insertions(+), 51 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/core.c b/drivers/net/wireless/realtek/rtlwifi/core.c
index f95760c..8e7f23c 100644
--- a/drivers/net/wireless/realtek/rtlwifi/core.c
+++ b/drivers/net/wireless/realtek/rtlwifi/core.c
@@ -111,7 +111,7 @@ static void rtl_fw_do_work(const struct firmware *firmware, void *context,
if (!err)
goto found_alt;
}
- pr_err("Firmware %s not available\n", rtlpriv->cfg->fw_name);
+ pr_err("Selected firmware is not available\n");
rtlpriv->max_fw_size = 0;
return;
}
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/sw.c b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/sw.c
index e7b11b4..f361808 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/sw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/sw.c
@@ -86,6 +86,7 @@ int rtl88e_init_sw_vars(struct ieee80211_hw *hw)
struct rtl_priv *rtlpriv = rtl_priv(hw);
struct rtl_pci *rtlpci = rtl_pcidev(rtl_pcipriv(hw));
u8 tid;
+ char *fw_name;
rtl8188ee_bt_reg_init(hw);
rtlpriv->dm.dm_initialgain_enable = 1;
@@ -169,10 +170,10 @@ int rtl88e_init_sw_vars(struct ieee80211_hw *hw)
return 1;
}
- rtlpriv->cfg->fw_name = "rtlwifi/rtl8188efw.bin";
+ fw_name = "rtlwifi/rtl8188efw.bin";
rtlpriv->max_fw_size = 0x8000;
- pr_info("Using firmware %s\n", rtlpriv->cfg->fw_name);
- err = request_firmware_nowait(THIS_MODULE, 1, rtlpriv->cfg->fw_name,
+ pr_info("Using firmware %s\n", fw_name);
+ err = request_firmware_nowait(THIS_MODULE, 1, fw_name,
rtlpriv->io.dev, GFP_KERNEL, hw,
rtl_fw_cb);
if (err) {
@@ -284,7 +285,6 @@ static const struct rtl_hal_cfg rtl88ee_hal_cfg = {
.bar_id = 2,
.write_readback = true,
.name = "rtl88e_pci",
- .fw_name = "rtlwifi/rtl8188efw.bin",
.ops = &rtl8188ee_hal_ops,
.mod_params = &rtl88ee_mod_params,
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/sw.c b/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/sw.c
index 5c46a98..691ddef 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/sw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/sw.c
@@ -92,6 +92,7 @@ int rtl92c_init_sw_vars(struct ieee80211_hw *hw)
struct rtl_priv *rtlpriv = rtl_priv(hw);
struct rtl_pci *rtlpci = rtl_pcidev(rtl_pcipriv(hw));
struct rtl_hal *rtlhal = rtl_hal(rtl_priv(hw));
+ char *fw_name = "rtlwifi/rtl8192cfwU.bin";
rtl8192ce_bt_reg_init(hw);
@@ -163,15 +164,12 @@ int rtl92c_init_sw_vars(struct ieee80211_hw *hw)
}
/* request fw */
- if (IS_VENDOR_UMC_A_CUT(rtlhal->version) &&
- !IS_92C_SERIAL(rtlhal->version))
- rtlpriv->cfg->fw_name = "rtlwifi/rtl8192cfwU.bin";
- else if (IS_81XXC_VENDOR_UMC_B_CUT(rtlhal->version))
- rtlpriv->cfg->fw_name = "rtlwifi/rtl8192cfwU_B.bin";
+ if (IS_81XXC_VENDOR_UMC_B_CUT(rtlhal->version))
+ fw_name = "rtlwifi/rtl8192cfwU_B.bin";
rtlpriv->max_fw_size = 0x4000;
- pr_info("Using firmware %s\n", rtlpriv->cfg->fw_name);
- err = request_firmware_nowait(THIS_MODULE, 1, rtlpriv->cfg->fw_name,
+ pr_info("Using firmware %s\n", fw_name);
+ err = request_firmware_nowait(THIS_MODULE, 1, fw_name,
rtlpriv->io.dev, GFP_KERNEL, hw,
rtl_fw_cb);
if (err) {
@@ -258,7 +256,6 @@ static const struct rtl_hal_cfg rtl92ce_hal_cfg = {
.bar_id = 2,
.write_readback = true,
.name = "rtl92c_pci",
- .fw_name = "rtlwifi/rtl8192cfw.bin",
.ops = &rtl8192ce_hal_ops,
.mod_params = &rtl92ce_mod_params,
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/sw.c b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/sw.c
index 92588e0..b84e13a 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/sw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/sw.c
@@ -55,6 +55,7 @@ static int rtl92cu_init_sw_vars(struct ieee80211_hw *hw)
{
struct rtl_priv *rtlpriv = rtl_priv(hw);
int err;
+ char *fw_name;
rtlpriv->dm.dm_initialgain_enable = true;
rtlpriv->dm.dm_flag = 0;
@@ -73,18 +74,18 @@ static int rtl92cu_init_sw_vars(struct ieee80211_hw *hw)
}
if (IS_VENDOR_UMC_A_CUT(rtlpriv->rtlhal.version) &&
!IS_92C_SERIAL(rtlpriv->rtlhal.version)) {
- rtlpriv->cfg->fw_name = "rtlwifi/rtl8192cufw_A.bin";
+ fw_name = "rtlwifi/rtl8192cufw_A.bin";
} else if (IS_81XXC_VENDOR_UMC_B_CUT(rtlpriv->rtlhal.version)) {
- rtlpriv->cfg->fw_name = "rtlwifi/rtl8192cufw_B.bin";
+ fw_name = "rtlwifi/rtl8192cufw_B.bin";
} else {
- rtlpriv->cfg->fw_name = "rtlwifi/rtl8192cufw_TMSC.bin";
+ fw_name = "rtlwifi/rtl8192cufw_TMSC.bin";
}
/* provide name of alternative file */
rtlpriv->cfg->alt_fw_name = "rtlwifi/rtl8192cufw.bin";
- pr_info("Loading firmware %s\n", rtlpriv->cfg->fw_name);
+ pr_info("Loading firmware %s\n", fw_name);
rtlpriv->max_fw_size = 0x4000;
err = request_firmware_nowait(THIS_MODULE, 1,
- rtlpriv->cfg->fw_name, rtlpriv->io.dev,
+ fw_name, rtlpriv->io.dev,
GFP_KERNEL, hw, rtl_fw_cb);
return err;
}
@@ -183,7 +184,6 @@ static struct rtl_hal_usbint_cfg rtl92cu_interface_cfg = {
static struct rtl_hal_cfg rtl92cu_hal_cfg = {
.name = "rtl92c_usb",
- .fw_name = "rtlwifi/rtl8192cufw.bin",
.ops = &rtl8192cu_hal_ops,
.mod_params = &rtl92cu_mod_params,
.usb_interface_cfg = &rtl92cu_interface_cfg,
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192de/sw.c b/drivers/net/wireless/realtek/rtlwifi/rtl8192de/sw.c
index a9c39eb..2d65e40 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192de/sw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192de/sw.c
@@ -88,6 +88,7 @@ static int rtl92d_init_sw_vars(struct ieee80211_hw *hw)
u8 tid;
struct rtl_priv *rtlpriv = rtl_priv(hw);
struct rtl_pci *rtlpci = rtl_pcidev(rtl_pcipriv(hw));
+ char *fw_name = "rtlwifi/rtl8192defw.bin";
rtlpriv->dm.dm_initialgain_enable = true;
rtlpriv->dm.dm_flag = 0;
@@ -177,10 +178,10 @@ static int rtl92d_init_sw_vars(struct ieee80211_hw *hw)
rtlpriv->max_fw_size = 0x8000;
pr_info("Driver for Realtek RTL8192DE WLAN interface\n");
- pr_info("Loading firmware file %s\n", rtlpriv->cfg->fw_name);
+ pr_info("Loading firmware file %s\n", fw_name);
/* request fw */
- err = request_firmware_nowait(THIS_MODULE, 1, rtlpriv->cfg->fw_name,
+ err = request_firmware_nowait(THIS_MODULE, 1, fw_name,
rtlpriv->io.dev, GFP_KERNEL, hw,
rtl_fw_cb);
if (err) {
@@ -262,7 +263,6 @@ static const struct rtl_hal_cfg rtl92de_hal_cfg = {
.bar_id = 2,
.write_readback = true,
.name = "rtl8192de",
- .fw_name = "rtlwifi/rtl8192defw.bin",
.ops = &rtl8192de_hal_ops,
.mod_params = &rtl92de_mod_params,
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/sw.c b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/sw.c
index ac299cb..46b605de3 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/sw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/sw.c
@@ -91,6 +91,7 @@ int rtl92ee_init_sw_vars(struct ieee80211_hw *hw)
struct rtl_priv *rtlpriv = rtl_priv(hw);
struct rtl_pci *rtlpci = rtl_pcidev(rtl_pcipriv(hw));
int err = 0;
+ char *fw_name;
rtl92ee_bt_reg_init(hw);
rtlpci->msi_support = rtlpriv->cfg->mod_params->msi_support;
@@ -170,11 +171,11 @@ int rtl92ee_init_sw_vars(struct ieee80211_hw *hw)
}
/* request fw */
- rtlpriv->cfg->fw_name = "rtlwifi/rtl8192eefw.bin";
+ fw_name = "rtlwifi/rtl8192eefw.bin";
rtlpriv->max_fw_size = 0x8000;
- pr_info("Using firmware %s\n", rtlpriv->cfg->fw_name);
- err = request_firmware_nowait(THIS_MODULE, 1, rtlpriv->cfg->fw_name,
+ pr_info("Using firmware %s\n", fw_name);
+ err = request_firmware_nowait(THIS_MODULE, 1, fw_name,
rtlpriv->io.dev, GFP_KERNEL, hw,
rtl_fw_cb);
if (err) {
@@ -266,7 +267,6 @@ static const struct rtl_hal_cfg rtl92ee_hal_cfg = {
.bar_id = 2,
.write_readback = true,
.name = "rtl92ee_pci",
- .fw_name = "rtlwifi/rtl8192eefw.bin",
.ops = &rtl8192ee_hal_ops,
.mod_params = &rtl92ee_mod_params,
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192se/sw.c b/drivers/net/wireless/realtek/rtlwifi/rtl8192se/sw.c
index a652d45..998cefb 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192se/sw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192se/sw.c
@@ -85,12 +85,13 @@ static void rtl92se_fw_cb(const struct firmware *firmware, void *context)
struct ieee80211_hw *hw = context;
struct rtl_priv *rtlpriv = rtl_priv(hw);
struct rt_firmware *pfirmware = NULL;
+ char *fw_name = "rtlwifi/rtl8192sefw.bin";
RT_TRACE(rtlpriv, COMP_ERR, DBG_LOUD,
"Firmware callback routine entered!\n");
complete(&rtlpriv->firmware_loading_complete);
if (!firmware) {
- pr_err("Firmware %s not available\n", rtlpriv->cfg->fw_name);
+ pr_err("Firmware %s not available\n", fw_name);
rtlpriv->max_fw_size = 0;
return;
}
@@ -113,6 +114,7 @@ static int rtl92s_init_sw_vars(struct ieee80211_hw *hw)
struct rtl_pci *rtlpci = rtl_pcidev(rtl_pcipriv(hw));
int err = 0;
u16 earlyrxthreshold = 7;
+ char *fw_name = "rtlwifi/rtl8192sefw.bin";
rtlpriv->dm.dm_initialgain_enable = true;
rtlpriv->dm.dm_flag = 0;
@@ -210,9 +212,9 @@ static int rtl92s_init_sw_vars(struct ieee80211_hw *hw)
rtlpriv->max_fw_size = RTL8190_MAX_FIRMWARE_CODE_SIZE*2 +
sizeof(struct fw_hdr);
pr_info("Driver for Realtek RTL8192SE/RTL8191SE\n"
- "Loading firmware %s\n", rtlpriv->cfg->fw_name);
+ "Loading firmware %s\n", fw_name);
/* request fw */
- err = request_firmware_nowait(THIS_MODULE, 1, rtlpriv->cfg->fw_name,
+ err = request_firmware_nowait(THIS_MODULE, 1, fw_name,
rtlpriv->io.dev, GFP_KERNEL, hw,
rtl92se_fw_cb);
if (err) {
@@ -306,7 +308,6 @@ static const struct rtl_hal_cfg rtl92se_hal_cfg = {
.bar_id = 1,
.write_readback = false,
.name = "rtl92s_pci",
- .fw_name = "rtlwifi/rtl8192sefw.bin",
.ops = &rtl8192se_hal_ops,
.mod_params = &rtl92se_mod_params,
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/sw.c b/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/sw.c
index 89c828a..c51a9e8 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/sw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/sw.c
@@ -94,6 +94,7 @@ int rtl8723e_init_sw_vars(struct ieee80211_hw *hw)
struct rtl_pci *rtlpci = rtl_pcidev(rtl_pcipriv(hw));
struct rtl_hal *rtlhal = rtl_hal(rtl_priv(hw));
int err = 0;
+ char *fw_name = "rtlwifi/rtl8723fw.bin";
rtl8723e_bt_reg_init(hw);
@@ -176,14 +177,12 @@ int rtl8723e_init_sw_vars(struct ieee80211_hw *hw)
return 1;
}
- if (IS_VENDOR_8723_A_CUT(rtlhal->version))
- rtlpriv->cfg->fw_name = "rtlwifi/rtl8723fw.bin";
- else if (IS_81xxC_VENDOR_UMC_B_CUT(rtlhal->version))
- rtlpriv->cfg->fw_name = "rtlwifi/rtl8723fw_B.bin";
+ if (IS_81xxC_VENDOR_UMC_B_CUT(rtlhal->version))
+ fw_name = "rtlwifi/rtl8723fw_B.bin";
rtlpriv->max_fw_size = 0x6000;
- pr_info("Using firmware %s\n", rtlpriv->cfg->fw_name);
- err = request_firmware_nowait(THIS_MODULE, 1, rtlpriv->cfg->fw_name,
+ pr_info("Using firmware %s\n", fw_name);
+ err = request_firmware_nowait(THIS_MODULE, 1, fw_name,
rtlpriv->io.dev, GFP_KERNEL, hw,
rtl_fw_cb);
if (err) {
@@ -280,7 +279,6 @@ static const struct rtl_hal_cfg rtl8723e_hal_cfg = {
.bar_id = 2,
.write_readback = true,
.name = "rtl8723e_pci",
- .fw_name = "rtlwifi/rtl8723efw.bin",
.ops = &rtl8723e_hal_ops,
.mod_params = &rtl8723e_mod_params,
.maps[SYS_ISO_CTRL] = REG_SYS_ISO_CTRL,
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/sw.c b/drivers/net/wireless/realtek/rtlwifi/rtl8723be/sw.c
index 20b53f0..847644d 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/sw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723be/sw.c
@@ -91,6 +91,7 @@ int rtl8723be_init_sw_vars(struct ieee80211_hw *hw)
struct rtl_priv *rtlpriv = rtl_priv(hw);
struct rtl_pci *rtlpci = rtl_pcidev(rtl_pcipriv(hw));
struct rtl_mac *mac = rtl_mac(rtl_priv(hw));
+ char *fw_name = "rtlwifi/rtl8723befw.bin";
rtl8723be_bt_reg_init(hw);
rtlpriv->btcoexist.btc_ops = rtl_btc_get_ops_pointer();
@@ -184,8 +185,8 @@ int rtl8723be_init_sw_vars(struct ieee80211_hw *hw)
}
rtlpriv->max_fw_size = 0x8000;
- pr_info("Using firmware %s\n", rtlpriv->cfg->fw_name);
- err = request_firmware_nowait(THIS_MODULE, 1, rtlpriv->cfg->fw_name,
+ pr_info("Using firmware %s\n", fw_name);
+ err = request_firmware_nowait(THIS_MODULE, 1, fw_name,
rtlpriv->io.dev, GFP_KERNEL, hw,
rtl_fw_cb);
if (err) {
@@ -280,7 +281,6 @@ static const struct rtl_hal_cfg rtl8723be_hal_cfg = {
.bar_id = 2,
.write_readback = true,
.name = "rtl8723be_pci",
- .fw_name = "rtlwifi/rtl8723befw.bin",
.ops = &rtl8723be_hal_ops,
.mod_params = &rtl8723be_mod_params,
.maps[SYS_ISO_CTRL] = REG_SYS_ISO_CTRL,
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/sw.c b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/sw.c
index 22f687b1..297938e 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/sw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/sw.c
@@ -93,6 +93,7 @@ int rtl8821ae_init_sw_vars(struct ieee80211_hw *hw)
struct rtl_pci *rtlpci = rtl_pcidev(rtl_pcipriv(hw));
struct rtl_mac *mac = rtl_mac(rtl_priv(hw));
struct rtl_hal *rtlhal = rtl_hal(rtl_priv(hw));
+ char *fw_name, *wowlan_fw_name;
rtl8821ae_bt_reg_init(hw);
rtlpriv->btcoexist.btc_ops = rtl_btc_get_ops_pointer();
@@ -203,17 +204,17 @@ int rtl8821ae_init_sw_vars(struct ieee80211_hw *hw)
}
if (rtlhal->hw_type == HARDWARE_TYPE_RTL8812AE) {
- rtlpriv->cfg->fw_name = "rtlwifi/rtl8812aefw.bin";
- rtlpriv->cfg->wowlan_fw_name = "rtlwifi/rtl8812aefw_wowlan.bin";
+ fw_name = "rtlwifi/rtl8812aefw.bin";
+ wowlan_fw_name = "rtlwifi/rtl8812aefw_wowlan.bin";
} else {
- rtlpriv->cfg->fw_name = "rtlwifi/rtl8821aefw.bin";
- rtlpriv->cfg->wowlan_fw_name = "rtlwifi/rtl8821aefw_wowlan.bin";
+ fw_name = "rtlwifi/rtl8821aefw.bin";
+ wowlan_fw_name = "rtlwifi/rtl8821aefw_wowlan.bin";
}
rtlpriv->max_fw_size = 0x8000;
/*load normal firmware*/
- pr_info("Using firmware %s\n", rtlpriv->cfg->fw_name);
- err = request_firmware_nowait(THIS_MODULE, 1, rtlpriv->cfg->fw_name,
+ pr_info("Using firmware %s\n", fw_name);
+ err = request_firmware_nowait(THIS_MODULE, 1, fw_name,
rtlpriv->io.dev, GFP_KERNEL, hw,
rtl_fw_cb);
if (err) {
@@ -222,9 +223,9 @@ int rtl8821ae_init_sw_vars(struct ieee80211_hw *hw)
return 1;
}
/*load wowlan firmware*/
- pr_info("Using firmware %s\n", rtlpriv->cfg->wowlan_fw_name);
+ pr_info("Using firmware %s\n", wowlan_fw_name);
err = request_firmware_nowait(THIS_MODULE, 1,
- rtlpriv->cfg->wowlan_fw_name,
+ wowlan_fw_name,
rtlpriv->io.dev, GFP_KERNEL, hw,
rtl_wowlan_fw_cb);
if (err) {
@@ -320,7 +321,6 @@ static const struct rtl_hal_cfg rtl8821ae_hal_cfg = {
.bar_id = 2,
.write_readback = true,
.name = "rtl8821ae_pci",
- .fw_name = "rtlwifi/rtl8821aefw.bin",
.ops = &rtl8821ae_hal_ops,
.mod_params = &rtl8821ae_mod_params,
.maps[SYS_ISO_CTRL] = REG_SYS_ISO_CTRL,
diff --git a/drivers/net/wireless/realtek/rtlwifi/wifi.h b/drivers/net/wireless/realtek/rtlwifi/wifi.h
index 595f7d5..dafe486 100644
--- a/drivers/net/wireless/realtek/rtlwifi/wifi.h
+++ b/drivers/net/wireless/realtek/rtlwifi/wifi.h
@@ -2278,9 +2278,7 @@ struct rtl_hal_cfg {
u8 bar_id;
bool write_readback;
char *name;
- char *fw_name;
char *alt_fw_name;
- char *wowlan_fw_name;
struct rtl_hal_ops *ops;
struct rtl_mod_params *mod_params;
struct rtl_hal_usbint_cfg *usb_interface_cfg;
--
2.10.0
^ permalink raw reply related
* Re: [PATCH] rtlwifi: Fix regression caused by commit d86e64768859
From: Larry Finger @ 2016-10-12 18:53 UTC (permalink / raw)
To: Kalle Valo; +Cc: devel, linux-wireless, Stable [ 4 . 8+ ], Julia Lawall
In-Reply-To: <87zim9cxtt.fsf@kamboji.qca.qualcomm.com>
On 10/12/2016 11:54 AM, Kalle Valo wrote:
> Larry Finger <Larry.Finger@lwfinger.net> writes:
>
>> In commit d86e64768859 ("rtlwifi: rtl818x: constify local structures"),
>> the configuration struct for most of the drivers was changed to be
>> constant. The problem is that five of the modified drivers need to be
>> able to update the firmware name based on the exact model of the card.
>> As the file names were stored in one of the members of that struct,
>> these drivers would fail with a kernel BUG splat when they tried to
>> update the firmware name.
>>
>> Rather than reverting the previous commit, I used a suggestion by
>> Johannes Berg and made the firmware file name pointers be local to
>> the routines that update the software variables.
>>
>> The configuration struct of rtl8192cu, which was not touched in the
>> previous patch, is now constantfied.
>>
>> Fixes: d86e64768859 ("rtlwifi: rtl818x: constify local structures")
>> Suggested-by: Johannes Berg <johannes@sipsolutions.net>
>> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
>> Cc: Stable [4.8+] <stable@vger.kernel.org>
>> Cc: Julia Lawall <Julia.Lawall@lip6.fr>
>
> I got warnings and after a quick look they look valid but not sure:
>
> drivers/net/wireless/realtek/rtlwifi/rtl8192ce/sw.c: In function 'rtl92c_init_sw_vars':
> drivers/net/wireless/realtek/rtlwifi/rtl8192ce/sw.c:179:6: warning: 'fw_name' may be used uninitialized in this function [-Wuninitialized]
> drivers/net/wireless/realtek/rtlwifi/rtl8723ae/sw.c: In function 'rtl8723e_init_sw_vars':
> drivers/net/wireless/realtek/rtlwifi/rtl8723ae/sw.c:187:6: warning: 'fw_name' may be used uninitialized in this function [-Wuninitialized]
>
> (Sending manually for the second time as I don't see my first mail
> anywhere.)
Kalle,
I did receive the first one. My compiler failed to show that warning, but I have
modified the patch to fix the warnings you see. In fact, the new version is a
bit cleaner in that "if () ... else if () ..." constructions are replaced by
simple if statements.
V2 will be sent shortly.
Larry
^ permalink raw reply
* Re: bcmdhd: Strange Power Save messages
From: Arend van Spriel @ 2016-10-12 18:48 UTC (permalink / raw)
To: Gucea Doru
Cc: Krishna Chaitanya, Arend van Spriel, Andra Paraschiv,
linux-wireless
In-Reply-To: <CANfLQrau67GtkyPeT9MqEu3SAC_xjrCuAywU6yRoHGfvAyJ30g@mail.gmail.com>
On 12-10-16 16:26, Gucea Doru wrote:
> On Tue, Oct 11, 2016 at 10:12 PM, Arend van Spriel
> <arend.vanspriel@broadcom.com> wrote:
>> On 07-10-16 16:33, Gucea Doru wrote:
>>> On Thu, Oct 6, 2016 at 10:25 AM, Arend Van Spriel
>>> <arend.vanspriel@broadcom.com> wrote:
>>>> On 6-10-2016 10:07, Gucea Doru wrote:
>>>>> On Wed, Oct 5, 2016 at 11:12 AM, Arend Van Spriel
>>>>> <arend.vanspriel@broadcom.com> wrote:
>>>>>> On 4-10-2016 13:39, Gucea Doru wrote:
>>>>>>> On Sat, Oct 1, 2016 at 2:52 PM, Arend van Spriel
>>>>>>>> <arend.vanspriel@broadcom.com> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 29-09-16 13:32, Gucea Doru wrote:
>>>>>>>>>> On Tue, Sep 27, 2016 at 12:03 PM, Gucea Doru <gucea.doru@gmail.com> wrote:
>>>>>>>>>>> What is the decision triggering the exit from the PS mode immediately
>>>>>>>>>>> after the ping request? I am asking this because 802.11 PS legacy
>>>>>>>>>>> specifies that the client should wait for a beacon with TIM set in
>>>>>>>>>>> order to wake up: in my case, there is no beacon between the ping
>>>>>>>>>>> request message and the Null frame that announces the exit from the PS
>>>>>>>>>>> mode.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Any help would be highly appreciated :)
>>>>>>>>>
>>>>>>>>> Actually though I already sent you are reply, but alas here it is.
>>>>>>>>>
>>>>>>>>> bcmdhd is our aosp driver. I am maintaining the upstream brcm80211
>>>>>>>>> drivers. Regardless your question is more for firmware running on the
>>>>>>>>> device. So like the same behavior would be observed when using brcmfmac
>>>>>>>>> with same firmware.
>>>>>>>>>
>>>>>>>>>> IEEE Std 802.11-2012, section 10.2.1.8 specifies that "when the STA
>>>>>>>>>> detects that the bit corresponding to its AID is 1 i the TIM, the STA
>>>>>>>>>> shall issue a PS Poll". In my capture there are cases when the STA
>>>>>>>>>> exits the PS mode without waiting for a beacon.
>>>>>>>>>
>>>>>>>>> It is a bit tricky, but the standard does not explicitly say the STA
>>>>>>>>> should be in power-save at any other time. So it is difficult to say
>>>>>>>>> what event occurred on the STA side to exit PS mode. Also STA means
>>>>>>>>> P2P-Client as you say. That means that you have multiple interfaces:
>>>>>>>>> regular STA and P2P-Client. So is the STA connected to some other AP or
>>>>>>>>> just not connected. wpa_supplicant will do intermittent scan or initiate
>>>>>>>>> scheduled scan by which firmware will scan at a certain interval. That
>>>>>>>>> is just some things I can come up with and I am sure there are more.
>>>>>>>
>>>>>>> I agree that there may be some events belonging to the regular STA
>>>>>>> interface that could trigger the Null Frame (which includes the exit
>>>>>>> from PS Mode). However, I would expect to see some management frames
>>>>>>> in the air before/after the Null Packet (e.g.: a Probe request in case
>>>>>>> of a scheduled scan). But in my case the trigger for the Null frame
>>>>>>> seems to be the ping request packet, the scenario is the same every
>>>>>>> time: ping request -> Block ACK -> Null Frame (Wireshark trace
>>>>>>> confirms this behavior).
>>>>>>>
>>>>>>> I thought that you had a power save optimization algorithm that keeps
>>>>>>> the card on a few milliseconds just to see if we can have a fast reply
>>>>>>> from the peer. Does this ring a bell? :)
>>>>>>
>>>>>> It does not. That would be implemented in firmware. As said I am working
>>>>>> on brcmfmac/brcmsmac. So bcmdhd and firmware are not my expertise.
>>>>>>
>>>>>
>>>>> Arend, could you please redirect me to a Broadcom firmware maintainer?
>>>>
>>>> Can you please elaborate on your platform, broadcom chipset, and what
>>>> version of bcmdhd you are using.
>>>>
>>>
>>> Platform: Nexus 5 running CM13 (Android 6.0.1)
>>> Broadcom chipset: BCM4339 Wi-Fi Chipset
>>> bcmdhd version:Dongle Host Driver, version 1.88.45 (r)
>>>
>>> Do you need more information?
>>
>> So can you indicate the mac addresses of the two nexus devices and which
>> one is P2P-GO. I entered the wpa key you mentioned in your initial
>> email, but my wireshark does not seem to be able to decrypt the packets,
>> which makes it a bit harder to analyze.
>
> Do you have a wpa-pwd entry "JYdrhZp3:DIRECT-35-Android_Intel" inside
> Edit->Preferences->Protocols->IEEE 802.11->Decryption Keys? I use
> Wireshark 2.0.4.
I see. I only entered the password but not the SSID. The examples showed
SSID was optional. Changed it, but still no luck using 2.2.0.
> P2P-GO MAC: 66:89:9a:81:0d:95
> P2P Client MAC: 66:89:9a:81:0f:20
Actually this was redundant question as it is clear which one sends the
beacon frames. Thanks anyway :-)
Regards,
Arend
> Thanks,
> Doru
>
^ permalink raw reply
* Re: [PATCH] iwlwifi: pcie: reduce "unsupported splx" to a warning
From: Chris Rorvick @ 2016-10-12 18:36 UTC (permalink / raw)
To: Paul Bolle
Cc: Luca Coelho, Intel Linux Wireless, Emmanuel Grumbach,
Johannes Berg, Kalle Valo, Oren Givon, linux-wireless, netdev,
linux-kernel
In-Reply-To: <1476295541.9670.26.camel@tiscali.nl>
On Wed, Oct 12, 2016 at 1:05 PM, Paul Bolle <pebolle@tiscali.nl> wrote:
> On Wed, 2016-10-12 at 12:50 -0500, Chris Rorvick wrote:
>> This may already be apparent, but Dell sells two versions of the 9350:
>> one with the Broadcom adapter and one with the AC 8260.
>
> Off topic, for most readers: my version (with the AC 8260) came with
> Ubuntu preinstalled. Perhaps Chris' version came preinstalled with
> something else?
Exactly. Mine came with Windows 10 and the Broadcom adapter, while
the "Developer Edition" comes preloaded with Ubuntu and has the AC
8260. The Broadcom adapter has been supported since 4.4 but still
seems to have issues. For example, I had it working at home but I was
not able to connect to a friend's AT&T U-Verse wireless gateway;
something was failing with -EBUSY. I ordered the AC 8260 and it works
fine after the upgrade.
Chris
^ permalink raw reply
* Re: [PATCH] iwlwifi: pcie: reduce "unsupported splx" to a warning
From: Paul Bolle @ 2016-10-12 18:05 UTC (permalink / raw)
To: Chris Rorvick, Luca Coelho
Cc: Intel Linux Wireless, Emmanuel Grumbach, Johannes Berg,
Kalle Valo, Oren Givon, linux-wireless, netdev, linux-kernel
In-Reply-To: <CAEUsAPYYJ3Gmh0T16veCn3wnzdD8bTxE+_U-AUYQpMo3TUd4Mg@mail.gmail.com>
On Wed, 2016-10-12 at 12:50 -0500, Chris Rorvick wrote:
> This may already be apparent, but Dell sells two versions of the 9350:
> one with the Broadcom adapter and one with the AC 8260.
Off topic, for most readers: my version (with the AC 8260) came with
Ubuntu preinstalled. Perhaps Chris' version came preinstalled with
something else?
Thanks,
Paul Bolle
^ permalink raw reply
* Re: [PATCH] iwlwifi: pcie: reduce "unsupported splx" to a warning
From: Chris Rorvick @ 2016-10-12 17:50 UTC (permalink / raw)
To: Paul Bolle, Luca Coelho
Cc: Intel Linux Wireless, Emmanuel Grumbach, Johannes Berg,
Kalle Valo, Oren Givon, linux-wireless, netdev, linux-kernel
In-Reply-To: <1476255135.1972.5.camel@tiscali.nl>
Hi Luca,
FYI, It seems that Google does not like your email as I'm not
receiving any of your messages in gmail. Some responses below:
On Wed, 2016-10-12 at 15:24 +0300, Luca Coelho wrote:
> Hi Chris,
> On Tue, 2016-10-11 at 09:09 -0500, Chris Rorvick wrote:
> > On Tue, Oct 11, 2016 at 5:11 AM, Paul Bolle <pebolle [at] tiscali> wrot=
e:
> > > > This is not coming from the NIC itself, but from the platform's ACP=
I
> > > > tables. Can you tell us which platform you are using?
> >
> > Interesting. I'm running a Dell XPS 13 9350. I replaced the
> > factory-provided Broadcom card with an AC 8260. I can update the
> > commit log to reflect this.
>
> Okay, so this makes sense. Those entries are probably formatted for
> the Broadcom card, which the iwlwifi driver obviously doesn't
> understand. The best we can do, as I already said, is to ignore values
> we don't understand.
This may already be apparent, but Dell sells two versions of the 9350:
one with the Broadcom adapter and one with the AC 8260. I just
happened to find the former version at a deep discount at Costco so
decided to chance it. Turns out the Broadcom card is not so good even
with new kernels so I upgraded. Anyway, since Paul is seeing the same
issue I don't think the values are intended to be Broadcom-specific.
On Wed, 2016-10-12 at 17:21 +0300, Luca Coelho wrote:
> And, the values in the SPLX structs are being changed here, to DOM1,
> LIM1, TIM1 etc., before being returned. =C3=82 This also matches your
> description that, at runtime, you got something different than the pure
> dump. =C3=82 If you follow these DOM*, LIM*, TIM* symbols, you'll probabl=
y
> end up getting the values you observed at runtime.
Probably not important, but it seems that there is some additional
indirection. The only values I'm seeing associated with those symbols
are 8 and 16:
$ grep -e 'DOM[0-9]' -e 'LIM[0-9]' -e 'TIM[0-9]' dsdt.dsl | grep -v Sto=
re
DOM1, 8,
LIM1, 16,
TIM1, 16,
DOM2, 8,
LIM2, 16,
TIM2, 16,
DOM3, 8,
LIM3, 16,
TIM3, 16,
> I'll send you a patch for testing soon.
I will keep an eye on the list archive, thanks!
Chris
^ permalink raw reply
* Re: rtlwifi: Fix regression caused by commit d86e64768859
From: Kalle Valo @ 2016-10-12 16:45 UTC (permalink / raw)
To: Larry Finger
Cc: devel, linux-wireless, Larry Finger, Stable [ 4 . 8+ ],
Julia Lawall
In-Reply-To: <20161010233211.13519-1-Larry.Finger@lwfinger.net>
Larry Finger <Larry.Finger@lwfinger.net> wrote:
> In commit d86e64768859 ("rtlwifi: rtl818x: constify local structures"),
> the configuration struct for most of the drivers was changed to be
> constant. The problem is that five of the modified drivers need to be
> able to update the firmware name based on the exact model of the card.
> As the file names were stored in one of the members of that struct,
> these drivers would fail with a kernel BUG splat when they tried to
> update the firmware name.
>
> Rather than reverting the previous commit, I used a suggestion by
> Johannes Berg and made the firmware file name pointers be local to
> the routines that update the software variables.
>
> The configuration struct of rtl8192cu, which was not touched in the
> previous patch, is now constantfied.
>
> Fixes: d86e64768859 ("rtlwifi: rtl818x: constify local structures")
> Cc: Stable <stable@vger.kernel.org> # 4.8
> Cc: Julia Lawall <Julia.Lawall@lip6.fr>
> Suggested-by: Johannes Berg <johannes@sipsolutions.net>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
I got warnings and after a quick look they look valid but not sure:
drivers/net/wireless/realtek/rtlwifi/rtl8192ce/sw.c: In function ‘rtl92c_init_sw_vars’:
drivers/net/wireless/realtek/rtlwifi/rtl8192ce/sw.c:179:6: warning: ‘fw_name’ may be used uninitialized in this function [-Wuninitialized]
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/sw.c: In function ‘rtl8723e_init_sw_vars’:
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/sw.c:187:6: warning: ‘fw_name’ may be used uninitialized in this function [-Wuninitialized]
--
https://patchwork.kernel.org/patch/9370013/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] docs-rst: sphinxify 802.11 documentation
From: Jonathan Corbet @ 2016-10-12 17:20 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1476223710.4118.12.camel@sipsolutions.net>
On Wed, 12 Oct 2016 00:08:30 +0200
Johannes Berg <johannes@sipsolutions.net> wrote:
> > As an alternative, one or the other of us could just send it up in
> > the next couple of days and be done with it. I'd say the chances of
> > regressions are pretty small...:) If you want to do that, feel free
> > to add my ack. If you'd rather I sent it, just say the word.
>
> Ok, fair enough. Please go ahead, I'll ask davem to pull it back in
> when I need it. You'll get it through to Linus quicker than me :)
OK, I'll let it sit in linux-next for a day or two just to observe the
niceties, then upward it goes.
Thanks,
jon
^ permalink raw reply
* Re: [PATCH] rtlwifi: Fix regression caused by commit d86e64768859
From: Kalle Valo @ 2016-10-12 16:54 UTC (permalink / raw)
To: Larry Finger; +Cc: devel, linux-wireless, Stable [ 4 . 8+ ], Julia Lawall
In-Reply-To: <20161010233211.13519-1-Larry.Finger@lwfinger.net>
Larry Finger <Larry.Finger@lwfinger.net> writes:
> In commit d86e64768859 ("rtlwifi: rtl818x: constify local structures"),
> the configuration struct for most of the drivers was changed to be
> constant. The problem is that five of the modified drivers need to be
> able to update the firmware name based on the exact model of the card.
> As the file names were stored in one of the members of that struct,
> these drivers would fail with a kernel BUG splat when they tried to
> update the firmware name.
>
> Rather than reverting the previous commit, I used a suggestion by
> Johannes Berg and made the firmware file name pointers be local to
> the routines that update the software variables.
>
> The configuration struct of rtl8192cu, which was not touched in the
> previous patch, is now constantfied.
>
> Fixes: d86e64768859 ("rtlwifi: rtl818x: constify local structures")
> Suggested-by: Johannes Berg <johannes@sipsolutions.net>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> Cc: Stable [4.8+] <stable@vger.kernel.org>
> Cc: Julia Lawall <Julia.Lawall@lip6.fr>
I got warnings and after a quick look they look valid but not sure:
drivers/net/wireless/realtek/rtlwifi/rtl8192ce/sw.c: In function 'rtl92c_init_sw_vars':
drivers/net/wireless/realtek/rtlwifi/rtl8192ce/sw.c:179:6: warning: 'fw_name' may be used uninitialized in this function [-Wuninitialized]
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/sw.c: In function 'rtl8723e_init_sw_vars':
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/sw.c:187:6: warning: 'fw_name' may be used uninitialized in this function [-Wuninitialized]
(Sending manually for the second time as I don't see my first mail
anywhere.)
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v2] mac80211: fix A-MSDU outer SA/DA
From: michael-dev @ 2016-10-12 16:31 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, projekt-wlan, Felix Fietkau
In-Reply-To: <1476275121.5271.28.camel@sipsolutions.net>
Am 12.10.2016 14:25, schrieb Johannes Berg:
> So, I actually think my first instinct that you were erroneously
> changing the inner header *was* right.
You're right.
> Seems like this code should be inserted towards the end of
> ieee80211_amsdu_aggregate() instead, where it's adding the RFC 1042
> header?
I'm not convinced.
ieee80211_amsdu_aggregate handles two skbs: the "skb" var and the "head"
var.
The skb is appended to the frag list of head by setting frag_tail and
does not appear to have an ieee80211_hdr, as memmove is only 2 *
ETH_ALEN. Additionally, the rfc1042_header is written after 2 bytes
containing subframe_len, so it looks like an A-MSDU subframe with
rfc1042_header is inserted at the beginning of the inner MSDU.
Only the head skb is processed by ieee80211_amsdu_prepare_head and
appears to have an 802.11 header. So its da/sa address should be
changed.
Regards,
M. Braun
^ permalink raw reply
* Re: [bug report] mac80211: Move reorder-sensitive TX handlers to after TXQ dequeue
From: Toke Høiland-Jørgensen @ 2016-10-12 15:57 UTC (permalink / raw)
To: Dan Carpenter; +Cc: linux-wireless
In-Reply-To: <20161012061458.GM12841@mwanda>
Dan Carpenter <dan.carpenter@oracle.com> writes:
> Hello Toke H=C3=B8iland-J=C3=B8rgensen,
>
> This is a semi-automatic email about new static checker warnings.
>
> The patch bb42f2d13ffc: "mac80211: Move reorder-sensitive TX handlers=20
> to after TXQ dequeue" from Sep 22, 2016, leads to the following=20
> Smatch complaint:
>
> net/mac80211/tx.c:3242 ieee80211_xmit_fast_finish()
> error: we previously assumed 'key' could be null (see line 3209)
>
> net/mac80211/tx.c
> 3208=09
> 3209 if (key)
> ^^^
> Check.
>
> 3210 info->control.hw_key =3D &key->conf;
> 3211=09
> 3212 ieee80211_tx_stats(skb->dev, skb->len);
> 3213=09
> 3214 if (hdr->frame_control & cpu_to_le16(IEEE80211_STYPE_QOS_DATA)) {
> 3215 tid =3D skb->priority & IEEE80211_QOS_CTL_TAG1D_MASK;
> 3216 *ieee80211_get_qos_ctl(hdr) =3D tid;
> 3217 hdr->seq_ctrl =3D ieee80211_tx_next_seq(sta, tid);
> 3218 } else {
> 3219 info->flags |=3D IEEE80211_TX_CTL_ASSIGN_SEQ;
> 3220 hdr->seq_ctrl =3D cpu_to_le16(sdata->sequence_number);
> 3221 sdata->sequence_number +=3D 0x10;
> 3222 }
> 3223=09
> 3224 if (skb_shinfo(skb)->gso_size)
> 3225 sta->tx_stats.msdu[tid] +=3D
> 3226 DIV_ROUND_UP(skb->len, skb_shinfo(skb)->gso_size);
> 3227 else
> 3228 sta->tx_stats.msdu[tid]++;
> 3229=09
> 3230 info->hw_queue =3D sdata->vif.hw_queue[skb_get_queue_mapping(skb)=
];
> 3231=09
> 3232 /* statistics normally done by ieee80211_tx_h_stats (but that
> 3233 * has to consider fragmentation, so is more complex)
> 3234 */
> 3235 sta->tx_stats.bytes[skb_get_queue_mapping(skb)] +=3D skb->len;
> 3236 sta->tx_stats.packets[skb_get_queue_mapping(skb)]++;
> 3237=09
> 3238 if (pn_offs) {
> ^^^^^^^
> Maybe when pn_offs is non-zero that implies key is non-NULL?
Yes, it does. fast_tx->pn_offs is set in ieee80211_check_fast_xmit()
which only sets it if fast_tx->key is set. The other call to
ieee80211_xmit_fast_finish() is in ieee80211_tx_dequeue() which also
only sets pn_offs if the key is set.
-Toke
^ permalink raw reply
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