kernel/linux.git/drivers/net/wireless/ath/regd.c, branch linux-4.16.y

ath: Fix updating radar flags for coutry code India

2017-04-19T14:09:26+00:00

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 Signed-off-by: Kalle Valo

ath: export alpha2 helper

2016-10-04T15:01:48+00:00

This will be helpful for drivers that can acquire alpha2 regulatory codes. Signed-off-by: Michal Kazior Signed-off-by: Bartosz Markowski Signed-off-by: Kalle Valo

tree-wide: replace config_enabled() with IS_ENABLED()

2016-08-04T12:50:07+00:00

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 Acked-by: Kees Cook Cc: Stas Sergeev Cc: Matt Redfearn Cc: Joshua Kinard Cc: Jiri Slaby Cc: Bjorn Helgaas Cc: Borislav Petkov Cc: Markos Chandras Cc: "Dmitry V. Levin" Cc: yu-cheng yu Cc: James Hogan Cc: Brian Gerst Cc: Johannes Berg Cc: Peter Zijlstra Cc: Al Viro Cc: Will Drewry Cc: Nikolay Martynov Cc: Huacai Chen Cc: "H. Peter Anvin" Cc: Thomas Gleixner Cc: Daniel Borkmann Cc: Leonid Yegoshin Cc: Rafal Milecki Cc: James Cowgill Cc: Greg Kroah-Hartman Cc: Ralf Baechle Cc: Alex Smith Cc: Adam Buchbinder Cc: Qais Yousef Cc: Jiang Liu Cc: Mikko Rapeli Cc: Paul Gortmaker Cc: Denys Vlasenko Cc: Brian Norris Cc: Hidehiro Kawai Cc: "Luis R. Rodriguez" Cc: Andy Lutomirski Cc: Ingo Molnar Cc: Dave Hansen Cc: "Kirill A. Shutemov" Cc: Roland McGrath Cc: Paul Burton Cc: Kalle Valo Cc: Viresh Kumar Cc: Tony Wu Cc: Huaitong Han Cc: Sumit Semwal Cc: Alexei Starovoitov Cc: Juergen Gross Cc: Jason Cooper Cc: "David S. Miller" Cc: Oleg Nesterov Cc: Andrea Gelmini Cc: David Woodhouse Cc: Marc Zyngier Cc: Rabin Vincent Cc: "Maciej W. Rozycki" Cc: David Daney Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

cfg80211: remove enum ieee80211_band

2016-04-12T13:56:15+00:00

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

ath: use CTL region from cfg80211 if unset in EEPROM

2014-10-23T18:02:06+00:00

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 Signed-off-by: John W. Linville

ath: remove camel case from struct reg_dmn_pair_mapping

2014-02-14T11:20:32+00:00

Fixes a checkpatch warning in ath10k: drivers/net/wireless/ath/ath10k/mac.c:1636: WARNING: Avoid CamelCase: regDmnEnum> Signed-off-by: Kalle Valo

cfg80211: make regulatory_hint() remove REGULATORY_CUSTOM_REG

2014-01-13T19:46:58+00:00

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 Signed-off-by: Luis R. Rodriguez Signed-off-by: John W. Linville

ath: fix warning on usage of REGULATORY_CUSTOM_REG

2014-01-13T19:46:58+00:00

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 Signed-off-by: Luis R. Rodriguez Signed-off-by: John W. Linville

ath: fix dynamic user regulatory domain support

2013-12-05T20:45:51+00:00

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 Signed-off-by: John W. Linville

ath: dynamic user allow check helper to the top

2013-12-05T20:45:37+00:00

This will be used later. Signed-off-by: Luis R. Rodriguez Signed-off-by: John W. Linville