* Re: [PATCH] brcmsmac: remove three set but not used variables
From: Kalle Valo @ 2019-08-06 12:38 UTC (permalink / raw)
To: YueHaibing
Cc: arend.vanspriel, franky.lin, hante.meuleman, chi-hsien.lin,
wright.feng, linux-kernel, netdev, linux-wireless,
brcm80211-dev-list.pdl, brcm80211-dev-list, YueHaibing
In-Reply-To: <20190726141535.33212-1-yuehaibing@huawei.com>
YueHaibing <yuehaibing@huawei.com> wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c: In function 'brcms_c_set_gmode':
> drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c:5257:7: warning: variable 'preamble_restrict' set but not used [-Wunused-but-set-variable]
> drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c:5256:6: warning: variable 'preamble' set but not used [-Wunused-but-set-variable]
> drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c:5251:7: warning: variable 'shortslot_restrict' set but not used [-Wunused-but-set-variable]
>
> They are never used so can be removed.
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Patch applied to wireless-drivers-next.git, thanks.
de019a3bdd6e brcmsmac: remove three set but not used variables
--
https://patchwork.kernel.org/patch/11061171/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] ipw2x00: remove redundant assignment to err
From: Kalle Valo @ 2019-08-06 12:37 UTC (permalink / raw)
To: Colin King
Cc: Stanislav Yakovlev, David S . Miller, linux-wireless, netdev,
kernel-janitors, linux-kernel
In-Reply-To: <20190726100614.6924-1-colin.king@canonical.com>
Colin King <colin.king@canonical.com> wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Variable err is initialized to a value that is never read and it
> is re-assigned later. The initialization is redundant and can
> be removed.
>
> Addresses-Coverity: ("Unused value")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Patch applied to wireless-drivers-next.git, thanks.
937a194ae865 ipw2x00: remove redundant assignment to err
--
https://patchwork.kernel.org/patch/11060715/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] rsi: fix for sdio reset card issue
From: Kalle Valo @ 2019-08-06 12:36 UTC (permalink / raw)
To: Ganapathi Kondraju
Cc: linux-wireless, rishikesh.basu, krishna.pedda, narasimha.a,
srinivas.chappidi, Ganapathi Kondraju
In-Reply-To: <1564051910-20136-1-git-send-email-ganapathirajukondraju@gmail.com>
Ganapathi Kondraju <ganapathirajukondraju@gmail.com> wrote:
> Issue: While removing and inserting the driver module, observed driver
> loading is not successful.
>
> Root cause: Card is not resetted completely without issuing cmd5.
>
> Fix: Issued cmd5 properly.
>
> Signed-off-by: Ganapathi Kondraju <ganapathirajukondraju@gmail.com>
Patch applied to wireless-drivers-next.git, thanks.
dfc7a8f7c857 rsi: fix for sdio reset card issue
--
https://patchwork.kernel.org/patch/11058603/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v3] libertas: Fix a double free in if_spi_c2h_data()
From: Kalle Valo @ 2019-08-06 12:36 UTC (permalink / raw)
To: Dan Williams
Cc: Philip Rakity, libertas-dev, kernel-janitors, linux-wireless,
Lubomir Rintel, Dan Carpenter, Allison Randal
In-Reply-To: <9153261627a0f84b996e023f1349a2bc06dd03ee.camel@redhat.com>
Dan Williams <dcbw@redhat.com> wrote:
> The lbs_process_rxed_packet() frees the skb. It didn't originally, but
> we fixed it in commit f54930f36311 ("libertas: don't leak skb on receive
> error").
>
> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> Signed-off-by: Dan Williams <dcbw@redhat.com>
Patch applied to wireless-drivers-next.git, thanks.
3915a252ce71 libertas: Fix a double free in if_spi_c2h_data()
--
https://patchwork.kernel.org/patch/11057049/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] mt7601u: null check the allocation
From: Kalle Valo @ 2019-08-06 12:35 UTC (permalink / raw)
To: Navid Emamdoost
Cc: emamd001, kjlu, smccaman, secalert, Navid Emamdoost,
Jakub Kicinski, David S. Miller, Matthias Brugger, linux-wireless,
netdev, linux-arm-kernel, linux-mediatek, linux-kernel
In-Reply-To: <20190724141736.29994-1-navid.emamdoost@gmail.com>
Navid Emamdoost <navid.emamdoost@gmail.com> wrote:
> devm_kzalloc may fail and return NULL. So the null check is needed.
>
> Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
> Acked-by: Jakub Kicinski <kubakici@wp.pl>
Patch applied to wireless-drivers-next.git, thanks.
b95c732234fa mt7601u: null check the allocation
--
https://patchwork.kernel.org/patch/11057013/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] brcmfmac: remove set but not used variable 'dtim_period'
From: Kalle Valo @ 2019-08-06 12:35 UTC (permalink / raw)
To: YueHaibing
Cc: arend.vanspriel, franky.lin, hante.meuleman, chi-hsien.lin,
wright.feng, linux-kernel, netdev, linux-wireless,
brcm80211-dev-list.pdl, brcm80211-dev-list, YueHaibing
In-Reply-To: <20190724141201.59640-1-yuehaibing@huawei.com>
YueHaibing <yuehaibing@huawei.com> wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c: In function brcmf_update_bss_info:
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:2962:5: warning: variable dtim_period set but not used [-Wunused-but-set-variable]
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c: In function brcmf_update_bss_info:
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:2961:6: warning: variable beacon_interval set but not used [-Wunused-but-set-variable]
>
> They are never used so can be removed.
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Patch applied to wireless-drivers-next.git, thanks.
cddecd92d1ec brcmfmac: remove set but not used variable 'dtim_period'
--
https://patchwork.kernel.org/patch/11056999/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] rtlwifi: remove unneeded function _rtl_dump_channel_map()
From: Kalle Valo @ 2019-08-06 12:34 UTC (permalink / raw)
To: YueHaibing
Cc: pkshih, linux-kernel, netdev, linux-wireless, davem, YueHaibing
In-Reply-To: <20190724141020.58800-1-yuehaibing@huawei.com>
YueHaibing <yuehaibing@huawei.com> wrote:
> Now _rtl_dump_channel_map() does not do any actual
> thing using the channel. So remove it.
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Patch applied to wireless-drivers-next.git, thanks.
a4a68f727fb8 rtlwifi: remove unneeded function _rtl_dump_channel_map()
--
https://patchwork.kernel.org/patch/11056997/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH net-next 06/10] iwlegacy: Use dev_get_drvdata where possible
From: Kalle Valo @ 2019-08-06 12:34 UTC (permalink / raw)
To: Chuhong Yuan
In-Reply-To: <20190724112730.13403-1-hslester96@gmail.com>
Chuhong Yuan <hslester96@gmail.com> wrote:
> Instead of using to_pci_dev + pci_get_drvdata,
> use dev_get_drvdata to make code simpler.
>
> Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
4 patches applied to wireless-drivers-next.git, thanks.
a40c28700d98 iwlegacy: Use dev_get_drvdata where possible
ffa4d78cbc26 mwifiex: pcie: Use dev_get_drvdata
1f5f5ea72fc9 qtnfmac_pcie: Use dev_get_drvdata
e7338e031985 rtlwifi: rtl_pci: Use dev_get_drvdata
--
https://patchwork.kernel.org/patch/11056621/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] rsi: fix for sdio interface setup in 9116
From: Kalle Valo @ 2019-08-06 12:33 UTC (permalink / raw)
To: ganapathirajukondraju
Cc: linux-wireless, Rishikesh Basu, ganapathi.kondraju, krishna.pedda,
narasimha.a, Ganapathi Kondraju
In-Reply-To: <1563964641-9413-1-git-send-email-ganapathirajukondraju@gmail.com>
ganapathirajukondraju@gmail.com wrote:
> From: Ganapathi Kondraju <ganapathirajukondraju@gmail.com>
>
> Issue: RS-9116 Card is not responding after firmware got loaded.
>
> Root cause: After firmware got loaded, we need to reset the program
> counter and few device specific registers. Those registers were not
> resetted properly.
>
> Fix: Properly resetting those registers.
>
> Signed-off-by: Ganapathi Kondraju <ganapathirajukondraju@gmail.com>
Patch applied to wireless-drivers-next.git, thanks.
8f9af6309b84 rsi: fix for sdio interface setup in 9116
--
https://patchwork.kernel.org/patch/11056571/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] marvell wireless: cleanup -- make error values consistent
From: Kalle Valo @ 2019-08-06 12:29 UTC (permalink / raw)
To: Pavel Machek
Cc: amitkarwar, nishants, gbhat, huxinming820, davem, linux-wireless,
netdev, linux-kernel
In-Reply-To: <20190724095015.GA6592@amd>
Pavel Machek <pavel@ucw.cz> writes:
> Surrounding code uses -ERRNO as a result, so don't pass plain -1.
>
> Signed-off-by: Pavel Machek <pavel@denx.de>
For some reason patchwork (or my patchwork script) didn't like this
patch:
Failed to apply the patch: ['git', 'am', '-s', '-3'] failed: 128
Patch is empty. Was it split wrong?
So I applied this manually:
6334dea8880a mwifiex: make error values consistent in mwifiex_update_bss_desc_with_ie()
--
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] bcma: Use dev_get_drvdata
From: Kalle Valo @ 2019-08-06 12:25 UTC (permalink / raw)
To: Chuhong Yuan
In-Reply-To: <20190723082918.21077-1-hslester96@gmail.com>
Chuhong Yuan <hslester96@gmail.com> wrote:
> Instead of using to_pci_dev + pci_get_drvdata,
> use dev_get_drvdata to make code simpler.
>
> Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
Patch applied to wireless-drivers-next.git, thanks.
9236c1250cb7 bcma: Use dev_get_drvdata
--
https://patchwork.kernel.org/patch/11054111/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [RFC PATCH] rtw88: use txpwr_lmt_cfg_pair struct, not arrays
From: Kalle Valo @ 2019-08-06 12:25 UTC (permalink / raw)
To: Brian Norris; +Cc: linux-wireless, Yan-Hsuan Chuang, Brian Norris
In-Reply-To: <20190713013232.215138-1-briannorris@chromium.org>
Brian Norris <briannorris@chromium.org> wrote:
> We're just trusting that these tables are of the right dimensions, when
> we could do better by just using the struct directly. Let's expose the
> struct txpwr_lmt_cfg_pair instead.
>
> The table changes were made by using some Vim macros, so that should
> help prevent any translation mistakes along the way.
>
> Remaining work: get the 'void *data' out of the generic struct
> rtw_table; all of these tables really deserve to be their own data
> structure, with proper type fields.
>
> Signed-off-by: Brian Norris <briannorris@chromium.org>
Patch applied to wireless-drivers-next.git, thanks.
3457f86da60d rtw88: use txpwr_lmt_cfg_pair struct, not arrays
--
https://patchwork.kernel.org/patch/11042813/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* pull-request: wireless-drivers 2019-08-06
From: Kalle Valo @ 2019-08-06 11:28 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, linux-kernel
Hi Dave,
here's a pull request to net tree for v5.3, more information below.
Please let me know if there are any problems.
Kalle
The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git tags/wireless-drivers-for-davem-2019-08-06
for you to fetch changes up to 1f66072503316134873060b24b7895dbbcccf00e:
iwlwifi: dbg_ini: fix compile time assert build errors (2019-08-01 19:48:00 +0300)
----------------------------------------------------------------
wireless-drivers fixes for 5.3
Second set of fixes for 5.3. Lots of iwlwifi fixes have accumulated
which consists most of patches in this pull request. Only most notable
iwlwifi fixes are listed below.
mwifiex
* fix a regression related to WPA1 networks since v5.3-rc1
iwlwifi
* fix use-after-free issues
* fix DMA mapping API usage errors
* fix frame drop occurring due to reorder buffer handling in
RSS in certain conditions
* fix rate scale locking issues
* disable TX A-MSDU on older NICs as it causes problems and was
never supposed to be supported
* new PCI IDs
* GEO_TX_POWER_LIMIT API issue that many people were hitting
----------------------------------------------------------------
Brian Norris (1):
mwifiex: fix 802.11n/WPA detection
Colin Ian King (1):
iwlwifi: mvm: fix comparison of u32 variable with less than zero
Emmanuel Grumbach (8):
iwlwifi: mvm: prepare the ground for more RSS notifications
iwlwifi: mvm: add a new RSS sync notification for NSSN sync
iwlwiif: mvm: refactor iwl_mvm_notify_rx_queue
iwlwifi: mvm: add a loose synchronization of the NSSN across Rx queues
iwlwifi: mvm: fix frame drop from the reordering buffer
iwlwifi: don't unmap as page memory that was mapped as single
iwlwifi: mvm: fix an out-of-bound access
iwlwifi: mvm: fix a use-after-free bug in iwl_mvm_tx_tso_segment
Gregory Greenman (4):
iwlwifi: mvm: add a wrapper around rs_tx_status to handle locks
iwlwifi: mvm: send LQ command always ASYNC
iwlwifi: mvm: replace RS mutex with a spin_lock
iwlwifi: mvm: fix possible out-of-bounds read when accessing lq_info
Ihab Zhaika (1):
iwlwifi: add 3 new IDs for the 9000 series (iwl9260_2ac_160_cfg)
Johannes Berg (2):
iwlwifi: mvm: disable TX-AMSDU on older NICs
iwlwifi: fix locking in delayed GTK setting
Kalle Valo (1):
Merge tag 'iwlwifi-fixes-for-kvalo-2019-07-30' of git://git.kernel.org/.../iwlwifi/iwlwifi-fixes
Luca Coelho (2):
iwlwifi: mvm: don't send GEO_TX_POWER_LIMIT on version < 41
iwlwifi: mvm: fix version check for GEO_TX_POWER_LIMIT support
Mauro Rossi (1):
iwlwifi: dbg_ini: fix compile time assert build errors
Mordechay Goodstein (1):
iwlwifi: mvm: avoid races in rate init and rate perform
Shahar S Matityahu (2):
iwlwifi: dbg_ini: move iwl_dbg_tlv_load_bin out of debug override ifdef
iwlwifi: dbg_ini: move iwl_dbg_tlv_free outside of debugfs ifdef
drivers/net/wireless/intel/iwlwifi/fw/api/rx.h | 3 +-
drivers/net/wireless/intel/iwlwifi/fw/dbg.c | 22 +-
drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 4 +-
drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 29 +-
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 58 ++-
drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 8 +-
drivers/net/wireless/intel/iwlwifi/mvm/nvm.c | 2 +-
drivers/net/wireless/intel/iwlwifi/mvm/ops.c | 4 +-
drivers/net/wireless/intel/iwlwifi/mvm/rs.c | 539 ++++++++++++----------
drivers/net/wireless/intel/iwlwifi/mvm/rs.h | 3 +-
drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c | 185 ++++++--
drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 6 +-
drivers/net/wireless/intel/iwlwifi/mvm/sta.h | 12 +-
drivers/net/wireless/intel/iwlwifi/mvm/tx.c | 3 +-
drivers/net/wireless/intel/iwlwifi/mvm/utils.c | 4 +-
drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 3 +
drivers/net/wireless/intel/iwlwifi/pcie/tx.c | 2 +
drivers/net/wireless/marvell/mwifiex/main.h | 1 +
drivers/net/wireless/marvell/mwifiex/scan.c | 3 +-
19 files changed, 538 insertions(+), 353 deletions(-)
--
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* [PATCH] staging: wilc1000: use helper API to pack data for firmware
From: Ajay.Kathat @ 2019-08-06 10:33 UTC (permalink / raw)
To: linux-wireless; +Cc: devel, gregkh, Adham.Abozaeid, johannes, Ajay.Kathat
From: Ajay Singh <ajay.kathat@microchip.com>
As discussed in [1] use put_unaligned_le16() & put_unaligned_le32()
helper to pack the data before sending to firmware.
[1]. https://lore.kernel.org/linux-wireless/86bc79ccd379497d56bade79ec8f717603110ef7.camel@sipsolutions.net/
Signed-off-by: Ajay Singh <ajay.kathat@microchip.com>
---
drivers/staging/wilc1000/wilc_wlan_cfg.c | 74 ++++++------------------
1 file changed, 18 insertions(+), 56 deletions(-)
diff --git a/drivers/staging/wilc1000/wilc_wlan_cfg.c b/drivers/staging/wilc1000/wilc_wlan_cfg.c
index f4144f93e4a9..3f53807cee0f 100644
--- a/drivers/staging/wilc1000/wilc_wlan_cfg.c
+++ b/drivers/staging/wilc1000/wilc_wlan_cfg.c
@@ -52,57 +52,35 @@ static const struct wilc_cfg_str g_cfg_str[] = {
static int wilc_wlan_cfg_set_byte(u8 *frame, u32 offset, u16 id, u8 val8)
{
- u8 *buf;
-
if ((offset + 4) >= WILC_MAX_CFG_FRAME_SIZE)
return 0;
- buf = &frame[offset];
-
- buf[0] = (u8)id;
- buf[1] = (u8)(id >> 8);
- buf[2] = 1;
- buf[3] = 0;
- buf[4] = val8;
+ put_unaligned_le16(id, &frame[offset]);
+ put_unaligned_le16(1, &frame[offset + 2]);
+ frame[offset + 4] = val8;
return 5;
}
static int wilc_wlan_cfg_set_hword(u8 *frame, u32 offset, u16 id, u16 val16)
{
- u8 *buf;
-
if ((offset + 5) >= WILC_MAX_CFG_FRAME_SIZE)
return 0;
- buf = &frame[offset];
-
- buf[0] = (u8)id;
- buf[1] = (u8)(id >> 8);
- buf[2] = 2;
- buf[3] = 0;
- buf[4] = (u8)val16;
- buf[5] = (u8)(val16 >> 8);
+ put_unaligned_le16(id, &frame[offset]);
+ put_unaligned_le16(2, &frame[offset + 2]);
+ put_unaligned_le16(val16, &frame[offset + 4]);
return 6;
}
static int wilc_wlan_cfg_set_word(u8 *frame, u32 offset, u16 id, u32 val32)
{
- u8 *buf;
-
if ((offset + 7) >= WILC_MAX_CFG_FRAME_SIZE)
return 0;
- buf = &frame[offset];
-
- buf[0] = (u8)id;
- buf[1] = (u8)(id >> 8);
- buf[2] = 4;
- buf[3] = 0;
- buf[4] = (u8)val32;
- buf[5] = (u8)(val32 >> 8);
- buf[6] = (u8)(val32 >> 16);
- buf[7] = (u8)(val32 >> 24);
+ put_unaligned_le16(id, &frame[offset]);
+ put_unaligned_le16(4, &frame[offset + 2]);
+ put_unaligned_le32(val32, &frame[offset + 4]);
return 8;
}
@@ -110,46 +88,35 @@ static int wilc_wlan_cfg_set_word(u8 *frame, u32 offset, u16 id, u32 val32)
static int wilc_wlan_cfg_set_str(u8 *frame, u32 offset, u16 id, u8 *str,
u32 size)
{
- u8 *buf;
-
if ((offset + size + 4) >= WILC_MAX_CFG_FRAME_SIZE)
return 0;
- buf = &frame[offset];
-
- buf[0] = (u8)id;
- buf[1] = (u8)(id >> 8);
- buf[2] = (u8)size;
- buf[3] = (u8)(size >> 8);
-
+ put_unaligned_le16(id, &frame[offset]);
+ put_unaligned_le16(size, &frame[offset + 2]);
if (str && size != 0)
- memcpy(&buf[4], str, size);
+ memcpy(&frame[offset + 4], str, size);
return (size + 4);
}
static int wilc_wlan_cfg_set_bin(u8 *frame, u32 offset, u16 id, u8 *b, u32 size)
{
- u8 *buf;
u32 i;
u8 checksum = 0;
if ((offset + size + 5) >= WILC_MAX_CFG_FRAME_SIZE)
return 0;
- buf = &frame[offset];
- buf[0] = (u8)id;
- buf[1] = (u8)(id >> 8);
- buf[2] = (u8)size;
- buf[3] = (u8)(size >> 8);
+ put_unaligned_le16(id, &frame[offset]);
+ put_unaligned_le16(size, &frame[offset + 2]);
if ((b) && size != 0) {
- memcpy(&buf[4], b, size);
+ memcpy(&frame[offset + 4], b, size);
for (i = 0; i < size; i++)
- checksum += buf[i + 4];
+ checksum += frame[offset + i + 4];
}
- buf[size + 4] = checksum;
+ frame[offset + size + 4] = checksum;
return (size + 5);
}
@@ -307,15 +274,10 @@ int wilc_wlan_cfg_set_wid(u8 *frame, u32 offset, u16 id, u8 *buf, int size)
int wilc_wlan_cfg_get_wid(u8 *frame, u32 offset, u16 id)
{
- u8 *buf;
-
if ((offset + 2) >= WILC_MAX_CFG_FRAME_SIZE)
return 0;
- buf = &frame[offset];
-
- buf[0] = (u8)id;
- buf[1] = (u8)(id >> 8);
+ put_unaligned_le16(id, &frame[offset]);
return 2;
}
--
2.22.0
^ permalink raw reply related
* Re: [EXT] [RFC/RFT] cfg80211: decouple us from the RTNL
From: Johannes Berg @ 2019-08-05 20:41 UTC (permalink / raw)
To: Dedy Lansky, linux-wireless; +Cc: 'Florian Westphal'
In-Reply-To: <000701d54ba1$48ea2520$dabe6f60$@codeaurora.org>
On Mon, 2019-08-05 at 18:20 +0300, Dedy Lansky wrote:
> > Then, we can restrict the RTNL to a few cases where we add or
> > remove interfaces and really need the added protection. Some
> > of the global list management still also uses the RTNL, since
> > we need to have it anyway for netdev management.
> > TODO:
> > - use wiphy_lock()/wiphy_unlock() in all drivers as the code
> > changed in mac80211 does
>
> I guess this change breaks existing drivers because some drivers assume RTNL
> is locked when their cfg callbacks are executed. Is that correct?
It might, to some extent. Mostly though, it shouldn't really matter to
them since the actual callbacks that manipulate interfaces (add, remove,
set type) and thus require RTNL still hold the RTNL.
> Would there be any simple rules for drivers when to use each one of the
> locking API: rtnl vs wiphy vs wdev ?
I'd say RTNL only if externally required. Wiphy vs. wdev I haven't
really quite made up my mind - I'm contemplating just removing the wdev
lock since for (driver/mac80211) simplicity we'll probably not want
concurrency there anyway? Should be rare (Ben Greear will be the only
one hitting it ...) that you really need concurrency there, and
simplifies things a lot.
johannes
^ permalink raw reply
* Re: NXP NFC version and ACPI
From: Sedat Dilek @ 2019-08-05 19:40 UTC (permalink / raw)
To: Daniel Lezcano
Cc: Samuel Ortiz, linux-wireless, linux-nfc, oleg.zhurakivskyy,
clement.perrochaud, charles.gorand, Andy Shevchenko
In-Reply-To: <525160f3-a76c-4b45-2e05-c27aaabbf74d@linaro.org>
v4 of the patchset was included in net-next Git.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
^ permalink raw reply
* Re: [PATCH 0/3] ath10k: Clean up regulator and clock handling
From: Bjorn Andersson @ 2019-08-05 18:06 UTC (permalink / raw)
To: Govind Singh
Cc: Kalle Valo, David S. Miller, ath10k, linux-wireless, netdev,
linux-kernel, linux-arm-msm
In-Reply-To: <196fa4aa63fd5135aead736396fe3f8c@codeaurora.org>
On Thu 25 Jul 23:52 PDT 2019, Govind Singh wrote:
> On 2019-07-25 23:17, Bjorn Andersson wrote:
> > The first patch in this series removes the regulator_set_voltage() of a
> > fixed
> > voltate, as fixed regulator constraints should be specified on a board
> > level
> > and on certain boards - such as the Lenovo Yoga C630 - the voltage
> > specified
> > for the 3.3V regulator is outside the given range.
> >
> > The following two patches cleans up regulator and clock usage by using
> > the bulk
> > API provided by the two frameworks.
> >
> > Bjorn Andersson (3):
> > ath10k: snoc: skip regulator operations
> > ath10k: Use standard regulator bulk API in snoc
> > ath10k: Use standard bulk clock API in snoc
> >
> > drivers/net/wireless/ath/ath10k/snoc.c | 324 ++++---------------------
> > drivers/net/wireless/ath/ath10k/snoc.h | 26 +-
> > 2 files changed, 48 insertions(+), 302 deletions(-)
>
> Tested on 845 MTP and QCS404 platform with normal sanity and driver recover
> cases for proxy votes.
>
> Tested-by: Govind Singh <govinds@codeaurora.org>
> Reviewed-by: Govind Singh <govinds@codeaurora.org>
>
Thanks Govind!
Regards,
Bjorn
^ permalink raw reply
* [engineering.redhat.com #494100] Question on submitting patch for a security bug
From: Red Hat Product Security @ 2019-08-05 17:38 UTC (permalink / raw)
To: b.zolnierkie, bob.liu, chuck.lever, davem, emamd001, gregkh,
kubakici, kvalo, navid.emamdoost, sam
Cc: airlied, alexandre.belloni, alexandre.torgue, allison,
andriy.shevchenko, anna.schumaker, axboe, bfields, colin.king,
daniel, devel, dri-devel, joabreu, johnfwhitmore, josef, jslaby,
kjlu, kstewart, linux-arm-kernel, linux-block, linux-ide,
linux-kernel, linux-mediatek, linux-nfs, linux-serial,
linux-stm32, linux-wireless, matthias.bgg, matthias,
mcoquelin.stm32, nbd, netdev, nishkadg.linux, peppe.cavallaro,
smccaman, tglx, thierry.reding, trond.myklebust, unglinuxdriver,
vishal, vkoul
In-Reply-To: <CAJ7L_Gp2HJoFOVxTgakCJw3LMuiPY0+60-giOtw3OwRD6zyNTQ@mail.gmail.com>
Hello Navid,
On Thu, 18 Jul 2019 01:30:20 GMT, emamd001@umn.edu wrote:
> I've found a null dereference bug in the Linux kernel source code. I was
> wondering should I cc the patch to you as well (along with the
> maintainers)?
No. Please do not cc <secalert@redhat.com> on the upstream kernel patches.
It is meant for reporting security issues only.
Going through the patches here
1. Issues in ../staging/ drivers are not considered for CVE, they are not to be
used
in production environment.
2. Many of the patches listed fix NULL pointer dereference when memory
allocation
fails and returns NULL.
3. Do you happen to have reproducers for these issues? Could an unprivileged
user trigger them?
> Also, I was wondering what are the steps to get CVE for the bug (this is
> the first time I am reporting a bug)?
Generally CVE is assigned after confirming that a given issue really is a
security issue. And it may
have impact ranging from information leakage, DoS to privilege escalation or
maybe arbitrary code
execution. Every NULL pointer dereference is not security issue.
Hope it helps. Thank you.
---
Prasad J Pandit / Red Hat Product Security Team
^ permalink raw reply
* [PATCH] Revert "mwifiex: fix system hang problem after resume"
From: Brian Norris @ 2019-08-05 17:15 UTC (permalink / raw)
To: Amitkumar Karwar, Nishant Sarmukadam, Ganapathi Bhat, Xinming Hu
Cc: linux-wireless, linux-kernel, Dmitry Torokhov, Doug Anderson,
Matthias Kaehlcke, Brian Norris, Amitkumar Karwar
This reverts commit 437322ea2a36d112e20aa7282c869bf924b3a836.
This above-mentioned "fix" does not actually do anything to prevent a
race condition. It simply papers over it so that the issue doesn't
appear.
If this is a real problem, it should be explained better than the above
commit does, and an alternative, non-racy solution should be found.
For further reason to revert this: there's no reason we can't try
resetting the card when it's *actually* stuck in host-sleep mode. So
instead, this is unnecessarily creating scenarios where we can't recover
Wifi (and in fact, I'm fielding reports of Chromebooks that can't
recover after the aforementioned commit).
Note that this was proposed in 2017 and Ack'ed then, but due to my
marking as RFC, it never went anywhere:
https://patchwork.kernel.org/patch/9657277/
[RFC] Revert "mwifiex: fix system hang problem after resume"
Cc: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: Amitkumar Karwar <amitkarwar@gmail.com>
Tested-by: Matthias Kaehlcke <mka@chromium.org>
---
drivers/net/wireless/marvell/mwifiex/init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/init.c b/drivers/net/wireless/marvell/mwifiex/init.c
index 6c0e52eb8794..1aa93e7e9835 100644
--- a/drivers/net/wireless/marvell/mwifiex/init.c
+++ b/drivers/net/wireless/marvell/mwifiex/init.c
@@ -59,7 +59,7 @@ static void wakeup_timer_fn(struct timer_list *t)
adapter->hw_status = MWIFIEX_HW_STATUS_RESET;
mwifiex_cancel_all_pending_cmd(adapter);
- if (adapter->if_ops.card_reset && !adapter->hs_activated)
+ if (adapter->if_ops.card_reset)
adapter->if_ops.card_reset(adapter);
}
--
2.22.0.770.g0f2c4a37fd-goog
^ permalink raw reply related
* [PATCH v2] cfg80211: Fix Extended Key ID key install checks
From: Alexander Wetzel @ 2019-08-05 12:34 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, Alexander Wetzel
Fix two shortcomings in the Extended Key ID API:
1) Allow the userspace to install pairwise keys using keyid 1 without
NL80211_KEY_NO_TX set. This allows the userspace to install and
activate pairwise keys with keyid 1 in the same way as for keyid 0,
simplifying the API usage for e.g. FILS and FT key installs.
2) IEEE 802.11 - 2016 restricts Extended Key ID usage to CCMP/GCMP
ciphers in IEEE 802.11 - 2016 "9.4.2.25.4 RSN capabilities".
Enforce that when installing a key.
Fixes: 6cdd3979a2bd ("nl80211/cfg80211: Extended Key ID support")
Signed-off-by: Alexander Wetzel <alexander@wetzel-home.de>
---
Changes compared to v1:
Refuse any Extended Key ID actions for TKIP keys. V1 still allowed them
for keyid 0.
Remarks from v1 still apply and are unchanged:
This patch ended up redesigning the Extended Key ID key install checks
from scratch...
While working on wpa_supplicant/hostapd Extended Key ID support it
turned out that it's still useful to be able to install and activate a
pairwise key for Tx in one step. So instead of forcing the userspace to
always install and then activate a key I would prefer to fix the API and
relax the checks with this patch.
Down side of that is, that we have to get the fix also into 5.2 and 5.3.
All kernels without the fix will potentially not work correctly with the
upcoming userspace when using FT (fast roaming) or FILS with an Extended
Key ID capable AP. (Anyone using the existing API will not notice the
difference, but I'm next to sure it's only used by my experimental hostapd
patches so far.)
So ideally we get this patch back ported to all kernels which also have
6cdd3979a2bd ("nl80211/cfg80211: Extended Key ID support")
Another issue I tripped over while getting the hostapd patches into
shape is, that our mac80211 TKIP SW crypto implementation drops unicast
packets on receive when they are using keyid 1.
Since a standard compliant implementation of Extended Key ID must not
use TKIP enforcing that rule at key install seems to be preferable
to handle that within mac80211.
net/wireless/util.c | 23 ++++++++++++++---------
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/net/wireless/util.c b/net/wireless/util.c
index d0e35b7b9e35..e74837824cea 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -233,25 +233,30 @@ int cfg80211_validate_key_settings(struct cfg80211_registered_device *rdev,
switch (params->cipher) {
case WLAN_CIPHER_SUITE_TKIP:
+ /* Extended Key ID can only be used with CCMP/GCMP ciphers */
+ if ((pairwise && key_idx) ||
+ params->mode != NL80211_KEY_RX_TX)
+ return -EINVAL;
+ break;
case WLAN_CIPHER_SUITE_CCMP:
case WLAN_CIPHER_SUITE_CCMP_256:
case WLAN_CIPHER_SUITE_GCMP:
case WLAN_CIPHER_SUITE_GCMP_256:
- /* IEEE802.11-2016 allows only 0 and - when using Extended Key
- * ID - 1 as index for pairwise keys.
+ /* IEEE802.11-2016 allows only 0 and - when supporting
+ * Extended Key ID - 1 as index for pairwise keys.
* @NL80211_KEY_NO_TX is only allowed for pairwise keys when
* the driver supports Extended Key ID.
* @NL80211_KEY_SET_TX can't be set when installing and
* validating a key.
*/
- if (params->mode == NL80211_KEY_NO_TX) {
- if (!wiphy_ext_feature_isset(&rdev->wiphy,
- NL80211_EXT_FEATURE_EXT_KEY_ID))
- return -EINVAL;
- else if (!pairwise || key_idx < 0 || key_idx > 1)
+ if ((params->mode == NL80211_KEY_NO_TX && !pairwise) ||
+ params->mode == NL80211_KEY_SET_TX)
+ return -EINVAL;
+ if (wiphy_ext_feature_isset(&rdev->wiphy,
+ NL80211_EXT_FEATURE_EXT_KEY_ID)) {
+ if (pairwise && (key_idx < 0 || key_idx > 1))
return -EINVAL;
- } else if ((pairwise && key_idx) ||
- params->mode == NL80211_KEY_SET_TX) {
+ } else if (pairwise && key_idx) {
return -EINVAL;
}
break;
--
2.22.0
^ permalink raw reply related
* RE: [EXT] [RFC/RFT] cfg80211: decouple us from the RTNL
From: Dedy Lansky @ 2019-08-05 15:20 UTC (permalink / raw)
To: 'Johannes Berg', linux-wireless
Cc: 'Florian Westphal', 'Johannes Berg'
In-Reply-To: <20190731220848.1045-1-johannes@sipsolutions.net>
From: linux-wireless-owner@vger.kernel.org
<linux-wireless-owner@vger.kernel.org> On Behalf Of Johannes Berg
Sent: Thursday, August 1, 2019 1:09 AM
> Fix that by re-adding a mutex to each wiphy/rdev as we had at
> some point, so we have locking for the wireless_dev lists and
> all the other things in there, and also so that drivers still
> don't have to worry too much about it (they still won't get
> parallel calls for a single device).
Sounds good.
> Then, we can restrict the RTNL to a few cases where we add or
> remove interfaces and really need the added protection. Some
> of the global list management still also uses the RTNL, since
> we need to have it anyway for netdev management.
> TODO:
> - use wiphy_lock()/wiphy_unlock() in all drivers as the code
> changed in mac80211 does
I guess this change breaks existing drivers because some drivers assume RTNL
is locked when their cfg callbacks are executed. Is that correct?
Would there be any simple rules for drivers when to use each one of the
locking API: rtnl vs wiphy vs wdev ?
Thanks,
Dedy.
^ permalink raw reply
* [PATCH] wireless-regdb: Fix ranges of EU countries as they are harmonized since 2014...
From: Emil Petersky @ 2019-08-05 14:19 UTC (permalink / raw)
To: seth.forshee; +Cc: linux-wireless, wireless-regdb
This patch unites entries for EU countries, as they have been harmonized
latest by July 2014...
EU decision 2005/513/EC:
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02005D0513-20070213
EU decision 2006/771/EC:
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02008D0432-20080611
Signed-off-by: Emil Petersky <emil.petersky@streamunlimited.com>
---
diff --git a/db.txt b/db.txt
index 37393e6..907b424 100755
--- a/db.txt
+++ b/db.txt
@@ -87,12 +87,20 @@ country AS: DFS-FCC
(5490 - 5730 @ 160), (24), DFS
(5735 - 5835 @ 80), (30)
+# AT as part of EU/CEPT accepted decisions 2005/513/EC (5GHz RLAN, EN 301 893)
+# and 2006/771/EC (amended by 2008/432/EC, Short-Range Devices, EN 300 440)
+# EU decision 2005/513/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02005D0513-20070213
+# EU decision 2006/771/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02008D0432-20080611
+# AT: https://www.rtr.at/en/tk/Spektrum5GHz/1997_bmvit-info-052010en.pdf
+# AT: acceptance https://www.ris.bka.gv.at/Dokumente/BgblAuth/BGBLA_2014_II_63/BGBLA_2014_II_63.pdfsig
country AT: DFS-ETSI
- (2402 - 2482 @ 40), (20)
- (5170 - 5250 @ 80), (20), AUTO-BW, wmmrule=ETSI
- (5250 - 5330 @ 80), (20), DFS, AUTO-BW, wmmrule=ETSI
- (5490 - 5710 @ 160), (27), DFS, wmmrule=ETSI
- # 60 GHz band channels 1-4, ref: Etsi En 302 567
+ (2400 - 2483.5 @ 40), (100 mW)
+ (5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
+ (5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
+ (5470 - 5725 @ 160), (500 mW), DFS, wmmrule=ETSI
+ # short range devices (ETSI EN 300 440-1)
+ (5725 - 5875 @ 80), (25 mW)
+ # 60 GHz band channels 1-4 (ETSI EN 302 567)
(57000 - 66000 @ 2160), (40)
# Source:
@@ -139,12 +147,22 @@ country BD: DFS-JP
(2402 - 2482 @ 40), (20)
(5735 - 5835 @ 80), (30)
+# BE as part of EU/CEPT accepted decisions 2005/513/EC (5GHz RLAN, EN 301 893)
+# and 2006/771/EC (amended by 2008/432/EC, Short-Range Devices, EN 300 440)
+# EU decision 2005/513/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02005D0513-20070213
+# EU decision 2006/771/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02008D0432-20080611
+# BE: https://www.ibpt.be/public/files/en/21760/B03-01_2.1_EN.pdf
+# BE: https://www.ibpt.be/public/files/en/21761/B03-02_2.1_EN.pdf
+# BE: https://www.ibpt.be/public/files/en/21762/B03-03_2.1_EN.pdf
+# BE: https://www.ibpt.be/public/files/en/22165/B01-28_3.1_EN.pdf
country BE: DFS-ETSI
- (2402 - 2482 @ 40), (20)
- (5170 - 5250 @ 80), (20), AUTO-BW, wmmrule=ETSI
- (5250 - 5330 @ 80), (20), DFS, AUTO-BW, wmmrule=ETSI
- (5490 - 5710 @ 160), (27), DFS, wmmrule=ETSI
- # 60 GHz band channels 1-4, ref: Etsi En 302 567
+ (2400 - 2483.5 @ 40), (100 mW)
+ (5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
+ (5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
+ (5470 - 5725 @ 160), (500 mW), DFS, wmmrule=ETSI
+ # short range devices (ETSI EN 300 440-1)
+ (5725 - 5875 @ 80), (25 mW)
+ # 60 GHz band channels 1-4 (ETSI EN 302 567)
(57000 - 66000 @ 2160), (40)
country BF: DFS-FCC
@@ -167,23 +185,30 @@ country BF: DFS-FCC
#
# Note: The transmit power limits in the 5250-5350 MHz and 5470-5725 MHz bands
# can be raised by 3 dBm if TPC is enabled. Refer to BDS EN 301 893 for details.
+#
+# BG as part of EU/CEPT accepted decisions 2005/513/EC (5GHz RLAN, EN 301 893)
+# and 2006/771/EC (amended by 2008/432/EC, Short-Range Devices, EN 300 440)
+# EU decision 2005/513/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02005D0513-20070213
+# EU decision 2006/771/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02008D0432-20080611
+# BG: https://crc.bg/files/_en/Electronic_Communications_Revised_EN1.pdf
+# BG: acceptance of 2006/771/EC https://crc.bg/files/Pravila_06_12_2018.pdf
+
country BG: DFS-ETSI
# Wideband data transmission systems (WDTS) in the 2.4GHz ISM band, ref:
# I.22 of the List, BDS EN 300 328
- (2402 - 2482 @ 40), (20)
+ (2400 - 2483.5 @ 40), (100 mW)
# 5 GHz Radio Local Area Networks (RLANs), ref:
# II.H01 of the List, BDS EN 301 893
- (5170 - 5250 @ 80), (23), AUTO-BW, wmmrule=ETSI
- (5250 - 5330 @ 80), (20), DFS, AUTO-BW, wmmrule=ETSI
+ (5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
+ (5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
# II.H01 of the List, I.54 from the List, BDS EN 301 893
- (5490 - 5710 @ 160), (27), DFS, wmmrule=ETSI
- # Short range devices (SRDs) in the 5725-5875 MHz frequency range, ref:
+ (5470 - 5725 @ 160), (500 mW), DFS, wmmrule=ETSI
+ # short range devices (ETSI EN 300 440-1)
# I.43 of the List, BDS EN 300 440-2, BDS EN 300 440-1
- (5725 - 5875 @ 80), (14)
- # 60 GHz Multiple-Gigabit RLAN Systems, ref:
+ (5725 - 5875 @ 80), (25 mW)
+ # 60 GHz band channels 1-4 (ETSI EN 302 567)
# II.H03 of the List, BDS EN 302 567-2
- (57000 - 66000 @ 2160), (40), NO-OUTDOOR
-
+ (57000 - 66000 @ 2160), (40)
country BH: DFS-JP
(2402 - 2482 @ 40), (20)
(5170 - 5250 @ 20), (20)
@@ -265,16 +290,23 @@ country CF: DFS-FCC
(5490 - 5730 @ 40), (24), DFS
(5735 - 5835 @ 40), (30)
-# Source:
-# https://www.ofcomnet.ch/#/fatTable
-# Note that the maximum transmitter power can be doubled for 5250-5710MHz if
-# transmitter power control is in use: 5250-5330@23db, 5490-5710@30db
+# CH as part of CEPT accepted decisions 2005/513/EC (5GHz RLAN, EN 301 893)
+# and 2006/771/EC (amended by 2008/432/EC, Short-Range Devices, EN 300 440)
+# EU decision 2005/513/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02005D0513-20070213
+# EU decision 2006/771/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02008D0432-20080611
+# CH: https://www.ofcomnet.ch/api/rir/1010/05
+# CH: https://www.ofcomnet.ch/api/rir/1010/04
+# CH: https://www.ofcomnet.ch/api/rir/1008/12
+# CH: https://www.ofcomnet.ch/#/fatTable
country CH: DFS-ETSI
- (2402 - 2482 @ 40), (20)
- (5150 - 5250 @ 80), (23), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
- (5250 - 5350 @ 80), (20), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
- (5490 - 5710 @ 160), (27), DFS, wmmrule=ETSI
- # 60 GHz band channels 1-4, ref: Etsi En 302 567
+ (2400 - 2483.5 @ 40), (100 mW)
+ (5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
+ (5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
+ (5470 - 5725 @ 160), (500 mW), DFS, wmmrule=ETSI
+ # short range devices (ETSI EN 300 440-1)
+ (5725 - 5875 @ 80), (25 mW)
+ # 60 GHz band channels 1-4 (ETSI EN 302 567)
(57000 - 66000 @ 2160), (40)
country CI: DFS-FCC
@@ -329,26 +361,43 @@ country CX: DFS-FCC
(5490 - 5730 @ 160), (24), DFS
(5735 - 5835 @ 80), (30)
+# CY as part of EU/CEPT accepted decisions 2005/513/EC (5GHz RLAN, EN 301 893)
+# and 2006/771/EC (amended by 2008/432/EC, Short-Range Devices, EN 300 440)
+# EU decision 2005/513/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02005D0513-20070213
+# EU decision 2006/771/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02008D0432-20080611
+# CY: http://www.mcw.gov.cy/mcw/dec/dec.nsf/all/292484CFC7013DD4C2256EBA0023D447/$file/Sxedio%20Radiosyxnothtwn%20ths%20Dhmokratias-3-8-2018-E2.2(English%20Unified%20Unofficial).pdf?openelement
country CY: DFS-ETSI
- (2402 - 2482 @ 40), (20)
- (5170 - 5250 @ 80), (20), AUTO-BW, wmmrule=ETSI
- (5250 - 5330 @ 80), (20), DFS, AUTO-BW, wmmrule=ETSI
- (5490 - 5710 @ 160), (27), DFS, wmmrule=ETSI
- # 60 GHz band channels 1-4, ref: Etsi En 302 567
+ (2400 - 2483.5 @ 40), (100 mW)
+ (5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
+ (5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
+ (5470 - 5725 @ 160), (500 mW), DFS, wmmrule=ETSI
+ # short range devices (ETSI EN 300 440-1)
+ (5725 - 5875 @ 80), (25 mW)
+ # 60 GHz band channels 1-4 (ETSI EN 302 567)
(57000 - 66000 @ 2160), (40)
-# Data from http://www.ctu.eu/164/download/VOR/VOR-12-08-2005-34.pdf
-# and http://www.ctu.eu/164/download/VOR/VOR-12-05-2007-6-AN.pdf
-# Power at 5250 - 5350 MHz and 5470 - 5725 MHz can be doubled if TPC is
-# implemented.
+# CZ as part of EU/CEPT accepted decisions 2005/513/EC (5GHz RLAN, EN 301 893)
+# and 2006/771/EC (amended by 2008/432/EC, Short-Range Devices, EN 300 440)
+# EU decision 2005/513/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02005D0513-20070213
+# EU decision 2006/771/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02008D0432-20080611
+# CZ: https://www.ctu.cz/cs/download/vseobecna-opravneni/archiv/vo-r_12-06_2010-09.pdf
+# CZ: https://www.ctu.cz/sites/default/files/obsah/ctu/vseobecne-opravneni-c.vo-r/10/12.2017-10/obrazky/vo-r10-122017-10.pdf
country CZ: DFS-ETSI
(2400 - 2483.5 @ 40), (100 mW)
(5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
(5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
(5470 - 5725 @ 160), (500 mW), DFS, wmmrule=ETSI
- # 60 GHz band channels 1-4, ref: Etsi En 302 567
+ # short range devices (ETSI EN 300 440-1)
+ (5725 - 5875 @ 80), (25 mW)
+ # 60 GHz band channels 1-4 (ETSI EN 302 567)
(57000 - 66000 @ 2160), (40)
+# DE as part of EU/CEPT accepted decisions 2005/513/EC (5GHz RLAN, EN 301 893)
+# and 2006/771/EC (amended by 2008/432/EC, Short-Range Devices, EN 300 440)
+# EU decision 2005/513/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02005D0513-20070213
+# EU decision 2006/771/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02008D0432-20080611
+#
# Allocation for the 2.4 GHz band (Vfg 10 / 2013, Allgemeinzuteilung von
# Frequenzen für die Nutzung in lokalen Netzwerken; Wireless Local Area
# Networks (WLAN-Funkanwendungen).
@@ -368,7 +417,6 @@ country CZ: DFS-ETSI
# Bereich 57 GHz - 66 GHz für Funkanwendungen für weitbandige
# Datenübertragungssysteme; „Multiple Gigabit WAS/RLAN Systems (MGWS)“).
# https://www.bundesnetzagentur.de/SharedDocs/Downloads/DE/Sachgebiete/Telekommunikation/Unternehmen_Institutionen/Frequenzen/Allgemeinzuteilungen/2011_08_MGWS_pdf.pdf
-
country DE: DFS-ETSI
(2400 - 2483.5 @ 40), (100 mW)
(5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
@@ -379,16 +427,22 @@ country DE: DFS-ETSI
# 60 GHz band channels 1-4 (ETSI EN 302 567)
(57000 - 66000 @ 2160), (40)
-# Sources:
+# DK as part of EU/CEPT accepted decisions 2005/513/EC (5GHz RLAN, EN 301 893)
+# and 2006/771/EC (amended by 2008/432/EC, Short-Range Devices, EN 300 440)
+# EU decision 2005/513/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02005D0513-20070213
+# EU decision 2006/771/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02008D0432-20080611
+# DK: https://ens.dk/sites/ens.dk/files/Tele/frekvensplan_0.pdf
# 5GHz: https://erhvervsstyrelsen.dk/sites/default/files/007_interface-datanet_5-6_ghz.pdf.pdf
# 60GHz: https://erhvervsstyrelsen.dk/sites/default/files/radiograenseflader-63.pdf
country DK: DFS-ETSI
- (2400 - 2483.5 @ 40), (20)
- (5150 - 5250 @ 80), (23), AUTO-BW, wmmrule=ETSI
- (5250 - 5350 @ 80), (20), DFS, AUTO-BW, wmmrule=ETSI
- (5470 - 5725 @ 160), (27), DFS, wmmrule=ETSI
+ (2400 - 2483.5 @ 40), (100 mW)
+ (5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
+ (5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
+ (5470 - 5725 @ 160), (500 mW), DFS, wmmrule=ETSI
+ # short range devices (ETSI EN 300 440-1)
+ (5725 - 5875 @ 80), (25 mW)
# 60 GHz band channels 1-4 (ETSI EN 302 567)
- (57000 - 66000 @ 2160), (40), NO-OUTDOOR
+ (57000 - 66000 @ 2160), (40)
# Source:
# http://www.ntrcdom.org/index.php?option=com_content&view=category&layout=blog&id=10&Itemid=55
@@ -417,12 +471,20 @@ country EC: DFS-FCC
(5490 - 5730 @ 20), (24), DFS
(5735 - 5835 @ 20), (30)
+# EE as part of EU/CEPT accepted decisions 2005/513/EC (5GHz RLAN, EN 301 893)
+# and 2006/771/EC (amended by 2008/432/EC, Short-Range Devices, EN 300 440)
+# EU decision 2005/513/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02005D0513-20070213
+# EU decision 2006/771/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02008D0432-20080611
+# EE: https://www.ttja.ee/et/ettevottele-organisatsioonile/sideteenused/raadioseadmed/wifi-seade
+# EE: https://www.itu.int/ITU-D/study_groups/SGP_1998-2002/JGRES09/pdf/estonia.pdf
country EE: DFS-ETSI
- (2402 - 2482 @ 40), (20)
- (5170 - 5250 @ 80), (20), AUTO-BW, wmmrule=ETSI
- (5250 - 5330 @ 80), (20), DFS, AUTO-BW, wmmrule=ETSI
- (5490 - 5710 @ 160), (27), DFS, wmmrule=ETSI
- # 60 GHz band channels 1-4, ref: Etsi En 302 567
+ (2400 - 2483.5 @ 40), (100 mW)
+ (5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
+ (5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
+ (5470 - 5725 @ 160), (500 mW), DFS, wmmrule=ETSI
+ # short range devices (ETSI EN 300 440-1)
+ (5725 - 5875 @ 80), (25 mW)
+ # 60 GHz band channels 1-4 (ETSI EN 302 567)
(57000 - 66000 @ 2160), (40)
country EG: DFS-ETSI
@@ -430,17 +492,19 @@ country EG: DFS-ETSI
(5170 - 5250 @ 40), (20)
(5250 - 5330 @ 40), (20), DFS
-# Source:
-# Cuadro nacional de atribución de frecuencias (CNAF)
-# https://avancedigital.gob.es/espectro/Paginas/cnaf.aspx
+# ES as part of EU/CEPT accepted decisions 2005/513/EC (5GHz RLAN, EN 301 893)
+# and 2006/771/EC (amended by 2008/432/EC, Short-Range Devices, EN 300 440)
+# EU decision 2005/513/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02005D0513-20070213
+# EU decision 2006/771/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02008D0432-20080611
+# ES: https://avancedigital.gob.es/espectro/Paginas/cnaf.aspx
country ES: DFS-ETSI
(2400 - 2483.5 @ 40), (100 mW)
(5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
(5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
(5470 - 5725 @ 160), (500 mW), DFS, wmmrule=ETSI
- # Short Range Devices (SRD) (ETSI EN 300 440)
+ # short range devices (ETSI EN 300 440-1)
(5725 - 5875 @ 80), (25 mW)
- # 60 GHz band channels 1-4, ref: Etsi En 302 567
+ # 60 GHz band channels 1-4 (ETSI EN 302 567)
(57000 - 66000 @ 2160), (40)
country ET: DFS-ETSI
@@ -449,14 +513,18 @@ country ET: DFS-ETSI
(5250 - 5330 @ 80), (20), DFS, AUTO-BW
(5490 - 5710 @ 160), (27), DFS
+# FI as part of EU/CEPT accepted decisions 2005/513/EC (5GHz RLAN, EN 301 893)
+# and 2006/771/EC (amended by 2008/432/EC, Short-Range Devices, EN 300 440)
+# EU decision 2005/513/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02005D0513-20070213
+# EU decision 2006/771/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02008D0432-20080611
country FI: DFS-ETSI
- (2400 - 2483.5 @ 40), (20)
- (5150 - 5250 @ 80), (23), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
- (5250 - 5350 @ 80), (20), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
- (5470 - 5725 @ 160), (27), DFS, wmmrule=ETSI
+ (2400 - 2483.5 @ 40), (100 mW)
+ (5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
+ (5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
+ (5470 - 5725 @ 160), (500 mW), DFS, wmmrule=ETSI
# short range devices (ETSI EN 300 440-1)
(5725 - 5875 @ 80), (25 mW)
- # 60 GHz band channels 1-4, ref: Etsi En 302 567
+ # 60 GHz band channels 1-4 (ETSI EN 302 567)
(57000 - 66000 @ 2160), (40)
country FM: DFS-FCC
@@ -466,22 +534,34 @@ country FM: DFS-FCC
(5490 - 5730 @ 160), (24), DFS
(5735 - 5835 @ 80), (30)
+# FR as part of EU/CEPT accepted decisions 2005/513/EC (5GHz RLAN, EN 301 893)
+# and 2006/771/EC (amended by 2008/432/EC, Short-Range Devices, EN 300 440)
+# EU decision 2005/513/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02005D0513-20070213
+# EU decision 2006/771/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02008D0432-20080611
country FR: DFS-ETSI
- (2402 - 2482 @ 40), (20)
- (5150 - 5250 @ 80), (23), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
- (5250 - 5350 @ 80), (20), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
- (5470 - 5725 @ 160), (27), DFS, wmmrule=ETSI
- # short range devices (ETSI EN 300 440)
+ (2400 - 2483.5 @ 40), (100 mW)
+ (5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
+ (5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
+ (5470 - 5725 @ 160), (500 mW), DFS, wmmrule=ETSI
+ # short range devices (ETSI EN 300 440-1)
(5725 - 5875 @ 80), (25 mW)
- # 60 GHz band channels 1-4, ref: Etsi En 302 567
+ # 60 GHz band channels 1-4 (ETSI EN 302 567)
(57000 - 66000 @ 2160), (40)
+# GB as part of EU/CEPT accepted decisions 2005/513/EC (5GHz RLAN, EN 301 893)
+# and 2006/771/EC (amended by 2008/432/EC, Short-Range Devices, EN 300 440)
+# EU decision 2005/513/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02005D0513-20070213
+# EU decision 2006/771/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02008D0432-20080611
+# GB: https://www.ofcom.org.uk/__data/assets/pdf_file/0019/136009/Ofcom-Information-Sheet-5-GHz-RLANs.pdf
+# GB: https://www.ofcom.org.uk/__data/assets/pdf_file/0028/84970/ir-2030.pdf
country GB: DFS-ETSI
- (2402 - 2482 @ 40), (20)
- (5170 - 5250 @ 80), (20), AUTO-BW, wmmrule=ETSI
- (5250 - 5330 @ 80), (20), DFS, AUTO-BW, wmmrule=ETSI
- (5490 - 5710 @ 160), (27), DFS, wmmrule=ETSI
- # 60 GHz band channels 1-4, ref: Etsi En 302 567
+ (2400 - 2483.5 @ 40), (100 mW)
+ (5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
+ (5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
+ (5470 - 5725 @ 160), (500 mW), DFS, wmmrule=ETSI
+ # short range devices (ETSI EN 300 440-1)
+ (5725 - 5875 @ 80), (25 mW)
+ # 60 GHz band channels 1-4 (ETSI EN 302 567)
(57000 - 66000 @ 2160), (40)
country GD: DFS-FCC
@@ -523,12 +603,20 @@ country GP: DFS-ETSI
(5250 - 5330 @ 80), (20), DFS, AUTO-BW, wmmrule=ETSI
(5490 - 5710 @ 160), (27), DFS, wmmrule=ETSI
+# GR as part of EU/CEPT accepted decisions 2005/513/EC (5GHz RLAN, EN 301 893)
+# and 2006/771/EC (amended by 2008/432/EC, Short-Range Devices, EN 300 440)
+# EU decision 2005/513/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02005D0513-20070213
+# EU decision 2006/771/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02008D0432-20080611
+# GR: https://www.eett.gr/opencms/export/sites/default/EETT_EN/Electronic_Communications/Radio_Communications/TelecommunicationEquipment/Radio_equipment_interface_requirement_2012.pdf
+# GR: https://www.eett.gr/opencms/export/sites/default/EETT_EN/Electronic_Communications/Radio_Communications/TelecommunicationEquipment/Radio_equipment_interface_requirement_107.pdf
country GR: DFS-ETSI
- (2402 - 2482 @ 40), (20)
- (5170 - 5250 @ 80), (20), AUTO-BW, wmmrule=ETSI
- (5250 - 5330 @ 80), (20), DFS, AUTO-BW, wmmrule=ETSI
- (5490 - 5710 @ 160), (27), DFS, wmmrule=ETSI
- # 60 GHz band channels 1-4, ref: Etsi En 302 567
+ (2400 - 2483.5 @ 40), (100 mW)
+ (5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
+ (5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
+ (5470 - 5725 @ 160), (500 mW), DFS, wmmrule=ETSI
+ # short range devices (ETSI EN 300 440-1)
+ (5725 - 5875 @ 80), (25 mW)
+ # 60 GHz band channels 1-4 (ETSI EN 302 567)
(57000 - 66000 @ 2160), (40)
country GT: DFS-FCC
@@ -563,11 +651,18 @@ country HN: DFS-FCC
(5735 - 5835 @ 80), (30)
country HR: DFS-ETSI
- (2400 - 2483.5 @ 40), (20)
- (5150 - 5250 @ 80), (23), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
- (5250 - 5350 @ 80), (20), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
- (5470 - 5725 @ 160), (27), DFS, wmmrule=ETSI
- # 60 GHz band channels 1-4, ref: Etsi En 302 567
+# HR as part of EU/CEPT accepted decisions 2005/513/EC (5GHz RLAN, EN 301 893)
+# and 2006/771/EC (amended by 2008/432/EC, Short-Range Devices, EN 300 440)
+# EU decision 2005/513/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02005D0513-20070213
+# EU decision 2006/771/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02008D0432-20080611
+# HR: http://tablice.hakom.hr:8080/vis?lang=en
+ (2400 - 2483.5 @ 40), (100 mW)
+ (5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
+ (5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
+ (5470 - 5725 @ 160), (500 mW), DFS, wmmrule=ETSI
+ # short range devices (ETSI EN 300 440-1)
+ (5725 - 5875 @ 80), (25 mW)
+ # 60 GHz band channels 1-4 (ETSI EN 302 567)
(57000 - 66000 @ 2160), (40)
country HT: DFS-FCC
@@ -577,37 +672,42 @@ country HT: DFS-FCC
(5490 - 5730 @ 160), (24), DFS
(5735 - 5835 @ 80), (30)
-# http://stir.nmhh.hu/?oldal=dokumentumGeneralo&root_rendeletelem_id=3&hatalyos=1
-# http://english.nmhh.hu/cikk/297/Eljarasi_tajekoztato_a_24_GHzes_es_az_5_GHzes_savban_mukodo_berendezesek_engedelyezeserol
-# http://nmhh.hu/dokumentum/319/kis_hatotavolsagu_eszkozok_srdk.pdf
+# HU as part of EU/CEPT accepted decisions 2005/513/EC (5GHz RLAN, EN 301 893)
+# and 2006/771/EC (amended by 2008/432/EC, Short-Range Devices, EN 300 440)
+# EU decision 2005/513/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02005D0513-20070213
+# EU decision 2006/771/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02008D0432-20080611
+# HU: http://stir.nmhh.hu/?oldal=dokumentumGeneralo&root_rendeletelem_id=3&hatalyos=1
+# HU: http://english.nmhh.hu/cikk/297/Eljarasi_tajekoztato_a_24_GHzes_es_az_5_GHzes_savban_mukodo_berendezesek_engedelyezeserol
+# HU: http://nmhh.hu/dokumentum/319/kis_hatotavolsagu_eszkozok_srdk.pdf
country HU: DFS-ETSI
- # ref: 2006/771/EK, (EU) 2017/1483, MSZ EN 300 328
- # additionally: 100mW @ 10MHz channels, 50mW @ 5MHz (max. 10mW/MHz)
- (2400 - 2483.5 @ 40), (20)
- # ref: 2005/513/EK
- # note: TPC not needed @ 5150-5250
- (5150 - 5250 @ 80), (23), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
- # note: max would be +3dB with TPC @ 5250-5725
- (5250 - 5350 @ 80), (20), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
- (5470 - 5725 @ 160), (27), DFS, wmmrule=ETSI
- # "Short Range Devices (SRD)"
- # ref: 2006/771/EK, (EU) 2017/1483, MSZ EN 300 440, MSZ EN 302 064
+ (2400 - 2483.5 @ 40), (100 mW)
+ (5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
+ (5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
+ (5470 - 5725 @ 160), (500 mW), DFS, wmmrule=ETSI
+ # short range devices (ETSI EN 300 440-1)
(5725 - 5875 @ 80), (25 mW)
- # 60 GHz band channels 1-4, "Fixed outdoor installation not allowed"
- # ref: 2006/771/EK, (EU) 2017/1483, MSZ EN 302 567
- (57000 - 66000 @ 2160), (40), NO-OUTDOOR
+ # 60 GHz band channels 1-4 (ETSI EN 302 567)
+ (57000 - 66000 @ 2160), (40)
country ID: DFS-JP
# ref: http://www.postel.go.id/content/ID/regulasi/standardisasi/kepdir/bwa%205,8%20ghz.pdf
(2402 - 2482 @ 20), (20)
(5735 - 5815 @ 20), (23)
+# IE as part of EU/CEPT accepted decisions 2005/513/EC (5GHz RLAN, EN 301 893)
+# and 2006/771/EC (amended by 2008/432/EC, Short-Range Devices, EN 300 440)
+# EU decision 2005/513/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02005D0513-20070213
+# EU decision 2006/771/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02008D0432-20080611
+# IE: https://www.comreg.ie/publication-download/interface-requirements-for-radio-services-in-ireland
+# IE: https://www.comreg.ie/publication-download/permitted-short-range-devices-ireland
country IE: DFS-ETSI
- (2402 - 2482 @ 40), (20)
- (5170 - 5250 @ 80), (20), AUTO-BW, wmmrule=ETSI
- (5250 - 5330 @ 80), (20), DFS, AUTO-BW, wmmrule=ETSI
- (5490 - 5710 @ 160), (27), DFS, wmmrule=ETSI
- # 60 GHz band channels 1-4, ref: Etsi En 302 567
+ (2400 - 2483.5 @ 40), (100 mW)
+ (5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
+ (5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
+ (5470 - 5725 @ 160), (500 mW), DFS, wmmrule=ETSI
+ # short range devices (ETSI EN 300 440-1)
+ (5725 - 5875 @ 80), (25 mW)
+ # 60 GHz band channels 1-4 (ETSI EN 302 567)
(57000 - 66000 @ 2160), (40)
country IL: DFS-ETSI
@@ -626,20 +726,33 @@ country IR: DFS-JP
(2402 - 2482 @ 40), (20)
(5735 - 5835 @ 80), (30)
+# IS as part of CEPT accepted decisions 2005/513/EC (5GHz RLAN, EN 301 893)
+# and 2006/771/EC (amended by 2008/432/EC, Short-Range Devices, EN 300 440)
+# EU decision 2005/513/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02005D0513-20070213
+# EU decision 2006/771/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02008D0432-20080611
+# IS: https://www.pfs.is/library/Skrar/Tidnir-og-taekni/MHZ_21022019.pdf
country IS: DFS-ETSI
- (2402 - 2482 @ 40), (20)
- (5170 - 5250 @ 80), (20), AUTO-BW, wmmrule=ETSI
- (5250 - 5330 @ 80), (20), DFS, AUTO-BW, wmmrule=ETSI
- (5490 - 5710 @ 160), (27), DFS, wmmrule=ETSI
- # 60 GHz band channels 1-4, ref: Etsi En 302 567
+ (2400 - 2483.5 @ 40), (100 mW)
+ (5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
+ (5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
+ (5470 - 5725 @ 160), (500 mW), DFS, wmmrule=ETSI
+ # short range devices (ETSI EN 300 440-1)
+ (5725 - 5875 @ 80), (25 mW)
+ # 60 GHz band channels 1-4 (ETSI EN 302 567)
(57000 - 66000 @ 2160), (40)
+# IT as part of EU/CEPT accepted decisions 2005/513/EC (5GHz RLAN, EN 301 893)
+# and 2006/771/EC (amended by 2008/432/EC, Short-Range Devices, EN 300 440)
+# EU decision 2005/513/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02005D0513-20070213
+# EU decision 2006/771/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02008D0432-20080611
country IT: DFS-ETSI
- (2402 - 2482 @ 40), (20)
- (5170 - 5250 @ 80), (20), AUTO-BW, wmmrule=ETSI
- (5250 - 5330 @ 80), (20), DFS, AUTO-BW, wmmrule=ETSI
- (5490 - 5710 @ 160), (27), DFS, wmmrule=ETSI
- # 60 GHz band channels 1-4, ref: Etsi En 302 567
+ (2400 - 2483.5 @ 40), (100 mW)
+ (5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
+ (5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
+ (5470 - 5725 @ 160), (500 mW), DFS, wmmrule=ETSI
+ # short range devices (ETSI EN 300 440-1)
+ (5725 - 5875 @ 80), (25 mW)
+ # 60 GHz band channels 1-4 (ETSI EN 302 567)
(57000 - 66000 @ 2160), (40)
country JM: DFS-FCC
@@ -741,16 +854,22 @@ country LC: DFS-ETSI
(5490 - 5710 @ 160), (30), DFS
(5735 - 5815 @ 80), (30)
-# Source:
-# https://www.ofcomnet.ch/#/fatTable
-# Note that the maximum transmitter power can be doubled for 5250-5710MHz if
-# transmitter power control is in use: 5250-5330@23db, 5490-5710@30db
+# LI as part of CEPT accepted decisions 2005/513/EC (5GHz RLAN, EN 301 893)
+# and 2006/771/EC (amended by 2008/432/EC, Short-Range Devices, EN 300 440)
+# EU decision 2005/513/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02005D0513-20070213
+# EU decision 2006/771/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02008D0432-20080611
+# LI: https://www.ofcomnet.ch/api/rir/1010/05
+# LI: https://www.ofcomnet.ch/api/rir/1010/04
+# LI: https://www.ofcomnet.ch/api/rir/1008/12
+# LI: https://www.ofcomnet.ch/#/fatTable
country LI: DFS-ETSI
- (2402 - 2482 @ 40), (20)
- (5150 - 5250 @ 80), (23), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
- (5250 - 5350 @ 80), (20), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
- (5490 - 5710 @ 160), (27), DFS, wmmrule=ETSI
- # 60 GHz band channels 1-4, ref: Etsi En 302 567
+ (2400 - 2483.5 @ 40), (100 mW)
+ (5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
+ (5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
+ (5470 - 5725 @ 160), (500 mW), DFS, wmmrule=ETSI
+ # short range devices (ETSI EN 300 440-1)
+ (5725 - 5875 @ 80), (25 mW)
+ # 60 GHz band channels 1-4 (ETSI EN 302 567)
(57000 - 66000 @ 2160), (40)
country LK: DFS-FCC
@@ -768,28 +887,50 @@ country LS: DFS-ETSI
(5250 - 5330 @ 80), (20), DFS, AUTO-BW
(5490 - 5710 @ 160), (27), DFS
+# LT as part of EU/CEPT accepted decisions 2005/513/EC (5GHz RLAN, EN 301 893)
+# and 2006/771/EC (amended by 2008/432/EC, Short-Range Devices, EN 300 440)
+# EU decision 2005/513/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02005D0513-20070213
+# EU decision 2006/771/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02008D0432-20080611
+# LT: https://www.rrt.lt/en/radio-spectrum/frequency-management/ or direct link:
+# LT: https://www.e-tar.lt/portal/lt/legalAct/6e718fd037a011e69101aaab2992cbcd/dGRioCBBHb
country LT: DFS-ETSI
- (2402 - 2482 @ 40), (20)
- (5170 - 5250 @ 80), (20), AUTO-BW, wmmrule=ETSI
- (5250 - 5330 @ 80), (20), DFS, AUTO-BW, wmmrule=ETSI
- (5490 - 5710 @ 160), (27), DFS, wmmrule=ETSI
- # 60 GHz band channels 1-4, ref: Etsi En 302 567
+ (2400 - 2483.5 @ 40), (100 mW)
+ (5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
+ (5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
+ (5470 - 5725 @ 160), (500 mW), DFS, wmmrule=ETSI
+ # short range devices (ETSI EN 300 440-1)
+ (5725 - 5875 @ 80), (25 mW)
+ # 60 GHz band channels 1-4 (ETSI EN 302 567)
(57000 - 66000 @ 2160), (40)
+# LU as part of EU/CEPT accepted decisions 2005/513/EC (5GHz RLAN, EN 301 893)
+# and 2006/771/EC (amended by 2008/432/EC, Short-Range Devices, EN 300 440)
+# EU decision 2005/513/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02005D0513-20070213
+# EU decision 2006/771/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02008D0432-20080611
+# LU: https://assets.ilr.lu/frequences/Documents/ILRLU-1723895916-183.pdf#search=en%20300%20440
country LU: DFS-ETSI
- (2402 - 2482 @ 40), (20)
- (5170 - 5250 @ 80), (20), AUTO-BW, wmmrule=ETSI
- (5250 - 5330 @ 80), (20), DFS, AUTO-BW, wmmrule=ETSI
- (5490 - 5710 @ 160), (27), DFS, wmmrule=ETSI
- # 60 GHz band channels 1-4, ref: Etsi En 302 567
+ (2400 - 2483.5 @ 40), (100 mW)
+ (5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
+ (5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
+ (5470 - 5725 @ 160), (500 mW), DFS, wmmrule=ETSI
+ # short range devices (ETSI EN 300 440-1)
+ (5725 - 5875 @ 80), (25 mW)
+ # 60 GHz band channels 1-4 (ETSI EN 302 567)
(57000 - 66000 @ 2160), (40)
-
+
+# LV as part of EU/CEPT accepted decisions 2005/513/EC (5GHz RLAN, EN 301 893)
+# and 2006/771/EC (amended by 2008/432/EC, Short-Range Devices, EN 300 440)
+# EU decision 2005/513/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02005D0513-20070213
+# EU decision 2006/771/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02008D0432-20080611
+# LV: http://likumi.lv/doc.php?id=198903
country LV: DFS-ETSI
- (2402 - 2482 @ 40), (20)
- (5170 - 5250 @ 80), (20), AUTO-BW, wmmrule=ETSI
- (5250 - 5330 @ 80), (20), DFS, AUTO-BW, wmmrule=ETSI
- (5490 - 5710 @ 160), (27), DFS, wmmrule=ETSI
- # 60 GHz band channels 1-4, ref: Etsi En 302 567
+ (2400 - 2483.5 @ 40), (100 mW)
+ (5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
+ (5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
+ (5470 - 5725 @ 160), (500 mW), DFS, wmmrule=ETSI
+ # short range devices (ETSI EN 300 440-1)
+ (5725 - 5875 @ 80), (25 mW)
+ # 60 GHz band channels 1-4 (ETSI EN 302 567)
(57000 - 66000 @ 2160), (40)
country MA: DFS-ETSI
@@ -875,12 +1016,19 @@ country MR: DFS-ETSI
(5250 - 5330 @ 80), (20), DFS, AUTO-BW
(5490 - 5710 @ 160), (27), DFS
+# MT as part of EU/CEPT accepted decisions 2005/513/EC (5GHz RLAN, EN 301 893)
+# and 2006/771/EC (amended by 2008/432/EC, Short-Range Devices, EN 300 440)
+# EU decision 2005/513/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02005D0513-20070213
+# EU decision 2006/771/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02008D0432-20080611
+# MT: https://www.mca.org.mt/sites/default/files/NFP_edition%206-1.pdf
country MT: DFS-ETSI
- (2402 - 2482 @ 40), (20)
- (5170 - 5250 @ 80), (20), AUTO-BW, wmmrule=ETSI
- (5250 - 5330 @ 80), (20), DFS, AUTO-BW, wmmrule=ETSI
- (5490 - 5710 @ 160), (27), DFS, wmmrule=ETSI
- # 60 GHz band channels 1-4, ref: Etsi En 302 567
+ (2400 - 2483.5 @ 40), (100 mW)
+ (5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
+ (5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
+ (5470 - 5725 @ 160), (500 mW), DFS, wmmrule=ETSI
+ # short range devices (ETSI EN 300 440-1)
+ (5725 - 5875 @ 80), (25 mW)
+ # 60 GHz band channels 1-4 (ETSI EN 302 567)
(57000 - 66000 @ 2160), (40)
country MU: DFS-FCC
@@ -930,34 +1078,36 @@ country NI: DFS-FCC
(5490 - 5730 @ 160), (24), DFS
(5735 - 5835 @ 80), (30)
-# Regulation on the use of frequency space without a license and
-# without notification 2015
-#
-# http://wetten.overheid.nl/BWBR0036378/2015-03-05
-
+# NL as part of EU/CEPT accepted decisions 2005/513/EC (5GHz RLAN, EN 301 893)
+# and 2006/771/EC (amended by 2008/432/EC, Short-Range Devices, EN 300 440)
+# EU decision 2005/513/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02005D0513-20070213
+# EU decision 2006/771/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02008D0432-20080611
+# NL: http://wetten.overheid.nl/BWBR0036378/2015-03-05
country NL: DFS-ETSI
- (2402 - 2482 @ 40), (20)
- (5170 - 5250 @ 80), (20), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
- (5250 - 5330 @ 80), (20), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
- (5490 - 5710 @ 160), (27), DFS, wmmrule=ETSI
+ (2400 - 2483.5 @ 40), (100 mW)
+ (5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
+ (5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
+ (5470 - 5725 @ 160), (500 mW), DFS, wmmrule=ETSI
# short range devices (ETSI EN 300 440-1)
(5725 - 5875 @ 80), (25 mW)
- # 60 GHz band channels 1-4, ref: Etsi En 302 567
+ # 60 GHz band channels 1-4 (ETSI EN 302 567)
(57000 - 66000 @ 2160), (40)
-# Data from http://www.lovdata.no/dokument/SF/forskrift/2012-01-19-77
-# Power at 5250 - 5350 MHz, 5470 - 5725 MHz and 5815 – 5850 MHz can
-# be doubled if TPC is implemented.
-# Up to 2W (or 4W with TPC) is allowed in the 5725 – 5795 MHz band
-# which has been merged with 5470 - 5725 MHz to allow wide channels
+# NO as part of CEPT accepted decisions 2005/513/EC (5GHz RLAN, EN 301 893)
+# and 2006/771/EC (amended by 2008/432/EC, Short-Range Devices, EN 300 440)
+# EU decision 2005/513/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02005D0513-20070213
+# EU decision 2006/771/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02008D0432-20080611
+# NO: https://eng.nkom.no/technical/temporary-licenses/mobile-videolink/wireless-cameras-mobile-video-links/_attachment/9947
+# NO: http://www.lovdata.no/dokument/SF/forskrift/2012-01-19-77
+# In addition to EU NO can use 5725–5795 MHz and 5815–5850 bands with limit of 4 W EIRP (with DFS and TPC)
country NO: DFS-ETSI
(2400 - 2483.5 @ 40), (100 mW)
- (5150 - 5250 @ 80), (200 mW), AUTO-BW, wmmrule=ETSI
- (5250 - 5350 @ 80), (100 mW), DFS, AUTO-BW, wmmrule=ETSI
- (5470 - 5795 @ 160), (500 mW), DFS, wmmrule=ETSI
- (5815 - 5850 @ 35), (2000 mW), DFS
- (17100 - 17300 @ 200), (100 mW)
- # 60 GHz band channels 1-4, ref: Etsi En 302 567
+ (5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
+ (5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
+ (5470 - 5725 @ 160), (500 mW), DFS, wmmrule=ETSI
+ # short range devices (ETSI EN 300 440-1)
+ (5725 - 5875 @ 80), (25 mW)
+ # 60 GHz band channels 1-4 (ETSI EN 302 567)
(57000 - 66000 @ 2160), (40)
country NP: DFS-JP
@@ -1020,12 +1170,18 @@ country PK: DFS-JP
(2402 - 2482 @ 40), (20)
(5735 - 5835 @ 80), (30)
+# PL as part of EU/CEPT accepted decisions 2005/513/EC (5GHz RLAN, EN 301 893)
+# and 2006/771/EC (amended by 2008/432/EC, Short-Range Devices, EN 300 440)
+# EU decision 2005/513/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02005D0513-20070213
+# EU decision 2006/771/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02008D0432-20080611
country PL: DFS-ETSI
- (2402 - 2482 @ 40), (20)
- (5170 - 5250 @ 80), (20), AUTO-BW, wmmrule=ETSI
- (5250 - 5330 @ 80), (20), DFS, AUTO-BW, wmmrule=ETSI
- (5490 - 5710 @ 160), (27), DFS, wmmrule=ETSI
- # 60 GHz band channels 1-4, ref: Etsi En 302 567
+ (2400 - 2483.5 @ 40), (100 mW)
+ (5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
+ (5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
+ (5470 - 5725 @ 160), (500 mW), DFS, wmmrule=ETSI
+ # short range devices (ETSI EN 300 440-1)
+ (5725 - 5875 @ 80), (25 mW)
+ # 60 GHz band channels 1-4 (ETSI EN 302 567)
(57000 - 66000 @ 2160), (40)
country PM: DFS-ETSI
@@ -1041,14 +1197,19 @@ country PR: DFS-FCC
(5490 - 5730 @ 160), (24), DFS
(5735 - 5835 @ 80), (30)
+# PT as part of EU/CEPT accepted decisions 2005/513/EC (5GHz RLAN, EN 301 893)
+# and 2006/771/EC (amended by 2008/432/EC, Short-Range Devices, EN 300 440)
+# EU decision 2005/513/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02005D0513-20070213
+# EU decision 2006/771/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02008D0432-20080611
+# PT: https://www.anacom.pt/render.jsp?categoryId=336334
country PT: DFS-ETSI
- (2402 - 2482 @ 40), (20)
- (5170 - 5250 @ 80), (20), AUTO-BW, wmmrule=ETSI
- (5250 - 5330 @ 80), (20), DFS, AUTO-BW, wmmrule=ETSI
- (5490 - 5710 @ 160), (27), DFS, wmmrule=ETSI
+ (2400 - 2483.5 @ 40), (100 mW)
+ (5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
+ (5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
+ (5470 - 5725 @ 160), (500 mW), DFS, wmmrule=ETSI
# short range devices (ETSI EN 300 440-1)
(5725 - 5875 @ 80), (25 mW)
- # 60 GHz band channels 1-4, ref: Etsi En 302 567
+ # 60 GHz band channels 1-4 (ETSI EN 302 567)
(57000 - 66000 @ 2160), (40)
country PW: DFS-FCC
@@ -1079,15 +1240,21 @@ country RE: DFS-ETSI
(5250 - 5330 @ 80), (20), DFS, AUTO-BW, wmmrule=ETSI
(5490 - 5710 @ 160), (27), DFS, wmmrule=ETSI
+# RO as part of EU/CEPT accepted decisions 2005/513/EC (5GHz RLAN, EN 301 893)
+# and 2006/771/EC (amended by 2008/432/EC, Short-Range Devices, EN 300 440)
+# EU decision 2005/513/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02005D0513-20070213
+# EU decision 2006/771/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02008D0432-20080611
+# RO: http://www.ancom.org.ro/en/uploads/links_files/ordin_262_2006.pdf
country RO: DFS-ETSI
- (2402 - 2482 @ 40), (20)
- (5170 - 5250 @ 80), (20), AUTO-BW, wmmrule=ETSI
- (5250 - 5330 @ 80), (20), DFS, AUTO-BW, wmmrule=ETSI
- (5490 - 5710 @ 160), (27), DFS, wmmrule=ETSI
- # 60 GHz band channels 1-4, ref: Etsi En 302 567
+ (2400 - 2483.5 @ 40), (100 mW)
+ (5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
+ (5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
+ (5470 - 5725 @ 160), (500 mW), DFS, wmmrule=ETSI
+ # short range devices (ETSI EN 300 440-1)
+ (5725 - 5875 @ 80), (25 mW)
+ # 60 GHz band channels 1-4 (ETSI EN 302 567)
(57000 - 66000 @ 2160), (40)
-
# Source:
# http://www.ratel.rs/upload/documents/Plan_namene/Plan_namene-sl_glasnik.pdf
country RS: DFS-ETSI
@@ -1119,18 +1286,20 @@ country SA: DFS-ETSI
(5250 - 5330 @ 80), (20), DFS, AUTO-BW
(5490 - 5710 @ 160), (27), DFS
-# Source:
-# https://pts.se/globalassets/startpage/dokument/legala-dokument/foreskrifter/radio/beslutade_ptsfs-2018-3-undantagsforeskrifter.pdf
+# SE as part of EU/CEPT accepted decisions 2005/513/EC (5GHz RLAN, EN 301 893)
+# and 2006/771/EC (amended by 2008/432/EC, Short-Range Devices, EN 300 440)
+# EU decision 2005/513/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02005D0513-20070213
+# EU decision 2006/771/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02008D0432-20080611
+# SE: https://pts.se/globalassets/startpage/dokument/legala-dokument/foreskrifter/radio/beslutade_ptsfs-2018-3-undantagsforeskrifter.pdf
country SE: DFS-ETSI
- (2400 - 2483.5 @ 40), (20)
- (5150 - 5250 @ 80), (23), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
- # note: max would be +3dB with TPC @ 5250-5725
- (5250 - 5350 @ 80), (20), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
- (5470 - 5725 @ 160), (27), DFS, wmmrule=ETSI
- # short range devices (ETSI EN 300 440)
+ (2400 - 2483.5 @ 40), (100 mW)
+ (5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
+ (5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
+ (5470 - 5725 @ 160), (500 mW), DFS, wmmrule=ETSI
+ # short range devices (ETSI EN 300 440-1)
(5725 - 5875 @ 80), (25 mW)
- # 60 GHz band channels 1-4, ref: Etsi En 302 567
- (57000 - 66000 @ 2160), (40), NO-OUTDOOR
+ # 60 GHz band channels 1-4 (ETSI EN 302 567)
+ (57000 - 66000 @ 2160), (40)
# Source
# https://www.imda.gov.sg/~/media/imda/files/regulation%20licensing%20and%20consultations/ict%20standards/telecommunication%20standards/radio-comms/imdatssrd.pdf?la=en
@@ -1144,20 +1313,36 @@ country SG: DFS-FCC
# (5470 - 5725 @ 160), (30), DFS
(5725 - 5850 @ 80), (30)
+# SI as part of EU/CEPT accepted decisions 2005/513/EC (5GHz RLAN, EN 301 893)
+# and 2006/771/EC (amended by 2008/432/EC, Short-Range Devices, EN 300 440)
+# EU decision 2005/513/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02005D0513-20070213
+# EU decision 2006/771/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02008D0432-20080611
+# SI: https://www.akos-rs.si/bwa
country SI: DFS-ETSI
- (2402 - 2482 @ 40), (20)
- (5170 - 5250 @ 80), (20), AUTO-BW, wmmrule=ETSI
- (5250 - 5330 @ 80), (20), DFS, AUTO-BW, wmmrule=ETSI
- (5490 - 5710 @ 160), (27), DFS, wmmrule=ETSI
- # 60 GHz band channels 1-4, ref: Etsi En 302 567
+ (2400 - 2483.5 @ 40), (100 mW)
+ (5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
+ (5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
+ (5470 - 5725 @ 160), (500 mW), DFS, wmmrule=ETSI
+ # short range devices (ETSI EN 300 440-1)
+ (5725 - 5875 @ 80), (25 mW)
+ # 60 GHz band channels 1-4 (ETSI EN 302 567)
(57000 - 66000 @ 2160), (40)
+# SK as part of EU/CEPT accepted decisions 2005/513/EC (5GHz RLAN, EN 301 893)
+# and 2006/771/EC (amended by 2008/432/EC, Short-Range Devices, EN 300 440)
+# EU decision 2005/513/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02005D0513-20070213
+# EU decision 2006/771/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02008D0432-20080611
+# SK: https://www.teleoff.gov.sk/data/files/25911.pdf
+# SK: https://www.teleoff.gov.sk/data/files/41072.pdf
+# SK: https://www.teleoff.gov.sk/data/files/49125_vpr-01_2018-rusi-vpr-10_2014a21_2012-nespecifik-srd_021018.pdf
country SK: DFS-ETSI
- (2402 - 2482 @ 40), (20)
- (5170 - 5250 @ 80), (20), AUTO-BW, wmmrule=ETSI
- (5250 - 5330 @ 80), (20), DFS, AUTO-BW, wmmrule=ETSI
- (5490 - 5710 @ 160), (27), DFS, wmmrule=ETSI
- # 60 GHz band channels 1-4, ref: Etsi En 302 567
+ (2400 - 2483.5 @ 40), (100 mW)
+ (5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
+ (5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
+ (5470 - 5725 @ 160), (500 mW), DFS, wmmrule=ETSI
+ # short range devices (ETSI EN 300 440-1)
+ (5725 - 5875 @ 80), (25 mW)
+ # 60 GHz band channels 1-4 (ETSI EN 302 567)
(57000 - 66000 @ 2160), (40)
# Source:
^ permalink raw reply related
* [RFC PATCH v7] rtl8xxxu: Improve TX performance of RTL8723BU on rtl8xxxu driver
From: Chris Chiu @ 2019-08-05 13:14 UTC (permalink / raw)
To: Jes.Sorensen, kvalo, davem
Cc: linux-wireless, netdev, linux-kernel, linux, Chris Chiu,
Daniel Drake
We have 3 laptops which connect the wifi by the same RTL8723BU.
The PCI VID/PID of the wifi chip is 10EC:B720 which is supported.
They have the same problem with the in-kernel rtl8xxxu driver, the
iperf (as a client to an ethernet-connected server) gets ~1Mbps.
Nevertheless, the signal strength is reported as around -40dBm,
which is quite good. From the wireshark capture, the tx rate for each
data and qos data packet is only 1Mbps. Compare to the Realtek driver
at https://github.com/lwfinger/rtl8723bu, the same iperf test gets
~12Mbps or better. The signal strength is reported similarly around
-40dBm. That's why we want to improve.
After reading the source code of the rtl8xxxu driver and Realtek's, the
major difference is that Realtek's driver has a watchdog which will keep
monitoring the signal quality and updating the rate mask just like the
rtl8xxxu_gen2_update_rate_mask() does if signal quality changes.
And this kind of watchdog also exists in rtlwifi driver of some specific
chips, ex rtl8192ee, rtl8188ee, rtl8723ae, rtl8821ae...etc. They have
the same member function named dm_watchdog and will invoke the
corresponding dm_refresh_rate_adaptive_mask to adjust the tx rate
mask.
With this commit, the tx rate of each data and qos data packet will
be 39Mbps (MCS4) with the 0xF00000 as the tx rate mask. The 20th bit
to 23th bit means MCS4 to MCS7. It means that the firmware still picks
the lowest rate from the rate mask and explains why the tx rate of
data and qos data is always lowest 1Mbps because the default rate mask
passed is always 0xFFFFFFF ranges from the basic CCK rate, OFDM rate,
and MCS rate. However, with Realtek's driver, the tx rate observed from
wireshark under the same condition is almost 65Mbps or 72Mbps, which
indicating that rtl8xxxu could still be further improved.
Signed-off-by: Chris Chiu <chiu@endlessm.com>
Reviewed-by: Daniel Drake <drake@endlessm.com>
---
Notes:
v2:
- Fix errors and warnings complained by checkpatch.pl
- Replace data structure rate_adaptive by 2 member variables
- Make rtl8xxxu_wireless_mode non-static
- Runs refresh_rate_mask() only in station mode
v3:
- Remove ugly rtl8xxxu_watchdog data structure
- Make sure only one vif exists
v4:
- Move cancel_delayed_work from rtl8xxxu_disconnect to rtl8xxxu_stop
- Clear priv->vif in rtl8xxxu_remove_interface
- Add rateid as the function argument of update_rate_mask
- Rephrase the comment for priv->vif more explicit.
v5:
- Make refresh_rate_mask() generic for all sub-drivers.
- Add definitions for SNR related to help determine rssi_level
v6:
- Fix typo of the comment for priv->vif
v7:
- Fix reported bug of watchdog stop
- refer to the RxPWDBAll in vendor driver for SNR calculation
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu.h | 55 ++++-
.../wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 229 +++++++++++++++++-
2 files changed, 277 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
index ade057d868f7..582c2a346cec 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
@@ -1187,6 +1187,48 @@ struct rtl8723bu_c2h {
struct rtl8xxxu_fileops;
+/*mlme related.*/
+enum wireless_mode {
+ WIRELESS_MODE_UNKNOWN = 0,
+ /* Sub-Element */
+ WIRELESS_MODE_B = BIT(0),
+ WIRELESS_MODE_G = BIT(1),
+ WIRELESS_MODE_A = BIT(2),
+ WIRELESS_MODE_N_24G = BIT(3),
+ WIRELESS_MODE_N_5G = BIT(4),
+ WIRELESS_AUTO = BIT(5),
+ WIRELESS_MODE_AC = BIT(6),
+ WIRELESS_MODE_MAX = 0x7F,
+};
+
+/* from rtlwifi/wifi.h */
+enum ratr_table_mode_new {
+ RATEID_IDX_BGN_40M_2SS = 0,
+ RATEID_IDX_BGN_40M_1SS = 1,
+ RATEID_IDX_BGN_20M_2SS_BN = 2,
+ RATEID_IDX_BGN_20M_1SS_BN = 3,
+ RATEID_IDX_GN_N2SS = 4,
+ RATEID_IDX_GN_N1SS = 5,
+ RATEID_IDX_BG = 6,
+ RATEID_IDX_G = 7,
+ RATEID_IDX_B = 8,
+ RATEID_IDX_VHT_2SS = 9,
+ RATEID_IDX_VHT_1SS = 10,
+ RATEID_IDX_MIX1 = 11,
+ RATEID_IDX_MIX2 = 12,
+ RATEID_IDX_VHT_3SS = 13,
+ RATEID_IDX_BGN_3SS = 14,
+};
+
+#define RTL8XXXU_RATR_STA_INIT 0
+#define RTL8XXXU_RATR_STA_HIGH 1
+#define RTL8XXXU_RATR_STA_MID 2
+#define RTL8XXXU_RATR_STA_LOW 3
+
+#define RTL8XXXU_NOISE_FLOOR_MIN -100
+#define RTL8XXXU_SNR_THRESH_HIGH 50
+#define RTL8XXXU_SNR_THRESH_LOW 20
+
struct rtl8xxxu_priv {
struct ieee80211_hw *hw;
struct usb_device *udev;
@@ -1291,6 +1333,13 @@ struct rtl8xxxu_priv {
u8 pi_enabled:1;
u8 no_pape:1;
u8 int_buf[USB_INTR_CONTENT_LENGTH];
+ u8 rssi_level;
+ /*
+ * Only one virtual interface permitted because only STA mode
+ * is supported and no iface_combinations are provided.
+ */
+ struct ieee80211_vif *vif;
+ struct delayed_work ra_watchdog;
};
struct rtl8xxxu_rx_urb {
@@ -1326,7 +1375,7 @@ struct rtl8xxxu_fileops {
void (*set_tx_power) (struct rtl8xxxu_priv *priv, int channel,
bool ht40);
void (*update_rate_mask) (struct rtl8xxxu_priv *priv,
- u32 ramask, int sgi);
+ u32 ramask, u8 rateid, int sgi);
void (*report_connect) (struct rtl8xxxu_priv *priv,
u8 macid, bool connect);
void (*fill_txdesc) (struct ieee80211_hw *hw, struct ieee80211_hdr *hdr,
@@ -1411,9 +1460,9 @@ void rtl8xxxu_gen2_config_channel(struct ieee80211_hw *hw);
void rtl8xxxu_gen1_usb_quirks(struct rtl8xxxu_priv *priv);
void rtl8xxxu_gen2_usb_quirks(struct rtl8xxxu_priv *priv);
void rtl8xxxu_update_rate_mask(struct rtl8xxxu_priv *priv,
- u32 ramask, int sgi);
+ u32 ramask, u8 rateid, int sgi);
void rtl8xxxu_gen2_update_rate_mask(struct rtl8xxxu_priv *priv,
- u32 ramask, int sgi);
+ u32 ramask, u8 rateid, int sgi);
void rtl8xxxu_gen1_report_connect(struct rtl8xxxu_priv *priv,
u8 macid, bool connect);
void rtl8xxxu_gen2_report_connect(struct rtl8xxxu_priv *priv,
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index c6c41fb962ff..a6f358b9e447 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -4304,7 +4304,8 @@ static void rtl8xxxu_sw_scan_complete(struct ieee80211_hw *hw,
rtl8xxxu_write8(priv, REG_BEACON_CTRL, val8);
}
-void rtl8xxxu_update_rate_mask(struct rtl8xxxu_priv *priv, u32 ramask, int sgi)
+void rtl8xxxu_update_rate_mask(struct rtl8xxxu_priv *priv,
+ u32 ramask, u8 rateid, int sgi)
{
struct h2c_cmd h2c;
@@ -4324,7 +4325,7 @@ void rtl8xxxu_update_rate_mask(struct rtl8xxxu_priv *priv, u32 ramask, int sgi)
}
void rtl8xxxu_gen2_update_rate_mask(struct rtl8xxxu_priv *priv,
- u32 ramask, int sgi)
+ u32 ramask, u8 rateid, int sgi)
{
struct h2c_cmd h2c;
u8 bw = 0;
@@ -4338,7 +4339,7 @@ void rtl8xxxu_gen2_update_rate_mask(struct rtl8xxxu_priv *priv,
h2c.b_macid_cfg.ramask3 = (ramask >> 24) & 0xff;
h2c.ramask.arg = 0x80;
- h2c.b_macid_cfg.data1 = 0;
+ h2c.b_macid_cfg.data1 = rateid;
if (sgi)
h2c.b_macid_cfg.data1 |= BIT(7);
@@ -4478,6 +4479,40 @@ static void rtl8xxxu_set_basic_rates(struct rtl8xxxu_priv *priv, u32 rate_cfg)
rtl8xxxu_write8(priv, REG_INIRTS_RATE_SEL, rate_idx);
}
+static u16
+rtl8xxxu_wireless_mode(struct ieee80211_hw *hw, struct ieee80211_sta *sta)
+{
+ u16 network_type = WIRELESS_MODE_UNKNOWN;
+ u32 rate_mask;
+
+ rate_mask = (sta->supp_rates[0] & 0xfff) |
+ (sta->ht_cap.mcs.rx_mask[0] << 12) |
+ (sta->ht_cap.mcs.rx_mask[0] << 20);
+
+ if (hw->conf.chandef.chan->band == NL80211_BAND_5GHZ) {
+ if (sta->vht_cap.vht_supported)
+ network_type = WIRELESS_MODE_AC;
+ else if (sta->ht_cap.ht_supported)
+ network_type = WIRELESS_MODE_N_5G;
+
+ network_type |= WIRELESS_MODE_A;
+ } else {
+ if (sta->vht_cap.vht_supported)
+ network_type = WIRELESS_MODE_AC;
+ else if (sta->ht_cap.ht_supported)
+ network_type = WIRELESS_MODE_N_24G;
+
+ if (sta->supp_rates[0] <= 0xf)
+ network_type |= WIRELESS_MODE_B;
+ else if (sta->supp_rates[0] & 0xf)
+ network_type |= (WIRELESS_MODE_B | WIRELESS_MODE_G);
+ else
+ network_type |= WIRELESS_MODE_G;
+ }
+
+ return network_type;
+}
+
static void
rtl8xxxu_bss_info_changed(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
struct ieee80211_bss_conf *bss_conf, u32 changed)
@@ -4520,7 +4555,10 @@ rtl8xxxu_bss_info_changed(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
sgi = 1;
rcu_read_unlock();
- priv->fops->update_rate_mask(priv, ramask, sgi);
+ priv->vif = vif;
+ priv->rssi_level = RTL8XXXU_RATR_STA_INIT;
+
+ priv->fops->update_rate_mask(priv, ramask, 0, sgi);
rtl8xxxu_write8(priv, REG_BCN_MAX_ERR, 0xff);
@@ -5464,6 +5502,10 @@ static int rtl8xxxu_add_interface(struct ieee80211_hw *hw,
switch (vif->type) {
case NL80211_IFTYPE_STATION:
+ if (!priv->vif)
+ priv->vif = vif;
+ else
+ return -EOPNOTSUPP;
rtl8xxxu_stop_tx_beacon(priv);
val8 = rtl8xxxu_read8(priv, REG_BEACON_CTRL);
@@ -5487,6 +5529,9 @@ static void rtl8xxxu_remove_interface(struct ieee80211_hw *hw,
struct rtl8xxxu_priv *priv = hw->priv;
dev_dbg(&priv->udev->dev, "%s\n", __func__);
+
+ if (priv->vif)
+ priv->vif = NULL;
}
static int rtl8xxxu_config(struct ieee80211_hw *hw, u32 changed)
@@ -5772,6 +5817,177 @@ rtl8xxxu_ampdu_action(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
return 0;
}
+static u8 rtl8xxxu_signal_to_snr(int signal)
+{
+ if (signal < RTL8XXXU_NOISE_FLOOR_MIN)
+ signal = RTL8XXXU_NOISE_FLOOR_MIN;
+ else if (signal > 0)
+ signal = 0;
+ return (u8)(signal - RTL8XXXU_NOISE_FLOOR_MIN);
+}
+
+static void rtl8xxxu_refresh_rate_mask(struct rtl8xxxu_priv *priv,
+ int signal, struct ieee80211_sta *sta)
+{
+ struct ieee80211_hw *hw = priv->hw;
+ u16 wireless_mode;
+ u8 rssi_level, ratr_idx;
+ u8 txbw_40mhz;
+ u8 snr, snr_thresh_high, snr_thresh_low;
+ u8 go_up_gap = 5;
+
+ rssi_level = priv->rssi_level;
+ snr = rtl8xxxu_signal_to_snr(signal);
+ snr_thresh_high = RTL8XXXU_SNR_THRESH_HIGH;
+ snr_thresh_low = RTL8XXXU_SNR_THRESH_LOW;
+ txbw_40mhz = (hw->conf.chandef.width == NL80211_CHAN_WIDTH_40) ? 1 : 0;
+
+ switch (rssi_level) {
+ case RTL8XXXU_RATR_STA_MID:
+ snr_thresh_high += go_up_gap;
+ break;
+ case RTL8XXXU_RATR_STA_LOW:
+ snr_thresh_high += go_up_gap;
+ snr_thresh_low += go_up_gap;
+ break;
+ default:
+ break;
+ }
+
+ if (snr > snr_thresh_high)
+ rssi_level = RTL8XXXU_RATR_STA_HIGH;
+ else if (snr > snr_thresh_low)
+ rssi_level = RTL8XXXU_RATR_STA_MID;
+ else
+ rssi_level = RTL8XXXU_RATR_STA_LOW;
+
+ if (rssi_level != priv->rssi_level) {
+ int sgi = 0;
+ u32 rate_bitmap = 0;
+
+ rcu_read_lock();
+ rate_bitmap = (sta->supp_rates[0] & 0xfff) |
+ (sta->ht_cap.mcs.rx_mask[0] << 12) |
+ (sta->ht_cap.mcs.rx_mask[1] << 20);
+ if (sta->ht_cap.cap &
+ (IEEE80211_HT_CAP_SGI_40 | IEEE80211_HT_CAP_SGI_20))
+ sgi = 1;
+ rcu_read_unlock();
+
+ wireless_mode = rtl8xxxu_wireless_mode(hw, sta);
+ switch (wireless_mode) {
+ case WIRELESS_MODE_B:
+ ratr_idx = RATEID_IDX_B;
+ if (rate_bitmap & 0x0000000c)
+ rate_bitmap &= 0x0000000d;
+ else
+ rate_bitmap &= 0x0000000f;
+ break;
+ case WIRELESS_MODE_A:
+ case WIRELESS_MODE_G:
+ ratr_idx = RATEID_IDX_G;
+ if (rssi_level == RTL8XXXU_RATR_STA_HIGH)
+ rate_bitmap &= 0x00000f00;
+ else
+ rate_bitmap &= 0x00000ff0;
+ break;
+ case (WIRELESS_MODE_B | WIRELESS_MODE_G):
+ ratr_idx = RATEID_IDX_BG;
+ if (rssi_level == RTL8XXXU_RATR_STA_HIGH)
+ rate_bitmap &= 0x00000f00;
+ else if (rssi_level == RTL8XXXU_RATR_STA_MID)
+ rate_bitmap &= 0x00000ff0;
+ else
+ rate_bitmap &= 0x00000ff5;
+ break;
+ case WIRELESS_MODE_N_24G:
+ case WIRELESS_MODE_N_5G:
+ case (WIRELESS_MODE_G | WIRELESS_MODE_N_24G):
+ case (WIRELESS_MODE_A | WIRELESS_MODE_N_5G):
+ if (priv->tx_paths == 2 && priv->rx_paths == 2)
+ ratr_idx = RATEID_IDX_GN_N2SS;
+ else
+ ratr_idx = RATEID_IDX_GN_N1SS;
+ case (WIRELESS_MODE_B | WIRELESS_MODE_G | WIRELESS_MODE_N_24G):
+ case (WIRELESS_MODE_B | WIRELESS_MODE_N_24G):
+ if (txbw_40mhz) {
+ if (priv->tx_paths == 2 && priv->rx_paths == 2)
+ ratr_idx = RATEID_IDX_BGN_40M_2SS;
+ else
+ ratr_idx = RATEID_IDX_BGN_40M_1SS;
+ } else {
+ if (priv->tx_paths == 2 && priv->rx_paths == 2)
+ ratr_idx = RATEID_IDX_BGN_20M_2SS_BN;
+ else
+ ratr_idx = RATEID_IDX_BGN_20M_1SS_BN;
+ }
+
+ if (priv->tx_paths == 2 && priv->rx_paths == 2) {
+ if (rssi_level == RTL8XXXU_RATR_STA_HIGH) {
+ rate_bitmap &= 0x0f8f0000;
+ } else if (rssi_level == RTL8XXXU_RATR_STA_MID) {
+ rate_bitmap &= 0x0f8ff000;
+ } else {
+ if (txbw_40mhz)
+ rate_bitmap &= 0x0f8ff015;
+ else
+ rate_bitmap &= 0x0f8ff005;
+ }
+ } else {
+ if (rssi_level == RTL8XXXU_RATR_STA_HIGH) {
+ rate_bitmap &= 0x000f0000;
+ } else if (rssi_level == RTL8XXXU_RATR_STA_MID) {
+ rate_bitmap &= 0x000ff000;
+ } else {
+ if (txbw_40mhz)
+ rate_bitmap &= 0x000ff015;
+ else
+ rate_bitmap &= 0x000ff005;
+ }
+ }
+ break;
+ default:
+ ratr_idx = RATEID_IDX_BGN_40M_2SS;
+ rate_bitmap &= 0x0fffffff;
+ break;
+ }
+
+ priv->rssi_level = rssi_level;
+ priv->fops->update_rate_mask(priv, rate_bitmap, ratr_idx, sgi);
+ }
+}
+
+static void rtl8xxxu_watchdog_callback(struct work_struct *work)
+{
+ struct ieee80211_vif *vif;
+ struct rtl8xxxu_priv *priv;
+
+ priv = container_of(work, struct rtl8xxxu_priv, ra_watchdog.work);
+ vif = priv->vif;
+
+ if (vif && vif->type == NL80211_IFTYPE_STATION) {
+ int signal;
+ struct ieee80211_sta *sta;
+
+ rcu_read_lock();
+ sta = ieee80211_find_sta(vif, vif->bss_conf.bssid);
+ if (!sta) {
+ struct device *dev = &priv->udev->dev;
+
+ dev_info(dev, "%s: no sta found\n", __func__);
+ rcu_read_unlock();
+ goto out;
+ }
+ rcu_read_unlock();
+
+ signal = ieee80211_ave_rssi(vif);
+ rtl8xxxu_refresh_rate_mask(priv, signal, sta);
+ }
+
+out:
+ schedule_delayed_work(&priv->ra_watchdog, 2 * HZ);
+}
+
static int rtl8xxxu_start(struct ieee80211_hw *hw)
{
struct rtl8xxxu_priv *priv = hw->priv;
@@ -5828,6 +6044,8 @@ static int rtl8xxxu_start(struct ieee80211_hw *hw)
ret = rtl8xxxu_submit_rx_urb(priv, rx_urb);
}
+
+ schedule_delayed_work(&priv->ra_watchdog, 2 * HZ);
exit:
/*
* Accept all data and mgmt frames
@@ -5879,6 +6097,8 @@ static void rtl8xxxu_stop(struct ieee80211_hw *hw)
if (priv->usb_interrupts)
rtl8xxxu_write32(priv, REG_USB_HIMR, 0);
+ cancel_delayed_work_sync(&priv->ra_watchdog);
+
rtl8xxxu_free_rx_resources(priv);
rtl8xxxu_free_tx_resources(priv);
}
@@ -6051,6 +6271,7 @@ static int rtl8xxxu_probe(struct usb_interface *interface,
INIT_LIST_HEAD(&priv->rx_urb_pending_list);
spin_lock_init(&priv->rx_urb_lock);
INIT_WORK(&priv->rx_urb_wq, rtl8xxxu_rx_urb_work);
+ INIT_DELAYED_WORK(&priv->ra_watchdog, rtl8xxxu_watchdog_callback);
usb_set_intfdata(interface, hw);
--
2.20.1
^ permalink raw reply related
* Re: [PING 2] [PATCH v5 1/7] nfc: pn533: i2c: "pn532" as dt compatible string
From: Johan Hovold @ 2019-08-05 12:42 UTC (permalink / raw)
To: Lars Poeschel
Cc: devicetree, Samuel Ortiz, open list:NFC SUBSYSTEM, open list,
Johan Hovold, netdev
In-Reply-To: <20190403094735.GA19351@lem-wkst-02.lemonage>
On Wed, Apr 03, 2019 at 11:47:35AM +0200, Lars Poeschel wrote:
> Second Ping.
> On Thu, Feb 28, 2019 at 11:48:01AM +0100, Lars Poeschel wrote:
> > A gentle ping on this whole patch series.
> > On Fri, Jan 11, 2019 at 05:18:04PM +0100, Lars Poeschel wrote:
> > > It is favourable to have one unified compatible string for devices that
> > > have multiple interfaces. So this adds simply "pn532" as the devicetree
> > > binding compatible string and makes a note that the old ones are
> > > deprecated.
> > >
> > > Cc: Johan Hovold <johan@kernel.org>
> > > Signed-off-by: Lars Poeschel <poeschel@lemonage.de>
You may want to resend this series to netdev now. David Miller will be
picking up NFC patches directly from there.
Johan
^ permalink raw reply
* Re: [RFC] mt76: fix tx hung regression on MT7630E
From: Stanislaw Gruszka @ 2019-08-05 12:39 UTC (permalink / raw)
To: Lorenzo Bianconi; +Cc: linux-wireless, Felix Fietkau, Ryder Lee, Roy Luo
In-Reply-To: <20190805112719.GA12280@localhost.localdomain>
On Mon, Aug 05, 2019 at 01:27:19PM +0200, Lorenzo Bianconi wrote:
> > ... but I think we have bug when do mt76_txq_schedule_all() in
> > tx_tasklet, because we can schedule on queues that are stoped.
> > So reverting 41634aa8d6db and then optimize by removing tx_tasklet
> > for mmio and remove not needed mt76_txq_schedule_all() calls looks
> > more reasoneble to me.
>
> schedule a stopped queue seems not harmful at a first glance since we do not
> copy pending skbs if we have not enough room in the dma ring.
mac80211 stop queues for various other reasons than
IEEE80211_QUEUE_STOP_REASON_DRIVER .
> Maybe we can be
> more conservative doing something like:
>
> diff --git a/drivers/net/wireless/mediatek/mt76/dma.c b/drivers/net/wireless/mediatek/mt76/dma.c
> index d8f61e540bfd..c6482155e5e4 100644
> --- a/drivers/net/wireless/mediatek/mt76/dma.c
> +++ b/drivers/net/wireless/mediatek/mt76/dma.c
> @@ -346,6 +346,11 @@ mt76_dma_tx_queue_skb(struct mt76_dev *dev, enum mt76_txq_id qid,
> goto unmap;
>
> if (q->queued + (tx_info.nbuf + 1) / 2 >= q->ndesc - 1) {
> + if (!q->stopped) {
> + ieee80211_stop_queue(dev->hw,
> + skb_get_queue_mapping(skb));
> + q->stopped = true;
> + }
> ret = -ENOMEM;
> goto unmap;
> }
> diff --git a/drivers/net/wireless/mediatek/mt76/tx.c b/drivers/net/wireless/mediatek/mt76/tx.c
> index 5397827668b9..bd2d34c4f326 100644
> --- a/drivers/net/wireless/mediatek/mt76/tx.c
> +++ b/drivers/net/wireless/mediatek/mt76/tx.c
> @@ -495,6 +495,9 @@ mt76_txq_schedule_list(struct mt76_dev *dev, enum mt76_txq_id qid)
> while (1) {
> bool empty = false;
>
> + if (hwq->stopped)
> + break;
> +
> if (sq->swq_queued >= 4)
> break;
>
> Does it fix the issue you are facing?
I'll not be able to test this patch this week. Will have access to
the hardware next week.
I checeked before, if
'q->queued + (tx_info.nbuf + 1) / 2 >= q->ndesc - 1' is triggered
when MT7630E hangs and it is not. But maybe second part of the patch
will help.
Stanislaw
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox