Radiotap header needs a new channel flag for 6GHz packets.
This change uses value 0x200 for new enum balue for 6GHz which was
previously used for passsive scan flag but has since been removed.
Signed-off-by: Aloka Dixit <[email protected]>
---
include/net/ieee80211_radiotap.h | 1 +
net/mac80211/rx.c | 4 +++-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/include/net/ieee80211_radiotap.h b/include/net/ieee80211_radiotap.h
index 19c00d100096..df631d177cf9 100644
--- a/include/net/ieee80211_radiotap.h
+++ b/include/net/ieee80211_radiotap.h
@@ -101,6 +101,7 @@ enum ieee80211_radiotap_channel_flags {
IEEE80211_CHAN_OFDM = 0x0040,
IEEE80211_CHAN_2GHZ = 0x0080,
IEEE80211_CHAN_5GHZ = 0x0100,
+ IEEE80211_CHAN_6GHZ = 0x0200,
IEEE80211_CHAN_DYN = 0x0400,
IEEE80211_CHAN_HALF = 0x4000,
IEEE80211_CHAN_QUARTER = 0x8000,
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 836cde516a18..21aa19c12afc 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -451,7 +451,9 @@ ieee80211_add_rx_radiotap_header(struct ieee80211_local *local,
else if (status->bw == RATE_INFO_BW_5)
channel_flags |= IEEE80211_CHAN_QUARTER;
- if (status->band == NL80211_BAND_5GHZ)
+ if (status->band == NL80211_BAND_6GHZ)
+ channel_flags |= IEEE80211_CHAN_OFDM | IEEE80211_CHAN_6GHZ;
+ else if (status->band == NL80211_BAND_5GHZ)
channel_flags |= IEEE80211_CHAN_OFDM | IEEE80211_CHAN_5GHZ;
else if (status->encoding != RX_ENC_LEGACY)
channel_flags |= IEEE80211_CHAN_DYN | IEEE80211_CHAN_2GHZ;
--
2.25.0
On Fri, 2020-09-11 at 20:39 +0000, Aloka Dixit wrote:
> Radiotap header needs a new channel flag for 6GHz packets.
> This change uses value 0x200 for new enum balue for 6GHz which was
> previously used for passsive scan flag but has since been removed.
You can't just add to radiotap in a kernel patch ...
But also, just today I replied elsewhere saying that we don't really
need a flag at all?
johannes
On 2020-09-11 13:39, Johannes Berg wrote:
> On Fri, 2020-09-11 at 20:39 +0000, Aloka Dixit wrote:
>> Radiotap header needs a new channel flag for 6GHz packets.
>> This change uses value 0x200 for new enum balue for 6GHz which was
>> previously used for passsive scan flag but has since been removed.
>
> You can't just add to radiotap in a kernel patch ...
>
> But also, just today I replied elsewhere saying that we don't really
> need a flag at all?
>
> johannes
Somehow your reply to other patch didn't show up on the patchwork, don't
know why :-)
What do you mean by we cannot add to radiotap in a kernel patch?
Thanks.
On Fri, 2020-09-11 at 20:45 +0000, Aloka Dixit wrote:
>
> What do you mean by we cannot add to radiotap in a kernel patch?
Radiotap is a Linux-independent "standard". Would have to go through the
process there to change it.
johannes
Aloka Dixit <[email protected]> writes:
> On 2020-09-11 13:39, Johannes Berg wrote:
>> On Fri, 2020-09-11 at 20:39 +0000, Aloka Dixit wrote:
>>> Radiotap header needs a new channel flag for 6GHz packets.
>>> This change uses value 0x200 for new enum balue for 6GHz which was
>>> previously used for passsive scan flag but has since been removed.
>>
>> You can't just add to radiotap in a kernel patch ...
>>
>> But also, just today I replied elsewhere saying that we don't really
>> need a flag at all?
>>
>> johannes
>
> Somehow your reply to other patch didn't show up on the patchwork,
> don't know why :-)
Oh, this is making me worry. I do see Johannes' reply on the list:
https://lore.kernel.org/linux-wireless/[email protected]/
But like you said, there's still nothing on the patchwork (even after 23h):
https://patchwork.kernel.org/patch/11769643/
I hope this is just a temporary glitch, but if this happens again please
do let me know about any patchwork problems. It will create major
problems for us if patchwork starts losing mail.
--
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
On 2020-09-11 23:16, Kalle Valo wrote:
> Aloka Dixit <[email protected]> writes:
>
>> On 2020-09-11 13:39, Johannes Berg wrote:
>>> On Fri, 2020-09-11 at 20:39 +0000, Aloka Dixit wrote:
>>>> Radiotap header needs a new channel flag for 6GHz packets.
>>>> This change uses value 0x200 for new enum balue for 6GHz which was
>>>> previously used for passsive scan flag but has since been removed.
>>>
>>> You can't just add to radiotap in a kernel patch ...
>>>
>>> But also, just today I replied elsewhere saying that we don't really
>>> need a flag at all?
>>>
>>> johannes
>>
>> Somehow your reply to other patch didn't show up on the patchwork,
>> don't know why :-)
>
> Oh, this is making me worry. I do see Johannes' reply on the list:
>
> https://lore.kernel.org/linux-wireless/[email protected]/
>
> But like you said, there's still nothing on the patchwork (even after
> 23h):
>
> https://patchwork.kernel.org/patch/11769643/
>
> I hope this is just a temporary glitch, but if this happens again
> please
> do let me know about any patchwork problems. It will create major
> problems for us if patchwork starts losing mail.
This is still happening, even your reply did not show up on the RFC
patch here:
https://patchwork.kernel.org/patch/11771491/
Aloka Dixit <[email protected]> writes:
> On 2020-09-11 23:16, Kalle Valo wrote:
>> Aloka Dixit <[email protected]> writes:
>>
>>> On 2020-09-11 13:39, Johannes Berg wrote:
>>>> On Fri, 2020-09-11 at 20:39 +0000, Aloka Dixit wrote:
>>>>> Radiotap header needs a new channel flag for 6GHz packets.
>>>>> This change uses value 0x200 for new enum balue for 6GHz which was
>>>>> previously used for passsive scan flag but has since been removed.
>>>>
>>>> You can't just add to radiotap in a kernel patch ...
>>>>
>>>> But also, just today I replied elsewhere saying that we don't really
>>>> need a flag at all?
>>>>
>>>> johannes
>>>
>>> Somehow your reply to other patch didn't show up on the patchwork,
>>> don't know why :-)
>>
>> Oh, this is making me worry. I do see Johannes' reply on the list:
>>
>> https://lore.kernel.org/linux-wireless/[email protected]/
>>
>> But like you said, there's still nothing on the patchwork (even
>> after 23h):
>>
>> https://patchwork.kernel.org/patch/11769643/
>>
>> I hope this is just a temporary glitch, but if this happens again
>> please
>> do let me know about any patchwork problems. It will create major
>> problems for us if patchwork starts losing mail.
>
> This is still happening, even your reply did not show up on the RFC
> patch here:
> https://patchwork.kernel.org/patch/11771491/
Aloka's original email (with the patch) had the id:
Message-ID: <010101747ee4b989-1d670a2f-a032-4f64-aa65-3847a5951522-000000@us-west-2.amazonses.com>
But Johannes' reply referenced different id:
In-Reply-To: <010101747ee4b985-86863ec8-33e2-4f78-9d9b-93110bfa29fc-000000@us-west-2.amazonses.com>
References: <010101747ee4b985-86863ec8-33e2-4f78-9d9b-93110bfa29fc-000000@us-west-2.amazonses.com>
And this is why patchwork cannot detect that the replies are to Aloka's
patch. I suspect smtp.codeaurora.org is to blame here, I have seen it
messing with message ids before so this would not be the first time this
is happening.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches