Search Linux Wireless

Re: wiki: tree labels in patches

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2018-11-16 09:46, Kalle Valo wrote:
(changing subject for better visibility and trimming Cc)

Rafał Miłecki <rafal@xxxxxxxxxx> writes:

On 2018-11-09 15:05, Kalle Valo wrote:
Rafał Miłecki <zajec5@xxxxxxxxx> writes:

From: Rafał Miłecki <rafal@xxxxxxxxxx>

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 <rafal@xxxxxxxxxx>
Cc: stable@xxxxxxxxxxxxxxx

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!



[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Wireless Regulations]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux