From: Rafał Miłecki <[email protected]>
Driver can report IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ so it's
important to provide valid & complete info about supported bands for
each channel. By default no support for 160 MHz should be assumed unless
firmware reports it for a given channel later.
This fixes info passed to the userspace. Without that change userspace
could try to use invalid channel and fail to start an interface.
Signed-off-by: Rafał Miłecki <[email protected]>
Cc: [email protected]
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 230a378c26fc..7f0a5bade70a 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -6005,7 +6005,8 @@ static int brcmf_construct_chaninfo(struct brcmf_cfg80211_info *cfg,
* for subsequent chanspecs.
*/
channel->flags = IEEE80211_CHAN_NO_HT40 |
- IEEE80211_CHAN_NO_80MHZ;
+ IEEE80211_CHAN_NO_80MHZ |
+ IEEE80211_CHAN_NO_160MHZ;
ch.bw = BRCMU_CHAN_BW_20;
cfg->d11inf.encchspec(&ch);
chaninfo = ch.chspec;
--
2.13.7
Rafał Miłecki <[email protected]> writes:
> From: Rafał Miłecki <[email protected]>
>
> Driver can report IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ so it's
> important to provide valid & complete info about supported bands for
> each channel. By default no support for 160 MHz should be assumed unless
> firmware reports it for a given channel later.
>
> This fixes info passed to the userspace. Without that change userspace
> could try to use invalid channel and fail to start an interface.
>
> Signed-off-by: Rafał Miłecki <[email protected]>
> Cc: [email protected]
Should this be queued to 4.20?
--
Kalle Valo
On 2018-11-09 15:05, Kalle Valo wrote:
> Rafał Miłecki <[email protected]> writes:
>
>> From: Rafał Miłecki <[email protected]>
>>
>> Driver can report IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ so it's
>> important to provide valid & complete info about supported bands for
>> each channel. By default no support for 160 MHz should be assumed
>> unless
>> firmware reports it for a given channel later.
>>
>> This fixes info passed to the userspace. Without that change userspace
>> could try to use invalid channel and fail to start an interface.
>>
>> Signed-off-by: Rafał Miłecki <[email protected]>
>> Cc: [email protected]
>
> Should this be queued to 4.20?
That's my suggestion.
I try to mark fixes (patches for currently developed release) with an
extra FIX tag in a subject. Do you see those when using your patchwork
tool? Do you have any other method in mind that would be preferred by
you?
Rafał Miłecki <[email protected]> writes:
> On 2018-11-09 15:05, Kalle Valo wrote:
>> Rafał Miłecki <[email protected]> writes:
>>
>>> From: Rafał Miłecki <[email protected]>
>>>
>>> Driver can report IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ so it's
>>> important to provide valid & complete info about supported bands for
>>> each channel. By default no support for 160 MHz should be assumed
>>> unless
>>> firmware reports it for a given channel later.
>>>
>>> This fixes info passed to the userspace. Without that change userspace
>>> could try to use invalid channel and fail to start an interface.
>>>
>>> Signed-off-by: Rafał Miłecki <[email protected]>
>>> Cc: [email protected]
>>
>> Should this be queued to 4.20?
>
> That's my suggestion.
Ok, I'll queue this for 4.20.
--
Kalle Valo
(changing subject for better visibility and trimming Cc)
Rafał Miłecki <[email protected]> writes:
> On 2018-11-09 15:05, Kalle Valo wrote:
>> Rafał Miłecki <[email protected]> writes:
>>
>>> From: Rafał Miłecki <[email protected]>
>>>
>>> Driver can report IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ so it's
>>> important to provide valid & complete info about supported bands for
>>> each channel. By default no support for 160 MHz should be assumed
>>> unless
>>> firmware reports it for a given channel later.
>>>
>>> This fixes info passed to the userspace. Without that change userspace
>>> could try to use invalid channel and fail to start an interface.
>>>
>>> Signed-off-by: Rafał Miłecki <[email protected]>
>>> Cc: [email protected]
>>
>> Should this be queued to 4.20?
>
> That's my suggestion.
>
> I try to mark fixes (patches for currently developed release) with an
> extra FIX tag in a subject. Do you have any other method in mind that
> would be preferred by you?
Yes, I do see your FIX tag in patchwork:
[ 31] [FIX] brcmfmac: fix reporting support for 160 MHz channels 2018-11-08
But "FIX" is a bit ambigous as not all fixes not go to wireless-drivers,
they can also go to wireless-drivers-next. So I prefer using the release
number (or name of the tree) like this:
[PATCH 4.20] brcmfmac: fix reporting support for 160 MHz channels
After seeing your question I added something about this to the wiki
which hopefully helps others:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#tree_labels
--
Kalle Valo
On Fri, 2018-11-16 at 10:46 +0200, Kalle Valo wrote:
> Yes, I do see your FIX tag in patchwork:
>
> [ 31] [FIX] brcmfmac: fix reporting support for 160 MHz channels 2018-11-08
>
> But "FIX" is a bit ambigous as not all fixes not go to wireless-drivers,
> they can also go to wireless-drivers-next. So I prefer using the release
> number (or name of the tree) like this:
>
> [PATCH 4.20] brcmfmac: fix reporting support for 160 MHz channels
FWIW, davem/networking just use
[PATCH net]
[PATCH net-next]
which puts a bit more effort on the submitter but is a bit easier on the
maintainer I suppose. Also, not really a problem here, but it would help
disambiguate different trees on the same mailing list. I don't really
mind either way.
johannes
Johannes Berg <[email protected]> writes:
> On Fri, 2018-11-16 at 10:46 +0200, Kalle Valo wrote:
>
>> Yes, I do see your FIX tag in patchwork:
>>
>> [ 31] [FIX] brcmfmac: fix reporting support for 160 MHz channels 2018-11-08
>>
>> But "FIX" is a bit ambigous as not all fixes not go to wireless-drivers,
>> they can also go to wireless-drivers-next. So I prefer using the release
>> number (or name of the tree) like this:
>>
>> [PATCH 4.20] brcmfmac: fix reporting support for 160 MHz channels
>
> FWIW, davem/networking just use
>
> [PATCH net]
> [PATCH net-next]
>
> which puts a bit more effort on the submitter but is a bit easier on the
> maintainer I suppose. Also, not really a problem here, but it would help
> disambiguate different trees on the same mailing list. I don't really
> mind either way.
Actually I already added that to the wiki[1] but made it optional just
bacause it's harder for patch submitters who are not so familiar with
our tree structure. But yes, I also like using the full tree name as the
label, even more so as it would help me to automatically assign patches
to correct maintainers in patchwork.
[1] https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#tree_labels
--
Kalle Valo
On 2018-11-16 09:46, Kalle Valo wrote:
> (changing subject for better visibility and trimming Cc)
>
> Rafał Miłecki <[email protected]> writes:
>
>> On 2018-11-09 15:05, Kalle Valo wrote:
>>> Rafał Miłecki <[email protected]> writes:
>>>
>>>> From: Rafał Miłecki <[email protected]>
>>>>
>>>> Driver can report IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ so it's
>>>> important to provide valid & complete info about supported bands for
>>>> each channel. By default no support for 160 MHz should be assumed
>>>> unless
>>>> firmware reports it for a given channel later.
>>>>
>>>> This fixes info passed to the userspace. Without that change
>>>> userspace
>>>> could try to use invalid channel and fail to start an interface.
>>>>
>>>> Signed-off-by: Rafał Miłecki <[email protected]>
>>>> Cc: [email protected]
>>>
>>> Should this be queued to 4.20?
>>
>> That's my suggestion.
>>
>> I try to mark fixes (patches for currently developed release) with an
>> extra FIX tag in a subject. Do you have any other method in mind that
>> would be preferred by you?
>
> Yes, I do see your FIX tag in patchwork:
>
> [ 31] [FIX] brcmfmac: fix reporting support for 160 MHz channels
> 2018-11-08
>
> But "FIX" is a bit ambigous as not all fixes not go to
> wireless-drivers,
> they can also go to wireless-drivers-next. So I prefer using the
> release
> number (or name of the tree) like this:
>
> [PATCH 4.20] brcmfmac: fix reporting support for 160 MHz channels
>
> After seeing your question I added something about this to the wiki
> which hopefully helps others:
>
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#tree_labels
Got it, thanks!
Rafał Miłecki wrote:
> From: Rafał Miłecki <[email protected]>
>
> Driver can report IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ so it's
> important to provide valid & complete info about supported bands for
> each channel. By default no support for 160 MHz should be assumed unless
> firmware reports it for a given channel later.
>
> This fixes info passed to the userspace. Without that change userspace
> could try to use invalid channel and fail to start an interface.
>
> Signed-off-by: Rafał Miłecki <[email protected]>
> Cc: [email protected]
Patch applied to wireless-drivers.git, thanks.
d1fe6ad6f6bd brcmfmac: fix reporting support for 160 MHz channels
--
https://patchwork.kernel.org/patch/10674521/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches