| Message ID | 1461244669-19871-1-git-send-email-kvalo@qca.qualcomm.com (mailing list archive) |
|---|---|
| State | Accepted |
| Headers | show |
On 04/21/2016 06:17 AM, Kalle Valo wrote: > From: Johannes Berg <johannes.berg@intel.com> > > According to the spec, VHT doesn't exist in 2.4GHz. > > There are vendor extensions to allow a subset of VHT to work > (notably 256-QAM), but since mac80211 doesn't support those > advertising VHT capability on 2.4GHz leads to the behaviour > of reporting VHT capabilities but not being able to use any > of them due to mac80211's code requiring 80 MHz support. > > Remove the VHT capabilities from 2.4GHz for now. If mac80211 > gets extended to use the (likely Broadcom) vendor IEs for it > and handles the lack of 80 MHz support, it can be added back. > > Signed-off-by: Johannes Berg <johannes.berg@intel.com> > Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com> The thing is, it actually works just fine with the patch I posted to fix mac80211, and at any rate, even if the mac80211 patch isn't applied, the ath10k driver works just fine in HT mode. Have you actually found any case where the existing behaviour causes a real problem? Thanks, Ben
Am 21.04.2016 um 17:15 schrieb Ben Greear: > On 04/21/2016 06:17 AM, Kalle Valo wrote: >> From: Johannes Berg <johannes.berg@intel.com> >> >> According to the spec, VHT doesn't exist in 2.4GHz. >> >> There are vendor extensions to allow a subset of VHT to work >> (notably 256-QAM), but since mac80211 doesn't support those >> advertising VHT capability on 2.4GHz leads to the behaviour >> of reporting VHT capabilities but not being able to use any >> of them due to mac80211's code requiring 80 MHz support. >> >> Remove the VHT capabilities from 2.4GHz for now. If mac80211 >> gets extended to use the (likely Broadcom) vendor IEs for it >> and handles the lack of 80 MHz support, it can be added back. >> >> Signed-off-by: Johannes Berg <johannes.berg@intel.com> >> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com> > > The thing is, it actually works just fine with the patch I posted > to fix mac80211, and at any rate, even if the mac80211 patch isn't > applied, the ath10k driver works just fine in HT mode. > > Have you actually found any case where the existing behaviour causes > a real problem? i agree. other vendor chipsets to support QAM256 as well in 2.4 ghz (notably broadcom) this is nonstandard, but since all going the same way it wouldnt be a great idea to keep QCA out of that extensions. > > Thanks, > Ben >
Also, several vendors are advertising QCA9980 and QCA9984 based access points with 256QAM support in 2.4GHz, such as the TP-Link AD7200 and the Netgear R7800, both of which advertise 800mbps 4-stream 2.4GHz capabilities. > On Apr 21, 2016, at 4:09 PM, Sebastian Gottschall <s.gottschall@dd-wrt.com> wrote: > > Am 21.04.2016 um 17:15 schrieb Ben Greear: >> On 04/21/2016 06:17 AM, Kalle Valo wrote: >>> From: Johannes Berg <johannes.berg@intel.com> >>> >>> According to the spec, VHT doesn't exist in 2.4GHz. >>> >>> There are vendor extensions to allow a subset of VHT to work >>> (notably 256-QAM), but since mac80211 doesn't support those >>> advertising VHT capability on 2.4GHz leads to the behaviour >>> of reporting VHT capabilities but not being able to use any >>> of them due to mac80211's code requiring 80 MHz support. >>> >>> Remove the VHT capabilities from 2.4GHz for now. If mac80211 >>> gets extended to use the (likely Broadcom) vendor IEs for it >>> and handles the lack of 80 MHz support, it can be added back. >>> >>> Signed-off-by: Johannes Berg <johannes.berg@intel.com> >>> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com> >> >> The thing is, it actually works just fine with the patch I posted >> to fix mac80211, and at any rate, even if the mac80211 patch isn't >> applied, the ath10k driver works just fine in HT mode. >> >> Have you actually found any case where the existing behaviour causes >> a real problem? > i agree. other vendor chipsets to support QAM256 as well in 2.4 ghz (notably broadcom) > this is nonstandard, but since all going the same way it wouldnt be a great idea to keep QCA out of that extensions. >> >> Thanks, >> Ben >> > > > _______________________________________________ > ath10k mailing list > ath10k@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/ath10k
On Thu, 2016-04-21 at 08:15 -0700, Ben Greear wrote: > The thing is, it actually works just fine with the patch I posted > to fix mac80211, and at any rate, even if the mac80211 patch isn't > applied, the ath10k driver works just fine in HT mode. This patch has no implications on HT, and I wasn't planning on applying the mac80211 patch. As I said, I have no objections to doing the (Broadcom) vendor specific IEs for "VHT" in 2.4 GHz band, but I don't think we should advertise the spec IEs when they're explicitly specified to be used only in the 5.2 GHz band. johannes
Johannes Berg <johannes@sipsolutions.net> writes: > On Thu, 2016-04-21 at 08:15 -0700, Ben Greear wrote: > >> The thing is, it actually works just fine with the patch I posted >> to fix mac80211, and at any rate, even if the mac80211 patch isn't >> applied, the ath10k driver works just fine in HT mode. > > This patch has no implications on HT, and I wasn't planning on applying > the mac80211 patch. Yeah, makes sense. I'm planning to apply this soon. > As I said, I have no objections to doing the (Broadcom) vendor specific > IEs for "VHT" in 2.4 GHz band, but I don't think we should advertise > the spec IEs when they're explicitly specified to be used only in the > 5.2 GHz band. But we really should have this, any volunteers? :) I think it shouldn't be too hard to do so this would be a good project for someone looking for a simple, but useful, task on wireless stack.
On Tue, Apr 26, 2016 at 5:33 PM, Valo, Kalle <kvalo@qca.qualcomm.com> wrote: > Johannes Berg <johannes@sipsolutions.net> writes: > >> On Thu, 2016-04-21 at 08:15 -0700, Ben Greear wrote: >> >>> The thing is, it actually works just fine with the patch I posted >>> to fix mac80211, and at any rate, even if the mac80211 patch isn't >>> applied, the ath10k driver works just fine in HT mode. >> >> This patch has no implications on HT, and I wasn't planning on applying >> the mac80211 patch. > > Yeah, makes sense. I'm planning to apply this soon. > >> As I said, I have no objections to doing the (Broadcom) vendor specific >> IEs for "VHT" in 2.4 GHz band, but I don't think we should advertise >> the spec IEs when they're explicitly specified to be used only in the >> 5.2 GHz band. > > But we really should have this, any volunteers? :) I think it shouldn't > be too hard to do so this would be a good project for someone looking > for a simple, but useful, task on wireless stack. Are these Broadcom IEs documented somewhere? If yes, then its a matter of parsing them and adding support to minstrel_ht, isn't it? major work would be in minstrel.
On 04/26/2016 01:07 PM, Krishna Chaitanya wrote: > On Tue, Apr 26, 2016 at 5:33 PM, Valo, Kalle <kvalo@qca.qualcomm.com> wrote: >> Johannes Berg <johannes@sipsolutions.net> writes: >> >>> On Thu, 2016-04-21 at 08:15 -0700, Ben Greear wrote: >>> >>>> The thing is, it actually works just fine with the patch I posted >>>> to fix mac80211, and at any rate, even if the mac80211 patch isn't >>>> applied, the ath10k driver works just fine in HT mode. >>> >>> This patch has no implications on HT, and I wasn't planning on applying >>> the mac80211 patch. >> >> Yeah, makes sense. I'm planning to apply this soon. >> >>> As I said, I have no objections to doing the (Broadcom) vendor specific >>> IEs for "VHT" in 2.4 GHz band, but I don't think we should advertise >>> the spec IEs when they're explicitly specified to be used only in the >>> 5.2 GHz band. >> >> But we really should have this, any volunteers? :) I think it shouldn't >> be too hard to do so this would be a good project for someone looking >> for a simple, but useful, task on wireless stack. > Are these Broadcom IEs documented somewhere? If yes, > then its a matter of parsing them and adding support to > minstrel_ht, isn't it? major work would be in minstrel. > For ath10k, rate-ctrl is done in the firmware, so no work at all in minstrel-ht. The end result, as far as I can tell, is you would just have to tell mac80211 to allow VHT on 2.4Ghz, and revert this patch that Kalle is proposing. Maybe someone that actually knows about these IEs can explain why they are worth using? Thanks, Ben
On Wed, Apr 27, 2016 at 1:40 AM, Ben Greear <greearb@candelatech.com> wrote: > On 04/26/2016 01:07 PM, Krishna Chaitanya wrote: >> >> On Tue, Apr 26, 2016 at 5:33 PM, Valo, Kalle <kvalo@qca.qualcomm.com> >> wrote: >>> >>> Johannes Berg <johannes@sipsolutions.net> writes: >>> >>>> On Thu, 2016-04-21 at 08:15 -0700, Ben Greear wrote: >>>> >>>>> The thing is, it actually works just fine with the patch I posted >>>>> to fix mac80211, and at any rate, even if the mac80211 patch isn't >>>>> applied, the ath10k driver works just fine in HT mode. >>>> >>>> >>>> This patch has no implications on HT, and I wasn't planning on applying >>>> the mac80211 patch. >>> >>> >>> Yeah, makes sense. I'm planning to apply this soon. >>> >>>> As I said, I have no objections to doing the (Broadcom) vendor specific >>>> IEs for "VHT" in 2.4 GHz band, but I don't think we should advertise >>>> the spec IEs when they're explicitly specified to be used only in the >>>> 5.2 GHz band. >>> >>> >>> But we really should have this, any volunteers? :) I think it shouldn't >>> be too hard to do so this would be a good project for someone looking >>> for a simple, but useful, task on wireless stack. >> >> Are these Broadcom IEs documented somewhere? If yes, >> then its a matter of parsing them and adding support to >> minstrel_ht, isn't it? major work would be in minstrel. >> > > For ath10k, rate-ctrl is done in the firmware, so > no work at all in minstrel-ht. Right, i think this might become more common. So may we need to change minstrel_ht as well? > The end result, as far as I can tell, > is you would just have to tell mac80211 to allow > VHT on 2.4Ghz, and revert this patch that Kalle is proposing. Ideally as this is vendor specific it makes sense to implement this at Driver/FW level rather than implementing it at a common stack like mac80211. > Maybe someone that actually knows about these IEs can explain why > they are worth using? These IE's can be parsed in the driver without any mac80211 involvement.
On Wed, Apr 27, 2016 at 12:13:46PM +0530, Krishna Chaitanya wrote: > On Wed, Apr 27, 2016 at 1:40 AM, Ben Greear <greearb@candelatech.com> wrote: > > On 04/26/2016 01:07 PM, Krishna Chaitanya wrote: > >> Are these Broadcom IEs documented somewhere? If yes, > >> then its a matter of parsing them and adding support to > >> minstrel_ht, isn't it? major work would be in minstrel. > > The end result, as far as I can tell, > > is you would just have to tell mac80211 to allow > > VHT on 2.4Ghz, and revert this patch that Kalle is proposing. > > Ideally as this is vendor specific it makes sense to implement this > at Driver/FW level rather than implementing it at a common stack > like mac80211. > > > Maybe someone that actually knows about these IEs can explain why > > they are worth using? > > These IE's can be parsed in the driver without any mac80211 involvement. Sure, these are vendor specific elements, but they are simply encapsulating the standard VHT elements that we already handle within mac80211 for STA functionality and hostapd for AP functionality. I don't see why we would make this any more complex for 2.4 GHz 256-QAM support than extending the existing locations that support the VHT elements. The main reason for me in using these particular vendor specific elements is in them being already supported by number of deployed devices. There is also support for these in hostapd (vendor_vht=1 in hostapd.conf) and as far as I know, this used to work with ath10k for AP mode (and this patch we discuss here may break that). The main missing functionality is for the matching STA side support with mac80211 and that's where the changes, IMHO, would fit in nicely in mac80211 next to the places where we handle the matching standard VHT elements in the 5 GHz band.
On Wed, Apr 27, 2016 at 2:46 PM, Jouni Malinen <j@w1.fi> wrote: > On Wed, Apr 27, 2016 at 12:13:46PM +0530, Krishna Chaitanya wrote: >> On Wed, Apr 27, 2016 at 1:40 AM, Ben Greear <greearb@candelatech.com> wrote: >> > On 04/26/2016 01:07 PM, Krishna Chaitanya wrote: >> >> Are these Broadcom IEs documented somewhere? If yes, >> >> then its a matter of parsing them and adding support to >> >> minstrel_ht, isn't it? major work would be in minstrel. > >> > The end result, as far as I can tell, >> > is you would just have to tell mac80211 to allow >> > VHT on 2.4Ghz, and revert this patch that Kalle is proposing. >> >> Ideally as this is vendor specific it makes sense to implement this >> at Driver/FW level rather than implementing it at a common stack >> like mac80211. >> >> > Maybe someone that actually knows about these IEs can explain why >> > they are worth using? >> >> These IE's can be parsed in the driver without any mac80211 involvement. > > Sure, these are vendor specific elements, but they are simply > encapsulating the standard VHT elements that we already handle within > mac80211 for STA functionality and hostapd for AP functionality. I don't > see why we would make this any more complex for 2.4 GHz 256-QAM support > than extending the existing locations that support the VHT elements. > > The main reason for me in using these particular vendor specific > elements is in them being already supported by number of deployed > devices. There is also support for these in hostapd (vendor_vht=1 in > hostapd.conf) and as far as I know, this used to work with ath10k for AP > mode (and this patch we discuss here may break that). The main missing > functionality is for the matching STA side support with mac80211 and > that's where the changes, IMHO, would fit in nicely in mac80211 next to > the places where we handle the matching standard VHT elements in the 5 > GHz band. If many vendors need this support, then mac80211 appraoch would be good. If not, we should stick to driver approach.
On Wed, 2016-04-27 at 15:07 +0530, Krishna Chaitanya wrote: > > If many vendors need this support, then mac80211 appraoch would be > good. If not, we should stick to driver approach. Trying to do this in the driver gets practically impossible, so no, it really should be done in mac80211 either way. Drivers have to opt in by reporting VHT caps for 2.4 GHz, at which point we simply revert this patch, but get the right over-the-air behaviour. johannes
Kalle Valo <kvalo@qca.qualcomm.com> writes: > From: Johannes Berg <johannes.berg@intel.com> > > According to the spec, VHT doesn't exist in 2.4GHz. > > There are vendor extensions to allow a subset of VHT to work > (notably 256-QAM), but since mac80211 doesn't support those > advertising VHT capability on 2.4GHz leads to the behaviour > of reporting VHT capabilities but not being able to use any > of them due to mac80211's code requiring 80 MHz support. > > Remove the VHT capabilities from 2.4GHz for now. If mac80211 > gets extended to use the (likely Broadcom) vendor IEs for it > and handles the lack of 80 MHz support, it can be added back. > > Signed-off-by: Johannes Berg <johannes.berg@intel.com> > Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com> Applied, thanks.
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c index bcf025f51310..d2a852805b07 100644 --- a/drivers/net/wireless/ath/ath10k/mac.c +++ b/drivers/net/wireless/ath/ath10k/mac.c @@ -4276,9 +4276,6 @@ static void ath10k_mac_setup_ht_vht_cap(struct ath10k *ar) if (ar->phy_capability & WHAL_WLAN_11G_CAPABILITY) { band = &ar->mac.sbands[NL80211_BAND_2GHZ]; band->ht_cap = ht_cap; - - /* Enable the VHT support at 2.4 GHz */ - band->vht_cap = vht_cap; } if (ar->phy_capability & WHAL_WLAN_11A_CAPABILITY) { band = &ar->mac.sbands[NL80211_BAND_5GHZ];