Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26 |
|
#
1ec7ed51 |
| 25-Feb-2022 |
Brian Norris <briannorris@chromium.org> |
Revert "ath: add support for special 0x0 regulatory domain"
This reverts commit 2dc016599cfa9672a147528ca26d70c3654a5423.
Users are reporting regressions in regulatory domain detection and channel
Revert "ath: add support for special 0x0 regulatory domain"
This reverts commit 2dc016599cfa9672a147528ca26d70c3654a5423.
Users are reporting regressions in regulatory domain detection and channel availability.
The problem this was trying to resolve was fixed in firmware anyway:
QCA6174 hw3.0: sdio-4.4.1: add firmware.bin_WLAN.RMH.4.4.1-00042 https://github.com/kvalo/ath10k-firmware/commit/4d382787f0efa77dba40394e0bc604f8eff82552
Link: https://bbs.archlinux.org/viewtopic.php?id=254535 Link: http://lists.infradead.org/pipermail/ath10k/2020-April/014871.html Link: http://lists.infradead.org/pipermail/ath10k/2020-May/015152.html Link: https://lore.kernel.org/all/1c160dfb-6ccc-b4d6-76f6-4364e0adb6dd@reox.at/ Fixes: 2dc016599cfa ("ath: add support for special 0x0 regulatory domain") Cc: <stable@vger.kernel.org> Cc: Wen Gong <wgong@codeaurora.org> Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20200527165718.129307-1-briannorris@chromium.org
show more ...
|
#
5023652c |
| 25-Feb-2022 |
Brian Norris <briannorris@chromium.org> |
Revert "ath: add support for special 0x0 regulatory domain"
commit 1ec7ed5163c70a0d040150d2279f932c7e7c143f upstream.
This reverts commit 2dc016599cfa9672a147528ca26d70c3654a5423.
Users are report
Revert "ath: add support for special 0x0 regulatory domain"
commit 1ec7ed5163c70a0d040150d2279f932c7e7c143f upstream.
This reverts commit 2dc016599cfa9672a147528ca26d70c3654a5423.
Users are reporting regressions in regulatory domain detection and channel availability.
The problem this was trying to resolve was fixed in firmware anyway:
QCA6174 hw3.0: sdio-4.4.1: add firmware.bin_WLAN.RMH.4.4.1-00042 https://github.com/kvalo/ath10k-firmware/commit/4d382787f0efa77dba40394e0bc604f8eff82552
Link: https://bbs.archlinux.org/viewtopic.php?id=254535 Link: http://lists.infradead.org/pipermail/ath10k/2020-April/014871.html Link: http://lists.infradead.org/pipermail/ath10k/2020-May/015152.html Link: https://lore.kernel.org/all/1c160dfb-6ccc-b4d6-76f6-4364e0adb6dd@reox.at/ Fixes: 2dc016599cfa ("ath: add support for special 0x0 regulatory domain") Cc: <stable@vger.kernel.org> Cc: Wen Gong <wgong@codeaurora.org> Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20200527165718.129307-1-briannorris@chromium.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60, v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13, v5.10.46, v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14, v5.10 |
|
#
aed7ee04 |
| 02-Nov-2020 |
Lee Jones <lee.jones@linaro.org> |
ath: regd: Provide description for ath_reg_apply_ir_flags's 'reg' param
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/ath/regd.c:378: warning: Function parameter or member
ath: regd: Provide description for ath_reg_apply_ir_flags's 'reg' param
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/ath/regd.c:378: warning: Function parameter or member 'reg' not described in 'ath_reg_apply_ir_flags'
Cc: Kalle Valo <kvalo@codeaurora.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: linux-wireless@vger.kernel.org Cc: netdev@vger.kernel.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20201102112410.1049272-20-lee.jones@linaro.org
show more ...
|
Revision tags: v5.8.17, v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43, v5.4.42, v5.4.41, v5.4.40, v5.4.39, v5.4.38, v5.4.37, v5.4.36, v5.4.35, v5.4.34, v5.4.33, v5.4.32, v5.4.31, v5.4.30, v5.4.29, v5.6, v5.4.28, v5.4.27, v5.4.26, v5.4.25, v5.4.24, v5.4.23, v5.4.22, v5.4.21, v5.4.20, v5.4.19, v5.4.18, v5.4.17, v5.4.16, v5.5, v5.4.15, v5.4.14, v5.4.13, v5.4.12, v5.4.11, v5.4.10, v5.4.9, v5.4.8, v5.4.7, v5.4.6, v5.4.5, v5.4.4, v5.4.3, v5.3.15, v5.4.2, v5.4.1, v5.3.14 |
|
#
2dc01659 |
| 29-Nov-2019 |
Wen Gong <wgong@codeaurora.org> |
ath: add support for special 0x0 regulatory domain
Some sdio chips of rome QCA6174's regulatory domain code of EEPROM is empty, then ath_is_world_regd will return false for this case, and it will le
ath: add support for special 0x0 regulatory domain
Some sdio chips of rome QCA6174's regulatory domain code of EEPROM is empty, then ath_is_world_regd will return false for this case, and it will lead function __ath_reg_dyn_country not work, thus the regdomain will not update for NL80211_REGDOM_SET_BY_COUNTRY_IE type, it result ath10k set the same regdomain/reg_5ghz_ctl/reg_2ghz_ctl to firmware, then the tx power will not changed with different regdomain's AP. The regulatory domain code of EEPROM of some QCA6174 PCIE chip is 0x6c, it means world wide regdomain, for this chip, it does not have the issue.
For empty reulatory domain code chip, set it to world regulatory domain in functio ath_regd_sanitize, then it will fix the issue.
Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00029.
Signed-off-by: Wen Gong <wgong@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
show more ...
|
Revision tags: v5.4, v5.3.13, v5.3.12, v5.3.11, v5.3.10, v5.3.9, v5.3.8, v5.3.7, v5.3.6 |
|
#
f433abfc |
| 10-Oct-2019 |
Tomislav Požega <pozega.tomislav@gmail.com> |
ath: rename regulatory rules
Regulatory rule defines in regd.c are used not only by ath9k but also ath10k driver (haven't test other drivers) and thus should be renamed from ATH9K* to ATH*.
Signed-
ath: rename regulatory rules
Regulatory rule defines in regd.c are used not only by ath9k but also ath10k driver (haven't test other drivers) and thus should be renamed from ATH9K* to ATH*.
Signed-off-by: Tomislav Požega <pozega.tomislav@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
show more ...
|
Revision tags: v5.3.5, v5.3.4, v5.3.3, v5.3.2, v5.3.1, v5.3, v5.2.14, v5.3-rc8, v5.2.13, v5.2.12, v5.2.11, v5.2.10, v5.2.9, v5.2.8, v5.2.7, v5.2.6, v5.2.5, v5.2.4, v5.2.3, v5.2.2, v5.2.1, v5.2, v5.1.16, v5.1.15, v5.1.14, v5.1.13, v5.1.12, v5.1.11, v5.1.10, v5.1.9, v5.1.8, v5.1.7, v5.1.6, v5.1.5, v5.1.4, v5.1.3, v5.1.2, v5.1.1, v5.0.14, v5.1, v5.0.13, v5.0.12, v5.0.11, v5.0.10, v5.0.9, v5.0.8, v5.0.7, v5.0.6, v5.0.5, v5.0.4, v5.0.3, v4.19.29, v5.0.2, v4.19.28, v5.0.1, v4.19.27, v5.0, v4.19.26, v4.19.25, v4.19.24, v4.19.23, v4.19.22, v4.19.21, v4.19.20, v4.19.19, v4.19.18, v4.19.17, v4.19.16, v4.19.15, v4.19.14, v4.19.13, v4.19.12, v4.19.11, v4.19.10, v4.19.9, v4.19.8, v4.19.7, v4.19.6, v4.19.5, v4.19.4, v4.18.20, v4.19.3, v4.18.19, v4.19.2, v4.18.18, v4.18.17, v4.19.1, v4.19, v4.18.16, v4.18.15, v4.18.14, v4.18.13, v4.18.12, v4.18.11, v4.18.10, v4.18.9, v4.18.7, v4.18.6, v4.18.5, v4.17.18, v4.18.4, v4.18.3, v4.17.17, v4.18.2, v4.17.16, v4.17.15, v4.18.1, v4.18, v4.17.14, v4.17.13, v4.17.12, v4.17.11, v4.17.10, v4.17.9, v4.17.8, v4.17.7, v4.17.6, v4.17.5, v4.17.4, v4.17.3, v4.17.2, v4.17.1, v4.17, v4.16, v4.15, v4.13.16, v4.14, v4.13.5, v4.13, v4.12, v4.10.17, v4.10.16, v4.10.15, v4.10.14, v4.10.13, v4.10.12, v4.10.11 |
|
#
c0c345d4 |
| 12-Apr-2017 |
Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> |
ath: Fix updating radar flags for coutry code India
As per latest regulatory update for India, channel 52, 56, 60, 64 is no longer restricted to DFS. Enabling DFS/no infra flags in driver results in
ath: Fix updating radar flags for coutry code India
As per latest regulatory update for India, channel 52, 56, 60, 64 is no longer restricted to DFS. Enabling DFS/no infra flags in driver results in applying all DFS related restrictions (like doing CAC etc before this channel moves to 'available state') for these channels even though the country code is programmed as 'India' in he hardware, fix this by relaxing the frequency range while applying RADAR flags only if the country code is programmed to India. If the frequency range needs to modified based on different country code, ath_is_radar_freq can be extended/modified dynamically.
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
show more ...
|
Revision tags: v4.10.10, v4.10.9, v4.10.8, v4.10.7, v4.10.6, v4.10.5, v4.10.4, v4.10.3, v4.10.2, v4.10.1, v4.10, v4.9, openbmc-4.4-20161121-1, v4.4.33, v4.4.32, v4.4.31, v4.4.30, v4.4.29, v4.4.28, v4.4.27, v4.7.10, openbmc-4.4-20161021-1, v4.7.9, v4.4.26, v4.7.8, v4.4.25, v4.4.24, v4.7.7, v4.8, v4.4.23, v4.7.6 |
|
#
d291d8e0 |
| 28-Sep-2016 |
Michal Kazior <michal.kazior@tieto.com> |
ath: export alpha2 helper
This will be helpful for drivers that can acquire alpha2 regulatory codes.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Bartosz Markowski <bartosz
ath: export alpha2 helper
This will be helpful for drivers that can acquire alpha2 regulatory codes.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
show more ...
|
Revision tags: v4.7.5, v4.4.22, v4.4.21, v4.7.4, v4.7.3, v4.4.20, v4.7.2, v4.4.19, openbmc-4.4-20160819-1, v4.7.1, v4.4.18, v4.4.17, openbmc-4.4-20160804-1 |
|
#
97f2645f |
| 03-Aug-2016 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
tree-wide: replace config_enabled() with IS_ENABLED()
The use of config_enabled() against config options is ambiguous. In practical terms, config_enabled() is equivalent to IS_BUILTIN(), but the au
tree-wide: replace config_enabled() with IS_ENABLED()
The use of config_enabled() against config options is ambiguous. In practical terms, config_enabled() is equivalent to IS_BUILTIN(), but the author might have used it for the meaning of IS_ENABLED(). Using IS_ENABLED(), IS_BUILTIN(), IS_MODULE() etc. makes the intention clearer.
This commit replaces config_enabled() with IS_ENABLED() where possible. This commit is only touching bool config options.
I noticed two cases where config_enabled() is used against a tristate option:
- config_enabled(CONFIG_HWMON) [ drivers/net/wireless/ath/ath10k/thermal.c ]
- config_enabled(CONFIG_BACKLIGHT_CLASS_DEVICE) [ drivers/gpu/drm/gma500/opregion.c ]
I did not touch them because they should be converted to IS_BUILTIN() in order to keep the logic, but I was not sure it was the authors' intention.
Link: http://lkml.kernel.org/r/1465215656-20569-1-git-send-email-yamada.masahiro@socionext.com Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Kees Cook <keescook@chromium.org> Cc: Stas Sergeev <stsp@list.ru> Cc: Matt Redfearn <matt.redfearn@imgtec.com> Cc: Joshua Kinard <kumba@gentoo.org> Cc: Jiri Slaby <jslaby@suse.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Borislav Petkov <bp@suse.de> Cc: Markos Chandras <markos.chandras@imgtec.com> Cc: "Dmitry V. Levin" <ldv@altlinux.org> Cc: yu-cheng yu <yu-cheng.yu@intel.com> Cc: James Hogan <james.hogan@imgtec.com> Cc: Brian Gerst <brgerst@gmail.com> Cc: Johannes Berg <johannes@sipsolutions.net> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Will Drewry <wad@chromium.org> Cc: Nikolay Martynov <mar.kolya@gmail.com> Cc: Huacai Chen <chenhc@lemote.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Daniel Borkmann <daniel@iogearbox.net> Cc: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com> Cc: Rafal Milecki <zajec5@gmail.com> Cc: James Cowgill <James.Cowgill@imgtec.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Alex Smith <alex.smith@imgtec.com> Cc: Adam Buchbinder <adam.buchbinder@gmail.com> Cc: Qais Yousef <qais.yousef@imgtec.com> Cc: Jiang Liu <jiang.liu@linux.intel.com> Cc: Mikko Rapeli <mikko.rapeli@iki.fi> Cc: Paul Gortmaker <paul.gortmaker@windriver.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: Brian Norris <computersforpeace@gmail.com> Cc: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com> Cc: "Luis R. Rodriguez" <mcgrof@do-not-panic.com> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Ingo Molnar <mingo@redhat.com> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> Cc: Roland McGrath <roland@hack.frob.com> Cc: Paul Burton <paul.burton@imgtec.com> Cc: Kalle Valo <kvalo@qca.qualcomm.com> Cc: Viresh Kumar <viresh.kumar@linaro.org> Cc: Tony Wu <tung7970@gmail.com> Cc: Huaitong Han <huaitong.han@intel.com> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: Alexei Starovoitov <ast@kernel.org> Cc: Juergen Gross <jgross@suse.com> Cc: Jason Cooper <jason@lakedaemon.net> Cc: "David S. Miller" <davem@davemloft.net> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Andrea Gelmini <andrea.gelmini@gelma.net> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: Rabin Vincent <rabin@rab.in> Cc: "Maciej W. Rozycki" <macro@imgtec.com> Cc: David Daney <david.daney@cavium.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
show more ...
|
Revision tags: v4.4.16, v4.7, openbmc-4.4-20160722-1, openbmc-20160722-1, openbmc-20160713-1, v4.4.15, v4.6.4, v4.6.3, v4.4.14, v4.6.2, v4.4.13, openbmc-20160606-1, v4.6.1, v4.4.12, openbmc-20160521-1, v4.4.11, openbmc-20160518-1, v4.6, v4.4.10, openbmc-20160511-1, openbmc-20160505-1, v4.4.9, v4.4.8, v4.4.7 |
|
#
57fbcce3 |
| 12-Apr-2016 |
Johannes Berg <johannes.berg@intel.com> |
cfg80211: remove enum ieee80211_band
This enum is already perfectly aliased to enum nl80211_band, and the only reason for it is that we get IEEE80211_NUM_BANDS out of it. There's no really good reas
cfg80211: remove enum ieee80211_band
This enum is already perfectly aliased to enum nl80211_band, and the only reason for it is that we get IEEE80211_NUM_BANDS out of it. There's no really good reason to not declare the number of bands in nl80211 though, so do that and remove the cfg80211 one.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
show more ...
|
Revision tags: openbmc-20160329-2, openbmc-20160329-1, openbmc-20160321-1, v4.4.6, v4.5, v4.4.5, v4.4.4, v4.4.3, openbmc-20160222-1, v4.4.2, openbmc-20160212-1, openbmc-20160210-1, openbmc-20160202-2, openbmc-20160202-1, v4.4.1, openbmc-20160127-1, openbmc-20160120-1, v4.4, openbmc-20151217-1, openbmc-20151210-1, openbmc-20151202-1, openbmc-20151123-1, openbmc-20151118-1, openbmc-20151104-1, v4.3, openbmc-20151102-1, openbmc-20151028-1, v4.3-rc1, v4.2, v4.2-rc8, v4.2-rc7, v4.2-rc6, v4.2-rc5, v4.2-rc4, v4.2-rc3, v4.2-rc2, v4.2-rc1, v4.1, v4.1-rc8, v4.1-rc7, v4.1-rc6, v4.1-rc5, v4.1-rc4, v4.1-rc3, v4.1-rc2, v4.1-rc1, v4.0, v4.0-rc7, v4.0-rc6, v4.0-rc5, v4.0-rc4, v4.0-rc3, v4.0-rc2, v4.0-rc1, v3.19, v3.19-rc7, v3.19-rc6, v3.19-rc5, v3.19-rc4, v3.19-rc3, v3.19-rc2, v3.19-rc1, v3.18, v3.18-rc7, v3.18-rc6, v3.18-rc5, v3.18-rc4, v3.18-rc3, v3.18-rc2 |
|
#
94e05900 |
| 22-Oct-2014 |
Felix Fietkau <nbd@openwrt.org> |
ath: use CTL region from cfg80211 if unset in EEPROM
Many AP devices do not have the proper regulatory domain programmed in EEPROM. Instead they expect the software to set the appropriate region. Fo
ath: use CTL region from cfg80211 if unset in EEPROM
Many AP devices do not have the proper regulatory domain programmed in EEPROM. Instead they expect the software to set the appropriate region. For these devices, the country code defaults to US, and the driver uses the US CTL tables as well. On devices bought in Europe this can lead to tx power being set too high on the band edges, even if the cfg80211 regdomain is set correctly. Fix this issue by taking into account the DFS region, but only when the EEPROM regdomain is set to default.
Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
show more ...
|
Revision tags: v3.18-rc1, v3.17, v3.17-rc7, v3.17-rc6, v3.17-rc5, v3.17-rc4, v3.17-rc3, v3.17-rc2, v3.17-rc1, v3.16, v3.16-rc7, v3.16-rc6, v3.16-rc5, v3.16-rc4, v3.16-rc3, v3.16-rc2, v3.16-rc1, v3.15, v3.15-rc8, v3.15-rc7, v3.15-rc6, v3.15-rc5, v3.15-rc4, v3.15-rc3, v3.15-rc2, v3.15-rc1, v3.14, v3.14-rc8, v3.14-rc7, v3.14-rc6, v3.14-rc5, v3.14-rc4, v3.14-rc3 |
|
#
ef8c0017 |
| 13-Feb-2014 |
Kalle Valo <kvalo@qca.qualcomm.com> |
ath: remove camel case from struct reg_dmn_pair_mapping
Fixes a checkpatch warning in ath10k:
drivers/net/wireless/ath/ath10k/mac.c:1636: WARNING: Avoid CamelCase: <regpair->regDmnEnum>
Signed-off
ath: remove camel case from struct reg_dmn_pair_mapping
Fixes a checkpatch warning in ath10k:
drivers/net/wireless/ath/ath10k/mac.c:1636: WARNING: Avoid CamelCase: <regpair->regDmnEnum>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
show more ...
|
Revision tags: v3.14-rc2, v3.14-rc1, v3.13, v3.13-rc8, v3.13-rc7, v3.13-rc6, v3.13-rc5, v3.13-rc4 |
|
#
4f7b9140 |
| 14-Dec-2013 |
Luis R. Rodriguez <mcgrof@do-not-panic.com> |
cfg80211: make regulatory_hint() remove REGULATORY_CUSTOM_REG
The REGULATORY_CUSTOM_REG can be used during early init with the goal of overriding the wiphy's default regulatory settings in case the
cfg80211: make regulatory_hint() remove REGULATORY_CUSTOM_REG
The REGULATORY_CUSTOM_REG can be used during early init with the goal of overriding the wiphy's default regulatory settings in case the alpha2 of the device is not known. In the case that the alpha2 becomes known lets avoid having drivers having to clear the REGULATORY_CUSTOM_REG flag by doing it for them when regulatory_hint() is used.
Cc: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
show more ...
|
#
8fc68580 |
| 14-Dec-2013 |
Luis R. Rodriguez <mcgrof@do-not-panic.com> |
ath: fix warning on usage of REGULATORY_CUSTOM_REG
ath wants to first apply the custom regd and only later will it revert to not using it if an alpha2 regulatory domain is found. Since the wireless
ath: fix warning on usage of REGULATORY_CUSTOM_REG
ath wants to first apply the custom regd and only later will it revert to not using it if an alpha2 regulatory domain is found. Since the wireless core now enforces usage of the REGULATORY_CUSTOM_REG strictly when wiphy_apply_custom_regulatory() is used this makes ath adhere to the expected behaviour but also updates the wiphy after its done with the custom usage.
This fixes this warning:
[ 5.488733] ath: phy0: ASPM enabled: 0x43 [ 5.488735] ath: EEPROM regdomain: 0x0 [ 5.488736] ath: EEPROM indicates default country code should be used [ 5.488736] ath: doing EEPROM country->regdmn map search [ 5.488737] ath: country maps to regdmn code: 0x3a [ 5.488737] ath: Country alpha2 being used: US [ 5.488738] ath: Regpair used: 0x3a [ 5.488738] ------------[ cut here ]------------ [ 5.488745] WARNING: CPU: 0 PID: 161 at /home/sujith/dev/wireless-testing/net/wireless/reg.c:1361 wiphy_apply_custom_regulatory+0x17a/0x1b0 [cfg80211]() [ 5.488746] wiphy should have REGULATORY_CUSTOM_REG
The wireless core can *later* lift this flag for us for when using the regulatory_hint() to make this fix more generic.
Reported-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
show more ...
|
Revision tags: v3.13-rc3, v3.13-rc2, v3.13-rc1, v3.12 |
|
#
251c9ba1 |
| 29-Oct-2013 |
Luis R. Rodriguez <mcgrof@do-not-panic.com> |
ath: fix dynamic user regulatory domain support
As it stands dynamic user regulatory domain support is only possible for a few programmed regulatory domains as a few countries do not allow for this.
ath: fix dynamic user regulatory domain support
As it stands dynamic user regulatory domain support is only possible for a few programmed regulatory domains as a few countries do not allow for this.
The existing code however only would take advantage of the feature if a custom world regulatory domain is used though as that's when we clear beconing flags. We need to lift this restriction as otherwise this feature is pointless.
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
show more ...
|
#
ba94c049 |
| 29-Oct-2013 |
Luis R. Rodriguez <mcgrof@do-not-panic.com> |
ath: dynamic user allow check helper to the top
This will be used later.
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
#
a44ea6ff |
| 29-Oct-2013 |
Luis R. Rodriguez <mcgrof@do-not-panic.com> |
ath: move dynamic_country_user_possible() to the top
This will be used later.
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
#
62452a99 |
| 29-Oct-2013 |
Luis R. Rodriguez <mcgrof@do-not-panic.com> |
ath: fix usage of freq_reg_info()
freq_reg_info() expects KHz and not MHz, fix this. In this case we'll now be getting the no-ir flags cleared on channels for any channel when the country IE trusts
ath: fix usage of freq_reg_info()
freq_reg_info() expects KHz and not MHz, fix this. In this case we'll now be getting the no-ir flags cleared on channels for any channel when the country IE trusts that channel.
@@ struct ieee80211_channel *ch; struct wiphy *wiphy; const struct ieee80211_reg_rule *rule; @@
-rule = freq_reg_info(wiphy, ch->center_freq); +rule = freq_reg_info(wiphy, MHZ_TO_KHZ(ch->center_freq));
Generated-by: Coccinelle SmPL Cc: Julia Lawall <julia.lawall@lip6.fr> Cc: Peter Senna Tschudin <peter.senna@gmail.com> Reported-by: Mihir Shete <smihir@qti.qualcomm.com> Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
show more ...
|
Revision tags: v3.12-rc7 |
|
#
07782d94 |
| 21-Oct-2013 |
Luis R. Rodriguez <mcgrof@do-not-panic.com> |
ath: move the channel for ath_reg_apply_beaconing_flags() into helper
While at it convert this into a switch statement, this makes it easier and manage.
Cc: smihir@qti.qualcomm.com Cc: tushnimb@qca
ath: move the channel for ath_reg_apply_beaconing_flags() into helper
While at it convert this into a switch statement, this makes it easier and manage.
Cc: smihir@qti.qualcomm.com Cc: tushnimb@qca.qualcomm.com Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
show more ...
|
#
6c3af588 |
| 21-Oct-2013 |
Luis R. Rodriguez <mcgrof@do-not-panic.com> |
ath: simplify ath_reg_apply_beaconing_flags()
Simplify ath_reg_apply_beaconing_flags() by making use of thew new no-ir helper.
Cc: smihir@qti.qualcomm.com Cc: tushnimb@qca.qualcomm.com Signed-off-b
ath: simplify ath_reg_apply_beaconing_flags()
Simplify ath_reg_apply_beaconing_flags() by making use of thew new no-ir helper.
Cc: smihir@qti.qualcomm.com Cc: tushnimb@qca.qualcomm.com Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
show more ...
|
#
f33cbc4f |
| 21-Oct-2013 |
Luis R. Rodriguez <mcgrof@do-not-panic.com> |
ath: rename ath_reg_apply_active_scan_flags() to ath_reg_apply_ir_flags()
This also applies the no-ibss flag to the channels or clears it. The idea here is to clarify no initiated radiation should b
ath: rename ath_reg_apply_active_scan_flags() to ath_reg_apply_ir_flags()
This also applies the no-ibss flag to the channels or clears it. The idea here is to clarify no initiated radiation should be allowed on these channels.
Cc: smihir@qti.qualcomm.com Cc: tushnimb@qca.qualcomm.com Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
show more ...
|
#
bc0aa069 |
| 21-Oct-2013 |
Luis R. Rodriguez <mcgrof@do-not-panic.com> |
ath: clean up ath_reg_apply_active_scan_flags()
The routine ath_reg_apply_active_scan_flags() can be a bit hard to read, this cleans it up by adding helpers for the two cases of clearing IR flags or
ath: clean up ath_reg_apply_active_scan_flags()
The routine ath_reg_apply_active_scan_flags() can be a bit hard to read, this cleans it up by adding helpers for the two cases of clearing IR flags or adding them. This approach also makes no assumptions on the index of channels 12 and 13 so it should be portable accross different drivers.
Cc: smihir@qti.qualcomm.com Cc: tushnimb@qca.qualcomm.com Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
show more ...
|
#
d44040de |
| 21-Oct-2013 |
Luis R. Rodriguez <mcgrof@do-not-panic.com> |
ath: fix logic on ath_reg_apply_active_scan_flags()
The existing logic removes the passive scan flag from channels 12 and 13 when a regulatory hint coming from something other than a country IE has
ath: fix logic on ath_reg_apply_active_scan_flags()
The existing logic removes the passive scan flag from channels 12 and 13 when a regulatory hint coming from something other than a country IE has been passed. This is incorrect, the original intention was to ensure we always have passive scan enabled for these two channels for a specific set of custom world regulatory domains.
Cc: smihir@qti.qualcomm.com Cc: tushnimb@qca.qualcomm.com Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
show more ...
|
#
a09a85a0 |
| 11-Nov-2013 |
Luis R. Rodriguez <mcgrof@do-not-panic.com> |
cfg80211: add flags to define country IE processing rules
802.11 cards may have different country IE parsing behavioural preferences and vendors may want to support these. These preferences were man
cfg80211: add flags to define country IE processing rules
802.11 cards may have different country IE parsing behavioural preferences and vendors may want to support these. These preferences were managed by the REGULATORY_CUSTOM_REG and the REGULATORY_STRICT_REG flags and their combination. Instead of using this existing notation, split out the country IE behavioural preferences as a new flag. This will allow us to add more customizations easily and make the code more maintainable.
Cc: Mihir Shete <smihir@qti.qualcomm.com> Cc: Henri Bahini <hbahini@qca.qualcomm.com> Cc: Tushnim Bhattacharyya <tushnimb@qca.qualcomm.com> Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com> [fix up conflicts] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
show more ...
|
#
a2f73b6c |
| 11-Nov-2013 |
Luis R. Rodriguez <mcgrof@do-not-panic.com> |
cfg80211: move regulatory flags to their own variable
We'll expand this later, this will make it easier to classify and review what things are related to regulatory or not.
Coccinelle only missed 4
cfg80211: move regulatory flags to their own variable
We'll expand this later, this will make it easier to classify and review what things are related to regulatory or not.
Coccinelle only missed 4 hits, which I had to do manually, supplying the SmPL in case of merge conflicts.
@@ struct wiphy *wiphy; @@ -wiphy->flags |= WIPHY_FLAG_CUSTOM_REGULATORY +wiphy->regulatory_flags |= REGULATORY_CUSTOM_REG @@ expression e; @@ -e->flags |= WIPHY_FLAG_CUSTOM_REGULATORY +e->regulatory_flags |= REGULATORY_CUSTOM_REG @@ struct wiphy *wiphy; @@ -wiphy->flags &= ~WIPHY_FLAG_CUSTOM_REGULATORY +wiphy->regulatory_flags &= ~REGULATORY_CUSTOM_REG @@ struct wiphy *wiphy; @@ -wiphy->flags & WIPHY_FLAG_CUSTOM_REGULATORY +wiphy->regulatory_flags & REGULATORY_CUSTOM_REG
@@ struct wiphy *wiphy; @@ -wiphy->flags |= WIPHY_FLAG_STRICT_REGULATORY +wiphy->regulatory_flags |= REGULATORY_STRICT_REG @@ expression e; @@ -e->flags |= WIPHY_FLAG_STRICT_REGULATORY +e->regulatory_flags |= REGULATORY_STRICT_REG @@ struct wiphy *wiphy; @@ -wiphy->flags &= ~WIPHY_FLAG_STRICT_REGULATORY +wiphy->regulatory_flags &= ~REGULATORY_STRICT_REG @@ struct wiphy *wiphy; @@ -wiphy->flags & WIPHY_FLAG_STRICT_REGULATORY +wiphy->regulatory_flags & REGULATORY_STRICT_REG
@@ struct wiphy *wiphy; @@ -wiphy->flags |= WIPHY_FLAG_DISABLE_BEACON_HINTS +wiphy->regulatory_flags |= REGULATORY_DISABLE_BEACON_HINTS @@ expression e; @@ -e->flags |= WIPHY_FLAG_DISABLE_BEACON_HINTS +e->regulatory_flags |= REGULATORY_DISABLE_BEACON_HINTS @@ struct wiphy *wiphy; @@ -wiphy->flags &= ~WIPHY_FLAG_DISABLE_BEACON_HINTS +wiphy->regulatory_flags &= ~REGULATORY_DISABLE_BEACON_HINTS @@ struct wiphy *wiphy; @@ -wiphy->flags & WIPHY_FLAG_DISABLE_BEACON_HINTS +wiphy->regulatory_flags & REGULATORY_DISABLE_BEACON_HINTS
Generated-by: Coccinelle SmPL Cc: Julia Lawall <julia.lawall@lip6.fr> Cc: Peter Senna Tschudin <peter.senna@gmail.com> Cc: Mihir Shete <smihir@qti.qualcomm.com> Cc: Henri Bahini <hbahini@qca.qualcomm.com> Cc: Tushnim Bhattacharyya <tushnimb@qca.qualcomm.com> Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com> [fix up whitespace damage, overly long lines] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
show more ...
|
#
8fe02e16 |
| 21-Oct-2013 |
Luis R. Rodriguez <mcgrof@do-not-panic.com> |
cfg80211: consolidate passive-scan and no-ibss flags
These two flags are used for the same purpose, just combine them into a no-ir flag to annotate no initiating radiation is allowed.
Old userspace
cfg80211: consolidate passive-scan and no-ibss flags
These two flags are used for the same purpose, just combine them into a no-ir flag to annotate no initiating radiation is allowed.
Old userspace sending either flag will have it treated as the no-ir flag. To be considerate to older userspace we also send both the no-ir flag and the old no-ibss flags. Newer userspace will have to be aware of older kernels.
Update all places in the tree using these flags with the following semantic patch:
@@ @@ -NL80211_RRF_PASSIVE_SCAN +NL80211_RRF_NO_IR @@ @@ -NL80211_RRF_NO_IBSS +NL80211_RRF_NO_IR @@ @@ -IEEE80211_CHAN_PASSIVE_SCAN +IEEE80211_CHAN_NO_IR @@ @@ -IEEE80211_CHAN_NO_IBSS +IEEE80211_CHAN_NO_IR @@ @@ -NL80211_RRF_NO_IR | NL80211_RRF_NO_IR +NL80211_RRF_NO_IR @@ @@ -IEEE80211_CHAN_NO_IR | IEEE80211_CHAN_NO_IR +IEEE80211_CHAN_NO_IR @@ @@ -(NL80211_RRF_NO_IR) +NL80211_RRF_NO_IR @@ @@ -(IEEE80211_CHAN_NO_IR) +IEEE80211_CHAN_NO_IR
Along with some hand-optimisations in documentation, to remove duplicates and to fix some indentation.
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com> [do all the driver updates in one go] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
show more ...
|