summaryrefslogtreecommitdiff
path: root/drivers/net/wireless/brcm80211/brcmsmac/channel.c
AgeCommit message (Collapse)AuthorFilesLines
2015-11-18brcm80211: move under broadcom vendor directoryKalle Valo1-774/+0
Part of reorganising wireless drivers directory and Kconfig. Note that I had to edit Makefiles from subdirectories to use the new location. Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2013-12-05brcm80211: fix usage of freq_reg_info()Luis R. Rodriguez1-1/+2
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> Cc: Seth Forshee <seth.forshee@canonical.com> Cc: Arend van Spriel <arend@broadcom.com> Reported-by: Mihir Shete <smihir@qti.qualcomm.com> Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com> Acked-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-11-25cfg80211: move regulatory flags to their own variableLuis R. Rodriguez1-2/+2
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>
2013-11-25cfg80211: consolidate passive-scan and no-ibss flagsLuis R. Rodriguez1-20/+11
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>
2013-03-25mac80211: Use a cfg80211_chan_def in ieee80211_hw_conf_chanKarl Beldan1-2/+2
Drivers that don't use chanctxes cannot perform VHT association because they still use a "backward compatibility" pair of {ieee80211_channel, nl80211_channel_type} in ieee80211_conf and ieee80211_local. Signed-off-by: Karl Beldan <karl.beldan@rivierawaves.com> [fix kernel-doc] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-14brcmsmac: fix brcms_c_country_valid()Dan Carpenter1-2/+1
ccode is not NUL terminated. Presumably insisting on a terminator makes brcms_c_country_valid() return false when it's not intended. ccode[2] is sprom->leddc_on_time. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-01-14wireless: make the reg_notifier() voidLuis R. Rodriguez1-4/+2
The reg_notifier()'s return value need not be checked as it is only supposed to do post regulatory work and that should never fail. Any behaviour to regulatory that needs to be considered before cfg80211 does work to a driver should be specified by using the already existing flags, the reg_notifier() just does post processing should it find it needs to. Also make lbs_reg_notifier static. Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com> [move lbs_reg_notifier to not break compile] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-01-03regulatory: use IS_ERR macro family for freq_reg_infoJohannes Berg1-4/+3
Instead of returning an error and filling a pointer return the pointer and an ERR_PTR value in error cases. Acked-by: Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-01-03regulatory: remove handling of channel bandwidthJohannes Berg1-1/+1
The channel bandwidth handling isn't really quite right, it assumes that a 40 MHz channel is really two 20 MHz channels, which isn't strictly true. This is the way the regulatory database handling is defined right now though so remove the logic to handle other channel widths. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-11-20brcmsmac: Use debug macros for general error and debug statementsSeth Forshee1-5/+5
Convert most uses of wiphy_* and pr_* for general error and debug messages to use the internal debug macros instead. Most code used only for initialization still use wiphy_err(), as well as some locations which are executed too early to use the debug macros. Some debug messages which are redundant or not useful are removed. Acked-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com> Tested-by: Daniel Wagner <wagi@monom.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-09-10brcmsmac: fix mismatch in number of custom regulatory rulesArend van Spriel1-1/+1
The driver provides the cfg80211 regulatory framework with a set of custom rules. However, there was a mismatch in number of rules and the actual rules provided. This resulted in setting an invalid power level: ieee80211 phy0: brcms_ops_config: change channel 13 ieee80211 phy0: brcms_ops_config: Error setting power_level (8758364) Closer look in cfg80211 regulatory blurb showed following bogus rule: cfg80211: 0 KHz - -60446948 KHz @ 875836468 KHz), (875836468 mBi, 875836468 mBm) Cc: Seth Forshee <seth.forshee@canonical.com> Reviewed-by: Piotr Haber <phaber@broadcom.com> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Reviewed-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-08-02brcmsmac: use channel flags to restrict OFDMSeth Forshee1-4/+1
brcmsmac cannot call freq_reg_info() during channel changes as it does not hold cfg80211_lock, and as a result it generates a lockdep warning. freq_reg_info() is being used to determine whether OFDM is allowed on the current channel, so we can avoid the errant call by using the new IEEE80211_CHAN_NO_OFDM for this purpose instead. Reported-by: Josh Boyer <jwboyer@redhat.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-07-10brcmsmac: fix brcms_c_regd_init() which crashed after 11ad patchArend van Spriel1-10/+7
This patch fixes an OOPS in brcmsmac driver, which was introduced by the 11ad patch 'cfg80211: add 802.11ad (60gHz band) support'. The value IEEE80211_NUM_BANDS increased, which was used in the brcms_c_regd_init() function. Cc: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com> Cc: Johannes Berg <johannes.berg@intel.com> Acked-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-06-22brcmsmac: fix NULL pointer crash in brcms_c_regd_init()Arend van Spriel1-0/+5
In the function brcms_c_regd_init() the channels are validated against the device capabilities. This is done for both 2.4G and 5G band, but there are devices that are 2.4G only, ie. BCM4313. For that device this leads to a NULL dereference. This patch adds a check in brcms_c_regd_init() to fix this. Issue introduced in wireless-next tree by following commit: cf03c5d brcm80211: smac: inform mac80211 of the X2 regulatory domain Cc: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-06-20brcm80211: smac: use current regulatory domain when checking whether OFDM is ↵Seth Forshee1-118/+14
allowed The brcmsmac internal regulatory data is being used to determine whether OFDM should be allowed, and this is only done once during initialization. To be effective this needs to be checked against mac80211's regulatory rules for the current channel. Reviewed-by: Arend Van Spriel <arend@broadcom.com> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-06-20brcm80211: smac: don't validate channels against internal regulatory dataSeth Forshee1-338/+6
The core regulatory support will disable channels not allowed by regulatory rules, so brcmsmac doesn't need to check whether or not the requested channel is permitted by regulatory. Reviewed-by: Arend Van Spriel <arend@broadcom.com> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-06-20brcm80211: smac: use mac80211 channel data for tx power limitsSeth Forshee1-59/+14
Currently the limits from the internal X2 domain are used, regardless of what regulatory rules are in effect. Instead use the power limits set by the higher-level regulatory support. The rules for the MIMO power limits are still always derived from the world domain, pending guidance from Broadcom as to how these need to be handled. This will be fixed later, but using the limits from the world domain works for now. Reviewed-by: Arend Van Spriel <arend@broadcom.com> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-06-20brcm80211: smac: enable/disable radio on regulatory updatesSeth Forshee1-41/+26
Currently the radio disable state is only updated during initialization, and it's only checked against the internal world domain. This is unnecessary, as there are always valid channels against this domain. Instead, check whether any channels are enabled in the regulatory notifier and update the radio state accordingly. Reviewed-by: Arend Van Spriel <arend@broadcom.com> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-06-20brcm80211: smac: inform mac80211 of the X2 regulatory domainSeth Forshee1-178/+207
brcmsmac implements enforcement of regulatory constraints internally, using a Broadcom-specific world roaming domain named X2. Besides being duplication of functionality this can also conflict with mac80211's regulatory implementation, as mac80211 is unaware of the X2 domain and thus might apply a more restrictive domain. This patch is the first step in making brcmsmac cooperate with mac80211's regulatory support. X2 is registered as a custom domain with mac80211, so that at least both implementations will be enforcing the same set of constraints. The internal enforcement of rules is kept for now; this will be converted over to relying on mac80211 regulatory enforcement in later patches. Reviewed-by: Arend Van Spriel <arend@broadcom.com> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-06-20brcm80211: smac: clean up channel.cSeth Forshee1-133/+5
Much of the code is either unsed or never put to any useful purpose. Remove this code in advance of reworking the driver's regulatory support. Reviewed-by: Arend Van Spriel <arend@broadcom.com> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Reviewed-by: Brett Rudley <brudley@broadcom.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-06-20brcm80211: smac: remove unused code for 40MHz channelsSeth Forshee1-116/+0
This code has been kept around in anticipation of adding support for 40MHz channels, but subsequent patches to better integrate with mac80211 regulatory support will render it completely broken. Therefore we should go ahead and remove it. Keep these changes separate from other cleanup patches in order to make it easier to resurrect 40MHz channel support at some point in the future. Reviewed-by: Arend Van Spriel <arend@broadcom.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-06-20brcm80211: smac: don't set up tx power limits during initializationSeth Forshee1-8/+0
This code is unnecessary, and in fact it's never executed because the interface is never up when brcms_c_channels_commit() is called. Removing it helps simplify the implementation of proper regulatory support. Reviewed-by: Arend Van Spriel <arend@broadcom.com> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Reviewed-by: Brett Rudley <brudley@broadcom.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-05-16brcmsmac: use sprom from bcmaHauke Mehrtens1-4/+3
bcma now provides all sprom attributes needed by brcmsmac and also parses them from the pci sprom ant otp. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Tested-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-04-13brcm80211: smac: only provide valid regulatory hintArend van Spriel1-1/+35
The driver provides a regulatory hint to cfg80211 as obtained from the SPROM. Mostly, this will be a two-letter ISO country code. However, it may obtain special country code similar to the world regulatory domain as used in cfg80211. This patch avoids setting these special codes as the hint is lost to cfg80211. Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Reviewed-by: Brett Rudley <brudley@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-11-11brcm80211: smac: remove code under unused macro definitionsArend van Spriel1-118/+0
There were a couple of code segments left that were placed under a macro definition that was not applicable or not used in the brcmsmac driver. These pieces of code have been removed. Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Reviewed-by: Roland Vossen <rvossen@broadcom.com> Reviewed-by: Alwin Beukers <alwin@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-10-14brcm80211: moved function brcmu_chspec_malformedAlwin Beukers1-1/+27
Moved brcmu_chspec_malformed into the only file using it. The function name was adjusted accordingly. Reported-by: Johannes Berg <johannes@sipsolutions.net> Reviewed-by: Roland Vossen <rvossen@broadcom.com> Reviewed-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-10-11net: wireless: add brcm80211 driversArend van Spriel1-0/+1565
Add the brcm80211 tree to drivers/net/wireless, and disable the version that's in drivers/staging. This version includes the sources currently in staging, plus any changes that have been sent out for review. Sources in staging will be deleted in a followup patch. Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-14 14:02:29 +0300