Am 17.05.2016 um 14:18 schrieb Michal Kazior:
+ re-adding ath10k list
On 17 May 2016 at 14:05, Sebastian Gottschall <s.gottsch...@dd-wrt.com> wrote:
Am 17.05.2016 um 14:00 schrieb Michal Kazior:
On 17 May 2016 at 13:43, Sebastian Gottschall <s.gottsch...@dd-wrt.com> wrote:
Attached you will find a testing patch for VHT160 support. i tested it today
on a QCA9984 device and it seems to work.
feel free to make any corrections
Hi,
Send patches inline, please. Preferably via git send-email. It's a lot
easier to review them this way.
unfortunaty i dont work with git right now and i wanted to send it to
the list first for getting comments.
since the patch is also very small, it should be that complicated
From a quick glance vht capabilities setup looks weird:
if (ar->vht_cap_info & IEEE80211_VHT_CAP_SHORT_GI_160) {
vht_cap.cap |= IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ;
vht_cap.cap |= IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160_80PLUS80MHZ;
}
Why? Is this really necessary?
the firmware does not report correct flags. just SHORT_GI_160.
i reviewed the firmware sourcecodes and found out that this is maybe a
misstake of the QCA developers.
so we need to add the 160MHZ support flags locally using the
SHORT_GI_160 which is always set on QCA9984.
otherwise mac80211 will not be capable of running vht160.
I'm not sure if SGI160 implies 80+80.
according to the firmware sourcecode of 9984 it seems so. thats the only
information source i have
I would expect IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ and
IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160_80PLUS80MHZ to be already set in
ar->vht_cap_info if the chip supports 160 or 80+80.
me too. but it isnt :-)
Sigh. A comment explaining that would be really nice.
there is no comment available. the only information source is the
firmware sourcecode for the 9984 which i reviewed.
let me give you a small snippet
#if defined(CONFIG_160MHZ_SUPPORT)
#define VHT_CAP_WITH_STBC_1SS_VHT160 ((VHT_CAP_WITH_STBC_1SS) |
(WMI_VHT_CAP_SGI_160MHZ))
#define VHT_CAP_WITH_STBC_2SS_VHT160 ((VHT_CAP_WITH_STBC_2SS) |
(WMI_VHT_CAP_SGI_160MHZ))
#define VHT_CAP_WITH_STBC_3SS_VHT160 ((VHT_CAP_WITH_STBC_3SS) |
(WMI_VHT_CAP_SGI_160MHZ))
#endif
#if defined(CONFIG_160MHZ_SUPPORT)
dev_info->vht_cap_info = VHT_CAP_WITH_STBC_1SS_VHT160;
#else
dev_info->vht_cap_info = VHT_CAP_WITH_STBC_1SS_VHT80;
#endif
so the firmware simply does not set the correct flags. thats all.
You also don't seem to handle 80+80 because you just as phymode to 160
regardless of center frequencies:
!ath10k_peer_assoc_h_vht_masked(vht_mcs_mask)) {
if (sta->bandwidth == IEEE80211_STA_RX_BW_80)
phymode = MODE_11AC_VHT80;
else if (sta->bandwidth == IEEE80211_STA_RX_BW_160)
phymode = MODE_11AC_VHT160;
else if (sta->bandwidth == IEEE80211_STA_RX_BW_40)
phymode = MODE_11AC_VHT40;
else if (sta->bandwidth == IEEE80211_STA_RX_BW_20)
there is no 80+80 STA_RX_BW flag. i dont know how to handle this. and
yes, just 160 mhz is tested right now. right now it looks like mac80211
is not 80+80 ready.
Hmm.. I wouldn't advertise 80+80 support then. All the more since
there's no way of telling whether hw/fw actually supports it in the
first place.
we can leave it out at the end, but the firmware seem to support it. so
far i just tested 160 in ap mode yet, but found other
things in ath10k which need to be fixed. i'm on it right now
Michal
--
Mit freundlichen Grüssen / Regards
Sebastian Gottschall / CTO
NewMedia-NET GmbH - DD-WRT
Firmensitz: Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
