* [PATCH] ath9k: Support 4.9Ghz channels on AR9580 adapter. @ 2016-05-12 22:40 ` greearb at candelatech.com 0 siblings, 0 replies; 20+ messages in thread From: greearb @ 2016-05-12 22:40 UTC (permalink / raw) To: linux-wireless; +Cc: ath9k-devel, Ben Greear From: Ben Greear <greearb@candelatech.com> NOTE: These channels must not be used in most regulatory domains unless you have a license from the FCC or similar! A proper regulatory database is also required to actually use these channels. Signed-off-by: Ben Greear <greearb@candelatech.com> --- drivers/net/wireless/ath/ath9k/ath9k.h | 2 +- drivers/net/wireless/ath/ath9k/common-init.c | 42 ++++++++++++++++++++++------ drivers/net/wireless/ath/ath9k/hw.h | 4 +-- 3 files changed, 37 insertions(+), 11 deletions(-) diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h b/drivers/net/wireless/ath/ath9k/ath9k.h index d78bb10..0429bd5 100644 --- a/drivers/net/wireless/ath/ath9k/ath9k.h +++ b/drivers/net/wireless/ath/ath9k/ath9k.h @@ -958,7 +958,7 @@ struct ath_softc { struct device *dev; struct survey_info *cur_survey; - struct survey_info survey[ATH9K_NUM_CHANNELS]; + struct survey_info survey[ATH9K_MAX_NUM_CHANNELS]; struct tasklet_struct intr_tq; struct tasklet_struct bcon_tasklet; diff --git a/drivers/net/wireless/ath/ath9k/common-init.c b/drivers/net/wireless/ath/ath9k/common-init.c index a006c14..2bff831 100644 --- a/drivers/net/wireless/ath/ath9k/common-init.c +++ b/drivers/net/wireless/ath/ath9k/common-init.c @@ -86,6 +86,20 @@ static const struct ieee80211_channel ath9k_5ghz_chantable[] = { CHAN5G(5785, 35), /* Channel 157 */ CHAN5G(5805, 36), /* Channel 161 */ CHAN5G(5825, 37), /* Channel 165 */ + + /* 4.9Ghz channels, public safety channels, license is required in US + * and most other regulatory domains! + */ + CHAN5G(4915, 38), /* Channel 183 */ + CHAN5G(4920, 39), /* Channel 184 */ + CHAN5G(4925, 40), /* Channel 185 */ + CHAN5G(4935, 41), /* Channel 187 */ + CHAN5G(4940, 42), /* Channel 188 */ + CHAN5G(4945, 43), /* Channel 189 */ + CHAN5G(4960, 44), /* Channel 192 */ + CHAN5G(4970, 45), /* Channel 194 */ + CHAN5G(4980, 46), /* Channel 196 */ +#define ATH9K_NUM_49GHZ_CHANNELS 9 }; /* Atheros hardware rate code addition for short premble */ @@ -122,14 +136,28 @@ static struct ieee80211_rate ath9k_legacy_rates[] = { IEEE80211_RATE_SUPPORTS_10MHZ)), }; +static bool ath9k_49ghz_capable(struct ath_hw* ah) +{ + /* Seems AR9580 supports 4.9ghz, at least. */ + switch (ah->hw_version.devid) { + case AR9300_DEVID_AR9580: + return true; + } + return false; +} + + int ath9k_cmn_init_channels_rates(struct ath_common *common) { struct ath_hw *ah = (struct ath_hw *)common->ah; void *channels; + int num_5ghz_chan = ARRAY_SIZE(ath9k_5ghz_chantable); + if (!ath9k_49ghz_capable(ah)) + num_5ghz_chan -= ATH9K_NUM_49GHZ_CHANNELS; BUILD_BUG_ON(ARRAY_SIZE(ath9k_2ghz_chantable) + - ARRAY_SIZE(ath9k_5ghz_chantable) != - ATH9K_NUM_CHANNELS); + ARRAY_SIZE(ath9k_5ghz_chantable) > + ATH9K_MAX_NUM_CHANNELS); if (ah->caps.hw_caps & ATH9K_HW_CAP_2GHZ) { channels = devm_kzalloc(ah->dev, @@ -149,17 +177,15 @@ int ath9k_cmn_init_channels_rates(struct ath_common *common) } if (ah->caps.hw_caps & ATH9K_HW_CAP_5GHZ) { - channels = devm_kzalloc(ah->dev, - sizeof(ath9k_5ghz_chantable), GFP_KERNEL); + int ch_sz = num_5ghz_chan * sizeof(ath9k_5ghz_chantable[0]); + channels = devm_kzalloc(ah->dev, ch_sz, GFP_KERNEL); if (!channels) return -ENOMEM; - memcpy(channels, ath9k_5ghz_chantable, - sizeof(ath9k_5ghz_chantable)); + memcpy(channels, ath9k_5ghz_chantable, ch_sz); common->sbands[IEEE80211_BAND_5GHZ].channels = channels; common->sbands[IEEE80211_BAND_5GHZ].band = IEEE80211_BAND_5GHZ; - common->sbands[IEEE80211_BAND_5GHZ].n_channels = - ARRAY_SIZE(ath9k_5ghz_chantable); + common->sbands[IEEE80211_BAND_5GHZ].n_channels = num_5ghz_chan; common->sbands[IEEE80211_BAND_5GHZ].bitrates = ath9k_legacy_rates + 4; common->sbands[IEEE80211_BAND_5GHZ].n_bitrates = diff --git a/drivers/net/wireless/ath/ath9k/hw.h b/drivers/net/wireless/ath/ath9k/hw.h index 831a544..eaf8d2d 100644 --- a/drivers/net/wireless/ath/ath9k/hw.h +++ b/drivers/net/wireless/ath/ath9k/hw.h @@ -73,7 +73,7 @@ #define ATH9K_RSSI_BAD -128 -#define ATH9K_NUM_CHANNELS 38 +#define ATH9K_MAX_NUM_CHANNELS 47 /* Register read/write primitives */ #define REG_WRITE(_ah, _reg, _val) \ @@ -776,7 +776,7 @@ struct ath_hw { struct ath9k_hw_version hw_version; struct ath9k_ops_config config; struct ath9k_hw_capabilities caps; - struct ath9k_channel channels[ATH9K_NUM_CHANNELS]; + struct ath9k_channel channels[ATH9K_MAX_NUM_CHANNELS]; struct ath9k_channel *curchan; union { -- 1.9.3 ^ permalink raw reply related [flat|nested] 20+ messages in thread
* [ath9k-devel] [PATCH] ath9k: Support 4.9Ghz channels on AR9580 adapter. @ 2016-05-12 22:40 ` greearb at candelatech.com 0 siblings, 0 replies; 20+ messages in thread From: greearb at candelatech.com @ 2016-05-12 22:40 UTC (permalink / raw) To: ath9k-devel From: Ben Greear <greearb@candelatech.com> NOTE: These channels must not be used in most regulatory domains unless you have a license from the FCC or similar! A proper regulatory database is also required to actually use these channels. Signed-off-by: Ben Greear <greearb@candelatech.com> --- drivers/net/wireless/ath/ath9k/ath9k.h | 2 +- drivers/net/wireless/ath/ath9k/common-init.c | 42 ++++++++++++++++++++++------ drivers/net/wireless/ath/ath9k/hw.h | 4 +-- 3 files changed, 37 insertions(+), 11 deletions(-) diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h b/drivers/net/wireless/ath/ath9k/ath9k.h index d78bb10..0429bd5 100644 --- a/drivers/net/wireless/ath/ath9k/ath9k.h +++ b/drivers/net/wireless/ath/ath9k/ath9k.h @@ -958,7 +958,7 @@ struct ath_softc { struct device *dev; struct survey_info *cur_survey; - struct survey_info survey[ATH9K_NUM_CHANNELS]; + struct survey_info survey[ATH9K_MAX_NUM_CHANNELS]; struct tasklet_struct intr_tq; struct tasklet_struct bcon_tasklet; diff --git a/drivers/net/wireless/ath/ath9k/common-init.c b/drivers/net/wireless/ath/ath9k/common-init.c index a006c14..2bff831 100644 --- a/drivers/net/wireless/ath/ath9k/common-init.c +++ b/drivers/net/wireless/ath/ath9k/common-init.c @@ -86,6 +86,20 @@ static const struct ieee80211_channel ath9k_5ghz_chantable[] = { CHAN5G(5785, 35), /* Channel 157 */ CHAN5G(5805, 36), /* Channel 161 */ CHAN5G(5825, 37), /* Channel 165 */ + + /* 4.9Ghz channels, public safety channels, license is required in US + * and most other regulatory domains! + */ + CHAN5G(4915, 38), /* Channel 183 */ + CHAN5G(4920, 39), /* Channel 184 */ + CHAN5G(4925, 40), /* Channel 185 */ + CHAN5G(4935, 41), /* Channel 187 */ + CHAN5G(4940, 42), /* Channel 188 */ + CHAN5G(4945, 43), /* Channel 189 */ + CHAN5G(4960, 44), /* Channel 192 */ + CHAN5G(4970, 45), /* Channel 194 */ + CHAN5G(4980, 46), /* Channel 196 */ +#define ATH9K_NUM_49GHZ_CHANNELS 9 }; /* Atheros hardware rate code addition for short premble */ @@ -122,14 +136,28 @@ static struct ieee80211_rate ath9k_legacy_rates[] = { IEEE80211_RATE_SUPPORTS_10MHZ)), }; +static bool ath9k_49ghz_capable(struct ath_hw* ah) +{ + /* Seems AR9580 supports 4.9ghz, at least. */ + switch (ah->hw_version.devid) { + case AR9300_DEVID_AR9580: + return true; + } + return false; +} + + int ath9k_cmn_init_channels_rates(struct ath_common *common) { struct ath_hw *ah = (struct ath_hw *)common->ah; void *channels; + int num_5ghz_chan = ARRAY_SIZE(ath9k_5ghz_chantable); + if (!ath9k_49ghz_capable(ah)) + num_5ghz_chan -= ATH9K_NUM_49GHZ_CHANNELS; BUILD_BUG_ON(ARRAY_SIZE(ath9k_2ghz_chantable) + - ARRAY_SIZE(ath9k_5ghz_chantable) != - ATH9K_NUM_CHANNELS); + ARRAY_SIZE(ath9k_5ghz_chantable) > + ATH9K_MAX_NUM_CHANNELS); if (ah->caps.hw_caps & ATH9K_HW_CAP_2GHZ) { channels = devm_kzalloc(ah->dev, @@ -149,17 +177,15 @@ int ath9k_cmn_init_channels_rates(struct ath_common *common) } if (ah->caps.hw_caps & ATH9K_HW_CAP_5GHZ) { - channels = devm_kzalloc(ah->dev, - sizeof(ath9k_5ghz_chantable), GFP_KERNEL); + int ch_sz = num_5ghz_chan * sizeof(ath9k_5ghz_chantable[0]); + channels = devm_kzalloc(ah->dev, ch_sz, GFP_KERNEL); if (!channels) return -ENOMEM; - memcpy(channels, ath9k_5ghz_chantable, - sizeof(ath9k_5ghz_chantable)); + memcpy(channels, ath9k_5ghz_chantable, ch_sz); common->sbands[IEEE80211_BAND_5GHZ].channels = channels; common->sbands[IEEE80211_BAND_5GHZ].band = IEEE80211_BAND_5GHZ; - common->sbands[IEEE80211_BAND_5GHZ].n_channels = - ARRAY_SIZE(ath9k_5ghz_chantable); + common->sbands[IEEE80211_BAND_5GHZ].n_channels = num_5ghz_chan; common->sbands[IEEE80211_BAND_5GHZ].bitrates = ath9k_legacy_rates + 4; common->sbands[IEEE80211_BAND_5GHZ].n_bitrates = diff --git a/drivers/net/wireless/ath/ath9k/hw.h b/drivers/net/wireless/ath/ath9k/hw.h index 831a544..eaf8d2d 100644 --- a/drivers/net/wireless/ath/ath9k/hw.h +++ b/drivers/net/wireless/ath/ath9k/hw.h @@ -73,7 +73,7 @@ #define ATH9K_RSSI_BAD -128 -#define ATH9K_NUM_CHANNELS 38 +#define ATH9K_MAX_NUM_CHANNELS 47 /* Register read/write primitives */ #define REG_WRITE(_ah, _reg, _val) \ @@ -776,7 +776,7 @@ struct ath_hw { struct ath9k_hw_version hw_version; struct ath9k_ops_config config; struct ath9k_hw_capabilities caps; - struct ath9k_channel channels[ATH9K_NUM_CHANNELS]; + struct ath9k_channel channels[ATH9K_MAX_NUM_CHANNELS]; struct ath9k_channel *curchan; union { -- 1.9.3 ^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: ath9k: Support 4.9Ghz channels on AR9580 adapter. 2016-05-12 22:40 ` [ath9k-devel] " greearb at candelatech.com @ 2016-06-20 20:34 ` Kalle Valo -1 siblings, 0 replies; 20+ messages in thread From: Kalle Valo @ 2016-06-20 20:34 UTC (permalink / raw) To: Ben Greear; +Cc: linux-wireless, ath9k-devel, Ben Greear Ben Greear <greearb@candelatech.com> wrote: > From: Ben Greear <greearb@candelatech.com> > > NOTE: These channels must not be used in most regulatory > domains unless you have a license from the FCC or similar! > > A proper regulatory database is also required to actually use > these channels. > > Signed-off-by: Ben Greear <greearb@candelatech.com> I feel that the license is a problem and this doesn't belong to the kernel. The patch has been dropped. -- Sent by pwcli https://patchwork.kernel.org/patch/9086491/ ^ permalink raw reply [flat|nested] 20+ messages in thread
* [ath9k-devel] ath9k: Support 4.9Ghz channels on AR9580 adapter. @ 2016-06-20 20:34 ` Kalle Valo 0 siblings, 0 replies; 20+ messages in thread From: Kalle Valo @ 2016-06-20 20:34 UTC (permalink / raw) To: ath9k-devel Ben Greear <greearb@candelatech.com> wrote: > From: Ben Greear <greearb@candelatech.com> > > NOTE: These channels must not be used in most regulatory > domains unless you have a license from the FCC or similar! > > A proper regulatory database is also required to actually use > these channels. > > Signed-off-by: Ben Greear <greearb@candelatech.com> I feel that the license is a problem and this doesn't belong to the kernel. The patch has been dropped. -- Sent by pwcli https://patchwork.kernel.org/patch/9086491/ ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: ath9k: Support 4.9Ghz channels on AR9580 adapter. 2016-06-20 20:34 ` [ath9k-devel] " Kalle Valo @ 2016-06-20 20:41 ` Ben Greear -1 siblings, 0 replies; 20+ messages in thread From: Ben Greear @ 2016-06-20 20:41 UTC (permalink / raw) To: Kalle Valo; +Cc: linux-wireless, ath9k-devel On 06/20/2016 01:34 PM, Kalle Valo wrote: > Ben Greear <greearb@candelatech.com> wrote: >> From: Ben Greear <greearb@candelatech.com> >> >> NOTE: These channels must not be used in most regulatory >> domains unless you have a license from the FCC or similar! >> >> A proper regulatory database is also required to actually use >> these channels. >> >> Signed-off-by: Ben Greear <greearb@candelatech.com> > > I feel that the license is a problem and this doesn't belong to the kernel. > The patch has been dropped. It's not a lot different from having to be in normal FCC regulations w/regard to DFS channels, tx power, and such, but maybe having driver support is considered to make it too easy for users to hack around restrictions? Another part of this is that Cisco APs, at least, use fractional center frequencies (4942.5, for instance) when using 5Mhz bandwidths on 4.9Ghz channels, and that requires more patches that I don't think I even bothered to post. I'll keep this in my trees, someone needing it can just clone it and/or borrow patches as needed. Thanks, Ben -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com ^ permalink raw reply [flat|nested] 20+ messages in thread
* [ath9k-devel] ath9k: Support 4.9Ghz channels on AR9580 adapter. @ 2016-06-20 20:41 ` Ben Greear 0 siblings, 0 replies; 20+ messages in thread From: Ben Greear @ 2016-06-20 20:41 UTC (permalink / raw) To: ath9k-devel On 06/20/2016 01:34 PM, Kalle Valo wrote: > Ben Greear <greearb@candelatech.com> wrote: >> From: Ben Greear <greearb@candelatech.com> >> >> NOTE: These channels must not be used in most regulatory >> domains unless you have a license from the FCC or similar! >> >> A proper regulatory database is also required to actually use >> these channels. >> >> Signed-off-by: Ben Greear <greearb@candelatech.com> > > I feel that the license is a problem and this doesn't belong to the kernel. > The patch has been dropped. It's not a lot different from having to be in normal FCC regulations w/regard to DFS channels, tx power, and such, but maybe having driver support is considered to make it too easy for users to hack around restrictions? Another part of this is that Cisco APs, at least, use fractional center frequencies (4942.5, for instance) when using 5Mhz bandwidths on 4.9Ghz channels, and that requires more patches that I don't think I even bothered to post. I'll keep this in my trees, someone needing it can just clone it and/or borrow patches as needed. Thanks, Ben -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: ath9k: Support 4.9Ghz channels on AR9580 adapter. 2016-06-20 20:41 ` [ath9k-devel] " Ben Greear @ 2016-06-20 23:53 ` Julian Calaby -1 siblings, 0 replies; 20+ messages in thread From: Julian Calaby @ 2016-06-20 23:53 UTC (permalink / raw) To: Ben Greear; +Cc: Kalle Valo, linux-wireless, ath9k-devel Hi Ben, On Tue, Jun 21, 2016 at 6:41 AM, Ben Greear <greearb@candelatech.com> wrote: > On 06/20/2016 01:34 PM, Kalle Valo wrote: >> >> Ben Greear <greearb@candelatech.com> wrote: >>> >>> From: Ben Greear <greearb@candelatech.com> >>> >>> NOTE: These channels must not be used in most regulatory >>> domains unless you have a license from the FCC or similar! >>> >>> A proper regulatory database is also required to actually use >>> these channels. >>> >>> Signed-off-by: Ben Greear <greearb@candelatech.com> >> >> >> I feel that the license is a problem and this doesn't belong to the >> kernel. >> The patch has been dropped. > > > It's not a lot different from having to be in normal FCC regulations > w/regard to > DFS channels, tx power, and such, but maybe having driver support is > considered to make it > too easy for users to hack around restrictions? Maybe hide this behind CFG80211_CERTIFICATION_ONUS or equivalent? (Maybe a new symbol CFG80211_LICENSE_REQUIRED with big scary feds-will-come-knocking warnings in the help text?) Thanks, -- Julian Calaby Email: julian.calaby@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ ^ permalink raw reply [flat|nested] 20+ messages in thread
* [ath9k-devel] ath9k: Support 4.9Ghz channels on AR9580 adapter. @ 2016-06-20 23:53 ` Julian Calaby 0 siblings, 0 replies; 20+ messages in thread From: Julian Calaby @ 2016-06-20 23:53 UTC (permalink / raw) To: ath9k-devel Hi Ben, On Tue, Jun 21, 2016 at 6:41 AM, Ben Greear <greearb@candelatech.com> wrote: > On 06/20/2016 01:34 PM, Kalle Valo wrote: >> >> Ben Greear <greearb@candelatech.com> wrote: >>> >>> From: Ben Greear <greearb@candelatech.com> >>> >>> NOTE: These channels must not be used in most regulatory >>> domains unless you have a license from the FCC or similar! >>> >>> A proper regulatory database is also required to actually use >>> these channels. >>> >>> Signed-off-by: Ben Greear <greearb@candelatech.com> >> >> >> I feel that the license is a problem and this doesn't belong to the >> kernel. >> The patch has been dropped. > > > It's not a lot different from having to be in normal FCC regulations > w/regard to > DFS channels, tx power, and such, but maybe having driver support is > considered to make it > too easy for users to hack around restrictions? Maybe hide this behind CFG80211_CERTIFICATION_ONUS or equivalent? (Maybe a new symbol CFG80211_LICENSE_REQUIRED with big scary feds-will-come-knocking warnings in the help text?) Thanks, -- Julian Calaby Email: julian.calaby at gmail.com Profile: http://www.google.com/profiles/julian.calaby/ ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: ath9k: Support 4.9Ghz channels on AR9580 adapter. 2016-06-20 23:53 ` [ath9k-devel] " Julian Calaby @ 2016-06-21 0:00 ` Ben Greear -1 siblings, 0 replies; 20+ messages in thread From: Ben Greear @ 2016-06-21 0:00 UTC (permalink / raw) To: Julian Calaby; +Cc: Kalle Valo, linux-wireless, ath9k-devel On 06/20/2016 04:53 PM, Julian Calaby wrote: > Hi Ben, > > On Tue, Jun 21, 2016 at 6:41 AM, Ben Greear <greearb@candelatech.com> wrote: >> On 06/20/2016 01:34 PM, Kalle Valo wrote: >>> >>> Ben Greear <greearb@candelatech.com> wrote: >>>> >>>> From: Ben Greear <greearb@candelatech.com> >>>> >>>> NOTE: These channels must not be used in most regulatory >>>> domains unless you have a license from the FCC or similar! >>>> >>>> A proper regulatory database is also required to actually use >>>> these channels. >>>> >>>> Signed-off-by: Ben Greear <greearb@candelatech.com> >>> >>> >>> I feel that the license is a problem and this doesn't belong to the >>> kernel. >>> The patch has been dropped. >> >> >> It's not a lot different from having to be in normal FCC regulations >> w/regard to >> DFS channels, tx power, and such, but maybe having driver support is >> considered to make it >> too easy for users to hack around restrictions? > > Maybe hide this behind CFG80211_CERTIFICATION_ONUS or equivalent? > (Maybe a new symbol CFG80211_LICENSE_REQUIRED with big scary > feds-will-come-knocking warnings in the help text?) That would be fine with me. As I said though, there are more patches than this one needed for full features and interoperability. The person that sent me the mac80211/wireless patches, and hostapd for that matter, may be able to put something together for upstream, but I am not sure if they will have time. I don't currently feel motivated enough to try to clean it all up and try to push it upstream myself. Thanks, Ben -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com ^ permalink raw reply [flat|nested] 20+ messages in thread
* [ath9k-devel] ath9k: Support 4.9Ghz channels on AR9580 adapter. @ 2016-06-21 0:00 ` Ben Greear 0 siblings, 0 replies; 20+ messages in thread From: Ben Greear @ 2016-06-21 0:00 UTC (permalink / raw) To: ath9k-devel On 06/20/2016 04:53 PM, Julian Calaby wrote: > Hi Ben, > > On Tue, Jun 21, 2016 at 6:41 AM, Ben Greear <greearb@candelatech.com> wrote: >> On 06/20/2016 01:34 PM, Kalle Valo wrote: >>> >>> Ben Greear <greearb@candelatech.com> wrote: >>>> >>>> From: Ben Greear <greearb@candelatech.com> >>>> >>>> NOTE: These channels must not be used in most regulatory >>>> domains unless you have a license from the FCC or similar! >>>> >>>> A proper regulatory database is also required to actually use >>>> these channels. >>>> >>>> Signed-off-by: Ben Greear <greearb@candelatech.com> >>> >>> >>> I feel that the license is a problem and this doesn't belong to the >>> kernel. >>> The patch has been dropped. >> >> >> It's not a lot different from having to be in normal FCC regulations >> w/regard to >> DFS channels, tx power, and such, but maybe having driver support is >> considered to make it >> too easy for users to hack around restrictions? > > Maybe hide this behind CFG80211_CERTIFICATION_ONUS or equivalent? > (Maybe a new symbol CFG80211_LICENSE_REQUIRED with big scary > feds-will-come-knocking warnings in the help text?) That would be fine with me. As I said though, there are more patches than this one needed for full features and interoperability. The person that sent me the mac80211/wireless patches, and hostapd for that matter, may be able to put something together for upstream, but I am not sure if they will have time. I don't currently feel motivated enough to try to clean it all up and try to push it upstream myself. Thanks, Ben -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com ^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH] ath9k: Support 4.9Ghz channels on AR9580 adapter. 2016-06-20 23:53 ` [ath9k-devel] " Julian Calaby @ 2016-06-21 1:02 ` Julian Calaby -1 siblings, 0 replies; 20+ messages in thread From: Julian Calaby @ 2016-06-21 1:02 UTC (permalink / raw) To: linux-wireless Cc: Kalle Valo, QCA ath9k Development, ath9k-devel, Ben Greear, Julian Calaby From: Ben Greear <greearb@candelatech.com> NOTE: These channels must not be used in most regulatory domains unless you have a license from the FCC or similar! A proper regulatory database is also required to actually use these channels. Signed-off-by: Ben Greear <greearb@candelatech.com> [Hide this support behind a Kconfig option] Signed-off-by: Julian Calaby <julian.calaby@gmail.com> --- drivers/net/wireless/ath/ath9k/Kconfig | 19 +++++++++++ drivers/net/wireless/ath/ath9k/ath9k.h | 2 +- drivers/net/wireless/ath/ath9k/common-init.c | 49 +++++++++++++++++++++++----- drivers/net/wireless/ath/ath9k/hw.h | 4 +-- 4 files changed, 63 insertions(+), 11 deletions(-) Hi Kalle, I've only done this work as I hate to see people's efforts go to waste and I feel that there's enough roadblocks in the way of actually using this functionality that casual idiots won't be able to. I've tried to keep the code hidden by the Kconfig option as minimal as possible, however the #ifdef in ath9k_49ghz_capable() is arguably not required as returning true from that function still results in no action if the option is not enabled. This is compile tested only as I cannot test this for real as I lack both the hardware and license required. Thanks, Julian Calaby diff --git a/drivers/net/wireless/ath/ath9k/Kconfig b/drivers/net/wireless/ath/ath9k/Kconfig index f68cb00..57b0a41 100644 --- a/drivers/net/wireless/ath/ath9k/Kconfig +++ b/drivers/net/wireless/ath/ath9k/Kconfig @@ -114,6 +114,25 @@ config ATH9K_DFS_CERTIFIED developed. At this point enabling this option won't do anything except increase code size. +config ATH9K_49_GHZ_CHAN + bool "Support 4.9Ghz public safety channels on some devices" + depends on ATH9K && CFG80211_CERTIFICATION_ONUS + default n + ---help--- + This option enables support for 4.9 GHz channels on AR9580. + + These are PUBLIC SAFETY CHANNELS and MUST NOT BE USED in most + regulatory domains UNLESS YOU HAVE A FULL LICENSE for their use from + your local radio regulator, e.g. the FCC or equivalent. Using these + channels without proper authorisation may result in serious legal + consequences. + + You will also have to build a regulatory database with these channels + enabled to actually use them. + + If you are a distro kernel builder or have any doubt whatsoever about + your legal ability to use these channels, say N. + config ATH9K_DYNACK bool "Atheros ath9k ACK timeout estimation algorithm (EXPERIMENTAL)" depends on ATH9K diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h b/drivers/net/wireless/ath/ath9k/ath9k.h index 93b3793..d8744b5 100644 --- a/drivers/net/wireless/ath/ath9k/ath9k.h +++ b/drivers/net/wireless/ath/ath9k/ath9k.h @@ -954,7 +954,7 @@ struct ath_softc { struct device *dev; struct survey_info *cur_survey; - struct survey_info survey[ATH9K_NUM_CHANNELS]; + struct survey_info survey[ATH9K_MAX_NUM_CHANNELS]; struct tasklet_struct intr_tq; struct tasklet_struct bcon_tasklet; diff --git a/drivers/net/wireless/ath/ath9k/common-init.c b/drivers/net/wireless/ath/ath9k/common-init.c index 8b4f7fd..f6a495b 100644 --- a/drivers/net/wireless/ath/ath9k/common-init.c +++ b/drivers/net/wireless/ath/ath9k/common-init.c @@ -86,6 +86,24 @@ static const struct ieee80211_channel ath9k_5ghz_chantable[] = { CHAN5G(5785, 35), /* Channel 157 */ CHAN5G(5805, 36), /* Channel 161 */ CHAN5G(5825, 37), /* Channel 165 */ + +#ifdef ATH9K_49_GHZ_CHAN + /* 4.9Ghz channels, public safety channels, license is required in US + * and most other regulatory domains! + */ + CHAN5G(4915, 38), /* Channel 183 */ + CHAN5G(4920, 39), /* Channel 184 */ + CHAN5G(4925, 40), /* Channel 185 */ + CHAN5G(4935, 41), /* Channel 187 */ + CHAN5G(4940, 42), /* Channel 188 */ + CHAN5G(4945, 43), /* Channel 189 */ + CHAN5G(4960, 44), /* Channel 192 */ + CHAN5G(4970, 45), /* Channel 194 */ + CHAN5G(4980, 46), /* Channel 196 */ +#define ATH9K_NUM_49GHZ_CHANNELS 9 +#else +#define ATH9K_NUM_49GHZ_CHANNELS 0 +#endif }; /* Atheros hardware rate code addition for short premble */ @@ -122,14 +140,31 @@ static struct ieee80211_rate ath9k_legacy_rates[] = { IEEE80211_RATE_SUPPORTS_10MHZ)), }; +static bool ath9k_49ghz_capable(struct ath_hw *ah) +{ +#ifdef ATH9K_49_GHZ_CHAN + /* Seems AR9580 supports 4.9ghz, at least. */ + switch (ah->hw_version.devid) { + case AR9300_DEVID_AR9580: + return true; + } +#endif + + return false; +} + int ath9k_cmn_init_channels_rates(struct ath_common *common) { struct ath_hw *ah = (struct ath_hw *)common->ah; void *channels; + int num_5ghz_chan = ARRAY_SIZE(ath9k_5ghz_chantable); + + if (!ath9k_49ghz_capable(ah)) + num_5ghz_chan -= ATH9K_NUM_49GHZ_CHANNELS; BUILD_BUG_ON(ARRAY_SIZE(ath9k_2ghz_chantable) + - ARRAY_SIZE(ath9k_5ghz_chantable) != - ATH9K_NUM_CHANNELS); + ARRAY_SIZE(ath9k_5ghz_chantable) > + ATH9K_MAX_NUM_CHANNELS); if (ah->caps.hw_caps & ATH9K_HW_CAP_2GHZ) { channels = devm_kzalloc(ah->dev, @@ -149,17 +184,16 @@ int ath9k_cmn_init_channels_rates(struct ath_common *common) } if (ah->caps.hw_caps & ATH9K_HW_CAP_5GHZ) { - channels = devm_kzalloc(ah->dev, - sizeof(ath9k_5ghz_chantable), GFP_KERNEL); + int ch_sz = num_5ghz_chan * sizeof(ath9k_5ghz_chantable[0]); + + channels = devm_kzalloc(ah->dev, ch_sz, GFP_KERNEL); if (!channels) return -ENOMEM; - memcpy(channels, ath9k_5ghz_chantable, - sizeof(ath9k_5ghz_chantable)); + memcpy(channels, ath9k_5ghz_chantable, ch_sz); common->sbands[NL80211_BAND_5GHZ].channels = channels; common->sbands[NL80211_BAND_5GHZ].band = NL80211_BAND_5GHZ; - common->sbands[NL80211_BAND_5GHZ].n_channels = - ARRAY_SIZE(ath9k_5ghz_chantable); + common->sbands[NL80211_BAND_5GHZ].n_channels = num_5ghz_chan; common->sbands[NL80211_BAND_5GHZ].bitrates = ath9k_legacy_rates + 4; common->sbands[NL80211_BAND_5GHZ].n_bitrates = diff --git a/drivers/net/wireless/ath/ath9k/hw.h b/drivers/net/wireless/ath/ath9k/hw.h index 9cbca12..8115d86 100644 --- a/drivers/net/wireless/ath/ath9k/hw.h +++ b/drivers/net/wireless/ath/ath9k/hw.h @@ -73,7 +73,7 @@ #define ATH9K_RSSI_BAD -128 -#define ATH9K_NUM_CHANNELS 38 +#define ATH9K_MAX_NUM_CHANNELS 47 /* Register read/write primitives */ #define REG_WRITE(_ah, _reg, _val) \ @@ -777,7 +777,7 @@ struct ath_hw { struct ath9k_hw_version hw_version; struct ath9k_ops_config config; struct ath9k_hw_capabilities caps; - struct ath9k_channel channels[ATH9K_NUM_CHANNELS]; + struct ath9k_channel channels[ATH9K_MAX_NUM_CHANNELS]; struct ath9k_channel *curchan; union { -- 2.8.1 ^ permalink raw reply related [flat|nested] 20+ messages in thread
* [ath9k-devel] [PATCH] ath9k: Support 4.9Ghz channels on AR9580 adapter. @ 2016-06-21 1:02 ` Julian Calaby 0 siblings, 0 replies; 20+ messages in thread From: Julian Calaby @ 2016-06-21 1:02 UTC (permalink / raw) To: ath9k-devel From: Ben Greear <greearb@candelatech.com> NOTE: These channels must not be used in most regulatory domains unless you have a license from the FCC or similar! A proper regulatory database is also required to actually use these channels. Signed-off-by: Ben Greear <greearb@candelatech.com> [Hide this support behind a Kconfig option] Signed-off-by: Julian Calaby <julian.calaby@gmail.com> --- drivers/net/wireless/ath/ath9k/Kconfig | 19 +++++++++++ drivers/net/wireless/ath/ath9k/ath9k.h | 2 +- drivers/net/wireless/ath/ath9k/common-init.c | 49 +++++++++++++++++++++++----- drivers/net/wireless/ath/ath9k/hw.h | 4 +-- 4 files changed, 63 insertions(+), 11 deletions(-) Hi Kalle, I've only done this work as I hate to see people's efforts go to waste and I feel that there's enough roadblocks in the way of actually using this functionality that casual idiots won't be able to. I've tried to keep the code hidden by the Kconfig option as minimal as possible, however the #ifdef in ath9k_49ghz_capable() is arguably not required as returning true from that function still results in no action if the option is not enabled. This is compile tested only as I cannot test this for real as I lack both the hardware and license required. Thanks, Julian Calaby diff --git a/drivers/net/wireless/ath/ath9k/Kconfig b/drivers/net/wireless/ath/ath9k/Kconfig index f68cb00..57b0a41 100644 --- a/drivers/net/wireless/ath/ath9k/Kconfig +++ b/drivers/net/wireless/ath/ath9k/Kconfig @@ -114,6 +114,25 @@ config ATH9K_DFS_CERTIFIED developed. At this point enabling this option won't do anything except increase code size. +config ATH9K_49_GHZ_CHAN + bool "Support 4.9Ghz public safety channels on some devices" + depends on ATH9K && CFG80211_CERTIFICATION_ONUS + default n + ---help--- + This option enables support for 4.9 GHz channels on AR9580. + + These are PUBLIC SAFETY CHANNELS and MUST NOT BE USED in most + regulatory domains UNLESS YOU HAVE A FULL LICENSE for their use from + your local radio regulator, e.g. the FCC or equivalent. Using these + channels without proper authorisation may result in serious legal + consequences. + + You will also have to build a regulatory database with these channels + enabled to actually use them. + + If you are a distro kernel builder or have any doubt whatsoever about + your legal ability to use these channels, say N. + config ATH9K_DYNACK bool "Atheros ath9k ACK timeout estimation algorithm (EXPERIMENTAL)" depends on ATH9K diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h b/drivers/net/wireless/ath/ath9k/ath9k.h index 93b3793..d8744b5 100644 --- a/drivers/net/wireless/ath/ath9k/ath9k.h +++ b/drivers/net/wireless/ath/ath9k/ath9k.h @@ -954,7 +954,7 @@ struct ath_softc { struct device *dev; struct survey_info *cur_survey; - struct survey_info survey[ATH9K_NUM_CHANNELS]; + struct survey_info survey[ATH9K_MAX_NUM_CHANNELS]; struct tasklet_struct intr_tq; struct tasklet_struct bcon_tasklet; diff --git a/drivers/net/wireless/ath/ath9k/common-init.c b/drivers/net/wireless/ath/ath9k/common-init.c index 8b4f7fd..f6a495b 100644 --- a/drivers/net/wireless/ath/ath9k/common-init.c +++ b/drivers/net/wireless/ath/ath9k/common-init.c @@ -86,6 +86,24 @@ static const struct ieee80211_channel ath9k_5ghz_chantable[] = { CHAN5G(5785, 35), /* Channel 157 */ CHAN5G(5805, 36), /* Channel 161 */ CHAN5G(5825, 37), /* Channel 165 */ + +#ifdef ATH9K_49_GHZ_CHAN + /* 4.9Ghz channels, public safety channels, license is required in US + * and most other regulatory domains! + */ + CHAN5G(4915, 38), /* Channel 183 */ + CHAN5G(4920, 39), /* Channel 184 */ + CHAN5G(4925, 40), /* Channel 185 */ + CHAN5G(4935, 41), /* Channel 187 */ + CHAN5G(4940, 42), /* Channel 188 */ + CHAN5G(4945, 43), /* Channel 189 */ + CHAN5G(4960, 44), /* Channel 192 */ + CHAN5G(4970, 45), /* Channel 194 */ + CHAN5G(4980, 46), /* Channel 196 */ +#define ATH9K_NUM_49GHZ_CHANNELS 9 +#else +#define ATH9K_NUM_49GHZ_CHANNELS 0 +#endif }; /* Atheros hardware rate code addition for short premble */ @@ -122,14 +140,31 @@ static struct ieee80211_rate ath9k_legacy_rates[] = { IEEE80211_RATE_SUPPORTS_10MHZ)), }; +static bool ath9k_49ghz_capable(struct ath_hw *ah) +{ +#ifdef ATH9K_49_GHZ_CHAN + /* Seems AR9580 supports 4.9ghz, at least. */ + switch (ah->hw_version.devid) { + case AR9300_DEVID_AR9580: + return true; + } +#endif + + return false; +} + int ath9k_cmn_init_channels_rates(struct ath_common *common) { struct ath_hw *ah = (struct ath_hw *)common->ah; void *channels; + int num_5ghz_chan = ARRAY_SIZE(ath9k_5ghz_chantable); + + if (!ath9k_49ghz_capable(ah)) + num_5ghz_chan -= ATH9K_NUM_49GHZ_CHANNELS; BUILD_BUG_ON(ARRAY_SIZE(ath9k_2ghz_chantable) + - ARRAY_SIZE(ath9k_5ghz_chantable) != - ATH9K_NUM_CHANNELS); + ARRAY_SIZE(ath9k_5ghz_chantable) > + ATH9K_MAX_NUM_CHANNELS); if (ah->caps.hw_caps & ATH9K_HW_CAP_2GHZ) { channels = devm_kzalloc(ah->dev, @@ -149,17 +184,16 @@ int ath9k_cmn_init_channels_rates(struct ath_common *common) } if (ah->caps.hw_caps & ATH9K_HW_CAP_5GHZ) { - channels = devm_kzalloc(ah->dev, - sizeof(ath9k_5ghz_chantable), GFP_KERNEL); + int ch_sz = num_5ghz_chan * sizeof(ath9k_5ghz_chantable[0]); + + channels = devm_kzalloc(ah->dev, ch_sz, GFP_KERNEL); if (!channels) return -ENOMEM; - memcpy(channels, ath9k_5ghz_chantable, - sizeof(ath9k_5ghz_chantable)); + memcpy(channels, ath9k_5ghz_chantable, ch_sz); common->sbands[NL80211_BAND_5GHZ].channels = channels; common->sbands[NL80211_BAND_5GHZ].band = NL80211_BAND_5GHZ; - common->sbands[NL80211_BAND_5GHZ].n_channels = - ARRAY_SIZE(ath9k_5ghz_chantable); + common->sbands[NL80211_BAND_5GHZ].n_channels = num_5ghz_chan; common->sbands[NL80211_BAND_5GHZ].bitrates = ath9k_legacy_rates + 4; common->sbands[NL80211_BAND_5GHZ].n_bitrates = diff --git a/drivers/net/wireless/ath/ath9k/hw.h b/drivers/net/wireless/ath/ath9k/hw.h index 9cbca12..8115d86 100644 --- a/drivers/net/wireless/ath/ath9k/hw.h +++ b/drivers/net/wireless/ath/ath9k/hw.h @@ -73,7 +73,7 @@ #define ATH9K_RSSI_BAD -128 -#define ATH9K_NUM_CHANNELS 38 +#define ATH9K_MAX_NUM_CHANNELS 47 /* Register read/write primitives */ #define REG_WRITE(_ah, _reg, _val) \ @@ -777,7 +777,7 @@ struct ath_hw { struct ath9k_hw_version hw_version; struct ath9k_ops_config config; struct ath9k_hw_capabilities caps; - struct ath9k_channel channels[ATH9K_NUM_CHANNELS]; + struct ath9k_channel channels[ATH9K_MAX_NUM_CHANNELS]; struct ath9k_channel *curchan; union { -- 2.8.1 ^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: [PATCH] ath9k: Support 4.9Ghz channels on AR9580 adapter. 2016-06-21 1:02 ` [ath9k-devel] " Julian Calaby @ 2016-06-21 9:41 ` Jouni Malinen -1 siblings, 0 replies; 20+ messages in thread From: Jouni Malinen @ 2016-06-21 9:41 UTC (permalink / raw) To: Julian Calaby Cc: linux-wireless, Kalle Valo, QCA ath9k Development, ath9k-devel, Ben Greear On Tue, Jun 21, 2016 at 11:02:20AM +1000, Julian Calaby wrote: > I've only done this work as I hate to see people's efforts go to > waste and I feel that there's enough roadblocks in the way of > actually using this functionality that casual idiots won't be able > to. Are these really ready to go to the upstream kernel in this state and without the other changes that would be needed to operate correctly? What is the use case for these and how have these been tested? > This is compile tested only as I cannot test this for real as I lack > both the hardware and license required. I don't think this is sufficient when touching this type of area. I would not apply these without proper testing and full set of functionality being available. I see no point in ath9k defining additional channels if all those new channels can cause is harm and not correct functionality. This channel list addition looks like the easiest part to handle compared to the other patches needed for 4.9 GHz and this would be the last patch on my list to get accepted.. > diff --git a/drivers/net/wireless/ath/ath9k/common-init.c b/drivers/net/wireless/ath/ath9k/common-init.c > +#ifdef ATH9K_49_GHZ_CHAN > + /* 4.9Ghz channels, public safety channels, license is required in US > + * and most other regulatory domains! > + */ > + CHAN5G(4915, 38), /* Channel 183 */ > + CHAN5G(4920, 39), /* Channel 184 */ > + CHAN5G(4925, 40), /* Channel 185 */ > + CHAN5G(4935, 41), /* Channel 187 */ > + CHAN5G(4940, 42), /* Channel 188 */ > + CHAN5G(4945, 43), /* Channel 189 */ > + CHAN5G(4960, 44), /* Channel 192 */ > + CHAN5G(4970, 45), /* Channel 194 */ > + CHAN5G(4980, 46), /* Channel 196 */ Where are these channels defined and are these really correct frequencies for them? Please note that many of the 4.9 GHz channels have channel starting frequencies like 4.9375 GHz and 4.0025 GHz, i.e., fractional MHz.. While US public safety may not have all those cases, even there are some 0.5 MHz cases. In addition, those channel numbers sound more like some of the channels defined in Japan rather than US public safety operating class. In addition, some of these channels seem to be outside the US public safety range. Is this trying to add 4.9 GHz channels in general for multiple different use cases? And if so, what are those use cases? Or is this only for some public safety cases? And if so, for which regulatory domains? To be frank, I really don't see how this would be even close to a state that should be accepted into the upstream tree. -- Jouni Malinen PGP id EFC895FA ^ permalink raw reply [flat|nested] 20+ messages in thread
* [ath9k-devel] [PATCH] ath9k: Support 4.9Ghz channels on AR9580 adapter. @ 2016-06-21 9:41 ` Jouni Malinen 0 siblings, 0 replies; 20+ messages in thread From: Jouni Malinen @ 2016-06-21 9:41 UTC (permalink / raw) To: ath9k-devel On Tue, Jun 21, 2016 at 11:02:20AM +1000, Julian Calaby wrote: > I've only done this work as I hate to see people's efforts go to > waste and I feel that there's enough roadblocks in the way of > actually using this functionality that casual idiots won't be able > to. Are these really ready to go to the upstream kernel in this state and without the other changes that would be needed to operate correctly? What is the use case for these and how have these been tested? > This is compile tested only as I cannot test this for real as I lack > both the hardware and license required. I don't think this is sufficient when touching this type of area. I would not apply these without proper testing and full set of functionality being available. I see no point in ath9k defining additional channels if all those new channels can cause is harm and not correct functionality. This channel list addition looks like the easiest part to handle compared to the other patches needed for 4.9 GHz and this would be the last patch on my list to get accepted.. > diff --git a/drivers/net/wireless/ath/ath9k/common-init.c b/drivers/net/wireless/ath/ath9k/common-init.c > +#ifdef ATH9K_49_GHZ_CHAN > + /* 4.9Ghz channels, public safety channels, license is required in US > + * and most other regulatory domains! > + */ > + CHAN5G(4915, 38), /* Channel 183 */ > + CHAN5G(4920, 39), /* Channel 184 */ > + CHAN5G(4925, 40), /* Channel 185 */ > + CHAN5G(4935, 41), /* Channel 187 */ > + CHAN5G(4940, 42), /* Channel 188 */ > + CHAN5G(4945, 43), /* Channel 189 */ > + CHAN5G(4960, 44), /* Channel 192 */ > + CHAN5G(4970, 45), /* Channel 194 */ > + CHAN5G(4980, 46), /* Channel 196 */ Where are these channels defined and are these really correct frequencies for them? Please note that many of the 4.9 GHz channels have channel starting frequencies like 4.9375 GHz and 4.0025 GHz, i.e., fractional MHz.. While US public safety may not have all those cases, even there are some 0.5 MHz cases. In addition, those channel numbers sound more like some of the channels defined in Japan rather than US public safety operating class. In addition, some of these channels seem to be outside the US public safety range. Is this trying to add 4.9 GHz channels in general for multiple different use cases? And if so, what are those use cases? Or is this only for some public safety cases? And if so, for which regulatory domains? To be frank, I really don't see how this would be even close to a state that should be accepted into the upstream tree. -- Jouni Malinen PGP id EFC895FA ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] ath9k: Support 4.9Ghz channels on AR9580 adapter. 2016-06-21 9:41 ` [ath9k-devel] " Jouni Malinen @ 2016-06-21 10:16 ` Julian Calaby -1 siblings, 0 replies; 20+ messages in thread From: Julian Calaby @ 2016-06-21 10:16 UTC (permalink / raw) To: Jouni Malinen Cc: linux-wireless, Kalle Valo, QCA ath9k Development, ath9k-devel, Ben Greear Hi Jouni, On Tue, Jun 21, 2016 at 7:41 PM, Jouni Malinen <j@w1.fi> wrote: > On Tue, Jun 21, 2016 at 11:02:20AM +1000, Julian Calaby wrote: >> I've only done this work as I hate to see people's efforts go to >> waste and I feel that there's enough roadblocks in the way of >> actually using this functionality that casual idiots won't be able >> to. > > Are these really ready to go to the upstream kernel in this state and > without the other changes that would be needed to operate correctly? > What is the use case for these and how have these been tested? This patch is a edited version (adding the Kconfig option) of Ben's patch. I picked it up as he seemed to have given up on it and I could see nothing directly wrong with the patch. >> This is compile tested only as I cannot test this for real as I lack >> both the hardware and license required. > > I don't think this is sufficient when touching this type of area. I > would not apply these without proper testing and full set of > functionality being available. I see no point in ath9k defining > additional channels if all those new channels can cause is harm and not > correct functionality. This channel list addition looks like the easiest > part to handle compared to the other patches needed for 4.9 GHz and this > would be the last patch on my list to get accepted.. It isn't, Ben himself has said that fractional MHz need to be supported for this to be 100% correct, however I believe that defining the channels is minimally sufficient for his purposes. I do know he's done more work than this, however I can't pick that up as getting it ready for upstream requires testing I can't do. >> diff --git a/drivers/net/wireless/ath/ath9k/common-init.c b/drivers/net/wireless/ath/ath9k/common-init.c >> +#ifdef ATH9K_49_GHZ_CHAN >> + /* 4.9Ghz channels, public safety channels, license is required in US >> + * and most other regulatory domains! >> + */ >> + CHAN5G(4915, 38), /* Channel 183 */ >> + CHAN5G(4920, 39), /* Channel 184 */ >> + CHAN5G(4925, 40), /* Channel 185 */ >> + CHAN5G(4935, 41), /* Channel 187 */ >> + CHAN5G(4940, 42), /* Channel 188 */ >> + CHAN5G(4945, 43), /* Channel 189 */ >> + CHAN5G(4960, 44), /* Channel 192 */ >> + CHAN5G(4970, 45), /* Channel 194 */ >> + CHAN5G(4980, 46), /* Channel 196 */ > > Where are these channels defined and are these really correct > frequencies for them? Please note that many of the 4.9 GHz channels have > channel starting frequencies like 4.9375 GHz and 4.0025 GHz, i.e., > fractional MHz.. While US public safety may not have all those cases, > even there are some 0.5 MHz cases. In addition, those channel numbers > sound more like some of the channels defined in Japan rather than US > public safety operating class. In addition, some of these channels seem > to be outside the US public safety range. >From my perspective, this is enough to reject the patch outright. I assumed the frequencies and numbers were correct, which is why I picked it up. > Is this trying to add 4.9 GHz channels in general for multiple different > use cases? And if so, what are those use cases? Or is this only for some > public safety cases? And if so, for which regulatory domains? I believe he has a client that requires this support in a Linux kernel. > To be frank, I really don't see how this would be even close to a state > that should be accepted into the upstream tree. Fair enough I'm dropping this. Kalle, I've marked this as rejected and archived on Patchwork. Thanks, -- Julian Calaby Email: julian.calaby@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ ^ permalink raw reply [flat|nested] 20+ messages in thread
* [ath9k-devel] [PATCH] ath9k: Support 4.9Ghz channels on AR9580 adapter. @ 2016-06-21 10:16 ` Julian Calaby 0 siblings, 0 replies; 20+ messages in thread From: Julian Calaby @ 2016-06-21 10:16 UTC (permalink / raw) To: ath9k-devel Hi Jouni, On Tue, Jun 21, 2016 at 7:41 PM, Jouni Malinen <j@w1.fi> wrote: > On Tue, Jun 21, 2016 at 11:02:20AM +1000, Julian Calaby wrote: >> I've only done this work as I hate to see people's efforts go to >> waste and I feel that there's enough roadblocks in the way of >> actually using this functionality that casual idiots won't be able >> to. > > Are these really ready to go to the upstream kernel in this state and > without the other changes that would be needed to operate correctly? > What is the use case for these and how have these been tested? This patch is a edited version (adding the Kconfig option) of Ben's patch. I picked it up as he seemed to have given up on it and I could see nothing directly wrong with the patch. >> This is compile tested only as I cannot test this for real as I lack >> both the hardware and license required. > > I don't think this is sufficient when touching this type of area. I > would not apply these without proper testing and full set of > functionality being available. I see no point in ath9k defining > additional channels if all those new channels can cause is harm and not > correct functionality. This channel list addition looks like the easiest > part to handle compared to the other patches needed for 4.9 GHz and this > would be the last patch on my list to get accepted.. It isn't, Ben himself has said that fractional MHz need to be supported for this to be 100% correct, however I believe that defining the channels is minimally sufficient for his purposes. I do know he's done more work than this, however I can't pick that up as getting it ready for upstream requires testing I can't do. >> diff --git a/drivers/net/wireless/ath/ath9k/common-init.c b/drivers/net/wireless/ath/ath9k/common-init.c >> +#ifdef ATH9K_49_GHZ_CHAN >> + /* 4.9Ghz channels, public safety channels, license is required in US >> + * and most other regulatory domains! >> + */ >> + CHAN5G(4915, 38), /* Channel 183 */ >> + CHAN5G(4920, 39), /* Channel 184 */ >> + CHAN5G(4925, 40), /* Channel 185 */ >> + CHAN5G(4935, 41), /* Channel 187 */ >> + CHAN5G(4940, 42), /* Channel 188 */ >> + CHAN5G(4945, 43), /* Channel 189 */ >> + CHAN5G(4960, 44), /* Channel 192 */ >> + CHAN5G(4970, 45), /* Channel 194 */ >> + CHAN5G(4980, 46), /* Channel 196 */ > > Where are these channels defined and are these really correct > frequencies for them? Please note that many of the 4.9 GHz channels have > channel starting frequencies like 4.9375 GHz and 4.0025 GHz, i.e., > fractional MHz.. While US public safety may not have all those cases, > even there are some 0.5 MHz cases. In addition, those channel numbers > sound more like some of the channels defined in Japan rather than US > public safety operating class. In addition, some of these channels seem > to be outside the US public safety range. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] ath9k: Support 4.9Ghz channels on AR9580 adapter. 2016-06-21 9:41 ` [ath9k-devel] " Jouni Malinen @ 2016-06-21 14:17 ` Ben Greear -1 siblings, 0 replies; 20+ messages in thread From: Ben Greear @ 2016-06-21 14:17 UTC (permalink / raw) To: Jouni Malinen, Julian Calaby Cc: linux-wireless, Kalle Valo, QCA ath9k Development, ath9k-devel On 06/21/2016 02:41 AM, Jouni Malinen wrote: > On Tue, Jun 21, 2016 at 11:02:20AM +1000, Julian Calaby wrote: >> I've only done this work as I hate to see people's efforts go to >> waste and I feel that there's enough roadblocks in the way of >> actually using this functionality that casual idiots won't be able >> to. > > Are these really ready to go to the upstream kernel in this state and > without the other changes that would be needed to operate correctly? > What is the use case for these and how have these been tested? More patches are needed to make this work properly. My full patchset, with modifications to supplicant, *has* been tested, including against a Cisco AP running 5Mhz channels. >> This is compile tested only as I cannot test this for real as I lack >> both the hardware and license required. > > I don't think this is sufficient when touching this type of area. I > would not apply these without proper testing and full set of > functionality being available. I see no point in ath9k defining > additional channels if all those new channels can cause is harm and not > correct functionality. This channel list addition looks like the easiest > part to handle compared to the other patches needed for 4.9 GHz and this > would be the last patch on my list to get accepted.. > > >> diff --git a/drivers/net/wireless/ath/ath9k/common-init.c b/drivers/net/wireless/ath/ath9k/common-init.c >> +#ifdef ATH9K_49_GHZ_CHAN >> + /* 4.9Ghz channels, public safety channels, license is required in US >> + * and most other regulatory domains! >> + */ >> + CHAN5G(4915, 38), /* Channel 183 */ >> + CHAN5G(4920, 39), /* Channel 184 */ >> + CHAN5G(4925, 40), /* Channel 185 */ >> + CHAN5G(4935, 41), /* Channel 187 */ >> + CHAN5G(4940, 42), /* Channel 188 */ >> + CHAN5G(4945, 43), /* Channel 189 */ >> + CHAN5G(4960, 44), /* Channel 192 */ >> + CHAN5G(4970, 45), /* Channel 194 */ >> + CHAN5G(4980, 46), /* Channel 196 */ > > Where are these channels defined and are these really correct > frequencies for them? Please note that many of the 4.9 GHz channels have > channel starting frequencies like 4.9375 GHz and 4.0025 GHz, i.e., > fractional MHz.. While US public safety may not have all those cases, > even there are some 0.5 MHz cases. In addition, those channel numbers > sound more like some of the channels defined in Japan rather than US > public safety operating class. In addition, some of these channels seem > to be outside the US public safety range. I got these from WiKi pedia. There is a later patch that adds the 5Mhz channels that Cisco uses. I figured that since this is all restricted anyway, that users of it would know how to make it work (and they would have to hack regdb in order to use any of them anyway). > Is this trying to add 4.9 GHz channels in general for multiple different > use cases? And if so, what are those use cases? Or is this only for some > public safety cases? And if so, for which regulatory domains? > > To be frank, I really don't see how this would be even close to a state > that should be accepted into the upstream tree. It was a starting point, and posted mainly to let folks know how to get started. As I said, I don't have interest in trying to push all the changes upstream, but they are in my kernel tree on dmz2.candelatech.com and hostap tree on github, so maybe someone who has interest in dealing with upstreaming them can take them over. Thanks, Ben -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com ^ permalink raw reply [flat|nested] 20+ messages in thread
* [ath9k-devel] [PATCH] ath9k: Support 4.9Ghz channels on AR9580 adapter. @ 2016-06-21 14:17 ` Ben Greear 0 siblings, 0 replies; 20+ messages in thread From: Ben Greear @ 2016-06-21 14:17 UTC (permalink / raw) To: ath9k-devel On 06/21/2016 02:41 AM, Jouni Malinen wrote: > On Tue, Jun 21, 2016 at 11:02:20AM +1000, Julian Calaby wrote: >> I've only done this work as I hate to see people's efforts go to >> waste and I feel that there's enough roadblocks in the way of >> actually using this functionality that casual idiots won't be able >> to. > > Are these really ready to go to the upstream kernel in this state and > without the other changes that would be needed to operate correctly? > What is the use case for these and how have these been tested? More patches are needed to make this work properly. My full patchset, with modifications to supplicant, *has* been tested, including against a Cisco AP running 5Mhz channels. >> This is compile tested only as I cannot test this for real as I lack >> both the hardware and license required. > > I don't think this is sufficient when touching this type of area. I > would not apply these without proper testing and full set of > functionality being available. I see no point in ath9k defining > additional channels if all those new channels can cause is harm and not > correct functionality. This channel list addition looks like the easiest > part to handle compared to the other patches needed for 4.9 GHz and this > would be the last patch on my list to get accepted.. > > >> diff --git a/drivers/net/wireless/ath/ath9k/common-init.c b/drivers/net/wireless/ath/ath9k/common-init.c >> +#ifdef ATH9K_49_GHZ_CHAN >> + /* 4.9Ghz channels, public safety channels, license is required in US >> + * and most other regulatory domains! >> + */ >> + CHAN5G(4915, 38), /* Channel 183 */ >> + CHAN5G(4920, 39), /* Channel 184 */ >> + CHAN5G(4925, 40), /* Channel 185 */ >> + CHAN5G(4935, 41), /* Channel 187 */ >> + CHAN5G(4940, 42), /* Channel 188 */ >> + CHAN5G(4945, 43), /* Channel 189 */ >> + CHAN5G(4960, 44), /* Channel 192 */ >> + CHAN5G(4970, 45), /* Channel 194 */ >> + CHAN5G(4980, 46), /* Channel 196 */ > > Where are these channels defined and are these really correct > frequencies for them? Please note that many of the 4.9 GHz channels have > channel starting frequencies like 4.9375 GHz and 4.0025 GHz, i.e., > fractional MHz.. While US public safety may not have all those cases, > even there are some 0.5 MHz cases. In addition, those channel numbers > sound more like some of the channels defined in Japan rather than US > public safety operating class. In addition, some of these channels seem > to be outside the US public safety range. I got these from WiKi pedia. There is a later patch that adds the 5Mhz channels that Cisco uses. I figured that since this is all restricted anyway, that users of it would know how to make it work (and they would have to hack regdb in order to use any of them anyway). > Is this trying to add 4.9 GHz channels in general for multiple different > use cases? And if so, what are those use cases? Or is this only for some > public safety cases? And if so, for which regulatory domains? > > To be frank, I really don't see how this would be even close to a state > that should be accepted into the upstream tree. It was a starting point, and posted mainly to let folks know how to get started. As I said, I don't have interest in trying to push all the changes upstream, but they are in my kernel tree on dmz2.candelatech.com and hostap tree on github, so maybe someone who has interest in dealing with upstreaming them can take them over. Thanks, Ben -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [ath9k-devel] [PATCH] ath9k: Support 4.9Ghz channels on AR9580 adapter. 2016-06-21 9:41 ` [ath9k-devel] " Jouni Malinen @ 2016-06-21 14:25 ` Dave Taht -1 siblings, 0 replies; 20+ messages in thread From: Dave Taht @ 2016-06-21 14:25 UTC (permalink / raw) To: Jouni Malinen Cc: Julian Calaby, ath9k-devel, linux-wireless, QCA ath9k Development, Kalle Valo On Tue, Jun 21, 2016 at 2:41 AM, Jouni Malinen <j@w1.fi> wrote: > On Tue, Jun 21, 2016 at 11:02:20AM +1000, Julian Calaby wrote: >> I've only done this work as I hate to see people's efforts go to >> waste and I feel that there's enough roadblocks in the way of >> actually using this functionality that casual idiots won't be able >> to. > > Are these really ready to go to the upstream kernel in this state and > without the other changes that would be needed to operate correctly? > What is the use case for these and how have these been tested? So far as I know the use case for these is to make it possible to build open source wifi systems that enable emergency services. This strikes me as a worthy goal. ^ permalink raw reply [flat|nested] 20+ messages in thread
* [ath9k-devel] [PATCH] ath9k: Support 4.9Ghz channels on AR9580 adapter. @ 2016-06-21 14:25 ` Dave Taht 0 siblings, 0 replies; 20+ messages in thread From: Dave Taht @ 2016-06-21 14:25 UTC (permalink / raw) To: ath9k-devel On Tue, Jun 21, 2016 at 2:41 AM, Jouni Malinen <j@w1.fi> wrote: > On Tue, Jun 21, 2016 at 11:02:20AM +1000, Julian Calaby wrote: >> I've only done this work as I hate to see people's efforts go to >> waste and I feel that there's enough roadblocks in the way of >> actually using this functionality that casual idiots won't be able >> to. > > Are these really ready to go to the upstream kernel in this state and > without the other changes that would be needed to operate correctly? > What is the use case for these and how have these been tested? So far as I know the use case for these is to make it possible to build open source wifi systems that enable emergency services. This strikes me as a worthy goal. ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2016-06-21 14:33 UTC | newest] Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-05-12 22:40 [PATCH] ath9k: Support 4.9Ghz channels on AR9580 adapter greearb 2016-05-12 22:40 ` [ath9k-devel] " greearb at candelatech.com 2016-06-20 20:34 ` Kalle Valo 2016-06-20 20:34 ` [ath9k-devel] " Kalle Valo 2016-06-20 20:41 ` Ben Greear 2016-06-20 20:41 ` [ath9k-devel] " Ben Greear 2016-06-20 23:53 ` Julian Calaby 2016-06-20 23:53 ` [ath9k-devel] " Julian Calaby 2016-06-21 0:00 ` Ben Greear 2016-06-21 0:00 ` [ath9k-devel] " Ben Greear 2016-06-21 1:02 ` [PATCH] " Julian Calaby 2016-06-21 1:02 ` [ath9k-devel] " Julian Calaby 2016-06-21 9:41 ` Jouni Malinen 2016-06-21 9:41 ` [ath9k-devel] " Jouni Malinen 2016-06-21 10:16 ` Julian Calaby 2016-06-21 10:16 ` [ath9k-devel] " Julian Calaby 2016-06-21 14:17 ` Ben Greear 2016-06-21 14:17 ` [ath9k-devel] " Ben Greear 2016-06-21 14:25 ` Dave Taht 2016-06-21 14:25 ` Dave Taht
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.