Re: ks7010 endianness question
> I think we can call this question resolved. Remove the comment and
> change the hostif_hdr description to
>
> struct hostif_hdr {
> __be16 size;
> __be16 event;
> } __packed;
>
> Are you happy with this?
Yes, I trust you.
signature.asc
Description: PGP signature
Re: ks7010 endianness question
On Wed, Apr 19, 2017 at 01:34:46PM +1000, Tobin C. Harding wrote:
> Hi Wolfram,
>
> May I please ask you with an ks7010 driver endianness question?
>
> Comments on the hostif_hdr data structure (ks_hostif.h) state that the
> target uses little endian byte order.
>
> /*
> * HOST-MAC I/F data structure
> * Byte alignmet Little Endian
> */
>
> struct hostif_hdr {
> u16 size;
> u16 event;
> } __packed;
>
> On the rx data path this header is unpacked using get_WORD()
>
> void hostif_receive(struct ks_wlan_private *priv, unsigned char *p,
> unsigned int size)
> {
> DPRINTK(4, "\n");
>
> devio_rec_ind(priv, p, size);
>
> priv->rxp = p;
> priv->rx_size = size;
>
> if (get_WORD(priv) == priv->rx_size) { /* length check !! */
> hostif_event_check(priv); /* event check */
> }
> }
>
> get_WORD() inverts the byte order
>
> static inline u16 get_WORD(struct ks_wlan_private *priv)
> {
> u16 data;
>
> data = (get_BYTE(priv) & 0xff);
> data |= ((get_BYTE(priv) << 8) & 0xff00);
> return data;
> }
>
> Am I missing something? It seems that this code will only work if the
> host and the target have differing endianness. It seems unlikely that
> the driver was tested solely on a big-endian machine, is the comment
> wrong - is the target actually big-endian?
Further investigation suggests that the target is actually using
network byte order (implying that the comment is wrong).
static void hostif_data_indication(struct ks_wlan_private *priv)
{
...
auth_type = get_WORD(priv); /* AuthType */
get_WORD(priv); /* Reserve Area */
eth_hdr = (struct ether_hdr *)(priv->rxp);
eth_proto = ntohs(eth_hdr->h_proto);
...
I think we can call this question resolved. Remove the comment and
change the hostif_hdr description to
struct hostif_hdr {
__be16 size;
__be16 event;
} __packed;
Are you happy with this?
thanks,
Tobin.
ks7010 endianness question
Hi Wolfram,
May I please ask you with an ks7010 driver endianness question?
Comments on the hostif_hdr data structure (ks_hostif.h) state that the
target uses little endian byte order.
/*
* HOST-MAC I/F data structure
* Byte alignmet Little Endian
*/
struct hostif_hdr {
u16 size;
u16 event;
} __packed;
On the rx data path this header is unpacked using get_WORD()
void hostif_receive(struct ks_wlan_private *priv, unsigned char *p,
unsigned int size)
{
DPRINTK(4, "\n");
devio_rec_ind(priv, p, size);
priv->rxp = p;
priv->rx_size = size;
if (get_WORD(priv) == priv->rx_size) { /* length check !! */
hostif_event_check(priv); /* event check */
}
}
get_WORD() inverts the byte order
static inline u16 get_WORD(struct ks_wlan_private *priv)
{
u16 data;
data = (get_BYTE(priv) & 0xff);
data |= ((get_BYTE(priv) << 8) & 0xff00);
return data;
}
Am I missing something? It seems that this code will only work if the
host and the target have differing endianness. It seems unlikely that
the driver was tested solely on a big-endian machine, is the comment
wrong - is the target actually big-endian?
Off topic, I watched your 2014 Fosdem talk on adding device support to
the kernel without adding code. It was very educational.
thanks for your time,
Tobin.
[PATCH 0/2] rtlwifi: btcoex: Two more patches
These two patches finish the updates to btcoex for the 4.12 streeam. Larry Signed-off-by: Yan-Hsuan Chuang Signed-off-by: Larry Finger Cc: Pkshih Cc: Birming Chiu Cc: Shaofu Cc: Steven Ting Yan-Hsuan Chuang (2): rtlwifi: btcoex: update new btcoex version rtlwifi: btcoex: fix compiler warnings for unused functions .../realtek/rtlwifi/btcoexist/halbt_precomp.h | 22 + .../realtek/rtlwifi/btcoexist/halbtc8192e2ant.h| 32 +- .../realtek/rtlwifi/btcoexist/halbtc8723b1ant.c| 52 +- .../realtek/rtlwifi/btcoexist/halbtc8723b1ant.h| 41 +- .../realtek/rtlwifi/btcoexist/halbtc8723b2ant.h| 3 + .../realtek/rtlwifi/btcoexist/halbtc8821a1ant.h| 38 +- .../realtek/rtlwifi/btcoexist/halbtc8821a2ant.c| 10 +- .../realtek/rtlwifi/btcoexist/halbtc8821a2ant.h| 28 +- .../realtek/rtlwifi/btcoexist/halbtcoutsrc.c | 838 - .../realtek/rtlwifi/btcoexist/halbtcoutsrc.h | 42 +- .../wireless/realtek/rtlwifi/btcoexist/rtl_btc.c | 35 +- 11 files changed, 824 insertions(+), 317 deletions(-) -- 2.12.0
[PATCH 2/2] rtlwifi: btcoex: fix compiler warnings for unused functions
From: Yan-Hsuan Chuang
Add if define ... endif to fix the unused warnings for 21a 2ant. The
routines in question are not needed at the moment, but will be
needed in the near future.
Signed-off-by: Yan-Hsuan Chuang
Signed-off-by: Larry Finger
Cc: Pkshih
Cc: Birming Chiu
Cc: Shaofu
Cc: Steven Ting
---
.../net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c | 10 +-
.../net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.h | 2 ++
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c
index 3b4c892fc233..93a264380016 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c
@@ -265,6 +265,8 @@ void btc8821a2ant_limited_rx(struct btc_coexist *btcoexist,
bool force_exec,
btcoexist->btc_set(btcoexist, BTC_SET_ACT_AGGREGATE_CTRL, NULL);
}
+#if (BT_AUTO_REPORT_ONLY_8821A_2ANT != 0)
+
static void btc8821a2ant_monitor_bt_ctr(struct btc_coexist *btcoexist)
{
struct rtl_priv *rtlpriv = btcoexist->adapter;
@@ -343,6 +345,8 @@ static void btc8821a2ant_monitor_wifi_ctr(struct
btc_coexist *btcoexist)
btcoexist->btc_write_1byte_bitmask(btcoexist, 0xf16, 0x1, 0x0);
}
+#endif
+
static void btc8821a2ant_query_bt_info(struct btc_coexist *btcoexist)
{
struct rtl_priv *rtlpriv = btcoexist->adapter;
@@ -359,7 +363,9 @@ static void btc8821a2ant_query_bt_info(struct btc_coexist
*btcoexist)
btcoexist->btc_fill_h2c(btcoexist, 0x61, 1, h2c_parameter);
}
-bool btc8821a2ant_is_wifi_status_changed(struct btc_coexist *btcoexist)
+#if (BT_AUTO_REPORT_ONLY_8821A_2ANT != 0)
+
+static bool btc8821a2ant_is_wifi_status_changed(struct btc_coexist *btcoexist)
{
static bool pre_wifi_busy = true;
static bool pre_under_4way = true;
@@ -400,6 +406,8 @@ bool btc8821a2ant_is_wifi_status_changed(struct btc_coexist
*btcoexist)
return false;
}
+#endif
+
static void btc8821a2ant_update_bt_link_info(struct btc_coexist *btcoexist)
{
struct btc_bt_link_info *bt_link_info = &btcoexist->bt_link_info;
diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.h
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.h
index a839d5574422..006f139f4882 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.h
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.h
@@ -43,6 +43,8 @@
/* BT RSSI Threshold for 2-Ant TDMA/1-Ant PS-TDMA translation */
#define BT_8821A_2ANT_BT_RSSI_COEXSWITCH_THRES 46
+#define BT_AUTO_REPORT_ONLY_8821A_2ANT 0
+
enum _BT_INFO_SRC_8821A_2ANT {
BT_INFO_SRC_8821A_2ANT_WIFI_FW = 0x0,
BT_INFO_SRC_8821A_2ANT_BT_RSP = 0x1,
--
2.12.0
[PATCH 1/2] rtlwifi: btcoex: update new btcoex version
From: Yan-Hsuan Chuang
Updates btcoexist to a newer version with some callbacks.
pre_load_firmware()
fix the unstable issues before FW is ready
power_on_seting()
fix the unstable issues before HW is ready
Add some notify functions, check hardware type and call corresponding
functions for specific chip
Signed-off-by: Yan-Hsuan Chuang
Signed-off-by: Larry Finger
Cc: Pkshih
Cc: Birming Chiu
Cc: Shaofu
Cc: Steven Ting
---
.../realtek/rtlwifi/btcoexist/halbt_precomp.h | 22 +
.../realtek/rtlwifi/btcoexist/halbtc8192e2ant.h| 32 +-
.../realtek/rtlwifi/btcoexist/halbtc8723b1ant.c| 52 +-
.../realtek/rtlwifi/btcoexist/halbtc8723b1ant.h| 41 +-
.../realtek/rtlwifi/btcoexist/halbtc8723b2ant.h| 3 +
.../realtek/rtlwifi/btcoexist/halbtc8821a1ant.h| 38 +-
.../realtek/rtlwifi/btcoexist/halbtc8821a2ant.h| 26 +-
.../realtek/rtlwifi/btcoexist/halbtcoutsrc.c | 838 -
.../realtek/rtlwifi/btcoexist/halbtcoutsrc.h | 42 +-
.../wireless/realtek/rtlwifi/btcoexist/rtl_btc.c | 35 +-
10 files changed, 813 insertions(+), 316 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbt_precomp.h
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbt_precomp.h
index 39b9a3309cfd..2ac989a4b2bb 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbt_precomp.h
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbt_precomp.h
@@ -37,6 +37,28 @@
#include "halbtcoutsrc.h"
+/* Interface type */
+#define RT_PCI_INTERFACE 1
+#define RT_USB_INTERFACE 2
+#define RT_SDIO_INTERFACE 3
+#define DEV_BUS_TYPE RT_PCI_INTERFACE
+
+/* IC type */
+#define RTL_HW_TYPE(adapter) (rtl_hal((struct rtl_priv *)adapter)->hw_type)
+
+#define IS_NEW_GENERATION_IC(adapter) \
+ (RTL_HW_TYPE(adapter) >= HARDWARE_TYPE_RTL8192EE)
+#define IS_HARDWARE_TYPE_8812(adapter) \
+ (RTL_HW_TYPE(adapter) == HARDWARE_TYPE_RTL8812AE)
+#define IS_HARDWARE_TYPE_8821(adapter) \
+ (RTL_HW_TYPE(adapter) == HARDWARE_TYPE_RTL8821AE)
+#define IS_HARDWARE_TYPE_8723A(adapter)\
+ (RTL_HW_TYPE(adapter) == HARDWARE_TYPE_RTL8723AE)
+#define IS_HARDWARE_TYPE_8723B(adapter)\
+ (RTL_HW_TYPE(adapter) == HARDWARE_TYPE_RTL8723BE)
+#define IS_HARDWARE_TYPE_8192E(adapter)\
+ (RTL_HW_TYPE(adapter) == HARDWARE_TYPE_RTL8192EE)
+
#include "halbtc8192e2ant.h"
#include "halbtc8723b1ant.h"
#include "halbtc8723b2ant.h"
diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8192e2ant.h
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8192e2ant.h
index fc0fa87ec404..f960dda2f682 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8192e2ant.h
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8192e2ant.h
@@ -166,20 +166,20 @@ struct coex_sta_8192e_2ant {
/
*The following is interface which will notify coex module.
/
-void ex_halbtc8192e2ant_init_hwconfig(struct btc_coexist *btcoexist);
-void ex_halbtc8192e2ant_init_coex_dm(struct btc_coexist *btcoexist);
-void ex_halbtc8192e2ant_ips_notify(struct btc_coexist *btcoexist, u8 type);
-void ex_halbtc8192e2ant_lps_notify(struct btc_coexist *btcoexist, u8 type);
-void ex_halbtc8192e2ant_scan_notify(struct btc_coexist *btcoexist, u8 type);
-void ex_halbtc8192e2ant_connect_notify(struct btc_coexist *btcoexist, u8 type);
-void ex_halbtc8192e2ant_media_status_notify(struct btc_coexist *btcoexist,
+void ex_btc8192e2ant_init_hwconfig(struct btc_coexist *btcoexist);
+void ex_btc8192e2ant_init_coex_dm(struct btc_coexist *btcoexist);
+void ex_btc8192e2ant_ips_notify(struct btc_coexist *btcoexist, u8 type);
+void ex_btc8192e2ant_lps_notify(struct btc_coexist *btcoexist, u8 type);
+void ex_btc8192e2ant_scan_notify(struct btc_coexist *btcoexist, u8 type);
+void ex_btc8192e2ant_connect_notify(struct btc_coexist *btcoexist, u8 type);
+void ex_btc8192e2ant_media_status_notify(struct btc_coexist *btcoexist,
+u8 type);
+void ex_btc8192e2ant_special_packet_notify(struct btc_coexist *btcoexist,
+ u8 type);
+void ex_btc8192e2ant_bt_info_notify(struct btc_coexist *btcoexist,
+ u8 *tmpbuf, u8 length);
+void ex_btc8192e2ant_stack_operation_notify(struct btc_coexist *btcoexist,
u8 type);
-void ex_halbtc8192e2ant_special_packet_notify(struct btc_coexist *btcoexist,
- u8 type);
-void ex_halbtc8192e2ant_bt_info_notify(struct btc_coexist *btcoexist,
- u8 *tmpbuf, u8 length);
-void ex_halbtc8192e2ant_stack_operation_notify(struct btc_coexist
Re: [PATCH 1/5] netlink: extended ACK reporting
On 18 April 2017 at 02:41, Johannes Berg wrote: > On Thu, 2017-04-13 at 14:44 -0700, Joe Stringer wrote > (something that never made it to the list, due to HTML formatting) >> >> I think that OVS was doing some more elaborate validation than most >> users, so over time we picked up a bunch of extra parsing code that >> layers on top of nla_parse(). I took a look at trying to broaden this >> and make it useful to other users a while ago, but when I posted >> there wasn't much interest from others on it so I just moved on. >> Maybe it's about time to pick that back up. > > Ah, ok. I didn't realize it was actually on top of nla_parse(). Some of > this does seem rather useful though, and having more expressive policy > would seem very useful too - I'd love to be able to express nesting > better, for example. Ah, correction - nla_parse() is used in some parts but not all of it. More expressive policy sounds useful for OVS cases too.
Re: [PATCH v2 0/8] NFC: fix device allocation and nfcmrvl crashes
Hi Johan, On Tue, Apr 18, 2017 at 12:09:16PM +0200, Johan Hovold wrote: > On Thu, Mar 30, 2017 at 12:15:34PM +0200, Johan Hovold wrote: > > This started out with the observation that the nfcmrvl_uart driver > > unconditionally dereferenced the tty class device despite the fact that > > not every tty has an associated struct device (Unix98 ptys). Some > > further changes were needed in the common nfcmrvl code to fully address > > this, some of which also incidentally fixed a few related bugs (e.g. > > resource leaks in error paths). > > > > While fixing this I stumbled over a regression in NFC core that lead to > > broken registration error paths and misnamed workqueues. > > > > Note that this has only been tested by configuring the n_hci line > > discipline for different ttys without any actual NFC hardware connected. > > > Johan Hovold (8): > > NFC: fix broken device allocation > > NFC: nfcmrvl_uart: add missing tty-device sanity check > > NFC: nfcmrvl: do not use device-managed resources > > NFC: nfcmrvl: use nfc-device for firmware download > > NFC: nfcmrvl: fix firmware-management initialisation > > NFC: nfcmrvl_uart: fix device-node leak during probe > > NFC: nfcmrvl_usb: use interface as phy device > > NFC: nfcmrvl: allow gpio 0 for reset signalling > > Any chance of getting these into 4.12, Samuel? I have yours and Mark Greer patchset pending. I'll push them to nfc-next and see if I can send another pull request to Dave by the end of this week. Cheers, Samuel.
[GIT] [4.12] NFC update
Hi David, This is the NFC pull request for 4.12. We have: - Improvements for the pn533 command queue handling and device registration order. - Removal of platform data for the pn544 and st21nfca drivers. - Additional device tree options to support more trf7970a hardware options. - Support for Sony's RC-S380P through the port100 driver. - Removal of the obsolte nfcwilink driver. - Headers inclusion cleanups (miscdevice.h, unaligned.h) for many drivers. The following changes since commit eefe06e8ceea88f8397a8df0880ab5ca28dcada6: Merge branch 'bpf-prog-testing-framework' (2017-04-01 12:45:58 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sameo/nfc-next.git tags/nfc-next-4.12-1 for you to fetch changes up to 4ea206395d3aede32bab94a75ec573530486fa44: nfc: fix get_unaligned_...() misuses (2017-04-17 00:42:22 +0200) Al Viro (1): nfc: fix get_unaligned_...() misuses Andrey Rusalin (3): NFC: pn533: change order of free_irq and dev unregistration NFC: pn533: improve cmd queue handling NFC: pn533: change order operations in dev registation Andy Shevchenko (12): NFC: pn544: Get rid of platform data NFC: pn544: Convert to use GPIO descriptor NFC: pn544: Convert to use devm_request_threaded_irq() NFC: pn544: Add GPIO ACPI mapping table NFC: pn544: Get rid of code duplication in ->probe() NFC: st21nfca: Fix obvious typo when check error code NFC: st21nfca: Get rid of platform data NFC: st21nfca: Get rid of "interesting" use of interrupt polarity NFC: st21nfca: Covert to use GPIO descriptor NFC: st21nfca: Use unified device property API meaningfully NFC: netlink: Use error code from nfc_activate_target() NFC: Add nfc_dbg() macro Christophe JAILLET (1): NFC: st21nfca: Fix potential memory leak Corentin Labbe (3): nfc: nxp-nci: Remove unneeded linux/miscdevice.h include nfc: pn544: Remove unneeded linux/miscdevice.h include nfc: st21nfca: Remove unneeded linux/miscdevice.h include Dan Carpenter (1): NFC: nfcmrvl: double free on error path Geliang Tang (1): NFC: nfcmrvl: drop duplicate header gpio.h Geoff Lansberry (2): NFC: trf7970a: add device tree option for 27MHz clock NFC: trf7970a: Add device tree option of 1.8 Volt IO voltage Guan Ben (1): NFC: Make EN2 pin optional in the TRF7970A driver Guenter Roeck (1): NFC: nxp-nci: Include unaligned.h instead of access_ok.h Michał Mirosław (1): NFC: pn533: use constant off-stack buffer for sending acks Nicholas Mc Guire (1): nfc: nxp-nci: use msleep for long delays OGAWA Hirofumi (4): nfc: Add support RC-S380P to port100 nfc: Send same info for both of NFC_CMD_GET_DEVICE and NFC_EVENT_DEVICE_ADDED nfc: Fix RC-S380* needs zero-length packet nfc: Fix hangup of RC-S380* in port100_send_ack() Rob Herring (1): NFC: remove TI nfcwilink driver Samuel Ortiz (1): MAINTAINERS: Remove Lauro and Aloisio from the NFC maintainers list Sudip Mukherjee (1): nfc: fdp: fix NULL pointer dereference Tobias Klauser (1): NFC: nfcmrvl: Include unaligned.h instead of access_ok.h .../devicetree/bindings/net/nfc/trf7970a.txt | 8 +- MAINTAINERS| 2 - drivers/nfc/Kconfig| 11 - drivers/nfc/Makefile | 1 - drivers/nfc/fdp/i2c.c | 6 +- drivers/nfc/nfcmrvl/fw_dnld.c | 7 +- drivers/nfc/nfcmrvl/spi.c | 6 +- drivers/nfc/nfcwilink.c| 578 - drivers/nfc/nxp-nci/firmware.c | 2 +- drivers/nfc/nxp-nci/i2c.c | 7 +- drivers/nfc/pn533/i2c.c| 34 +- drivers/nfc/pn533/pn533.c | 82 +-- drivers/nfc/pn533/pn533.h | 1 + drivers/nfc/pn533/usb.c| 8 +- drivers/nfc/pn544/i2c.c| 221 ++-- drivers/nfc/port100.c | 44 +- drivers/nfc/st21nfca/core.c| 12 +- drivers/nfc/st21nfca/i2c.c | 123 + drivers/nfc/trf7970a.c | 98 +++- include/linux/platform_data/pn544.h| 43 -- include/linux/platform_data/st21nfca.h | 33 -- include/net/nfc/nfc.h | 1 + net/nfc/netlink.c | 24 +- 23 files changed, 289 insertions(+), 1063 deletions(-) delete mode 100644 drivers/nfc/nfcwilink.c delete mode 100644 include/linux/platform_data/pn544.h delete mode 100644 include/linux/platform_data/st21nfca.h
[PATCH 25/25] iwlwifi: mvm: allow block ack response without data
From: Sara Sharon
When FW fails to get block ack, it will send the notification with
0 items in the TFD queue elements. Allow this and handle accordingly.
Fixes: c46e7724bfe9 ("iwlwifi: mvm: support new BA notification response")
Signed-off-by: Sara Sharon
Signed-off-by: Luca Coelho
---
drivers/net/wireless/intel/iwlwifi/mvm/tx.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
b/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
index 65308c4ad8b8..a3de91e5e543 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
@@ -1782,6 +1782,9 @@ void iwl_mvm_rx_ba_notif(struct iwl_mvm *mvm, struct
iwl_rx_cmd_buffer *rxb)
ba_info.status.status_driver_data[0] =
(void *)(uintptr_t)ba_res->reduced_txp;
+ if (!le16_to_cpu(ba_res->tfd_cnt))
+ goto out;
+
/*
* TODO:
* When supporting multi TID aggregations - we need to move
@@ -1799,6 +1802,7 @@ void iwl_mvm_rx_ba_notif(struct iwl_mvm *mvm, struct
iwl_rx_cmd_buffer *rxb)
le16_to_cpu(ba_res->tfd[0].tfd_index),
&ba_info, le32_to_cpu(ba_res->tx_rate));
+out:
IWL_DEBUG_TX_REPLY(mvm,
"BA_NOTIFICATION Received from sta_id = %d,
flags %x, sent:%d, acked:%d\n",
sta_id, le32_to_cpu(ba_res->flags),
--
2.11.0
[PATCH 23/25] iwlwifi: a000: fix memory offsets and lengths
From: Liad Kaufman
Memory offsets and lengths for A000 HW is different
than currently specified.
Fixes: e34d975e40ff ("iwlwifi: Add a000 HW family support")
Signed-off-by: Liad Kaufman
Signed-off-by: Luca Coelho
---
drivers/net/wireless/intel/iwlwifi/iwl-a000.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-a000.c
b/drivers/net/wireless/intel/iwlwifi/iwl-a000.c
index 1c731b88d08c..097cb45c8ad9 100644
--- a/drivers/net/wireless/intel/iwlwifi/iwl-a000.c
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-a000.c
@@ -65,12 +65,12 @@
#define IWL_A000_TX_POWER_VERSION 0x /* meaningless */
/* Memory offsets and lengths */
-#define IWL_A000_DCCM_OFFSET 0x80
-#define IWL_A000_DCCM_LEN 0x18000
+#define IWL_A000_DCCM_OFFSET 0x80 /* LMAC1 */
+#define IWL_A000_DCCM_LEN 0x1 /* LMAC1 */
#define IWL_A000_DCCM2_OFFSET 0x88
#define IWL_A000_DCCM2_LEN 0x8000
#define IWL_A000_SMEM_OFFSET 0x40
-#define IWL_A000_SMEM_LEN 0x68000
+#define IWL_A000_SMEM_LEN 0xD
#define IWL_A000_JF_FW_PRE "iwlwifi-Qu-a0-jf-b0-"
#define IWL_A000_HR_FW_PRE "iwlwifi-Qu-a0-hr-a0-"
--
2.11.0
[PATCH 21/25] iwlwifi: mvm: flip address 4 of AMSDU frames
From: Sara Sharon
Address 4 is reversed as well.
Signed-off-by: Sara Sharon
Signed-off-by: Luca Coelho
---
drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c
b/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c
index 0f74a200e812..24c4fbe139a3 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c
@@ -925,7 +925,7 @@ void iwl_mvm_rx_mpdu_mq(struct iwl_mvm *mvm, struct
napi_struct *napi,
* Our hardware de-aggregates AMSDUs but copies the mac header
* as it to the de-aggregated MPDUs. We need to turn off the
* AMSDU bit in the QoS control ourselves.
-* In addition, HW reverses addr3 - reverse it back.
+* In addition, HW reverses addr3 and addr4 - reverse it back.
*/
if ((desc->mac_flags2 & IWL_RX_MPDU_MFLG2_AMSDU) &&
!WARN_ON(!ieee80211_is_data_qos(hdr->frame_control))) {
@@ -938,6 +938,13 @@ void iwl_mvm_rx_mpdu_mq(struct iwl_mvm *mvm, struct
napi_struct *napi,
for (i = 0; i < ETH_ALEN; i++)
mac_addr[i] = hdr->addr3[ETH_ALEN - i - 1];
ether_addr_copy(hdr->addr3, mac_addr);
+
+ if (ieee80211_has_a4(hdr->frame_control)) {
+ for (i = 0; i < ETH_ALEN; i++)
+ mac_addr[i] =
+ hdr->addr4[ETH_ALEN - i - 1];
+ ether_addr_copy(hdr->addr4, mac_addr);
+ }
}
if (baid != IWL_RX_REORDER_DATA_INVALID_BAID) {
u32 reorder_data = le32_to_cpu(desc->reorder_data);
--
2.11.0
[PATCH 13/25] iwlwifi: mvm: support change to a000 smem API
From: Sara Sharon
API was changed once more to support 2 LMACs.
Adapt to change while preserving current functionality.
Signed-off-by: Sara Sharon
Signed-off-by: Luca Coelho
---
drivers/net/wireless/intel/iwlwifi/iwl-prph.h | 2 +
drivers/net/wireless/intel/iwlwifi/mvm/fw-api.h | 41 +++-
drivers/net/wireless/intel/iwlwifi/mvm/fw-dbg.c | 287 ++--
drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 53 +++--
drivers/net/wireless/intel/iwlwifi/mvm/mvm.h| 11 +-
drivers/net/wireless/intel/iwlwifi/mvm/tx.c | 2 +-
6 files changed, 241 insertions(+), 155 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-prph.h
b/drivers/net/wireless/intel/iwlwifi/iwl-prph.h
index 4bceaccee62f..f832e58e0ef9 100644
--- a/drivers/net/wireless/intel/iwlwifi/iwl-prph.h
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-prph.h
@@ -314,6 +314,8 @@
#define LMPM_SECURE_CPU1_HDR_MEM_SPACE (0x42)
#define LMPM_SECURE_CPU2_HDR_MEM_SPACE (0x420400)
+#define LMAC2_PRPH_OFFSET (0x10)
+
/* Rx FIFO */
#define RXF_SIZE_ADDR (0xa00c88)
#define RXF_RD_D_SPACE (0xa00c40)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/fw-api.h
b/drivers/net/wireless/intel/iwlwifi/mvm/fw-api.h
index dd2bd7c3587c..56f50d8a7b69 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/fw-api.h
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/fw-api.h
@@ -2026,19 +2026,48 @@ struct iwl_shared_mem_cfg_v1 {
__le32 internal_txfifo_size[TX_FIFO_INTERNAL_MAX_NUM];
} __packed; /* SHARED_MEM_ALLOC_API_S_VER_2 */
+/**
+ * struct iwl_shared_mem_lmac_cfg - LMAC shared memory configuration
+ *
+ * @txfifo_addr: start addr of TXF0 (excluding the context table 0.5KB)
+ * @txfifo_size: size of TX FIFOs
+ * @rxfifo1_addr: RXF1 addr
+ * @rxfifo1_size: RXF1 size
+ */
+struct iwl_shared_mem_lmac_cfg {
+ __le32 txfifo_addr;
+ __le32 txfifo_size[TX_FIFO_MAX_NUM];
+ __le32 rxfifo1_addr;
+ __le32 rxfifo1_size;
+
+} __packed; /* SHARED_MEM_ALLOC_LMAC_API_S_VER_1 */
+
+/**
+ * Shared memory configuration information from the FW
+ *
+ * @shared_mem_addr: shared memory address
+ * @shared_mem_size: shared memory size
+ * @sample_buff_addr: internal sample (mon/adc) buff addr
+ * @sample_buff_size: internal sample buff size
+ * @rxfifo2_addr: start addr of RXF2
+ * @rxfifo2_size: size of RXF2
+ * @page_buff_addr: used by UMAC and performance debug (page miss analysis),
+ * when paging is not supported this should be 0
+ * @page_buff_size: size of %page_buff_addr
+ * @lmac_num: number of LMACs (1 or 2)
+ * @lmac_smem: per - LMAC smem data
+ */
struct iwl_shared_mem_cfg {
__le32 shared_mem_addr;
__le32 shared_mem_size;
__le32 sample_buff_addr;
__le32 sample_buff_size;
- __le32 txfifo_addr;
- __le32 txfifo_size[TX_FIFO_MAX_NUM];
- __le32 rxfifo_size[RX_FIFO_MAX_NUM];
+ __le32 rxfifo2_addr;
+ __le32 rxfifo2_size;
__le32 page_buff_addr;
__le32 page_buff_size;
- __le32 rxfifo_addr;
- __le32 internal_txfifo_addr;
- __le32 internal_txfifo_size[TX_FIFO_INTERNAL_MAX_NUM];
+ __le32 lmac_num;
+ struct iwl_shared_mem_lmac_cfg lmac_smem[2];
} __packed; /* SHARED_MEM_ALLOC_API_S_VER_3 */
/**
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/fw-dbg.c
b/drivers/net/wireless/intel/iwlwifi/mvm/fw-dbg.c
index a027b11bbdb3..7b86a4f1b574 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/fw-dbg.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/fw-dbg.c
@@ -7,7 +7,7 @@
*
* Copyright(c) 2008 - 2014 Intel Corporation. All rights reserved.
* Copyright(c) 2013 - 2015 Intel Mobile Communications GmbH
- * Copyright(c) 2015 - 2016 Intel Deutschland GmbH
+ * Copyright(c) 2015 - 2017 Intel Deutschland GmbH
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of version 2 of the GNU General Public License as
@@ -32,7 +32,7 @@
*
* Copyright(c) 2005 - 2014 Intel Corporation. All rights reserved.
* Copyright(c) 2013 - 2015 Intel Mobile Communications GmbH
- * Copyright(c) 2015 - 2016 Intel Deutschland GmbH
+ * Copyright(c) 2015 - 2017 Intel Deutschland GmbH
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -99,10 +99,120 @@ static void iwl_mvm_read_radio_reg(struct iwl_mvm *mvm,
iwl_trans_release_nic_access(mvm->trans, &flags);
}
+static void iwl_mvm_dump_rxf(struct iwl_mvm *mvm,
+struct iwl_fw_error_dump_data **dump_data,
+int size, u32 offset, int fifo_num)
+{
+ struct iwl_fw_error_dump_fifo *fifo_hdr;
+ u32 *fifo_data;
+ u32 fifo_len;
+ int i;
+
+ fifo_hdr = (void *)(*dump_data)->data;
+ fifo_data = (void *)fifo_hdr->data;
+ fifo_len = size;
+
+ /* No need to try to read the data if the length is 0 */
+ if (fifo_len == 0)
+
[PATCH 10/25] iwlwifi: mvm: ignore BAID for SN smaller than SSN
From: Sara Sharon
When we get SN that is smaller than SSN of the aggregation,
we shouldn't apply any reordering on them.
Further more, HW NSSN will be zeroed, which can cause us
to make some invalid decisions.
Detect the situation and invalidate the BAID.
Fixes: b915c10174fb ("iwlwifi: mvm: add reorder buffer per queue")
Signed-off-by: Sara Sharon
Signed-off-by: Luca Coelho
---
drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 2 ++
drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c | 30 +--
drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 1 +
3 files changed, 27 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
b/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
index a22fe45eecc4..32e62175cbd5 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
@@ -626,6 +626,7 @@ struct iwl_mvm_shared_mem_cfg {
* @reorder_timer: timer for frames are in the reorder buffer. For AMSDU
* it is the time of last received sub-frame
* @removed: prevent timer re-arming
+ * @valid: reordering is valid for this queue
* @lock: protect reorder buffer internal state
* @mvm: mvm pointer, needed for frame timer context
*/
@@ -641,6 +642,7 @@ struct iwl_mvm_reorder_buffer {
unsigned long reorder_time[IEEE80211_MAX_AMPDU_BUF];
struct timer_list reorder_timer;
bool removed;
+ bool valid;
spinlock_t lock;
struct iwl_mvm *mvm;
} cacheline_aligned_in_smp;
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c
b/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c
index c99775039f59..8601d25407b3 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c
@@ -636,9 +636,13 @@ static bool iwl_mvm_reorder(struct iwl_mvm *mvm,
return false;
baid_data = rcu_dereference(mvm->baid_map[baid]);
- if (WARN(!baid_data,
-"Received baid %d, but no data exists for this BAID\n", baid))
+ if (!baid_data) {
+ WARN(!(reorder & IWL_RX_MPDU_REORDER_BA_OLD_SN),
+"Received baid %d, but no data exists for this BAID\n",
+baid);
return false;
+ }
+
if (WARN(tid != baid_data->tid || mvm_sta->sta_id != baid_data->sta_id,
"baid 0x%x is mapped to sta:%d tid:%d, but was received for
sta:%d tid:%d\n",
baid, baid_data->sta_id, baid_data->tid, mvm_sta->sta_id,
@@ -653,6 +657,14 @@ static bool iwl_mvm_reorder(struct iwl_mvm *mvm,
spin_lock_bh(&buffer->lock);
+ if (!buffer->valid) {
+ if (reorder & IWL_RX_MPDU_REORDER_BA_OLD_SN) {
+ spin_unlock_bh(&buffer->lock);
+ return false;
+ }
+ buffer->valid = true;
+ }
+
if (ieee80211_is_back_req(hdr->frame_control)) {
iwl_mvm_release_frames(mvm, sta, napi, buffer, nssn);
goto drop;
@@ -737,7 +749,8 @@ static bool iwl_mvm_reorder(struct iwl_mvm *mvm,
return true;
}
-static void iwl_mvm_agg_rx_received(struct iwl_mvm *mvm, u8 baid)
+static void iwl_mvm_agg_rx_received(struct iwl_mvm *mvm,
+ u32 reorder_data, u8 baid)
{
unsigned long now = jiffies;
unsigned long timeout;
@@ -746,8 +759,10 @@ static void iwl_mvm_agg_rx_received(struct iwl_mvm *mvm,
u8 baid)
rcu_read_lock();
data = rcu_dereference(mvm->baid_map[baid]);
- if (WARN_ON(!data))
+ if (!data) {
+ WARN_ON(!(reorder_data & IWL_RX_MPDU_REORDER_BA_OLD_SN));
goto out;
+ }
if (!data->timeout)
goto out;
@@ -925,8 +940,11 @@ void iwl_mvm_rx_mpdu_mq(struct iwl_mvm *mvm, struct
napi_struct *napi,
mac_addr[i] = hdr->addr3[ETH_ALEN - i - 1];
ether_addr_copy(hdr->addr3, mac_addr);
}
- if (baid != IWL_RX_REORDER_DATA_INVALID_BAID)
- iwl_mvm_agg_rx_received(mvm, baid);
+ if (baid != IWL_RX_REORDER_DATA_INVALID_BAID) {
+ u32 reorder_data = le32_to_cpu(desc->reorder_data);
+
+ iwl_mvm_agg_rx_received(mvm, reorder_data, baid);
+ }
}
/* Set up the HT phy flags */
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
b/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
index a58f0cb291bd..65706ddb979b 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
@@ -2225,6 +2225,7 @@ static void iwl_mvm_init_reorder_buffer(struct iwl_mvm
*mvm,
reorder_buf->mvm = mvm;
reorder_buf->queue = i;
reorder_buf->sta_id = sta_id;
+ reorder_buf->valid = false;
for (j = 0; j < reorder_buf->buf
[PATCH 20/25] iwlwifi: split the handler and the wake parts of the notification infra
From: Emmanuel Grumbach
The notification infrastructure (iwl_notification_wait_*
functions) allows to wait until a list of notifications
will come up from the firmware and to run a special handler
(notif_wait handler) when those are received.
The operation mode notifies the notification infrastructure
about any Rx being received by the mean of
iwl_notification_wait_notify() which will do two things:
1) call the notif_wait handler
2) wakeup the thread that was waiting for the notification
Typically, only after those two steps happened, the
operation mode will run its own handler for the notification
that was received from the firmware. This means that the
thread that was waiting for that notification can be
running before the operation mode's handler was called.
When the operation mode's handler is ASYNC, things get even
worse since the thread that was waiting for the
notification isn't even guaranteed that the ASYNC callback
was added to async_handlers_list before it starts to run.
This means that even calling
iwl_mvm_wait_for_async_handlers() can't guarantee that
absolutely everything related to that notification has run.
The following can happen:
Thread sending the commandOperation mode's Rx path
--
iwl_init_notification_wait()
iwl_mvm_send_cmd()
iwl_mvm_rx_common()
iwl_notification_wait_notify()
iwl_mvm_wait_for_async_handlers()
// Possibly free some data
// structure
list_add_tail(async_handlers_list);
schedule_work(async_handlers_wk);
// Access the freed structure
Split the 'run notif_wait's handler' and the 'wake up the
thread' parts to fix this. This allows the operation mode
to do the following:
Thread sending the commandOperation mode's Rx path
--
iwl_init_notification_wait()
iwl_mvm_send_cmd()
iwl_mvm_rx_common()
iwl_notification_wait()
// Will run the notif_wait's handler
list_add_tail(async_handlers_list);
schedule_work(async_handlers_wk);
iwl_notification_notify()
iwl_mvm_wait_for_async_handlers()
This way, the waiter is guaranteed that all the handlers
have been run (if SYNC), or at least enqueued (if ASYNC)
by the time it wakes up.
Signed-off-by: Emmanuel Grumbach
Signed-off-by: Luca Coelho
---
.../net/wireless/intel/iwlwifi/iwl-notif-wait.c| 10 -
.../net/wireless/intel/iwlwifi/iwl-notif-wait.h| 25 +-
2 files changed, 24 insertions(+), 11 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-notif-wait.c
b/drivers/net/wireless/intel/iwlwifi/iwl-notif-wait.c
index 88f260db3744..68412ff2112e 100644
--- a/drivers/net/wireless/intel/iwlwifi/iwl-notif-wait.c
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-notif-wait.c
@@ -76,8 +76,8 @@ void iwl_notification_wait_init(struct iwl_notif_wait_data
*notif_wait)
}
IWL_EXPORT_SYMBOL(iwl_notification_wait_init);
-void iwl_notification_wait_notify(struct iwl_notif_wait_data *notif_wait,
- struct iwl_rx_packet *pkt)
+bool iwl_notification_wait(struct iwl_notif_wait_data *notif_wait,
+ struct iwl_rx_packet *pkt)
{
bool triggered = false;
@@ -118,13 +118,11 @@ void iwl_notification_wait_notify(struct
iwl_notif_wait_data *notif_wait,
}
}
spin_unlock(¬if_wait->notif_wait_lock);
-
}
- if (triggered)
- wake_up_all(¬if_wait->notif_waitq);
+ return triggered;
}
-IWL_EXPORT_SYMBOL(iwl_notification_wait_notify);
+IWL_EXPORT_SYMBOL(iwl_notification_wait);
void iwl_abort_notification_waits(struct iwl_notif_wait_data *notif_wait)
{
diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-notif-wait.h
b/drivers/net/wireless/intel/iwlwifi/iwl-notif-wait.h
index 0f9995ed71cd..368884be4e7c 100644
--- a/drivers/net/wireless/intel/iwlwifi/iwl-notif-wait.h
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-notif-wait.h
@@ -6,7 +6,7 @@
* GPL LICENSE SUMMARY
*
* Copyright(c) 2007 - 2014 Intel Corporation. All rights reserved.
- * Copyright(c) 2015 Intel Deutschland GmbH
+ * Copyright(c) 2015 - 2017 Intel Deutschland GmbH
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of version 2 of the GNU General Public License as
@@ -32,6 +32,7 @@
* BSD LICENSE
*
* Copyright(c) 2005 - 2014 Intel Corporation. All rights reserved.
+ * Copyright(c) 2015 - 2017 Intel Deutschland GmbH
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -89,10 +90,10 @@ struct iwl_notif_wai
[PATCH 11/25] iwlwifi: mvm: provide the actual number of frames for the SP len
From: Emmanuel Grumbach
In the end, the firmware doesn't want the SP len as present
in the WMM IE, but rather the actual number of frames.
Fixes: bd3c6cf901a8 ("iwlwifi: mvm: tell the firmware about the U-APSD
parameters")
Signed-off-by: Emmanuel Grumbach
Signed-off-by: Luca Coelho
---
drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
b/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
index 65706ddb979b..839596c7a562 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
@@ -223,7 +223,7 @@ int iwl_mvm_sta_send_to_fw(struct iwl_mvm *mvm, struct
ieee80211_sta *sta,
if (sta->uapsd_queues & IEEE80211_WMM_IE_STA_QOSINFO_AC_VO)
add_sta_cmd.uapsd_acs |= BIT(AC_VO);
add_sta_cmd.uapsd_acs |= add_sta_cmd.uapsd_acs << 4;
- add_sta_cmd.sp_length = sta->max_sp;
+ add_sta_cmd.sp_length = sta->max_sp ? sta->max_sp * 2 : 128;
}
status = ADD_STA_SUCCESS;
--
2.11.0
[PATCH 14/25] iwlwifi: support a000 CDB product
From: Sara Sharon
Identify and load FW for a000 CDB product.
Signed-off-by: Sara Sharon
Signed-off-by: Luca Coelho
---
drivers/net/wireless/intel/iwlwifi/iwl-a000.c | 20
drivers/net/wireless/intel/iwlwifi/iwl-config.h | 5 -
drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 7 ---
3 files changed, 24 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-a000.c
b/drivers/net/wireless/intel/iwlwifi/iwl-a000.c
index df4e8714d627..1c731b88d08c 100644
--- a/drivers/net/wireless/intel/iwlwifi/iwl-a000.c
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-a000.c
@@ -5,7 +5,7 @@
*
* GPL LICENSE SUMMARY
*
- * Copyright(c) 2015-2016 Intel Deutschland GmbH
+ * Copyright(c) 2015-2017 Intel Deutschland GmbH
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of version 2 of the GNU General Public License as
@@ -18,7 +18,7 @@
*
* BSD LICENSE
*
- * Copyright(c) 2015-2016 Intel Deutschland GmbH
+ * Copyright(c) 2015-2017 Intel Deutschland GmbH
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -72,8 +72,9 @@
#define IWL_A000_SMEM_OFFSET 0x40
#define IWL_A000_SMEM_LEN 0x68000
-#define IWL_A000_JF_FW_PRE "iwlwifi-Qu-a0-jf-b0-"
-#define IWL_A000_HR_FW_PRE "iwlwifi-Qu-a0-hr-a0-"
+#define IWL_A000_JF_FW_PRE "iwlwifi-Qu-a0-jf-b0-"
+#define IWL_A000_HR_FW_PRE "iwlwifi-Qu-a0-hr-a0-"
+#define IWL_A000_HR_CDB_FW_PRE "iwlwifi-QuIcp-a0-hrcdb-a0-"
#define IWL_A000_HR_MODULE_FIRMWARE(api) \
IWL_A000_HR_FW_PRE "-" __stringify(api) ".ucode"
@@ -134,6 +135,17 @@ const struct iwl_cfg iwla000_2ac_cfg_hr = {
.max_ht_ampdu_exponent = IEEE80211_HT_MAX_AMPDU_64K,
};
+const struct iwl_cfg iwla000_2ac_cfg_hr_cdb = {
+ .name = "Intel(R) Dual Band Wireless AC a000",
+ .fw_name_pre = IWL_A000_HR_CDB_FW_PRE,
+ IWL_DEVICE_A000,
+ .ht_params = &iwl_a000_ht_params,
+ .nvm_ver = IWL_A000_NVM_VERSION,
+ .nvm_calib_ver = IWL_A000_TX_POWER_VERSION,
+ .max_ht_ampdu_exponent = IEEE80211_HT_MAX_AMPDU_64K,
+ .cdb = true,
+};
+
const struct iwl_cfg iwla000_2ac_cfg_jf = {
.name = "Intel(R) Dual Band Wireless AC a000",
.fw_name_pre = IWL_A000_JF_FW_PRE,
diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-config.h
b/drivers/net/wireless/intel/iwlwifi/iwl-config.h
index 06034a71a190..4af1267181a9 100644
--- a/drivers/net/wireless/intel/iwlwifi/iwl-config.h
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-config.h
@@ -314,6 +314,7 @@ struct iwl_pwr_tx_backoff {
* @rf_id: need to read rf_id to determine the firmware image
* @integrated: discrete or integrated
* @gen2: a000 and on transport operation
+ * @cdb: CDB support
*
* We enable the driver to be backward compatible wrt. hardware features.
* API differences in uCode shouldn't be handled here but through TLVs
@@ -360,7 +361,8 @@ struct iwl_cfg {
rf_id:1,
integrated:1,
use_tfh:1,
- gen2:1;
+ gen2:1,
+ cdb:1;
u8 valid_tx_ant;
u8 valid_rx_ant;
u8 non_shared_ant;
@@ -450,6 +452,7 @@ extern const struct iwl_cfg iwl9270_2ac_cfg;
extern const struct iwl_cfg iwl9460_2ac_cfg;
extern const struct iwl_cfg iwl9560_2ac_cfg;
extern const struct iwl_cfg iwla000_2ac_cfg_hr;
+extern const struct iwl_cfg iwla000_2ac_cfg_hr_cdb;
extern const struct iwl_cfg iwla000_2ac_cfg_jf;
#endif /* CONFIG_IWLMVM */
diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
index 52e1d0c9428d..e51760e752d4 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
@@ -537,7 +537,8 @@ static const struct pci_device_id iwl_hw_card_ids[] = {
{IWL_PCI_DEVICE(0xA370, 0x1030, iwl9560_2ac_cfg)},
/* a000 Series */
- {IWL_PCI_DEVICE(0x2720, 0x0A10, iwla000_2ac_cfg_hr)},
+ {IWL_PCI_DEVICE(0x2720, 0x0A10, iwla000_2ac_cfg_hr_cdb)},
+ {IWL_PCI_DEVICE(0x2722, 0x0A10, iwla000_2ac_cfg_hr)},
#endif /* CONFIG_IWLMVM */
{0}
@@ -672,8 +673,8 @@ static int iwl_pci_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
}
if (iwl_trans->cfg->rf_id &&
- (cfg == &iwla000_2ac_cfg_hr &&
-iwl_trans->hw_rf_id == CSR_HW_RF_ID_TYPE_JF)) {
+ (cfg == &iwla000_2ac_cfg_hr || cfg == &iwla000_2ac_cfg_hr_cdb) &&
+iwl_trans->hw_rf_id == CSR_HW_RF_ID_TYPE_JF) {
cfg = &iwla000_2ac_cfg_jf;
iwl_trans->cfg = cfg;
}
--
2.11.0
[PATCH 22/25] iwlwifi: mvm: support changing band for phy context
From: Sara Sharon
In a000 CDB firmware, we cannot update phy context to a
different band - we must first remove it and add it
again. Support this flow for all a000 devices since
we may have various combinations that cause us to fail
regardless if CDB is active.
Signed-off-by: Sara Sharon
Signed-off-by: Luca Coelho
---
drivers/net/wireless/intel/iwlwifi/mvm/fw-api.h | 2 +-
drivers/net/wireless/intel/iwlwifi/mvm/phy-ctxt.c | 21 -
2 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/fw-api.h
b/drivers/net/wireless/intel/iwlwifi/mvm/fw-api.h
index 8302cf03ac28..f545c5f9e4e3 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/fw-api.h
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/fw-api.h
@@ -690,7 +690,7 @@ struct iwl_error_resp {
(_color << FW_CTXT_COLOR_POS))
/* Possible actions on PHYs, MACs and Bindings */
-enum {
+enum iwl_phy_ctxt_action {
FW_CTXT_ACTION_STUB = 0,
FW_CTXT_ACTION_ADD,
FW_CTXT_ACTION_MODIFY,
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/phy-ctxt.c
b/drivers/net/wireless/intel/iwlwifi/mvm/phy-ctxt.c
index 95138830b9f8..d59efe804356 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/phy-ctxt.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/phy-ctxt.c
@@ -7,6 +7,7 @@
*
* Copyright(c) 2012 - 2014 Intel Corporation. All rights reserved.
* Copyright(c) 2013 - 2014 Intel Mobile Communications GmbH
+ * Copyright(c) 2017 Intel Deutschland GmbH
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of version 2 of the GNU General Public License as
@@ -250,12 +251,30 @@ int iwl_mvm_phy_ctxt_changed(struct iwl_mvm *mvm, struct
iwl_mvm_phy_ctxt *ctxt,
struct cfg80211_chan_def *chandef,
u8 chains_static, u8 chains_dynamic)
{
+ enum iwl_phy_ctxt_action action = FW_CTXT_ACTION_MODIFY;
+
lockdep_assert_held(&mvm->mutex);
+ /* In CDB mode we cannot modify PHY context between bands so... */
+ if (iwl_mvm_has_new_tx_api(mvm) &&
+ ctxt->channel->band != chandef->chan->band) {
+ int ret;
+
+ /* ... remove it here ...*/
+ ret = iwl_mvm_phy_ctxt_apply(mvm, ctxt, chandef,
+chains_static, chains_dynamic,
+FW_CTXT_ACTION_REMOVE, 0);
+ if (ret)
+ return ret;
+
+ /* ... and proceed to add it again */
+ action = FW_CTXT_ACTION_ADD;
+ }
+
ctxt->channel = chandef->chan;
return iwl_mvm_phy_ctxt_apply(mvm, ctxt, chandef,
chains_static, chains_dynamic,
- FW_CTXT_ACTION_MODIFY, 0);
+ action, 0);
}
void iwl_mvm_phy_ctxt_unref(struct iwl_mvm *mvm, struct iwl_mvm_phy_ctxt *ctxt)
--
2.11.0
[PATCH 19/25] iwlwifi: mvm: dump frames early on invalid rate
From: Sara Sharon
Currently when rate isn't found (invalid rate or CCK rate in high
band) driver is assigning rate -1, which causes mac80211 to dump
it later with the cryptic rate value of 0xFF.
Instead, warn early and dump the frame in mvm.
Signed-off-by: Sara Sharon
Signed-off-by: Luca Coelho
---
drivers/net/wireless/intel/iwlwifi/mvm/rx.c | 13 ++---
drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c | 18 +-
2 files changed, 23 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/rx.c
b/drivers/net/wireless/intel/iwlwifi/mvm/rx.c
index eab6e2ad62e1..d4c0ca7ccb34 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/rx.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/rx.c
@@ -460,9 +460,16 @@ void iwl_mvm_rx_rx_mpdu(struct iwl_mvm *mvm, struct
napi_struct *napi,
if (rate_n_flags & RATE_MCS_BF_MSK)
rx_status->vht_flag |= RX_VHT_FLAG_BF;
} else {
- rx_status->rate_idx =
- iwl_mvm_legacy_rate_to_mac80211_idx(rate_n_flags,
- rx_status->band);
+ int rate = iwl_mvm_legacy_rate_to_mac80211_idx(rate_n_flags,
+ rx_status->band);
+
+ if (WARN(rate < 0 || rate > 0xFF,
+"Invalid rate flags 0x%x, band %d,\n",
+rate_n_flags, rx_status->band)) {
+ kfree_skb(skb);
+ return;
+ }
+ rx_status->rate_idx = rate;
}
#ifdef CONFIG_IWLWIFI_DEBUGFS
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c
b/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c
index 8601d25407b3..0f74a200e812 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c
@@ -918,8 +918,7 @@ void iwl_mvm_rx_mpdu_mq(struct iwl_mvm *mvm, struct
napi_struct *napi,
if (iwl_mvm_is_nonagg_dup(sta, queue, rx_status, hdr, desc)) {
kfree_skb(skb);
- rcu_read_unlock();
- return;
+ goto out;
}
/*
@@ -985,9 +984,17 @@ void iwl_mvm_rx_mpdu_mq(struct iwl_mvm *mvm, struct
napi_struct *napi,
if (rate_n_flags & RATE_MCS_BF_MSK)
rx_status->vht_flag |= RX_VHT_FLAG_BF;
} else {
- rx_status->rate_idx =
- iwl_mvm_legacy_rate_to_mac80211_idx(rate_n_flags,
- rx_status->band);
+ int rate = iwl_mvm_legacy_rate_to_mac80211_idx(rate_n_flags,
+ rx_status->band);
+
+ if (WARN(rate < 0 || rate > 0xFF,
+"Invalid rate flags 0x%x, band %d,\n",
+rate_n_flags, rx_status->band)) {
+ kfree_skb(skb);
+ goto out;
+ }
+ rx_status->rate_idx = rate;
+
}
/* management stuff on default queue */
@@ -1006,6 +1013,7 @@ void iwl_mvm_rx_mpdu_mq(struct iwl_mvm *mvm, struct
napi_struct *napi,
iwl_mvm_create_skb(skb, hdr, len, crypt_len, rxb);
if (!iwl_mvm_reorder(mvm, napi, queue, sta, skb, desc))
iwl_mvm_pass_packet_to_mac80211(mvm, napi, skb, queue, sta);
+out:
rcu_read_unlock();
}
--
2.11.0
[PATCH 18/25] iwlwifi: mvm: disable RX queue notification for a000 devices
From: Sara Sharon For a000 devices, we don't really have multi RX queue for now, until we have the RX queue configuration API. Disable RX queue notification for now. Signed-off-by: Sara Sharon Signed-off-by: Luca Coelho --- drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c index 26cf3dfcc108..f35f295d0c81 100644 --- a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c +++ b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c @@ -4218,7 +4218,8 @@ void iwl_mvm_sync_rx_queues_internal(struct iwl_mvm *mvm, lockdep_assert_held(&mvm->mutex); - if (!iwl_mvm_has_new_rx_api(mvm)) + /* TODO - remove a000 disablement when we have RXQ config API */ + if (!iwl_mvm_has_new_rx_api(mvm) || iwl_mvm_has_new_tx_api(mvm)) return; notif->cookie = mvm->queue_sync_cookie; -- 2.11.0
[PATCH 24/25] iwlwifi: bump API to 31
From: Emmanuel Grumbach Omit 7265D and 3168 since those are now stuck on 30. Signed-off-by: Emmanuel Grumbach Signed-off-by: Luca Coelho --- drivers/net/wireless/intel/iwlwifi/iwl-8000.c | 4 ++-- drivers/net/wireless/intel/iwlwifi/iwl-9000.c | 2 +- drivers/net/wireless/intel/iwlwifi/iwl-a000.c | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-8000.c b/drivers/net/wireless/intel/iwlwifi/iwl-8000.c index b9718c0cf174..904e17956e2c 100644 --- a/drivers/net/wireless/intel/iwlwifi/iwl-8000.c +++ b/drivers/net/wireless/intel/iwlwifi/iwl-8000.c @@ -70,8 +70,8 @@ #include "iwl-agn-hw.h" /* Highest firmware API version supported */ -#define IWL8000_UCODE_API_MAX 30 -#define IWL8265_UCODE_API_MAX 30 +#define IWL8000_UCODE_API_MAX 31 +#define IWL8265_UCODE_API_MAX 31 /* Lowest firmware API version supported */ #define IWL8000_UCODE_API_MIN 17 diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-9000.c b/drivers/net/wireless/intel/iwlwifi/iwl-9000.c index 110ceefccc15..42a6e723191e 100644 --- a/drivers/net/wireless/intel/iwlwifi/iwl-9000.c +++ b/drivers/net/wireless/intel/iwlwifi/iwl-9000.c @@ -55,7 +55,7 @@ #include "iwl-agn-hw.h" /* Highest firmware API version supported */ -#define IWL9000_UCODE_API_MAX 30 +#define IWL9000_UCODE_API_MAX 31 /* Lowest firmware API version supported */ #define IWL9000_UCODE_API_MIN 30 diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-a000.c b/drivers/net/wireless/intel/iwlwifi/iwl-a000.c index 097cb45c8ad9..6d745c36f1d8 100644 --- a/drivers/net/wireless/intel/iwlwifi/iwl-a000.c +++ b/drivers/net/wireless/intel/iwlwifi/iwl-a000.c @@ -55,7 +55,7 @@ #include "iwl-agn-hw.h" /* Highest firmware API version supported */ -#define IWL_A000_UCODE_API_MAX 30 +#define IWL_A000_UCODE_API_MAX 31 /* Lowest firmware API version supported */ #define IWL_A000_UCODE_API_MIN 24 -- 2.11.0
[PATCH 12/25] iwlwifi: add four new 8265 and 8275 series PCI IDs
From: Tzipi Peres
Add one new PCI ID for the 8265 series.
Add three new PCI ID for the 8275 series.
Signed-off-by: Tzipi Peres
Signed-off-by: Luca Coelho
---
drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
index d38fcc1a4768..52e1d0c9428d 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
@@ -501,6 +501,10 @@ static const struct pci_device_id iwl_hw_card_ids[] = {
{IWL_PCI_DEVICE(0x24FD, 0x0930, iwl8265_2ac_cfg)},
{IWL_PCI_DEVICE(0x24FD, 0x0950, iwl8265_2ac_cfg)},
{IWL_PCI_DEVICE(0x24FD, 0x0850, iwl8265_2ac_cfg)},
+ {IWL_PCI_DEVICE(0x24FD, 0x1014, iwl8265_2ac_cfg)},
+ {IWL_PCI_DEVICE(0x24FD, 0x3E02, iwl8275_2ac_cfg)},
+ {IWL_PCI_DEVICE(0x24FD, 0x3E01, iwl8275_2ac_cfg)},
+ {IWL_PCI_DEVICE(0x24FD, 0x1012, iwl8275_2ac_cfg)},
{IWL_PCI_DEVICE(0x24FD, 0x0012, iwl8275_2ac_cfg)},
/* 9000 Series */
--
2.11.0
[PATCH 16/25] iwlwifi: mvm: add GEO_TX_POWER_LIMIT cmd for geographic tx power table
From: Haim Dreyfuss
To utilize the maximum allowed tx power, an additional table was added
to the BIOS. The table consists of up to seven different regions
(currently only three are in use). Each region contains per band:
1. Maximum allowed tx power on the band.
2. Tx power offset for chain A.
3. Tx power offset for chain B.
On init flow driver reads this table by means of ACPI and
passes it to the firmware with GEO_TX_POWER_LIMIT cmd.
The firmware will use this table to enhance tx power with
the offset in the relevant table as well as verifying it does not
violate the maximum allowed tx power.
Signed-off-by: Haim Dreyfuss
Signed-off-by: Luca Coelho
---
.../net/wireless/intel/iwlwifi/mvm/fw-api-power.h | 43 +++-
drivers/net/wireless/intel/iwlwifi/mvm/fw-api.h| 1 +
drivers/net/wireless/intel/iwlwifi/mvm/fw.c| 112 +
drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 5 +
drivers/net/wireless/intel/iwlwifi/mvm/ops.c | 1 +
5 files changed, 160 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/fw-api-power.h
b/drivers/net/wireless/intel/iwlwifi/mvm/fw-api-power.h
index 3fa43d1348a2..750510aff70b 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/fw-api-power.h
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/fw-api-power.h
@@ -7,7 +7,7 @@
*
* Copyright(c) 2012 - 2014 Intel Corporation. All rights reserved.
* Copyright(c) 2013 - 2014 Intel Mobile Communications GmbH
- * Copyright(c) 2015 - 2016 Intel Deutschland GmbH
+ * Copyright(c) 2015 - 2017 Intel Deutschland GmbH
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of version 2 of the GNU General Public License as
@@ -34,7 +34,7 @@
*
* Copyright(c) 2012 - 2014 Intel Corporation. All rights reserved.
* Copyright(c) 2013 - 2014 Intel Mobile Communications GmbH
- * Copyright(c) 2015 - 2016 Intel Deutschland GmbH
+ * Copyright(c) 2015 - 2017 Intel Deutschland GmbH
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -351,6 +351,45 @@ struct iwl_dev_tx_power_cmd {
u8 reserved[3];
} __packed; /* TX_REDUCED_POWER_API_S_VER_4 */
+#define IWL_NUM_GEO_PROFILES 3
+
+/**
+ * enum iwl_geo_per_chain_offset_operation - type of operation
+ * @IWL_PER_CHAIN_OFFSET_SET_TABLES: send the tables from the host to the FW.
+ * @IWL_PER_CHAIN_OFFSET_GET_CURRENT_TABLE: retrieve the last configured table.
+ */
+enum iwl_geo_per_chain_offset_operation {
+ IWL_PER_CHAIN_OFFSET_SET_TABLES,
+ IWL_PER_CHAIN_OFFSET_GET_CURRENT_TABLE,
+}; /* GEO_TX_POWER_LIMIT FLAGS TYPE */
+
+/**
+ * struct iwl_per_chain_offset - embedded struct for GEO_TX_POWER_LIMIT.
+ * @max_tx_power: maximum allowed tx power.
+ * @chain_a: tx power offset for chain a.
+ * @chain_b: tx power offset for chain b.
+ */
+struct iwl_per_chain_offset {
+ __le16 max_tx_power;
+ u8 chain_a;
+ u8 chain_b;
+} __packed; /* PER_CHAIN_LIMIT_OFFSET_PER_CHAIN_S_VER_1 */
+
+struct iwl_per_chain_offset_group {
+ struct iwl_per_chain_offset lb;
+ struct iwl_per_chain_offset hb;
+} __packed; /* PER_CHAIN_LIMIT_OFFSET_GROUP_S_VER_1 */
+
+/**
+ * struct iwl_geo_tx_power_profile_cmd - struct for GEO_TX_POWER_LIMIT cmd.
+ * @ops: operations, value from &enum iwl_geo_per_chain_offset_operation
+ * @table: offset profile per band.
+ */
+struct iwl_geo_tx_power_profiles_cmd {
+ __le32 ops;
+ struct iwl_per_chain_offset_group table[IWL_NUM_GEO_PROFILES];
+} __packed; /* GEO_TX_POWER_LIMIT */
+
/**
* struct iwl_beacon_filter_cmd
* REPLY_BEACON_FILTERING_CMD = 0xd2 (command)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/fw-api.h
b/drivers/net/wireless/intel/iwlwifi/mvm/fw-api.h
index 56f50d8a7b69..5086dc00346c 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/fw-api.h
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/fw-api.h
@@ -320,6 +320,7 @@ enum iwl_phy_ops_subcmd_ids {
CMD_DTS_MEASUREMENT_TRIGGER_WIDE = 0x0,
CTDP_CONFIG_CMD = 0x03,
TEMP_REPORTING_THRESHOLDS_CMD = 0x04,
+ GEO_TX_POWER_LIMIT = 0x05,
CT_KILL_NOTIFICATION = 0xFE,
DTS_MEASUREMENT_NOTIF_WIDE = 0xFF,
};
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
b/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
index a845233d14a3..bce3cf5fab67 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
@@ -998,10 +998,14 @@ static int iwl_mvm_config_ltr(struct iwl_mvm *mvm)
#ifdef CONFIG_ACPI
#define ACPI_WRDS_METHOD "WRDS"
#define ACPI_EWRD_METHOD "EWRD"
+#define ACPI_WGDS_METHOD "WGDS"
#define ACPI_WIFI_DOMAIN (0x07)
#define ACPI_WRDS_WIFI_DATA_SIZE (IWL_MVM_SAR_TABLE_SIZE + 2)
#define ACPI_EWRD_WIFI_DATA_SIZE ((IWL_MVM_SAR_PROFILE_NUM - 1) * \
IWL_MVM_SAR_TABLE_SIZE + 3)
+#define ACPI_WGDS_WIFI_DATA_SIZE
[PATCH 17/25] iwlwifi: mvm: support init extended command
From: Sara Sharon
When we load firmware in extended mode (as we do by default for
now) driver should send a command what kind of commands ucode
should stop and wait for before proceeding with phy calibrations.
Support this command. Currently we only do NVM access - so mark
this bit only.
Signed-off-by: Sara Sharon
Signed-off-by: Luca Coelho
---
drivers/net/wireless/intel/iwlwifi/mvm/fw-api.h | 23 +++
drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 15 +++
drivers/net/wireless/intel/iwlwifi/mvm/ops.c| 1 +
3 files changed, 39 insertions(+)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/fw-api.h
b/drivers/net/wireless/intel/iwlwifi/mvm/fw-api.h
index 5086dc00346c..8302cf03ac28 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/fw-api.h
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/fw-api.h
@@ -327,6 +327,7 @@ enum iwl_phy_ops_subcmd_ids {
enum iwl_system_subcmd_ids {
SHARED_MEM_CFG_CMD = 0x0,
+ INIT_EXTENDED_CFG_CMD = 0x03,
};
enum iwl_data_path_subcmd_ids {
@@ -2236,4 +2237,26 @@ struct iwl_nvm_access_complete_cmd {
__le32 reserved;
} __packed; /* NVM_ACCESS_COMPLETE_CMD_API_S_VER_1 */
+/**
+ * enum iwl_extended_cfg_flag - commands driver may send before
+ * finishing init flow
+ * @IWL_INIT_DEBUG_CFG: driver is going to send debug config command
+ * @IWL_INIT_NVM: driver is going to send NVM_ACCESS commands
+ * @IWL_INIT_PHY: driver is going to send PHY_DB commands
+ */
+enum iwl_extended_cfg_flags {
+ IWL_INIT_DEBUG_CFG,
+ IWL_INIT_NVM,
+ IWL_INIT_PHY,
+};
+
+/**
+ * struct iwl_extended_cfg_cmd - mark what commands ucode should wait for
+ * before finishing init flows
+ * @init_flags: values from iwl_extended_cfg_flags
+ */
+struct iwl_init_extended_cfg_cmd {
+ __le32 init_flags;
+} __packed; /* INIT_EXTENDED_CFG_CMD_API_S_VER_1 */
+
#endif /* __fw_api_h__ */
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
b/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
index bce3cf5fab67..900f1e25b9da 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
@@ -836,6 +836,9 @@ int iwl_run_unified_mvm_ucode(struct iwl_mvm *mvm, bool
read_nvm)
{
struct iwl_notification_wait init_wait;
struct iwl_nvm_access_complete_cmd nvm_complete = {};
+ struct iwl_init_extended_cfg_cmd init_cfg = {
+ .init_flags = cpu_to_le32(BIT(IWL_INIT_NVM)),
+ };
static const u16 init_complete[] = {
INIT_COMPLETE_NOTIF,
};
@@ -857,6 +860,18 @@ int iwl_run_unified_mvm_ucode(struct iwl_mvm *mvm, bool
read_nvm)
goto error;
}
+ /* Send init config command to mark that we are sending NVM access
+* commands
+*/
+ ret = iwl_mvm_send_cmd_pdu(mvm, WIDE_ID(SYSTEM_GROUP,
+ INIT_EXTENDED_CFG_CMD), 0,
+ sizeof(init_cfg), &init_cfg);
+ if (ret) {
+ IWL_ERR(mvm, "Failed to run init config command: %d\n",
+ ret);
+ goto error;
+ }
+
/* Read the NVM only at driver load time, no need to do this twice */
if (read_nvm) {
/* Read nvm */
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/ops.c
b/drivers/net/wireless/intel/iwlwifi/mvm/ops.c
index 488d3c948fe8..888053323c92 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/ops.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/ops.c
@@ -428,6 +428,7 @@ static const struct iwl_hcmd_names iwl_mvm_legacy_names[] =
{
*/
static const struct iwl_hcmd_names iwl_mvm_system_names[] = {
HCMD_NAME(SHARED_MEM_CFG_CMD),
+ HCMD_NAME(INIT_EXTENDED_CFG_CMD),
};
/* Please keep this array *SORTED* by hex value.
--
2.11.0
[PATCH 15/25] iwlwifi: pcie: remove RSA race workaround
From: Luca Coelho
This workaround is not needed anymore. Remove it.
Signed-off-by: Luca Coelho
---
drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 46 -
1 file changed, 46 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
index ed1034e58cb4..91f6030529b3 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
@@ -720,47 +720,6 @@ static int iwl_pcie_load_section(struct iwl_trans *trans,
u8 section_num,
return ret;
}
-/*
- * Driver Takes the ownership on secure machine before FW load
- * and prevent race with the BT load.
- * W/A for ROM bug. (should be remove in the next Si step)
- */
-static int iwl_pcie_rsa_race_bug_wa(struct iwl_trans *trans)
-{
- u32 val, loop = 1000;
-
- /*
-* Check the RSA semaphore is accessible.
-* If the HW isn't locked and the rsa semaphore isn't accessible,
-* we are in trouble.
-*/
- val = iwl_read_prph(trans, PREG_AUX_BUS_WPROT_0);
- if (val & (BIT(1) | BIT(17))) {
- IWL_DEBUG_INFO(trans,
- "can't access the RSA semaphore it is write
protected\n");
- return 0;
- }
-
- /* take ownership on the AUX IF */
- iwl_write_prph(trans, WFPM_CTRL_REG, WFPM_AUX_CTL_AUX_IF_MAC_OWNER_MSK);
- iwl_write_prph(trans, AUX_MISC_MASTER1_EN, AUX_MISC_MASTER1_EN_SBE_MSK);
-
- do {
- iwl_write_prph(trans, AUX_MISC_MASTER1_SMPHR_STATUS, 0x1);
- val = iwl_read_prph(trans, AUX_MISC_MASTER1_SMPHR_STATUS);
- if (val == 0x1) {
- iwl_write_prph(trans, RSA_ENABLE, 0);
- return 0;
- }
-
- udelay(10);
- loop--;
- } while (loop > 0);
-
- IWL_ERR(trans, "Failed to take ownership on secure machine\n");
- return -EIO;
-}
-
static int iwl_pcie_load_cpu_sections_8000(struct iwl_trans *trans,
const struct fw_img *image,
int cpu,
@@ -1010,11 +969,6 @@ static int iwl_pcie_load_given_ucode_8000(struct
iwl_trans *trans,
if (trans->dbg_dest_tlv)
iwl_pcie_apply_destination(trans);
- /* TODO: remove in the next Si step */
- ret = iwl_pcie_rsa_race_bug_wa(trans);
- if (ret)
- return ret;
-
IWL_DEBUG_POWER(trans, "Original WFPM value = 0x%08X\n",
iwl_read_prph(trans, WFPM_GP2));
--
2.11.0
[PATCH 03/25] iwlwifi: pcie: get rid of txq id assignment
From: Sara Sharon
In TVQM mode the queue ID is assigned after enablement.
Get rid of assuming pre-defined TX queue ID in functions
that will be used by TVQM allocation path.
Signed-off-by: Sara Sharon
Signed-off-by: Luca Coelho
---
drivers/net/wireless/intel/iwlwifi/pcie/internal.h | 4 +-
drivers/net/wireless/intel/iwlwifi/pcie/tx-gen2.c | 50 +-
drivers/net/wireless/intel/iwlwifi/pcie/tx.c | 33 +++---
3 files changed, 47 insertions(+), 40 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/internal.h
b/drivers/net/wireless/intel/iwlwifi/pcie/internal.h
index 405ae3799f5e..b9e9e10c32fa 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/internal.h
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/internal.h
@@ -772,9 +772,9 @@ int iwl_queue_space(const struct iwl_txq *q);
int iwl_pcie_apm_stop_master(struct iwl_trans *trans);
void iwl_pcie_conf_msix_hw(struct iwl_trans_pcie *trans_pcie);
int iwl_pcie_txq_init(struct iwl_trans *trans, struct iwl_txq *txq,
- int slots_num, u32 txq_id);
+ int slots_num, bool cmd_queue);
int iwl_pcie_txq_alloc(struct iwl_trans *trans,
- struct iwl_txq *txq, int slots_num, u32 txq_id);
+ struct iwl_txq *txq, int slots_num, bool cmd_queue);
int iwl_pcie_alloc_dma_ptr(struct iwl_trans *trans,
struct iwl_dma_ptr *ptr, size_t size);
void iwl_pcie_free_dma_ptr(struct iwl_trans *trans, struct iwl_dma_ptr *ptr);
diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/tx-gen2.c
b/drivers/net/wireless/intel/iwlwifi/pcie/tx-gen2.c
index 446e837613a5..0bc9522cf364 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/tx-gen2.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/tx-gen2.c
@@ -801,6 +801,27 @@ void iwl_pcie_gen2_txq_unmap(struct iwl_trans *trans, int
txq_id)
iwl_wake_queue(trans, txq);
}
+static void iwl_pcie_gen2_txq_free_memory(struct iwl_trans *trans,
+ struct iwl_txq *txq)
+{
+ struct iwl_trans_pcie *trans_pcie = IWL_TRANS_GET_PCIE_TRANS(trans);
+ struct device *dev = trans->dev;
+
+ /* De-alloc circular buffer of TFDs */
+ if (txq->tfds) {
+ dma_free_coherent(dev,
+ trans_pcie->tfd_size * TFD_QUEUE_SIZE_MAX,
+ txq->tfds, txq->dma_addr);
+ dma_free_coherent(dev,
+ sizeof(*txq->first_tb_bufs) * txq->n_window,
+ txq->first_tb_bufs, txq->first_tb_dma);
+ }
+
+ kfree(txq->entries);
+ iwl_pcie_free_dma_ptr(trans, &txq->bc_tbl);
+ kfree(txq);
+}
+
/*
* iwl_pcie_txq_free - Deallocate DMA queue.
* @txq: Transmit queue to deallocate.
@@ -813,7 +834,6 @@ static void iwl_pcie_gen2_txq_free(struct iwl_trans *trans,
int txq_id)
{
struct iwl_trans_pcie *trans_pcie = IWL_TRANS_GET_PCIE_TRANS(trans);
struct iwl_txq *txq = trans_pcie->txq[txq_id];
- struct device *dev = trans->dev;
int i;
if (WARN_ON(!txq))
@@ -827,23 +847,10 @@ static void iwl_pcie_gen2_txq_free(struct iwl_trans
*trans, int txq_id)
kzfree(txq->entries[i].cmd);
kzfree(txq->entries[i].free_buf);
}
-
- /* De-alloc circular buffer of TFDs */
- if (txq->tfds) {
- dma_free_coherent(dev,
- trans_pcie->tfd_size * TFD_QUEUE_SIZE_MAX,
- txq->tfds, txq->dma_addr);
- dma_free_coherent(dev,
- sizeof(*txq->first_tb_bufs) * txq->n_window,
- txq->first_tb_bufs, txq->first_tb_dma);
- }
-
- kfree(txq->entries);
-
del_timer_sync(&txq->stuck_timer);
- iwl_pcie_free_dma_ptr(trans, &txq->bc_tbl);
- kfree(txq);
+ iwl_pcie_gen2_txq_free_memory(trans, txq);
+
trans_pcie->txq[txq_id] = NULL;
clear_bit(txq_id, trans_pcie->queue_used);
@@ -882,13 +889,14 @@ int iwl_trans_pcie_dyn_txq_alloc(struct iwl_trans *trans,
}
trans_pcie->txq[qid] = txq;
+ trans_pcie->txq[qid]->id = qid;
- ret = iwl_pcie_txq_alloc(trans, txq, TFD_TX_CMD_SLOTS, qid);
+ ret = iwl_pcie_txq_alloc(trans, txq, TFD_TX_CMD_SLOTS, false);
if (ret) {
IWL_ERR(trans, "Tx %d queue init failed\n", qid);
goto error;
}
- ret = iwl_pcie_txq_init(trans, txq, TFD_TX_CMD_SLOTS, qid);
+ ret = iwl_pcie_txq_init(trans, txq, TFD_TX_CMD_SLOTS, false);
if (ret) {
IWL_ERR(trans, "Tx %d queue alloc failed\n", qid);
goto error;
@@ -970,8 +978,7 @@ int iwl_pcie_gen2_tx_init(struct iwl_trans *trans)
return -ENOMEM;
}
trans_pcie->txq[txq_id] = cmd_queue;
- r
[PATCH 08/25] iwlwifi: mvm: work around HW issue with AMSDU de-aggregation
From: Sara Sharon
Seems like HW is reversing addr3 in the MAC header of de-aggregated
AMSDU. Reverse it back.
Signed-off-by: Sara Sharon
Signed-off-by: Luca Coelho
---
drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c
b/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c
index 44072c3c4b5f..c99775039f59 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c
@@ -911,12 +911,19 @@ void iwl_mvm_rx_mpdu_mq(struct iwl_mvm *mvm, struct
napi_struct *napi,
* Our hardware de-aggregates AMSDUs but copies the mac header
* as it to the de-aggregated MPDUs. We need to turn off the
* AMSDU bit in the QoS control ourselves.
+* In addition, HW reverses addr3 - reverse it back.
*/
if ((desc->mac_flags2 & IWL_RX_MPDU_MFLG2_AMSDU) &&
!WARN_ON(!ieee80211_is_data_qos(hdr->frame_control))) {
+ int i;
u8 *qc = ieee80211_get_qos_ctl(hdr);
+ u8 mac_addr[ETH_ALEN];
*qc &= ~IEEE80211_QOS_CTL_A_MSDU_PRESENT;
+
+ for (i = 0; i < ETH_ALEN; i++)
+ mac_addr[i] = hdr->addr3[ETH_ALEN - i - 1];
+ ether_addr_copy(hdr->addr3, mac_addr);
}
if (baid != IWL_RX_REORDER_DATA_INVALID_BAID)
iwl_mvm_agg_rx_received(mvm, baid);
--
2.11.0
[PATCH 05/25] iwlwifi: move to TVQM mode
From: Sara Sharon
In TVQM firmware returns the value of the queue ID and code
should accept it.
The TX queue config API was changed. Move to new API.
This has to be done in parallel in mvm and pcie.
Do not move yet to 512 queues since there are some opens
with enabling it.
Signed-off-by: Sara Sharon
Signed-off-by: Luca Coelho
---
drivers/net/wireless/intel/iwlwifi/iwl-trans.h| 38 ---
drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 3 +
drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 124 --
drivers/net/wireless/intel/iwlwifi/mvm/utils.c| 63 +++
drivers/net/wireless/intel/iwlwifi/pcie/tx-gen2.c | 70 +++-
5 files changed, 202 insertions(+), 96 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-trans.h
b/drivers/net/wireless/intel/iwlwifi/iwl-trans.h
index c87a58ee012a..626e2703a57f 100644
--- a/drivers/net/wireless/intel/iwlwifi/iwl-trans.h
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-trans.h
@@ -531,37 +531,43 @@ struct iwl_trans_txq_scd_cfg {
int frame_limit;
};
+/* Available options for &struct iwl_tx_queue_cfg_cmd */
+enum iwl_tx_queue_cfg_actions {
+ TX_QUEUE_CFG_ENABLE_QUEUE = BIT(0),
+ TX_QUEUE_CFG_TFD_SHORT_FORMAT = BIT(1),
+};
+
/**
* struct iwl_tx_queue_cfg_cmd - txq hw scheduler config command
- * @token: token of the command
* @sta_id: station id
* @tid: tid of the queue
- * @scd_queue: scheduler queue to config
- * @action: 1 queue enable, 0 queue disable
- * @aggregate: 1 aggregated queue, 0 otherwise
- * @tx_fifo: TX fifo
- * @window: BA window size
- * @ssn: SSN for the BA agreement
+ * @flags: Bit 0 - on enable, off - disable, Bit 1 - short TFD format
* @cb_size: size of TFD cyclic buffer. Value is exponent - 3.
* Minimum value 0 (8 TFDs), maximum value 5 (256 TFDs)
* @byte_cnt_addr: address of byte count table
* @tfdq_addr: address of TFD circular buffer
*/
struct iwl_tx_queue_cfg_cmd {
- u8 token;
u8 sta_id;
u8 tid;
- u8 scd_queue;
- u8 action;
- u8 aggregate;
- u8 tx_fifo;
- u8 window;
- __le16 ssn;
- __le16 reserved;
+ __le16 flags;
__le32 cb_size;
__le64 byte_cnt_addr;
__le64 tfdq_addr;
-} __packed; /* TX_QUEUE_CFG_CMD_API_S_VER_1 */
+} __packed; /* TX_QUEUE_CFG_CMD_API_S_VER_2 */
+
+/**
+ * struct iwl_tx_queue_cfg_rsp - response to txq hw scheduler config
+ * @queue_number: queue number assigned to this RA -TID
+ * @flags: set on failure
+ * @write_pointer: initial value for write pointer
+ */
+struct iwl_tx_queue_cfg_rsp {
+ __le16 queue_number;
+ __le16 flags;
+ __le16 write_pointer;
+ __le16 reserved;
+} __packed; /* TX_QUEUE_CFG_RSP_API_S_VER_2 */
/**
* struct iwl_trans_ops - transport specific operations
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
b/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
index 70abc6cd3b47..a22fe45eecc4 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
@@ -1699,6 +1699,9 @@ static inline bool iwl_mvm_vif_low_latency(struct
iwl_mvm_vif *mvmvif)
void iwl_mvm_enable_txq(struct iwl_mvm *mvm, int queue, int mac80211_queue,
u16 ssn, const struct iwl_trans_txq_scd_cfg *cfg,
unsigned int wdg_timeout);
+int iwl_mvm_tvqm_enable_txq(struct iwl_mvm *mvm, int mac80211_queue,
+ u8 sta_id, u8 tid, unsigned int timeout);
+
/*
* Disable a TXQ.
* Note that in non-DQA mode the %mac80211_queue and %tid params are ignored.
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
b/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
index 20a8f529760f..a58f0cb291bd 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
@@ -702,6 +702,41 @@ int iwl_mvm_scd_queue_redirect(struct iwl_mvm *mvm, int
queue, int tid,
return ret;
}
+static int iwl_mvm_sta_alloc_queue_tvqm(struct iwl_mvm *mvm,
+ struct ieee80211_sta *sta, u8 ac,
+ int tid)
+{
+ struct iwl_mvm_sta *mvmsta = iwl_mvm_sta_from_mac80211(sta);
+ unsigned int wdg_timeout =
+ iwl_mvm_get_wd_timeout(mvm, mvmsta->vif, false, false);
+ u8 mac_queue = mvmsta->vif->hw_queue[ac];
+ int queue = -1;
+
+ lockdep_assert_held(&mvm->mutex);
+
+ IWL_DEBUG_TX_QUEUES(mvm,
+ "Allocating queue for sta %d on tid %d\n",
+ mvmsta->sta_id, tid);
+ queue = iwl_mvm_tvqm_enable_txq(mvm, mac_queue, mvmsta->sta_id, tid,
+ wdg_timeout);
+ if (queue < 0)
+ return queue;
+
+ IWL_DEBUG_TX_QUEUES(mvm, "Allocated queue is %d\n", queue);
+
+ spin_lock_bh(&mvmsta->lock);
+ mvmsta->tid_data[tid].txq_id = queue;
+ mvmst
[PATCH 09/25] iwlwifi: mvm: change TX_CMD_SEC_KEY_FROM_TABLE value
From: David Spinadel
Change the value of TX_CMD_SEC_KEY_FROM_TABLE flag
in TX_CMD security flags to accommodate a FW API change.
Bump min API for 9000 series devices to 30 to keep the driver aligned
aligned the FW.
Signed-off-by: David Spinadel
Signed-off-by: Luca Coelho
---
drivers/net/wireless/intel/iwlwifi/iwl-9000.c | 2 +-
drivers/net/wireless/intel/iwlwifi/mvm/fw-api-tx.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-9000.c
b/drivers/net/wireless/intel/iwlwifi/iwl-9000.c
index d265b279b2ca..110ceefccc15 100644
--- a/drivers/net/wireless/intel/iwlwifi/iwl-9000.c
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-9000.c
@@ -58,7 +58,7 @@
#define IWL9000_UCODE_API_MAX 30
/* Lowest firmware API version supported */
-#define IWL9000_UCODE_API_MIN 17
+#define IWL9000_UCODE_API_MIN 30
/* NVM versions */
#define IWL9000_NVM_VERSION0x0a1d
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/fw-api-tx.h
b/drivers/net/wireless/intel/iwlwifi/mvm/fw-api-tx.h
index e9f055706a6f..81b98915b1a4 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/fw-api-tx.h
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/fw-api-tx.h
@@ -174,7 +174,7 @@ enum iwl_tx_cmd_sec_ctrl {
TX_CMD_SEC_EXT = 0x04,
TX_CMD_SEC_GCMP = 0x05,
TX_CMD_SEC_KEY128 = 0x08,
- TX_CMD_SEC_KEY_FROM_TABLE = 0x08,
+ TX_CMD_SEC_KEY_FROM_TABLE = 0x10,
};
/* TODO: how does these values are OK with only 16 bit variable??? */
--
2.11.0
[PATCH 07/25] iwlwifi: mvm: do not turn on RX_FLAG_AMSDU_MORE
From: Sara Sharon This flag is used for mac80211 reordering. As we do reordering ourselves, turning it on is misleading and pointless. Signed-off-by: Sara Sharon Signed-off-by: Luca Coelho --- drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c b/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c index 29c9c56ed3fa..44072c3c4b5f 100644 --- a/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c +++ b/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c @@ -917,9 +917,6 @@ void iwl_mvm_rx_mpdu_mq(struct iwl_mvm *mvm, struct napi_struct *napi, u8 *qc = ieee80211_get_qos_ctl(hdr); *qc &= ~IEEE80211_QOS_CTL_A_MSDU_PRESENT; - if (!(desc->amsdu_info & - IWL_RX_MPDU_AMSDU_LAST_SUBFRAME)) - rx_status->flag |= RX_FLAG_AMSDU_MORE; } if (baid != IWL_RX_REORDER_DATA_INVALID_BAID) iwl_mvm_agg_rx_received(mvm, baid); -- 2.11.0
[PATCH 06/25] iwlwifi: mvm: remove unneeded reg write in iwl_mvm_up()
From: Liad Kaufman Not only that this write is not needed (as FW does this itself), on newer HW this register is write protected so trying to write there will cause problems. Signed-off-by: Liad Kaufman Signed-off-by: Luca Coelho --- drivers/net/wireless/intel/iwlwifi/iwl-prph.h | 3 --- drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 4 2 files changed, 7 deletions(-) diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-prph.h b/drivers/net/wireless/intel/iwlwifi/iwl-prph.h index e1aa1f7836fc..4bceaccee62f 100644 --- a/drivers/net/wireless/intel/iwlwifi/iwl-prph.h +++ b/drivers/net/wireless/intel/iwlwifi/iwl-prph.h @@ -294,9 +294,6 @@ /*** END TX SCHEDULER */ -/* tcp checksum offload */ -#define RX_EN_CSUM (0x00a00d88) - /* Oscillator clock */ #define OSC_CLK(0xa04068) #define OSC_CLK_FORCE_CONTROL (0x8) diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/fw.c b/drivers/net/wireless/intel/iwlwifi/mvm/fw.c index 2a4c952ef01a..bfccbadd1a6e 100644 --- a/drivers/net/wireless/intel/iwlwifi/mvm/fw.c +++ b/drivers/net/wireless/intel/iwlwifi/mvm/fw.c @@ -1475,10 +1475,6 @@ int iwl_mvm_up(struct iwl_mvm *mvm) goto error; } - if (iwl_mvm_is_csum_supported(mvm) && - mvm->cfg->features & NETIF_F_RXCSUM) - iwl_trans_write_prph(mvm->trans, RX_EN_CSUM, 0x3); - /* allow FW/transport low power modes if not during restart */ if (!test_bit(IWL_MVM_STATUS_IN_HW_RESTART, &mvm->status)) iwl_mvm_unref(mvm, IWL_MVM_REF_UCODE_DOWN); -- 2.11.0
[PATCH 04/25] iwlwifi: mvm: support new TX response for TVQM
From: Sara Sharon
In TVQM mode the TX responses were changed to include
queue number since legacy TX queue number retrieval cannot
be scaled up to 512 queues.
Support this change.
Signed-off-by: Sara Sharon
Signed-off-by: Luca Coelho
---
drivers/net/wireless/intel/iwlwifi/mvm/fw-api-tx.h | 42 ++
drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c | 4 ++-
drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 10 ++
drivers/net/wireless/intel/iwlwifi/mvm/tx.c| 34 +++---
4 files changed, 61 insertions(+), 29 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/fw-api-tx.h
b/drivers/net/wireless/intel/iwlwifi/mvm/fw-api-tx.h
index f83ee6e760d0..e9f055706a6f 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/fw-api-tx.h
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/fw-api-tx.h
@@ -548,9 +548,11 @@ struct agg_tx_status {
* @tlc_info: TLC rate info
* @ra_tid: bits [3:0] = ra, bits [7:4] = tid
* @frame_ctrl: frame control
+ * @tx_queue: TX queue for this response
* @status: for non-agg: frame status TX_STATUS_*
* for agg: status of 1st frame, AGG_TX_STATE_*; other frame status fields
* follow this one, up to frame_count.
+ * For version 6 TX response isn't received for aggregation at all.
*
* After the array of statuses comes the SSN of the SCD. Look at
* %iwl_mvm_get_scd_ssn for more details.
@@ -577,9 +579,17 @@ struct iwl_mvm_tx_resp {
u8 tlc_info;
u8 ra_tid;
__le16 frame_ctrl;
-
- struct agg_tx_status status;
-} __packed; /* TX_RSP_API_S_VER_3 */
+ union {
+ struct {
+ struct agg_tx_status status;
+ } v3;/* TX_RSP_API_S_VER_3 */
+ struct {
+ __le16 tx_queue;
+ __le16 reserved2;
+ struct agg_tx_status status;
+ } v6;
+ };
+} __packed; /* TX_RSP_API_S_VER_6 */
/**
* struct iwl_mvm_ba_notif - notifies about reception of BA
@@ -619,11 +629,14 @@ struct iwl_mvm_ba_notif {
* struct iwl_mvm_compressed_ba_tfd - progress of a TFD queue
* @q_num: TFD queue number
* @tfd_index: Index of first un-acked frame in the TFD queue
+ * @scd_queue: For debug only - the physical queue the TFD queue is bound to
*/
struct iwl_mvm_compressed_ba_tfd {
- u8 q_num;
- u8 reserved;
+ __le16 q_num;
__le16 tfd_index;
+ u8 scd_queue;
+ u8 reserved;
+ __le16 reserved2;
} __packed; /* COMPRESSED_BA_TFD_API_S_VER_1 */
/**
@@ -799,25 +812,6 @@ struct iwl_tx_path_flush_cmd {
__le16 reserved;
} __packed; /* TX_PATH_FLUSH_CMD_API_S_VER_1 */
-/**
- * iwl_mvm_get_scd_ssn - returns the SSN of the SCD
- * @tx_resp: the Tx response from the fw (agg or non-agg)
- *
- * When the fw sends an AMPDU, it fetches the MPDUs one after the other. Since
- * it can't know that everything will go well until the end of the AMPDU, it
- * can't know in advance the number of MPDUs that will be sent in the current
- * batch. This is why it writes the agg Tx response while it fetches the MPDUs.
- * Hence, it can't know in advance what the SSN of the SCD will be at the end
- * of the batch. This is why the SSN of the SCD is written at the end of the
- * whole struct at a variable offset. This function knows how to cope with the
- * variable offset and returns the SSN of the SCD.
- */
-static inline u32 iwl_mvm_get_scd_ssn(struct iwl_mvm_tx_resp *tx_resp)
-{
- return le32_to_cpup((__le32 *)&tx_resp->status +
- tx_resp->frame_count) & 0xfff;
-}
-
/* Available options for the SCD_QUEUE_CFG HCMD */
enum iwl_scd_cfg_actions {
SCD_CFG_DISABLE_QUEUE = 0x0,
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c
b/drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c
index 2473f4bd6238..edaaa3bcf0b2 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c
@@ -1442,6 +1442,7 @@ void iwl_mvm_rx_beacon_notif(struct iwl_mvm *mvm,
struct iwl_mvm_tx_resp *beacon_notify_hdr;
struct ieee80211_vif *csa_vif;
struct ieee80211_vif *tx_blocked_vif;
+ struct agg_tx_status *agg_status;
u16 status;
lockdep_assert_held(&mvm->mutex);
@@ -1449,7 +1450,8 @@ void iwl_mvm_rx_beacon_notif(struct iwl_mvm *mvm,
beacon_notify_hdr = &beacon->beacon_notify_hdr;
mvm->ap_last_beacon_gp2 = le32_to_cpu(beacon->gp2);
- status = le16_to_cpu(beacon_notify_hdr->status.status) & TX_STATUS_MSK;
+ agg_status = iwl_mvm_get_agg_status(mvm, beacon_notify_hdr);
+ status = le16_to_cpu(agg_status->status) & TX_STATUS_MSK;
IWL_DEBUG_RX(mvm,
"beacon status %#x retries:%d tsf:0x%16llX gp2:0x%X
rate:%d\n",
status, beacon_notify_hdr->failure_frame,
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
b/drivers/net/wireless/in
[PATCH 02/25] iwlwifi: mvm: fix accessing fw_id_to_mac_id
From: Sara Sharon
Access should be by rcu_dereference. Issue was found by sparse.
Fixes: 65e254821cee ("iwlwifi: mvm: use firmware station PM notification for
AP_LINK_PS")
Signed-off-by: Sara Sharon
Signed-off-by: Luca Coelho
---
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
index 5f9d5339fc3d..26cf3dfcc108 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
@@ -2424,7 +2424,7 @@ void iwl_mvm_sta_pm_notif(struct iwl_mvm *mvm, struct
iwl_rx_cmd_buffer *rxb)
return;
rcu_read_lock();
- sta = mvm->fw_id_to_mac_id[notif->sta_id];
+ sta = rcu_dereference(mvm->fw_id_to_mac_id[notif->sta_id]);
if (WARN_ON(IS_ERR_OR_NULL(sta))) {
rcu_read_unlock();
return;
--
2.11.0
[PATCH 01/25] iwlwifi: mvm: remove unnecessary label in iwl_mvm_handle_rx_statistics()
From: Luca Coelho
The "invalid" label was a bit ugly and unnecessary. Remove it.
Signed-off-by: Luca Coelho
---
drivers/net/wireless/intel/iwlwifi/mvm/rx.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/rx.c
b/drivers/net/wireless/intel/iwlwifi/mvm/rx.c
index 655bd1384158..eab6e2ad62e1 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/rx.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/rx.c
@@ -660,8 +660,11 @@ void iwl_mvm_handle_rx_statistics(struct iwl_mvm *mvm,
else
expected_size = sizeof(struct iwl_notif_statistics_v10);
- if (iwl_rx_packet_payload_len(pkt) != expected_size)
- goto invalid;
+ if (iwl_rx_packet_payload_len(pkt) != expected_size) {
+ IWL_ERR(mvm, "received invalid statistics size (%d)!\n",
+ iwl_rx_packet_payload_len(pkt));
+ return;
+ }
data.mac_id = stats->rx.general.mac_id;
data.beacon_filter_average_energy =
@@ -714,12 +717,6 @@ void iwl_mvm_handle_rx_statistics(struct iwl_mvm *mvm,
sta->avg_energy = energy[i];
}
rcu_read_unlock();
-
- return;
-
- invalid:
- IWL_ERR(mvm, "received invalid statistics size (%d)!\n",
- iwl_rx_packet_payload_len(pkt));
}
void iwl_mvm_rx_statistics(struct iwl_mvm *mvm, struct iwl_rx_cmd_buffer *rxb)
--
2.11.0
[PATCH 00/25] iwlwifi: updates intended for v4.12 2017-04-19
From: Luca Coelho Hi, This is the third patch set intended for v4.12. These are the changes: * Heavy work for the A000 device series; * Some cleanup patches; * A couple of fixes; * Start supporting FW API version 31; * Geographical SAR support; * Support a few new PCI device IDs; As usual, I'm pushing this to a pending branch, for kbuild bot, and will send a pull-request later. Please review. Cheers, Luca. David Spinadel (1): iwlwifi: mvm: change TX_CMD_SEC_KEY_FROM_TABLE value Emmanuel Grumbach (3): iwlwifi: mvm: provide the actual number of frames for the SP len iwlwifi: split the handler and the wake parts of the notification infra iwlwifi: bump API to 31 Haim Dreyfuss (1): iwlwifi: mvm: add GEO_TX_POWER_LIMIT cmd for geographic tx power table Liad Kaufman (2): iwlwifi: mvm: remove unneeded reg write in iwl_mvm_up() iwlwifi: a000: fix memory offsets and lengths Luca Coelho (2): iwlwifi: mvm: remove unnecessary label in iwl_mvm_handle_rx_statistics() iwlwifi: pcie: remove RSA race workaround Sara Sharon (15): iwlwifi: mvm: fix accessing fw_id_to_mac_id iwlwifi: pcie: get rid of txq id assignment iwlwifi: mvm: support new TX response for TVQM iwlwifi: move to TVQM mode iwlwifi: mvm: do not turn on RX_FLAG_AMSDU_MORE iwlwifi: mvm: work around HW issue with AMSDU de-aggregation iwlwifi: mvm: ignore BAID for SN smaller than SSN iwlwifi: mvm: support change to a000 smem API iwlwifi: support a000 CDB product iwlwifi: mvm: support init extended command iwlwifi: mvm: disable RX queue notification for a000 devices iwlwifi: mvm: dump frames early on invalid rate iwlwifi: mvm: flip address 4 of AMSDU frames iwlwifi: mvm: support changing band for phy context iwlwifi: mvm: allow block ack response without data Tzipi Peres (1): iwlwifi: add four new 8265 and 8275 series PCI IDs drivers/net/wireless/intel/iwlwifi/iwl-8000.c | 4 +- drivers/net/wireless/intel/iwlwifi/iwl-9000.c | 4 +- drivers/net/wireless/intel/iwlwifi/iwl-a000.c | 28 +- drivers/net/wireless/intel/iwlwifi/iwl-config.h| 5 +- .../net/wireless/intel/iwlwifi/iwl-notif-wait.c| 10 +- .../net/wireless/intel/iwlwifi/iwl-notif-wait.h| 25 +- drivers/net/wireless/intel/iwlwifi/iwl-prph.h | 5 +- drivers/net/wireless/intel/iwlwifi/iwl-trans.h | 38 +-- .../net/wireless/intel/iwlwifi/mvm/fw-api-power.h | 43 ++- drivers/net/wireless/intel/iwlwifi/mvm/fw-api-tx.h | 44 ++-- drivers/net/wireless/intel/iwlwifi/mvm/fw-api.h| 67 - drivers/net/wireless/intel/iwlwifi/mvm/fw-dbg.c| 287 - drivers/net/wireless/intel/iwlwifi/mvm/fw.c| 184 +++-- drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c | 4 +- drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 5 +- drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 31 ++- drivers/net/wireless/intel/iwlwifi/mvm/ops.c | 2 + drivers/net/wireless/intel/iwlwifi/mvm/phy-ctxt.c | 21 +- drivers/net/wireless/intel/iwlwifi/mvm/rx.c| 26 +- drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c | 65 - drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 127 ++--- drivers/net/wireless/intel/iwlwifi/mvm/tx.c| 40 ++- drivers/net/wireless/intel/iwlwifi/mvm/utils.c | 63 +++-- drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 11 +- drivers/net/wireless/intel/iwlwifi/pcie/internal.h | 4 +- drivers/net/wireless/intel/iwlwifi/pcie/trans.c| 46 drivers/net/wireless/intel/iwlwifi/pcie/tx-gen2.c | 118 + drivers/net/wireless/intel/iwlwifi/pcie/tx.c | 33 ++- 28 files changed, 908 insertions(+), 432 deletions(-) -- 2.11.0
Re: [PATCH V2 02/10] nl80211: allow multiple active scheduled scan requests
On 4/18/2017 10:55 AM, Johannes Berg wrote: On Tue, 2017-04-18 at 10:53 +0200, Johannes Berg wrote: Hi Arend, Overall this looks good, and I've almost applied it - but I have a question on this patch. You have this list: + struct list_head sched_scan_req_list; struct cfg80211_sched_scan_request __rcu *sched_scan_req; but you kept this. In fact, it's even still *used*. I don't understand that part. Also, you used RCU primitives for the new list, but you never actually used them - except in one place (in nl80211_stop_sched_scan) where it's actually not needed at all and the _rcu should be removed (since it holds the lock) What's up with that? Actually, I think I see what's up - you simply forgot to remove the sched_scan_req member, and then didn't realize that it was still used in nl80211_netlink_notify(), and that's the place that *does* need the RCU stuff. Yes. Sorry for screwing it up. Will rebase the series and fix it. Regards, Arend
Re: [v2,1/3] ath9k: Support channels in licensed bands
On 04/18/2017 09:33 AM, Steve deRosier wrote: Hi, On Tue, Apr 18, 2017 at 7:50 AM, Simon Wunderlich mailto:s...@simonwunderlich.de>> wrote: Hi, On Tuesday, April 18, 2017 2:36:54 PM CEST Kalle Valo wrote: > Simon Wunderlich mailto:s...@simonwunderlich.de>> wrote: > > From: Ben Greear mailto:gree...@candelatech.com>> > > > > Many chips support channels in licensed bands. Add support for those, > > along with a corresponding kernel config option to disable them by ... > I am not sure that we should support unlicensed bands in Linux and hence > hesitant to apply these. My view is that due to regulatory restrictions we > should not make it too easy to use unlicensed bands. But I'm open for > discussion, this is a challenging area and my knowledge here is limited. ... In my personal view, we have quite a few obstacles which I consider "enough", but would be interesting to hear others opinions ... I'll throw in my 2-cents. This patch is treading on very dangerous ground. I can't speak to other regulatory environments, but at least the FCC is cracking down on even the possibility that anyone can operate a WiFi device outside the regulatory bounds. These patches make it slightly easier to use the licensed bands, but no one can accidentally use them due to the regdb and other constaints in these patches. So, I don't think these patches offer any fundamental new vulnerability that should concern the FCC. After all, someone who really wants to do evil can find and apply the patches without undue effort, and it could easily be that those applying the patches would then make it even easier to abuse the new channels due to laziness or poor coding choices. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com
Re: [v2,1/3] ath9k: Support channels in licensed bands
Hi, (sorry, resending due to my not noticing that gmail had changed my default compose mode to HTML. Why does it randomly do that sometimes?!?!) On Tue, Apr 18, 2017 at 7:50 AM, Simon Wunderlich wrote: > > Hi, > > On Tuesday, April 18, 2017 2:36:54 PM CEST Kalle Valo wrote: > > Simon Wunderlich wrote: > > > From: Ben Greear > > > > > > Many chips support channels in licensed bands. Add support for those, > > > along with a corresponding kernel config option to disable them by ... > > I am not sure that we should support unlicensed bands in Linux and hence > > hesitant to apply these. My view is that due to regulatory restrictions we > > should not make it too easy to use unlicensed bands. But I'm open for > > discussion, this is a challenging area and my knowledge here is limited. > ... > > > In my personal view, we have quite a few obstacles which I consider "enough", > but would be interesting to hear others opinions ... > I'll throw in my 2-cents. This patch is treading on very dangerous ground. I can't speak to other regulatory environments, but at least the FCC is cracking down on even the possibility that anyone can operate a WiFi device outside the regulatory bounds. I know this is going to be TLDR, but please bear with me. The testing groups are (incorrectly in my opinion) interpreting the current FCC guidelines to be that no one with the device could ever get in and change it to operate outside the permitted frequencies and powers. And I'm not even talking about having a command-line interface and issuing a command as sudo. To the degree that if it's even possible to recompile a driver or otherwise change the source code and put that changed code on the device they're denying modular certifications. The end result is we have a lot of chip manufacturers' scrambling to do things like require eeproms, signed board files, etc. Module manufacturers (think of things like Laird's msd45nbt, msd50nbt, or the Sterling LWB) are scrambling even harder trying to think of ways to force chips to fail to function if they aren't using their regulatory file or other strategies to manage to fulfill their customer's needs while still getting it to pass through the regulatory agencies. @Simon, with much respect: With the current regulatory environment, those obstacles which you are considering "enough", the testing boards aren't considering "enough". I happen to agree with you that it's more than enough. And just because it's possible for a customer of a module who is integrating a device to operate it out of the regulatory bounds, doesn't mean it shouldn't get the modular certification. In fact, depending on the exact situations, it might be _necessary_ for them to make setting adjustments for their products. And the reality is, anyone with a soldering iron can make the thing operate outside the regulatory domain anyway. The whole thing just makes it impossible for modular operators and for the Linux community instead of solving any real problems. What's going on in the FCC regulatory environment has stark implications that those of us in the Linux wireless community can't afford to ignore anymore. This is a direct threat to mac80211, Open Source and the ability to do anything sane with our devices. And even if you're more practical (like me) about these things, think of it: each manufacturer being forced to make it harder and harder for anyone to change the code or work with their chips - you think it's hard to work with a Marvell or Broadcom chip right now with minimal and non-accessible documentation? Imagine how it's going to be when everything is locked behind Secure Boot and signed proprietary drivers where the hardware itself is locked so it can only work with the (bad quality and buggy) closed-source driver. I brought this up at Wireless Summit at the last LPC and basically got a room of shrugs. Admittedly I wasn't terribly eloquent on the subject so it's solely my fault I didn't impress. I know that most of us are representing various companies (though not I anymore) and each has their own proprietary way to deal with it and no one wants to rock the boat*. And many of the people in the room are just implementing code to make stuff work and don't actually know that much depth about the regulatory environment in which we're working. But we all need to get together and come up with a better solution. What's going on right now doesn't serve our interests. I know it's an agenda being pushed by someone and while I have a few suspects I really don't know for sure. In any case, who it's being pushed by and for doesn't matter too much - we as a community aren't pushing back as a cohesive group; we aren't even talking about it! And so, we're going to get the short end of the stick. So, with re: to the patch, that's the environment it will live in. Personally I don't really care one way or another specifically to what Simon's patch does. But he opened the door to discussion and it seemed like an appro
Re: [v2,1/3] ath9k: Support channels in licensed bands
Hi, On Tuesday, April 18, 2017 2:36:54 PM CEST Kalle Valo wrote: > Simon Wunderlich wrote: > > From: Ben Greear > > > > Many chips support channels in licensed bands. Add support for those, > > along with a corresponding kernel config option to disable them by > > default. Note that these channels are not selectable even if the > > option has been compiled unless the user modifies the regulatory > > database to explicitly enable the corresponding channels. > > > > NOTE: These channels must not be used in most regulatory > > domains unless you have a license from the FCC or similar! > > > > Signed-off-by: Ben Greear > > [Hide this support behind a Kconfig option] > > Signed-off-by: Julian Calaby > > [only use the 20 mhz channels, add 5 ghz, change to 4.9ghz to licensed > > bands, simplify] Signed-off-by: Simon Wunderlich > > Signed-off-by: Mathias Kretschmer > > I am not sure that we should support unlicensed bands in Linux and hence > hesitant to apply these. My view is that due to regulatory restrictions we > should not make it too easy to use unlicensed bands. But I'm open for > discussion, this is a challenging area and my knowledge here is limited. thanks for your reply! I agree that we should not make it too easy, and therefore there are the following "obstacles" which should avoid accidental use of license bands: * we have the kernel CONFIG option which features a big fat warning * regulatory database must be tampered with to enabel the channels. In distributions, the regdb also gets signed. There is also the "internal regdb" CONFIG option if you compile your own kernel (rarely used, except for OpenWRT). In each case, a user must actively add the 4.9 GHz channels into it, because they are not included in the default regdb (and this should not change). * CFG80211_CERTIFICATION_ONUS is also required, which also says "you are on your own". I had a comparison with ath5k, which also allows using those channels without at least the special configuration option (there is one enabling even more channels). The regdb "obstacle" is in place as well. However, ath5k is for very old chips and therefore the threat is limited. In my personal view, we have quite a few obstacles which I consider "enough", but would be interesting to hear others opinions ... Cheers, Simon signature.asc Description: This is a digitally signed message part.
Re: [v2,1/3] ath9k: Support channels in licensed bands
Simon Wunderlich wrote: > From: Ben Greear > > Many chips support channels in licensed bands. Add support for those, > along with a corresponding kernel config option to disable them by > default. Note that these channels are not selectable even if the > option has been compiled unless the user modifies the regulatory > database to explicitly enable the corresponding channels. > > NOTE: These channels must not be used in most regulatory > domains unless you have a license from the FCC or similar! > > Signed-off-by: Ben Greear > [Hide this support behind a Kconfig option] > Signed-off-by: Julian Calaby > [only use the 20 mhz channels, add 5 ghz, change to 4.9ghz to licensed bands, > simplify] > Signed-off-by: Simon Wunderlich > Signed-off-by: Mathias Kretschmer I am not sure that we should support unlicensed bands in Linux and hence hesitant to apply these. My view is that due to regulatory restrictions we should not make it too easy to use unlicensed bands. But I'm open for discussion, this is a challenging area and my knowledge here is limited. -- https://patchwork.kernel.org/patch/9641105/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: pull-request: iwlwifi-next 2017-04-13
Luca Coelho writes: > On Tue, 2017-04-18 at 06:56 +, Kalle Valo wrote: >> Kalle Valo writes: >> >> > Luca Coelho writes: >> > >> > > git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git >> > > tags/iwlwifi-next-for-kalle-2017-04-13 >> > > >> > > for you to fetch changes up to 87d0e1af9db3bff4ec2f68fd4d032f89c23867a4: >> > > >> > > iwlwifi: mvm: separate queue mapping from queue enablement >> > > (2017-04-11 15:25:00 +0300) >> > > >> > > >> > > Patches intended for v4.12: >> > > >> > > * Some small fixes here and there; >> > > * The usual cleanups and small improvements; >> > > * Work to support A000 devices continues; >> > > * New FW API version; >> > > * Some debugging improvements; >> > > >> > > >> > >> > This one has few conflicts. I can fix those manually, but can you give >> > some guidance how? >> >> I think I got it now, see below for the diff I did. Can you please >> check that? >> >> The resolution is also in the pending branch: >> >> https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git/log/?h=pending > > > Yes, looks good! Thanks for resolving it and sorry for not foreseeing it > to give you a heads up. Good, thanks. I pushed it to master branch now. -- Kalle Valo
[PATCH] cfg80211: Fix dfs state propagation for non-DFS center channel
When part of a bigger bandwidth (160 MHz) channel falls in DFS
channel range it is possible that the center frequency may not
necessarily be a radar channel. Remove the sanity check on channel
flag for IEEE80211_CHAN_RADAR in regulatory_propagate_dfs_state(),
this should fix the dfs state propagation for non-DFS center freq
which has DFS channels in it's bandwidth, should also fix unnecessary
WARN_ON() spam in regulatory_propagate_dfs_state().
Fixes: 8976672736d6 ("cfg80211: Share Channel DFS state across wiphys of same
DFS domain")
Reported-by: Johannes Berg
Signed-off-by: Vasanthakumar Thiagarajan
---
net/wireless/reg.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index a38f315..5fae296 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -3244,9 +3244,6 @@ void regulatory_propagate_dfs_state(struct wiphy *wiphy,
if (WARN_ON(!cfg80211_chandef_valid(chandef)))
return;
- if (WARN_ON(!(chandef->chan->flags & IEEE80211_CHAN_RADAR)))
- return;
-
list_for_each_entry(rdev, &cfg80211_rdev_list, list) {
if (wiphy == &rdev->wiphy)
continue;
--
1.9.1
Re: [PATCH V2 3/3] cfg80211: Share Channel DFS state across wiphys of same DFS domain
On Tuesday 18 April 2017 04:20 PM, Johannes Berg wrote:
>
>> +void regulatory_propagate_dfs_state(struct wiphy *wiphy,
>> +struct cfg80211_chan_def
>> *chandef,
>> +enum nl80211_dfs_state
>> dfs_state,
>> +enum nl80211_radar_event event)
>> +{
>> +struct cfg80211_registered_device *rdev;
>> +
>> +ASSERT_RTNL();
>> +
>> +if (WARN_ON(!cfg80211_chandef_valid(chandef)))
>> +return;
>> +
>> +if (WARN_ON(!(chandef->chan->flags & IEEE80211_CHAN_RADAR)))
>> +return;
>
>
> This warn on reliably triggers for me when I run the "ap_vht160" hwsim
> test from wpa_supplicant.
>
> I think there might be some confusion about this when parts of the 160
> MHz channel require radar and parts don't? But I haven't looked into
> this at all.
Correct, when some part of a bigger bandwidth channel falls in DFS channel range
channel definition of that channel's center freq is may not be a radar channel
and
bailing out based on the channel flag there is not right.
Sorry for the bug and thanks for reporting it.
>
> Please send me a fix ASAP so Jouni doesn't shout at me for test
> failures :)
Sure.
Vasanth
Re: [PATCH v3] staging: wilc1000: New cfg packet format in handle_set_wfi_drv_handler
On Thu, Apr 13, 2017 at 08:14:23AM +0530, Aditya Shankar wrote: > On Tue, 11 Apr 2017 19:35:46 +0200 > Greg KH wrote: > > > On Tue, Apr 11, 2017 at 10:11:43PM +0530, Aditya Shankar wrote: > > > Change the config packet format used in handle_set_wfi_drv_handler() > > > to align the host driver with the new format used in the wilc firmware. > > > > So does this break devices with "old" firmware? > > > > Where is the "new" firmware? What is enforcing the usage only of new > > firmware? > > > > thanks, > > > > greg k-h > > Yes, this new change would break devices with firmware older than ver > 14.2(released on our vendor tree in March 2016). The older firmware in the > linux-firmware repository is close to 2 years old and not being used with the > staging driver even before this change was submitted. Developers picked up > the firmware mostly from one of our vendor trees on github. > > To resolve this confusion about firmware location, I submitted a patch to > linux-firmware to make the latest firmware available through this channel. > Below are the details. The driver currently does not enforce usage of new > firmware but would fail to properly configure the older firmware. Please put that information in the changelog text for the next version of this patch that you submit. thanks, greg k-h
Re: [PATCH v3] staging: wilc1000: New cfg packet format in handle_set_wfi_drv_handler
On Tue, Apr 11, 2017 at 10:11:43PM +0530, Aditya Shankar wrote:
> Change the config packet format used in handle_set_wfi_drv_handler()
> to align the host driver with the new format used in the wilc firmware.
>
> The change updates the format in which the host driver provides the
> firmware with the drv_handler index and also uses two new
> fields viz. "mode" and 'name" in the config packet along with this index
> to directly provide details about the interface and its mode to the
> firmware instead of having multiple if-else statements in the host driver
> to decide which interface to configure.
>
> Signed-off-by: Aditya Shankar
> Reviewed-by: Arend Van Spriel
> ---
> Change in v2: Fix build warning
> Change in v3: Address review comments from v2
> ---
> drivers/staging/wilc1000/host_interface.c | 48
> ++-
> drivers/staging/wilc1000/host_interface.h | 9 -
> drivers/staging/wilc1000/linux_wlan.c | 37 +
> drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 2 +-
> drivers/staging/wilc1000/wilc_wfi_netdevice.h | 1 +
> drivers/staging/wilc1000/wilc_wlan_if.h | 2 +-
> 6 files changed, 59 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/staging/wilc1000/host_interface.c
> b/drivers/staging/wilc1000/host_interface.c
> index c3a8af0..7352488 100644
> --- a/drivers/staging/wilc1000/host_interface.c
> +++ b/drivers/staging/wilc1000/host_interface.c
> @@ -334,14 +334,39 @@ static void handle_set_wfi_drv_handler(struct wilc_vif
> *vif,
> {
> int ret = 0;
> struct wid wid;
> + u8 *currbyte, *buffer;
> + struct host_if_drv *hif_drv = NULL;
> +
> + if (!vif->hif_drv)
> + return;
> +
> + if (!hif_drv_handler)
> + return;
> +
> + hif_drv = vif->hif_drv;
> + buffer = kzalloc(DRV_HANDLER_SIZE, GFP_ATOMIC);
> +
> + if (!buffer)
> + return;
Test on the line right after allocation.
And there is no way to return an error from this function? That seems
bad.
And why do you need GFP_ATOMIC?
And finally, where do you free this buffer?
> @@ -3449,8 +3477,10 @@ void wilc_network_info_received(struct wilc *wilc, u8
> *buffer, u32 length)
>
> id = ((buffer[length - 4]) | (buffer[length - 3] << 8) | (buffer[length
> - 2] << 16) | (buffer[length - 1] << 24));
> vif = wilc_get_vif_from_idx(wilc, id);
> +
> if (!vif)
> return;
> +
> hif_drv = vif->hif_drv;
>
> if (!hif_drv || hif_drv == terminated_handle) {
Unneeded whitespace changes. Don't do that in a patch that does other
things.
thanks,
greg k-h
Re: [RFC 1/3] bpf/wireless: add wifimon program type
So actually, come to think of it ... > > The mapping in samples/bpf/bpf_helpers.h, for example, for > > mentioned > > bpf_skb_load_bytes() would also work out of the box, since it takes > > a > > void *ctx as an argument, so you can just pass the __wifi_sk_buff > > pointer as ctx there from program side. > > Hah. That's what I was missing - I always assumed the argument was > "struct __sk_buff *" without ever checking that assumption. Given this, I think I'll actually make a __wifi_sk_buff. > The thing is that __wifi_sk_buff doesn't have much information that's > generally useful available Because I just realized that this isn't true. To make sense of the SKB beyond the 802.11 header, which may not be possible at all though due to encryption happening in software later, it will have to know a few things like whether or not it was encrypted and if the IV was stripped etc. Actually, perhaps we should just restrict it to just look at the header ;-) johannes
Re: [RFC 1/3] bpf/wireless: add wifimon program type
On Tue, 2017-04-18 at 12:58 +0200, Daniel Borkmann wrote:
>
> Note that for skbs the data / data_end model (aka direct read /
> write) is also supported. There's also a bpf_skb_pull_data() helper
> that pulls in data from non-linear parts if necessary (f.e. if data /
> data_end test in the program fails). bpf_skb_load_bytes() is fine as
> well, comes with function call overhead, though, but depending on the
> use-case that might be just fine, too.
Yeah. I did see this, I just wasn't convinced I wanted the program to
be able to modify the SKB that way. OTOH, it doesn't actually matter if
it does this since that doesn't fundamentally change the SKB, so I
might as well allow it - and hook up data/data_end. In many cases, the
decision will be taken on the 802.11 header only, and that will be in
the linear portion anyway (with any self-respecting driver :p)
> Yeah, *_is_valid_access() callbacks would need to reject these
> members for most of the program types.
Yes, but that's the default case, so there's no real danger.
> Assuming you would introduce __wifi_sk_buff to the uapi, then it
> would be that the kernel internally still operates on an skb, you'd
> still call the program through BPF_PROG_RUN(prog, skb). However, your
> *_convert_ctx_access() would map from __wifi_sk_buff to the actual
> skb member, for example:
>
> [...]
> case offsetof(struct __wifi_sk_buff, len):
> BUILD_BUG_ON(FIELD_SIZEOF(struct sk_buff, len) != 4);
>
> *insn++ = BPF_LDX_MEM(BPF_W, si->dst_reg, si->src_reg,
> offsetof(struct sk_buff, len));
> break;
> [...]
>
> Your *_func_proto() would just reuse the available skb helpers like:
>
> switch (func_id) {
> case BPF_FUNC_skb_load_bytes:
> return &bpf_skb_load_bytes_proto;
> [...]
> }
>
> So, it's not that you need a local struct xdp_buff -like definition
> in the kernel and convert all helpers to it, reusing skb in kernel
> works just fine this way.
Sure.
> The mapping in samples/bpf/bpf_helpers.h, for example, for mentioned
> bpf_skb_load_bytes() would also work out of the box, since it takes a
> void *ctx as an argument, so you can just pass the __wifi_sk_buff
> pointer as ctx there from program side.
Hah. That's what I was missing - I always assumed the argument was
"struct __sk_buff *" without ever checking that assumption.
> Assuming __wifi_sk_buff would get few wifi specific attributes over
> time which cannot be reused in other types, it's probably fine to
> go with a __wifi_sk_buff uapi definition. If helper functions
> dedicated to wifi program type can extract all necessary information,
> it's probably okay as well to go that route.
The thing is that __wifi_sk_buff doesn't have much information that's
generally useful available - for example, there's not much point in
allowing it to access the raw rate data, having the actual converted
bitrate is much more useful, and that requires a function call since I
don't want the overhead of calculating that in cases the program
doesn't need it.
> If the data passed to such a helper function would eventually be a
> __wifi_sk_buff-like struct that gets extended with further attributes
> over time, then it's probably easier to use __wifi_sk_buff itself as
> a ctx instead of argument for helpers. Reason is that once a helper
> is set in stone, you need to keep compatibility on the passed struct,
> meaning you need to test the passed length of the struct like we do
> in case of bpf_skb_get_tunnel_key() / bpf_skb_set_tunnel_key()
> helpers and only copy meta data up to that length for older programs.
Right.
johannes
Re: [RFC 1/3] bpf/wireless: add wifimon program type
On 04/18/2017 11:55 AM, Johannes Berg wrote:
On Fri, 2017-04-14 at 11:51 -0700, Alexei Starovoitov wrote:
so today only 'len' field is needed,
Correct, the other __sk_buff fields don't apply.
It's more of an XDP model (with data/data_end), but as the SKB might be
non-linear at this point I prefer to have the SKB so that skb data
access (skb_copy_bits equivalent) works.
Note that for skbs the data / data_end model (aka direct read / write)
is also supported. There's also a bpf_skb_pull_data() helper that
pulls in data from non-linear parts if necessary (f.e. if data /
data_end test in the program fails). bpf_skb_load_bytes() is fine as
well, comes with function call overhead, though, but depending on the
use-case that might be just fine, too.
but the plan to add wifi specific
stuff to bpf context?
Maybe, maybe not.
If so, adding these very wifi specific fields to __sk_buff will
confuse other program types,
I don't think this is true - the verifier still checks that you can't
actually use them. It might confuse authors though, if not documented
well.
Yeah, *_is_valid_access() callbacks would need to reject these members
for most of the program types.
so new program type (like you did) and new 'struct bpf_wifi_md' are
probably cleaner.
The problem is that I still need struct __wifi_sk_buff or so, and need
to internally let it operate like an SKB, since I need
bpf_skb_load_bytes().
Now, bpf_helpers declares bpf_skb_load_bytes() to take an argument of
type "struct __sk_buff *", and thus I either need to provide an alias
to it, or cast every time I use this function.
Assuming you would introduce __wifi_sk_buff to the uapi, then it
would be that the kernel internally still operates on an skb, you'd
still call the program through BPF_PROG_RUN(prog, skb). However, your
*_convert_ctx_access() would map from __wifi_sk_buff to the actual
skb member, for example:
[...]
case offsetof(struct __wifi_sk_buff, len):
BUILD_BUG_ON(FIELD_SIZEOF(struct sk_buff, len) != 4);
*insn++ = BPF_LDX_MEM(BPF_W, si->dst_reg, si->src_reg,
offsetof(struct sk_buff, len));
break;
[...]
Your *_func_proto() would just reuse the available skb helpers like:
switch (func_id) {
case BPF_FUNC_skb_load_bytes:
return &bpf_skb_load_bytes_proto;
[...]
}
So, it's not that you need a local struct xdp_buff -like definition
in the kernel and convert all helpers to it, reusing skb in kernel
works just fine this way.
The mapping in samples/bpf/bpf_helpers.h, for example, for mentioned
bpf_skb_load_bytes() would also work out of the box, since it takes a
void *ctx as an argument, so you can just pass the __wifi_sk_buff
pointer as ctx there from program side.
Assuming __wifi_sk_buff would get few wifi specific attributes over
time which cannot be reused in other types, it's probably fine to
go with a __wifi_sk_buff uapi definition. If helper functions dedicated
to wifi program type can extract all necessary information, it's
probably okay as well to go that route.
If the data passed to such a helper function would eventually be a
__wifi_sk_buff-like struct that gets extended with further attributes
over time, then it's probably easier to use __wifi_sk_buff itself as
a ctx instead of argument for helpers. Reason is that once a helper
is set in stone, you need to keep compatibility on the passed struct,
meaning you need to test the passed length of the struct like we do
in case of bpf_skb_get_tunnel_key() / bpf_skb_set_tunnel_key() helpers
and only copy meta data up to that length for older programs.
Physically the R1 register to bpf program will still be 'struct
sk_buff', but from bpf program side it will be:
struct bpf_wifi_md {
__u32 len;
__u32 wifi_things;
};
Right, that would work immediately if it's only about the extra fields.
But it's more about being able to call bpf_skb_load_bytes() easily.
I don't even know if I want to add *any* wifi_things here at all. I
don't actually have much data available directly at this point, or at
least not in a format that would be useful, so I think it'd be better
to have a BPF helper function to obtain wifi_things outside of the
struct itself, passing the struct bpf_wifi_md * (and thus getting
struct sk_buff * in the kernel code) to it.
At the same time if most of the __sk_buff fields can be useful to
wifimon, then just use it as-is (without restricting to 'len' only)
and add wifi specific fields to it with a comment.
No, I don't think they can ever be useful.
johannes
Directed to you please
Dear Good Friend, Sorry if this email came to you as a surprise,I am Dr.Dawuda Usman and we are looking for a company or individual from your region to help us receive investment fund and safekeeping.I will send you full details As soon As I hear from you. Thanks Dr.Dawuda Usman
Re: [PATCH V2 3/3] cfg80211: Share Channel DFS state across wiphys of same DFS domain
> +void regulatory_propagate_dfs_state(struct wiphy *wiphy,
> + struct cfg80211_chan_def
> *chandef,
> + enum nl80211_dfs_state
> dfs_state,
> + enum nl80211_radar_event event)
> +{
> + struct cfg80211_registered_device *rdev;
> +
> + ASSERT_RTNL();
> +
> + if (WARN_ON(!cfg80211_chandef_valid(chandef)))
> + return;
> +
> + if (WARN_ON(!(chandef->chan->flags & IEEE80211_CHAN_RADAR)))
> + return;
This warn on reliably triggers for me when I run the "ap_vht160" hwsim
test from wpa_supplicant.
I think there might be some confusion about this when parts of the 160
MHz channel require radar and parts don't? But I haven't looked into
this at all.
Please send me a fix ASAP so Jouni doesn't shout at me for test
failures :)
johannes
Re: [B.A.T.M.A.N.] [batman-adv] Does batman-adv works perfectly?
Hi Xuebing, I didn't try the QSDK on those devices, mainly because of its poor upstream support/community involvement. We tried it on other devices, with "mixed" results. Cheers, Simon On Monday, April 17, 2017 10:19:02 PM CEST Xuebing Wang wrote: > Hi Sven and Simon, > > Thank you very much for your help. I am curious that did you try QCA-WiFi > driver for ath9k device (like AR9331) + OpenWRT, instead of trying to > improve ath9k driver? > > QCA-WiFi driver included in QSDK: > https://www.codeaurora.org/projects/all-active-projects/qsdk > > Thanks. > Xuebing Wang > > On Thu, Apr 6, 2017 at 3:13 PM, Sven Eckelmann wrote: > > On Donnerstag, 6. April 2017 09:04:50 CEST Simon Wunderlich wrote: > > > Hello Xuebing, > > > > > > it sounds like you have WiFi driver issues. There are some effects like > > > > key > > > > > cache corruption, deafness, and other effects known for the AR93xx > > > > series. > > > > Correct, completely forgot about the deaf and 0xdeadbeef issues. There > > were > > also two workarounds for them [1,2] from Simon. > > > > Kind regards, > > > > Sven > > > > [1] https://patchwork.kernel.org/patch/9433619/ > > [2] https://patchwork.kernel.org/patch/9433621/ signature.asc Description: This is a digitally signed message part.
Re: [PATCH v2 0/8] NFC: fix device allocation and nfcmrvl crashes
On Thu, Mar 30, 2017 at 12:15:34PM +0200, Johan Hovold wrote: > This started out with the observation that the nfcmrvl_uart driver > unconditionally dereferenced the tty class device despite the fact that > not every tty has an associated struct device (Unix98 ptys). Some > further changes were needed in the common nfcmrvl code to fully address > this, some of which also incidentally fixed a few related bugs (e.g. > resource leaks in error paths). > > While fixing this I stumbled over a regression in NFC core that lead to > broken registration error paths and misnamed workqueues. > > Note that this has only been tested by configuring the n_hci line > discipline for different ttys without any actual NFC hardware connected. > Johan Hovold (8): > NFC: fix broken device allocation > NFC: nfcmrvl_uart: add missing tty-device sanity check > NFC: nfcmrvl: do not use device-managed resources > NFC: nfcmrvl: use nfc-device for firmware download > NFC: nfcmrvl: fix firmware-management initialisation > NFC: nfcmrvl_uart: fix device-node leak during probe > NFC: nfcmrvl_usb: use interface as phy device > NFC: nfcmrvl: allow gpio 0 for reset signalling Any chance of getting these into 4.12, Samuel? Note that patches 2 and 4 fixes NULL-derefs that can be triggered by an unprivileged user. Thanks, Johan
Re: [PATCH v3 1/4] mac80211-hwsim: notify user-space about channel change.
On Fri, 2017-03-31 at 06:33 -0700, Ben Greear wrote: > > In my experience, the big problem with netlink is that if you write > a patch that cannot make it upstream (or takes forever), then the > netlink IDs conflict as upstream adds more stuff. Sure, that's a common problem we all run into :) > Other than that, it is easy to add new members, or completely new > commands. > > User-space can drop old API and simply not fully work against older > kernels if it wants, especially for something as specialized as a > simulated wifi radio. Yeah, but the kernel will have to maintain both versions, and strictly speaking shouldn't be breaking old userspace - but that would be impossible as one moves to chanctx, perhaps even by default. This is the problem I have with it - chanctx code already exists and is used, so there's no technical reason not to support both now. > So, if my patch can go in as is or with small tweaks, then I'm happy > to keep working on it. If it needs a complete re-write, then it will > have to wait for someone else or some later date. Ok, that's fair. I think I'll leave it out then though, because I really do think that we should aim to support chanctx from the start with this, it's well-established by now. johannes
Re: [RFC 1/3] bpf/wireless: add wifimon program type
On Fri, 2017-04-14 at 11:51 -0700, Alexei Starovoitov wrote:
>
> so today only 'len' field is needed,
Correct, the other __sk_buff fields don't apply.
It's more of an XDP model (with data/data_end), but as the SKB might be
non-linear at this point I prefer to have the SKB so that skb data
access (skb_copy_bits equivalent) works.
> but the plan to add wifi specific
> stuff to bpf context?
Maybe, maybe not.
> If so, adding these very wifi specific fields to __sk_buff will
> confuse other program types,
I don't think this is true - the verifier still checks that you can't
actually use them. It might confuse authors though, if not documented
well.
> so new program type (like you did) and new 'struct bpf_wifi_md' are
> probably cleaner.
The problem is that I still need struct __wifi_sk_buff or so, and need
to internally let it operate like an SKB, since I need
bpf_skb_load_bytes().
Now, bpf_helpers declares bpf_skb_load_bytes() to take an argument of
type "struct __sk_buff *", and thus I either need to provide an alias
to it, or cast every time I use this function.
> Physically the R1 register to bpf program will still be 'struct
> sk_buff', but from bpf program side it will be:
> struct bpf_wifi_md {
> __u32 len;
> __u32 wifi_things;
> };
Right, that would work immediately if it's only about the extra fields.
But it's more about being able to call bpf_skb_load_bytes() easily.
I don't even know if I want to add *any* wifi_things here at all. I
don't actually have much data available directly at this point, or at
least not in a format that would be useful, so I think it'd be better
to have a BPF helper function to obtain wifi_things outside of the
struct itself, passing the struct bpf_wifi_md * (and thus getting
struct sk_buff * in the kernel code) to it.
> At the same time if most of the __sk_buff fields can be useful to
> wifimon, then just use it as-is (without restricting to 'len' only)
> and add wifi specific fields to it with a comment.
No, I don't think they can ever be useful.
johannes
[PATCH] rt2800: fix mt7620 E2 channel registers
From: Tomislav Požega update RF register 47 and 54 values according to vendor driver Signed-off-by: Tomislav Požega Signed-off-by: Daniel Golle --- drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c index 86cffee6876a..8585cdc3de53 100644 --- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c +++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c @@ -8145,9 +8145,11 @@ static void rt2800_init_rfcsr_6352(struct rt2x00_dev *rt2x00dev) rt2800_rfcsr_write_chanreg(rt2x00dev, 44, 0xB3); rt2800_rfcsr_write_chanreg(rt2x00dev, 45, 0xD5); rt2800_rfcsr_write_chanreg(rt2x00dev, 46, 0x27); - rt2800_rfcsr_write_chanreg(rt2x00dev, 47, 0x69); + rt2800_rfcsr_write_bank(rt2x00dev, 4, 47, 0x67); + rt2800_rfcsr_write_bank(rt2x00dev, 6, 47, 0x69); rt2800_rfcsr_write_chanreg(rt2x00dev, 48, 0xFF); - rt2800_rfcsr_write_chanreg(rt2x00dev, 54, 0x20); + rt2800_rfcsr_write_bank(rt2x00dev, 4, 54, 0x27); + rt2800_rfcsr_write_bank(rt2x00dev, 6, 54, 0x20); rt2800_rfcsr_write_chanreg(rt2x00dev, 55, 0x66); rt2800_rfcsr_write_chanreg(rt2x00dev, 56, 0xFF); rt2800_rfcsr_write_chanreg(rt2x00dev, 57, 0x1C); -- 2.12.2
Re: [PATCH 1/5] netlink: extended ACK reporting
On Thu, 2017-04-13 at 14:44 -0700, Joe Stringer wrote (something that never made it to the list, due to HTML formatting) > > I think that OVS was doing some more elaborate validation than most > users, so over time we picked up a bunch of extra parsing code that > layers on top of nla_parse(). I took a look at trying to broaden this > and make it useful to other users a while ago, but when I posted > there wasn't much interest from others on it so I just moved on. > Maybe it's about time to pick that back up. Ah, ok. I didn't realize it was actually on top of nla_parse(). Some of this does seem rather useful though, and having more expressive policy would seem very useful too - I'd love to be able to express nesting better, for example. Also, I think we should - at least with the strict checking that Jiri is proposing - think about checking the actual size, not just against a minimum. johannes
[PATCH] rt2800: fix mt7620 vco calibration registers
From: Tomislav Požega
Use register values from init LNA function instead of the ones from
restore LNA function. Apply register values based on rx path
configuration.
Signed-off-by: Tomislav Požega
Signed-off-by: Daniel Golle
---
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index 870bf315f98b..86cffee6876a 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -4932,7 +4932,7 @@ void rt2800_vco_calibration(struct rt2x00_dev *rt2x00dev)
rt2800_register_write(rt2x00dev, TX_PIN_CFG, tx_pin);
if (rt2x00_rt(rt2x00dev, RT6352)) {
- if (rt2x00dev->default_ant.tx_chain_num == 1) {
+ if (rt2x00dev->default_ant.rx_chain_num == 1) {
rt2800_bbp_write(rt2x00dev, 91, 0x07);
rt2800_bbp_write(rt2x00dev, 95, 0x1A);
rt2800_bbp_write(rt2x00dev, 195, 128);
@@ -4953,8 +4953,8 @@ void rt2800_vco_calibration(struct rt2x00_dev *rt2x00dev)
}
if (rt2x00_has_cap_external_lna_bg(rt2x00dev)) {
- rt2800_bbp_write(rt2x00dev, 75, 0x60);
- rt2800_bbp_write(rt2x00dev, 76, 0x44);
+ rt2800_bbp_write(rt2x00dev, 75, 0x68);
+ rt2800_bbp_write(rt2x00dev, 76, 0x4C);
rt2800_bbp_write(rt2x00dev, 79, 0x1C);
rt2800_bbp_write(rt2x00dev, 80, 0x0C);
rt2800_bbp_write(rt2x00dev, 82, 0xB6);
--
2.12.2
pull-request: mac80211-next 2017-04-18
Hi Dave, I hadn't realized that I actually had this many patches pending, but most of them really are cleanups and little fixes. Despite a bunch of driver changes, there don't seem to be any conflicts. Please pull and let me know if there's any problem. Thanks, johannes The following changes since commit 8d70eeb84ab277377c017af6a21d0a337025dede: Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2017-03-04 17:31:39 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git tags/mac80211-next-for-davem-2017-04-18 for you to fetch changes up to bbf67e450a5dc2a595e1e7a67b4869f1a7f5a338: nl80211: Fix enum type of variable in nl80211_put_sta_rate() (2017-04-18 11:03:03 +0200) My last pull request has been a while, we now have: * connection quality monitoring with multiple thresholds * support for FILS shared key authentication offload * pre-CAC regulatory compliance - only ETSI allows this * sanity check for some rate confusion that hit ChromeOS (but nobody else uses it, evidently) * some documentation updates * lots of cleanups Andrew Zaborowski (4): cfg80211: Accept multiple RSSI thresholds for CQM mac80211: Add set_cqm_rssi_range_config wireless: Set NL80211_EXT_FEATURE_CQM_RSSI_LIST in multiple drivers mac80211_hwsim: Make sure NEW_RADIO contains final name Arend Van Spriel (1): nl80211: add request id in scheduled scan event messages Arkadiusz Miskiewicz (1): mac80211: Print text for disassociation reason Avraham Stern (1): ieee80211: add FT-PSK AKM suite selector Ben Greear (1): mac80211-hwsim: remove dmesg spam about get-survey. Johannes Berg (24): cfg80211: combine two nested ifs into a single condition ieee80211: rename CCFS1/CCFS2 to CCFS0/CCFS1 mac80211: remove local pointer from rate_ctrl_ref cfg80211: refactor cfg80211_calculate_bitrate() mac80211: encode rate type (legacy, HT, VHT) with fewer bits ieee80211: define HT operation CCFS2 field mac80211_hwsim: fix command documentation indentation mac80211_hwsim: report survey data for scanned channels mac80211: ignore VHT membership selector when parsing rates iwlegacy: remove usage of txrc->max_rate_idx iwlwifi: dvm: remove usage of txrc->max_rate_idx mac80211: remove ieee80211_tx_rate_control.max_rate_idx mac80211: reject/clear user rate mask if not usable cfg80211: preserve wdev ID across netns changes cfg80211: add documentation for cfg80211_get_bss() cfg80211: add intro to documentation mac80211: drop frames too short for FCS earlier cfg80211: allow leaving MU-MIMO monitor configuration unchanged mac80211: correct MU-MIMO monitor follow functionality cfg80211: move add/change interface monitor flags into params cfg80211: refactor nl80211 monitor option parsing mac80211: use common code for monitor options in add/change mac80211_hwsim: use per-interface power level mac80211: keep a separate list of monitor interfaces that are up Jouni Malinen (1): mac80211_hwsim: Add channel 169 (5845 MHz) Manoharan, Rajkumar (2): mac80211: use DECLARE_EWMA for mesh_fail_avg mac80211: fix mesh fail_avg check Masashi Honma (2): nl80211: Use signed function for a signed variable mac80211: mesh: drop new node with weak power Matthias Kaehlcke (4): mac80211: Fix clang warning about constant operand in logical operation cfg80211: Fix array-bounds warning in fragment copy mac80211: ibss: Fix channel type enum in ieee80211_sta_join_ibss() nl80211: Fix enum type of variable in nl80211_put_sta_rate() Ondřej Lysoněk (2): mac80211: Use setup_timer instead of init_timer mac80211: Use setup_timer instead of init_timer for mesh path Vasanthakumar Thiagarajan (3): cfg80211: Make pre-CAC results valid only for ETSI domain cfg80211: Disallow moving out of operating DFS channel in non-ETSI cfg80211: Share Channel DFS state across wiphys of same DFS domain Vidyullatha Kanchanapally (2): cfg80211: Use a structure to pass connect response params cfg80211: Add support for FILS shared key authentication offload Documentation/driver-api/80211/cfg80211.rst| 9 + drivers/net/wireless/admtek/adm8211.c | 2 + drivers/net/wireless/ath/ar5523/ar5523.c | 2 + drivers/net/wireless/ath/ath10k/mac.c | 2 + drivers/net/wireless/ath/ath5k/base.c | 2 + drivers/net/wireless/ath/ath6kl/cfg80211.c | 3 +- drivers/net/wireless/ath/ath9k/htc_drv_init.c | 2 + drivers/net/wireless/ath/ath9k/init.c | 2 + drivers/net/wireless/ath/carl9170/main.c | 2 + drivers/net/wireless/a
Re: [PATCH] nl80211: Fix enum type of variable in nl80211_put_sta_rate()
On Mon, 2017-04-17 at 15:59 -0700, Matthias Kaehlcke wrote: > rate_flg is of type 'enum nl80211_attrs', however it is assigned with > 'enum nl80211_rate_info' values. Change the type of rate_flg > accordingly. Applied this, and the other two patches you had (IBSS enum and array- bounds) johannes
Re: [PATCH V2 01/10] nl80211: add request id in scheduled scan event messages
On Thu, 2017-04-13 at 13:06 +0100, Arend van Spriel wrote: > For multi-scheduled scan support in subsequent patch a request id > will be added. This patch add this request id to the scheduled > scan event messages. For now the request id will always be zero. > With multi-scheduled scan its value will inform user-space to which > scan the event relates. I've applied this, but please resend all of the remaining ones, even if only patch 2 changes. johannes
Re: [PATCH V2 02/10] nl80211: allow multiple active scheduled scan requests
On Tue, 2017-04-18 at 10:53 +0200, Johannes Berg wrote: > Hi Arend, > > Overall this looks good, and I've almost applied it - but I have a > question on this patch. > > You have this list: > > > + struct list_head sched_scan_req_list; > > struct cfg80211_sched_scan_request __rcu *sched_scan_req; > > but you kept this. In fact, it's even still *used*. I don't > understand > that part. > > Also, you used RCU primitives for the new list, but you never > actually > used them - except in one place (in nl80211_stop_sched_scan) where > it's > actually not needed at all and the _rcu should be removed (since it > holds the lock) > > What's up with that? Actually, I think I see what's up - you simply forgot to remove the sched_scan_req member, and then didn't realize that it was still used in nl80211_netlink_notify(), and that's the place that *does* need the RCU stuff. johannes
Re: [PATCH V2 02/10] nl80211: allow multiple active scheduled scan requests
Hi Arend, Overall this looks good, and I've almost applied it - but I have a question on this patch. You have this list: > + struct list_head sched_scan_req_list; > struct cfg80211_sched_scan_request __rcu *sched_scan_req; but you kept this. In fact, it's even still *used*. I don't understand that part. Also, you used RCU primitives for the new list, but you never actually used them - except in one place (in nl80211_stop_sched_scan) where it's actually not needed at all and the _rcu should be removed (since it holds the lock) What's up with that? johannes
pull-request: mac80211 2017-04-18
Hi Dave, Here's a single remaining fix - it's not even super urgent for this cycle since it's in a "fringe" feature, but it's for an SKB out-of-bounds access. Please pull and let me know if there's any problem. Thanks, johannes The following changes since commit fc9c89b19c56813434c3d2967652a4fa6906926a: Merge branch 'bridge-register-netdev-before-changelink' (2017-04-11 22:22:45 -0400) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git tags/mac80211-for-davem-2017-04-18 for you to fetch changes up to 9e478066eae41211c92a8f63cc69aafc391bd6ab: mac80211: fix MU-MIMO follow-MAC mode (2017-04-13 14:35:53 +0200) A single fix, for the MU-MIMO monitor mode, that fixes bad SKB accesses if the SKB was paged, which is the case for the only driver supporting this - iwlwifi. Johannes Berg (1): mac80211: fix MU-MIMO follow-MAC mode net/mac80211/rx.c | 65 --- 1 file changed, 47 insertions(+), 18 deletions(-)
Re: pull-request: iwlwifi-next 2017-04-13
On Tue, 2017-04-18 at 06:56 +, Kalle Valo wrote: > Kalle Valo writes: > > > Luca Coelho writes: > > > > > Here's my first pull-request intended for v4.12. This is generic > > > development work, nothing really stands out. More > > > details in the tag description. > > > > > > I have sent this out before, and kbuildbot reported success. > > > > > > Please let me know if there are any issues. > > > > > > Cheers, > > > Luca. > > > > > > > > > The following changes since commit > > > 1aed89640a899cd695bbfc976a4356affa474646: > > > > > > mwifiex: apply radar flag (2017-04-05 15:54:52 +0300) > > > > > > are available in the git repository at: > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git > > > tags/iwlwifi-next-for-kalle-2017-04-13 > > > > > > for you to fetch changes up to 87d0e1af9db3bff4ec2f68fd4d032f89c23867a4: > > > > > > iwlwifi: mvm: separate queue mapping from queue enablement (2017-04-11 > > > 15:25:00 +0300) > > > > > > > > > Patches intended for v4.12: > > > > > > * Some small fixes here and there; > > > * The usual cleanups and small improvements; > > > * Work to support A000 devices continues; > > > * New FW API version; > > > * Some debugging improvements; > > > > > > > > > > This one has few conflicts. I can fix those manually, but can you give > > some guidance how? > > I think I got it now, see below for the diff I did. Can you please > check that? > > The resolution is also in the pending branch: > > https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git/log/?h=pending Yes, looks good! Thanks for resolving it and sorry for not foreseeing it to give you a heads up. -- Cheers, Luca.
