From: Krishna Chaitanya <chaitanya.mgit@gmail.com>
To: Jouni Malinen <j@w1.fi>
Cc: Ben Greear <greearb@candelatech.com>,
"Valo, Kalle" <kvalo@qca.qualcomm.com>,
Johannes Berg <johannes@sipsolutions.net>,
"ath10k@lists.infradead.org" <ath10k@lists.infradead.org>,
"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: Re: [PATCH v2] ath10k: remove VHT capabilities from 2.4GHz
Date: Wed, 27 Apr 2016 15:07:26 +0530 [thread overview]
Message-ID: <CABPxzYJz59wOXjK2fCK_Tp05g0g1FY+VWscFKz9fG+D1swZGBA@mail.gmail.com> (raw)
In-Reply-To: <20160427091653.GB4345@w1.fi>
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.
WARNING: multiple messages have this Message-ID (diff)
From: Krishna Chaitanya <chaitanya.mgit@gmail.com>
To: Jouni Malinen <j@w1.fi>
Cc: Johannes Berg <johannes@sipsolutions.net>,
Ben Greear <greearb@candelatech.com>,
"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
"Valo, Kalle" <kvalo@qca.qualcomm.com>,
"ath10k@lists.infradead.org" <ath10k@lists.infradead.org>
Subject: Re: [PATCH v2] ath10k: remove VHT capabilities from 2.4GHz
Date: Wed, 27 Apr 2016 15:07:26 +0530 [thread overview]
Message-ID: <CABPxzYJz59wOXjK2fCK_Tp05g0g1FY+VWscFKz9fG+D1swZGBA@mail.gmail.com> (raw)
In-Reply-To: <20160427091653.GB4345@w1.fi>
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.
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
next prev parent reply other threads:[~2016-04-27 9:37 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-21 13:17 [PATCH v2] ath10k: remove VHT capabilities from 2.4GHz Kalle Valo
2016-04-21 13:17 ` Kalle Valo
2016-04-21 15:15 ` Ben Greear
2016-04-21 15:15 ` Ben Greear
2016-04-21 20:09 ` Sebastian Gottschall
2016-04-21 23:07 ` Michael Ney
2016-04-26 7:04 ` Johannes Berg
2016-04-26 7:04 ` Johannes Berg
2016-04-26 12:03 ` Valo, Kalle
2016-04-26 12:03 ` Valo, Kalle
2016-04-26 20:07 ` Krishna Chaitanya
2016-04-26 20:07 ` Krishna Chaitanya
2016-04-26 20:10 ` Ben Greear
2016-04-26 20:10 ` Ben Greear
2016-04-27 6:43 ` Krishna Chaitanya
2016-04-27 6:43 ` Krishna Chaitanya
2016-04-27 9:16 ` Jouni Malinen
2016-04-27 9:16 ` Jouni Malinen
2016-04-27 9:37 ` Krishna Chaitanya [this message]
2016-04-27 9:37 ` Krishna Chaitanya
2016-04-27 9:45 ` Johannes Berg
2016-04-27 9:45 ` Johannes Berg
2016-05-06 18:08 ` Valo, Kalle
2016-05-06 18:08 ` Valo, Kalle
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CABPxzYJz59wOXjK2fCK_Tp05g0g1FY+VWscFKz9fG+D1swZGBA@mail.gmail.com \
--to=chaitanya.mgit@gmail.com \
--cc=ath10k@lists.infradead.org \
--cc=greearb@candelatech.com \
--cc=j@w1.fi \
--cc=johannes@sipsolutions.net \
--cc=kvalo@qca.qualcomm.com \
--cc=linux-wireless@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.