* [PATCH 6/6] mac80211: shorten debug message
From: Johannes Berg @ 2017-02-20 13:24 UTC (permalink / raw)
To: linux-wireless; +Cc: Sara Sharon
In-Reply-To: <20170220132439.16064-1-johannes@sipsolutions.net>
From: Sara Sharon <sara.sharon@intel.com>
Tracing is limited to 100 characters and this message passes
the limit when there are a few buffered frames. Shorten it.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/mac80211/sta_info.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
index 8bb99d299cda..3323a2fb289b 100644
--- a/net/mac80211/sta_info.c
+++ b/net/mac80211/sta_info.c
@@ -1264,7 +1264,7 @@ void ieee80211_sta_ps_deliver_wakeup(struct sta_info *sta)
sta_info_recalc_tim(sta);
ps_dbg(sdata,
- "STA %pM aid %d sending %d filtered/%d PS frames since STA not sleeping anymore\n",
+ "STA %pM aid %d sending %d filtered/%d PS frames since STA woke up\n",
sta->sta.addr, sta->sta.aid, filtered, buffered);
ieee80211_check_fast_xmit(sta);
--
2.9.3
^ permalink raw reply related
* [PATCH 2/2] mac80211: don't reorder frames with SN smaller than SSN
From: Johannes Berg @ 2017-02-20 13:24 UTC (permalink / raw)
To: linux-wireless; +Cc: Sara Sharon
In-Reply-To: <20170220132448.16140-1-johannes@sipsolutions.net>
From: Sara Sharon <sara.sharon@intel.com>
When RX aggregation starts, transmitter may continue send frames
with SN smaller than SSN until the AddBA response is received.
However, the reorder buffer is already initialized at this point,
which will cause the drop of such frames as duplicates since the
head SN of the reorder buffer is set to the SSN, which is bigger.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/mac80211/agg-rx.c | 1 +
net/mac80211/rx.c | 14 +++++++++++++-
net/mac80211/sta_info.h | 6 ++++--
3 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/net/mac80211/agg-rx.c b/net/mac80211/agg-rx.c
index 3b5fd4188f2a..58ad23a44109 100644
--- a/net/mac80211/agg-rx.c
+++ b/net/mac80211/agg-rx.c
@@ -398,6 +398,7 @@ void __ieee80211_start_rx_ba_session(struct sta_info *sta,
tid_agg_rx->timeout = timeout;
tid_agg_rx->stored_mpdu_num = 0;
tid_agg_rx->auto_seq = auto_seq;
+ tid_agg_rx->started = false;
tid_agg_rx->reorder_buf_filtered = 0;
status = WLAN_STATUS_SUCCESS;
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index cc2599739ce1..90b43c3d6f7d 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -4,7 +4,7 @@
* Copyright 2006-2007 Jiri Benc <jbenc@suse.cz>
* Copyright 2007-2010 Johannes Berg <johannes@sipsolutions.net>
* Copyright 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 the GNU General Public License version 2 as
@@ -1034,6 +1034,18 @@ static bool ieee80211_sta_manage_reorder_buf(struct ieee80211_sub_if_data *sdata
buf_size = tid_agg_rx->buf_size;
head_seq_num = tid_agg_rx->head_seq_num;
+ /*
+ * If the current MPDU's SN is smaller than the SSN, it shouldn't
+ * be reordered.
+ */
+ if (unlikely(!tid_agg_rx->started)) {
+ if (ieee80211_sn_less(mpdu_seq_num, head_seq_num)) {
+ ret = false;
+ goto out;
+ }
+ tid_agg_rx->started = true;
+ }
+
/* frame with out of date sequence number */
if (ieee80211_sn_less(mpdu_seq_num, head_seq_num)) {
dev_kfree_skb(skb);
diff --git a/net/mac80211/sta_info.h b/net/mac80211/sta_info.h
index dd06ef0b8861..15599c70a38f 100644
--- a/net/mac80211/sta_info.h
+++ b/net/mac80211/sta_info.h
@@ -189,6 +189,7 @@ struct tid_ampdu_tx {
* @auto_seq: used for offloaded BA sessions to automatically pick head_seq_and
* and ssn.
* @removed: this session is removed (but might have been found due to RCU)
+ * @started: this session has started (head ssn or higher was received)
*
* This structure's lifetime is managed by RCU, assignments to
* the array holding it must hold the aggregation mutex.
@@ -212,8 +213,9 @@ struct tid_ampdu_rx {
u16 ssn;
u16 buf_size;
u16 timeout;
- bool auto_seq;
- bool removed;
+ u8 auto_seq:1,
+ removed:1,
+ started:1;
};
/**
--
2.9.3
^ permalink raw reply related
* [rtl8xxxu] rtl8192cu (0bda:8176) on linux-4.9.11 (arm) high sirq rate
From: Christian Hilberg @ 2017-02-20 13:51 UTC (permalink / raw)
To: linux-wireless
Hi all,
currently I'm testing rtl8xxxu on an ARM device (i.mx28, armv5te) under
linux-4.9.11 with a RealTek 8192cu (0bda:8176) wifi dongle. Since
I had to set CONFIG_RTL8XXXU_UNTESTED, I'm prepared to see some
rough edges here and there. :-)
The driver actually works and I'm getting a stable connection on
a WPA2 secured wifi network. As a firmware blob, the driver loads
the "rtl8192cufw_TMSC.bin", which I extracted from [0].
However, the sirg rate is rather high (between 20% to 50% in top),
as soon as the device is getting upped, that is, as soon as IFF_UP
gets written to the device via ioctl().
In the same setup, but with the rtlwifi driver, I'm not seeing a high
sirq rate, but that driver drops connection every now and then for me,
so I'd rather resort to rtl8xxxu.
I've prepped a kernel with ftrace functionality and got some logs,
which seem to point to the USB subsystem (many entries about URB
giveback, but I'm not clear whether this is an issue here).
In a private mail, Jes hinted that there might be something going on
with enabling interrupts on the chip or some debugging related
stuff (just I'm not seeing any on the console).
I'm a little lost here, any pointers on the matter are much welcome.
If needed, I can provide ftrace logs, just slip me a note.
Regards,
Christian
PS.: I've seen the same sirq rate back to rc-Versions of 4.9 on
that arm device.
[0] http://ftp.de.debian.org/debian/pool/non-free/f/firmware-nonfree/firmware-realtek_20161130-2_all.deb
--
^ permalink raw reply
* [PATCH] ath10k: Clean header files from bad block comments
From: Marcin Rokicki @ 2017-02-20 14:37 UTC (permalink / raw)
To: marcin.rokicki; +Cc: linux-wireless
Fix output from checkpatch.pl like:
Block comments use a trailing */ on a separate line
Signed-off-by: Marcin Rokicki <marcin.rokicki@tieto.com>
---
drivers/net/wireless/ath/ath10k/bmi.h | 3 ++-
drivers/net/wireless/ath/ath10k/core.h | 9 ++++++---
drivers/net/wireless/ath/ath10k/hif.h | 6 ++++--
drivers/net/wireless/ath/ath10k/htt.h | 24 +++++++++++++++--------
drivers/net/wireless/ath/ath10k/hw.h | 3 ++-
drivers/net/wireless/ath/ath10k/rx_desc.h | 13 ++++++++-----
drivers/net/wireless/ath/ath10k/targaddrs.h | 19 +++++++++---------
drivers/net/wireless/ath/ath10k/wmi-ops.h | 3 ++-
drivers/net/wireless/ath/ath10k/wmi.h | 30 +++++++++++++++++++----------
9 files changed, 70 insertions(+), 40 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/bmi.h b/drivers/net/wireless/ath/ath10k/bmi.h
index 7d3231a..98be562 100644
--- a/drivers/net/wireless/ath/ath10k/bmi.h
+++ b/drivers/net/wireless/ath/ath10k/bmi.h
@@ -176,7 +176,8 @@ union bmi_resp {
} rompatch_uninstall;
struct {
/* 0 = nothing executed
- * otherwise = NVRAM segment return value */
+ * otherwise = NVRAM segment return value
+ */
__le32 result;
} nvram_process;
u8 payload[BMI_MAX_CMDBUF_SIZE];
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 88d14be..53a66e6 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -501,14 +501,16 @@ enum ath10k_state {
* stopped in ath10k_core_restart() work holding conf_mutex. The state
* RESTARTED means that the device is up and mac80211 has started hw
* reconfiguration. Once mac80211 is done with the reconfiguration we
- * set the state to STATE_ON in reconfig_complete(). */
+ * set the state to STATE_ON in reconfig_complete().
+ */
ATH10K_STATE_RESTARTING,
ATH10K_STATE_RESTARTED,
/* The device has crashed while restarting hw. This state is like ON
* but commands are blocked in HTC and -ECOMM response is given. This
* prevents completion timeouts and makes the driver more responsive to
- * userspace commands. This is also prevents recursive recovery. */
+ * userspace commands. This is also prevents recursive recovery.
+ */
ATH10K_STATE_WEDGED,
/* factory tests */
@@ -918,7 +920,8 @@ struct ath10k {
struct work_struct restart_work;
/* cycle count is reported twice for each visited channel during scan.
- * access protected by data_lock */
+ * access protected by data_lock
+ */
u32 survey_last_rx_clear_count;
u32 survey_last_cycle_count;
struct survey_info survey[ATH10K_NUM_CHANS];
diff --git a/drivers/net/wireless/ath/ath10k/hif.h b/drivers/net/wireless/ath/ath10k/hif.h
index b2566b0..6679dd9 100644
--- a/drivers/net/wireless/ath/ath10k/hif.h
+++ b/drivers/net/wireless/ath/ath10k/hif.h
@@ -54,7 +54,8 @@ struct ath10k_hif_ops {
int (*start)(struct ath10k *ar);
/* Clean up what start() did. This does not revert to BMI phase. If
- * desired so, call power_down() and power_up() */
+ * desired so, call power_down() and power_up()
+ */
void (*stop)(struct ath10k *ar);
int (*map_service_to_pipe)(struct ath10k *ar, u16 service_id,
@@ -82,7 +83,8 @@ struct ath10k_hif_ops {
int (*power_up)(struct ath10k *ar);
/* Power down the device and free up resources. stop() must be called
- * before this if start() was called earlier */
+ * before this if start() was called earlier
+ */
void (*power_down)(struct ath10k *ar);
int (*suspend)(struct ath10k *ar);
diff --git a/drivers/net/wireless/ath/ath10k/htt.h b/drivers/net/wireless/ath/ath10k/htt.h
index 90c2f72..6305308 100644
--- a/drivers/net/wireless/ath/ath10k/htt.h
+++ b/drivers/net/wireless/ath/ath10k/htt.h
@@ -51,7 +51,8 @@ enum htt_h2t_msg_type { /* host-to-target */
HTT_H2T_MSG_TYPE_FRAG_DESC_BANK_CFG = 6,
/* This command is used for sending management frames in HTT < 3.0.
- * HTT >= 3.0 uses TX_FRM for everything. */
+ * HTT >= 3.0 uses TX_FRM for everything.
+ */
HTT_H2T_MSG_TYPE_MGMT_TX = 7,
HTT_H2T_MSG_TYPE_TX_FETCH_RESP = 11,
@@ -910,7 +911,8 @@ struct htt_rx_test {
/* payload consists of 2 lists:
* a) num_ints * sizeof(__le32)
- * b) num_chars * sizeof(u8) aligned to 4bytes */
+ * b) num_chars * sizeof(u8) aligned to 4bytes
+ */
u8 payload[0];
} __packed;
@@ -1307,7 +1309,8 @@ struct htt_frag_desc_bank_id {
} __packed;
/* real is 16 but it wouldn't fit in the max htt message size
- * so we use a conservatively safe value for now */
+ * so we use a conservatively safe value for now
+ */
#define HTT_FRAG_DESC_BANK_MAX 4
#define HTT_FRAG_DESC_BANK_CFG_INFO_PDEV_ID_MASK 0x03
@@ -1684,12 +1687,14 @@ struct ath10k_htt {
DECLARE_KFIFO_PTR(txdone_fifo, struct htt_tx_done);
/* set if host-fw communication goes haywire
- * used to avoid further failures */
+ * used to avoid further failures
+ */
bool rx_confused;
atomic_t num_mpdus_ready;
/* This is used to group tx/rx completions separately and process them
- * in batches to reduce cache stalls */
+ * in batches to reduce cache stalls
+ */
struct sk_buff_head rx_compl_q;
struct sk_buff_head rx_in_ord_compl_q;
struct sk_buff_head tx_fetch_ind_q;
@@ -1725,11 +1730,13 @@ struct ath10k_htt {
/* This structure layout is programmed via rx ring setup
* so that FW knows how to transfer the rx descriptor to the host.
- * Buffers like this are placed on the rx ring. */
+ * Buffers like this are placed on the rx ring.
+ */
struct htt_rx_desc {
union {
/* This field is filled on the host using the msdu buffer
- * from htt_rx_indication */
+ * from htt_rx_indication
+ */
struct fw_rx_desc_base fw_desc;
u32 pad;
} __packed;
@@ -1760,7 +1767,8 @@ struct htt_rx_desc {
#define HTT_RX_MSDU_SIZE (HTT_RX_BUF_SIZE - (int)sizeof(struct htt_rx_desc))
/* Refill a bunch of RX buffers for each refill round so that FW/HW can handle
- * aggregated traffic more nicely. */
+ * aggregated traffic more nicely.
+ */
#define ATH10K_HTT_MAX_NUM_REFILL 100
/*
diff --git a/drivers/net/wireless/ath/ath10k/hw.h b/drivers/net/wireless/ath/ath10k/hw.h
index f0fda0f..5343376 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -293,7 +293,8 @@ void ath10k_hw_fill_survey_time(struct ath10k *ar, struct survey_info *survey,
* - raw appears in nwifi decap, raw and nwifi appear in ethernet decap
* - raw have FCS, nwifi doesn't
* - ethernet frames have 802.11 header decapped and parts (base hdr, cipher
- * param, llc/snap) are aligned to 4byte boundaries each */
+ * param, llc/snap) are aligned to 4byte boundaries each
+ */
enum ath10k_hw_txrx_mode {
ATH10K_HW_TXRX_RAW = 0,
diff --git a/drivers/net/wireless/ath/ath10k/rx_desc.h b/drivers/net/wireless/ath/ath10k/rx_desc.h
index 034e7a5..c1022a1 100644
--- a/drivers/net/wireless/ath/ath10k/rx_desc.h
+++ b/drivers/net/wireless/ath/ath10k/rx_desc.h
@@ -439,19 +439,22 @@ struct rx_mpdu_end {
* c) A-MSDU subframe header (14 bytes) if appliable
* d) LLC/SNAP (RFC1042, 8 bytes)
*
- * In case of A-MSDU only first frame in sequence contains (a) and (b). */
+ * In case of A-MSDU only first frame in sequence contains (a) and (b).
+ */
enum rx_msdu_decap_format {
RX_MSDU_DECAP_RAW = 0,
/* Note: QoS frames are reported as non-QoS. The rx_hdr_status in
- * htt_rx_desc contains the original decapped 802.11 header. */
+ * htt_rx_desc contains the original decapped 802.11 header.
+ */
RX_MSDU_DECAP_NATIVE_WIFI = 1,
/* Payload contains an ethernet header (struct ethhdr). */
RX_MSDU_DECAP_ETHERNET2_DIX = 2,
/* Payload contains two 48-bit addresses and 2-byte length (14 bytes
- * total), followed by an RFC1042 header (8 bytes). */
+ * total), followed by an RFC1042 header (8 bytes).
+ */
RX_MSDU_DECAP_8023_SNAP_LLC = 3
};
@@ -867,7 +870,7 @@ struct rx_ppdu_start {
*
* reserved_9
* Reserved: HW should fill with 0, FW should ignore.
-*/
+ */
#define RX_PPDU_END_FLAGS_PHY_ERR (1 << 0)
#define RX_PPDU_END_FLAGS_RX_LOCATION (1 << 1)
@@ -1207,7 +1210,7 @@ struct rx_ppdu_end {
* Every time HW sets this bit in memory FW/SW must clear this
* bit in memory. FW will initialize all the ppdu_done dword
* to 0.
-*/
+ */
#define FW_RX_DESC_INFO0_DISCARD (1 << 0)
#define FW_RX_DESC_INFO0_FORWARD (1 << 1)
diff --git a/drivers/net/wireless/ath/ath10k/targaddrs.h b/drivers/net/wireless/ath/ath10k/targaddrs.h
index a47cab4..cbac9e42 100644
--- a/drivers/net/wireless/ath/ath10k/targaddrs.h
+++ b/drivers/net/wireless/ath/ath10k/targaddrs.h
@@ -268,13 +268,13 @@ struct host_interest {
#define HI_OPTION_FW_BRIDGE_SHIFT 0x04
/*
-Fw Mode/SubMode Mask
-|-----------------------------------------------------------------------------|
-| SUB | SUB | SUB | SUB | | | | |
-|MODE[3] | MODE[2] | MODE[1] | MODE[0] | MODE[3] | MODE[2] | MODE[1] | MODE[0]|
-| (2) | (2) | (2) | (2) | (2) | (2) | (2) | (2) |
-|-----------------------------------------------------------------------------|
-*/
+ * Fw Mode/SubMode Mask
+ *-----------------------------------------------------------------------------
+ * SUB | SUB | SUB | SUB | | | |
+ *MODE[3] | MODE[2] | MODE[1] | MODE[0] | MODE[3] | MODE[2] | MODE[1] | MODE[0]
+ * (2) | (2) | (2) | (2) | (2) | (2) | (2) | (2)
+ *-----------------------------------------------------------------------------
+ */
#define HI_OPTION_FW_MODE_BITS 0x2
#define HI_OPTION_FW_MODE_MASK 0x3
#define HI_OPTION_FW_MODE_SHIFT 0xC
@@ -428,8 +428,9 @@ Fw Mode/SubMode Mask
#define HI_PWR_SAVE_LPL_ENABLED 0x1
/*b1-b3 reserved*/
/*b4-b5 : dev0 LPL type : 0 - none
- 1- Reduce Pwr Search
- 2- Reduce Pwr Listen*/
+ * 1- Reduce Pwr Search
+ * 2- Reduce Pwr Listen
+ */
/*b6-b7 : dev1 LPL type and so on for Max 8 devices*/
#define HI_PWR_SAVE_LPL_DEV0_LSB 4
#define HI_PWR_SAVE_LPL_DEV_MASK 0x3
diff --git a/drivers/net/wireless/ath/ath10k/wmi-ops.h b/drivers/net/wireless/ath/ath10k/wmi-ops.h
index c7956e1..2fc3f24 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-ops.h
+++ b/drivers/net/wireless/ath/ath10k/wmi-ops.h
@@ -390,7 +390,8 @@ ath10k_wmi_mgmt_tx(struct ath10k *ar, struct sk_buff *msdu)
return ret;
/* FIXME There's no ACK event for Management Tx. This probably
- * shouldn't be called here either. */
+ * shouldn't be called here either.
+ */
info->flags |= IEEE80211_TX_STAT_ACK;
ieee80211_tx_status_irqsafe(ar->hw, msdu);
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
index 386aa51..427220c 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -1038,7 +1038,8 @@ enum wmi_cmd_id {
WMI_STA_UAPSD_AUTO_TRIG_CMDID,
/* STA Keep alive parameter configuration,
- Requires WMI_SERVICE_STA_KEEP_ALIVE */
+ * Requires WMI_SERVICE_STA_KEEP_ALIVE
+ */
WMI_STA_KEEPALIVE_CMD,
/* misc command group */
@@ -1774,7 +1775,8 @@ static inline const char *ath10k_wmi_phymode_str(enum wmi_phy_mode mode)
break;
/* no default handler to allow compiler to check that the
- * enum is fully handled */
+ * enum is fully handled
+ */
};
return "<unknown>";
@@ -2974,7 +2976,8 @@ struct wmi_start_scan_arg {
/* When set, DFS channels will not be scanned */
#define WMI_SCAN_BYPASS_DFS_CHN 0x40
/* Different FW scan engine may choose to bail out on errors.
- * Allow the driver to have influence over that. */
+ * Allow the driver to have influence over that.
+ */
#define WMI_SCAN_CONTINUE_ON_ERROR 0x80
/* WMI_SCAN_CLASS_MASK must be the same value as IEEE80211_SCAN_CLASS_MASK */
@@ -4447,14 +4450,16 @@ enum wmi_vdev_subtype_10_4 {
/* values for vdev_start_request flags */
/*
* Indicates that AP VDEV uses hidden ssid. only valid for
- * AP/GO */
+ * AP/GO
+ */
#define WMI_VDEV_START_HIDDEN_SSID (1 << 0)
/*
* Indicates if robust management frame/management frame
* protection is enabled. For GO/AP vdevs, it indicates that
* it may support station/client associations with RMF enabled.
* For STA/client vdevs, it indicates that sta will
- * associate with AP with RMF enabled. */
+ * associate with AP with RMF enabled.
+ */
#define WMI_VDEV_START_PMF_ENABLED (1 << 1)
struct wmi_p2p_noa_descriptor {
@@ -4814,7 +4819,8 @@ enum wmi_vdev_param {
* An associated STA is considered unresponsive if there is no recent
* TX/RX activity and downlink frames are buffered for it. Once a STA
* exceeds the maximum unresponsive time, the AP will send a
- * WMI_STA_KICKOUT event to the host so the STA can be deleted. */
+ * WMI_STA_KICKOUT event to the host so the STA can be deleted.
+ */
WMI_VDEV_PARAM_AP_KEEPALIVE_MAX_UNRESPONSIVE_TIME_SECS,
/* Enable NAWDS : MCAST INSPECT Enable, NAWDS Flag set */
@@ -4941,7 +4947,8 @@ enum wmi_10x_vdev_param {
* An associated STA is considered unresponsive if there is no recent
* TX/RX activity and downlink frames are buffered for it. Once a STA
* exceeds the maximum unresponsive time, the AP will send a
- * WMI_10X_STA_KICKOUT event to the host so the STA can be deleted. */
+ * WMI_10X_STA_KICKOUT event to the host so the STA can be deleted.
+ */
WMI_10X_VDEV_PARAM_AP_KEEPALIVE_MAX_UNRESPONSIVE_TIME_SECS,
/* Enable NAWDS : MCAST INSPECT Enable, NAWDS Flag set */
@@ -5605,12 +5612,14 @@ struct wmi_tim_info_arg {
struct wmi_p2p_noa_info {
/* Bit 0 - Flag to indicate an update in NOA schedule
- Bits 7-1 - Reserved */
+ * Bits 7-1 - Reserved
+ */
u8 changed;
/* NOA index */
u8 index;
/* Bit 0 - Opp PS state of the AP
- Bits 1-7 - Ctwindow in TUs */
+ * Bits 1-7 - Ctwindow in TUs
+ */
u8 ctwindow_oppps;
/* Number of NOA descriptors */
u8 num_descriptors;
@@ -6000,7 +6009,8 @@ struct wmi_main_peer_assoc_complete_cmd {
struct wmi_common_peer_assoc_complete_cmd cmd;
/* HT Operation Element of the peer. Five bytes packed in 2
- * INT32 array and filled from lsb to msb. */
+ * INT32 array and filled from lsb to msb.
+ */
__le32 peer_ht_info[2];
} __packed;
--
2.7.4
^ permalink raw reply related
* [PATCH] ath10k: Clean header files from bad block comments
From: Marcin Rokicki @ 2017-02-20 14:38 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Marcin Rokicki
Fix output from checkpatch.pl like:
Block comments use a trailing */ on a separate line
Signed-off-by: Marcin Rokicki <marcin.rokicki@tieto.com>
---
drivers/net/wireless/ath/ath10k/bmi.h | 3 ++-
drivers/net/wireless/ath/ath10k/core.h | 9 ++++++---
drivers/net/wireless/ath/ath10k/hif.h | 6 ++++--
drivers/net/wireless/ath/ath10k/htt.h | 24 +++++++++++++++--------
drivers/net/wireless/ath/ath10k/hw.h | 3 ++-
drivers/net/wireless/ath/ath10k/rx_desc.h | 13 ++++++++-----
drivers/net/wireless/ath/ath10k/targaddrs.h | 19 +++++++++---------
drivers/net/wireless/ath/ath10k/wmi-ops.h | 3 ++-
drivers/net/wireless/ath/ath10k/wmi.h | 30 +++++++++++++++++++----------
9 files changed, 70 insertions(+), 40 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/bmi.h b/drivers/net/wireless/ath/ath10k/bmi.h
index 7d3231a..98be562 100644
--- a/drivers/net/wireless/ath/ath10k/bmi.h
+++ b/drivers/net/wireless/ath/ath10k/bmi.h
@@ -176,7 +176,8 @@ union bmi_resp {
} rompatch_uninstall;
struct {
/* 0 = nothing executed
- * otherwise = NVRAM segment return value */
+ * otherwise = NVRAM segment return value
+ */
__le32 result;
} nvram_process;
u8 payload[BMI_MAX_CMDBUF_SIZE];
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 88d14be..53a66e6 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -501,14 +501,16 @@ enum ath10k_state {
* stopped in ath10k_core_restart() work holding conf_mutex. The state
* RESTARTED means that the device is up and mac80211 has started hw
* reconfiguration. Once mac80211 is done with the reconfiguration we
- * set the state to STATE_ON in reconfig_complete(). */
+ * set the state to STATE_ON in reconfig_complete().
+ */
ATH10K_STATE_RESTARTING,
ATH10K_STATE_RESTARTED,
/* The device has crashed while restarting hw. This state is like ON
* but commands are blocked in HTC and -ECOMM response is given. This
* prevents completion timeouts and makes the driver more responsive to
- * userspace commands. This is also prevents recursive recovery. */
+ * userspace commands. This is also prevents recursive recovery.
+ */
ATH10K_STATE_WEDGED,
/* factory tests */
@@ -918,7 +920,8 @@ struct ath10k {
struct work_struct restart_work;
/* cycle count is reported twice for each visited channel during scan.
- * access protected by data_lock */
+ * access protected by data_lock
+ */
u32 survey_last_rx_clear_count;
u32 survey_last_cycle_count;
struct survey_info survey[ATH10K_NUM_CHANS];
diff --git a/drivers/net/wireless/ath/ath10k/hif.h b/drivers/net/wireless/ath/ath10k/hif.h
index b2566b0..6679dd9 100644
--- a/drivers/net/wireless/ath/ath10k/hif.h
+++ b/drivers/net/wireless/ath/ath10k/hif.h
@@ -54,7 +54,8 @@ struct ath10k_hif_ops {
int (*start)(struct ath10k *ar);
/* Clean up what start() did. This does not revert to BMI phase. If
- * desired so, call power_down() and power_up() */
+ * desired so, call power_down() and power_up()
+ */
void (*stop)(struct ath10k *ar);
int (*map_service_to_pipe)(struct ath10k *ar, u16 service_id,
@@ -82,7 +83,8 @@ struct ath10k_hif_ops {
int (*power_up)(struct ath10k *ar);
/* Power down the device and free up resources. stop() must be called
- * before this if start() was called earlier */
+ * before this if start() was called earlier
+ */
void (*power_down)(struct ath10k *ar);
int (*suspend)(struct ath10k *ar);
diff --git a/drivers/net/wireless/ath/ath10k/htt.h b/drivers/net/wireless/ath/ath10k/htt.h
index 90c2f72..6305308 100644
--- a/drivers/net/wireless/ath/ath10k/htt.h
+++ b/drivers/net/wireless/ath/ath10k/htt.h
@@ -51,7 +51,8 @@ enum htt_h2t_msg_type { /* host-to-target */
HTT_H2T_MSG_TYPE_FRAG_DESC_BANK_CFG = 6,
/* This command is used for sending management frames in HTT < 3.0.
- * HTT >= 3.0 uses TX_FRM for everything. */
+ * HTT >= 3.0 uses TX_FRM for everything.
+ */
HTT_H2T_MSG_TYPE_MGMT_TX = 7,
HTT_H2T_MSG_TYPE_TX_FETCH_RESP = 11,
@@ -910,7 +911,8 @@ struct htt_rx_test {
/* payload consists of 2 lists:
* a) num_ints * sizeof(__le32)
- * b) num_chars * sizeof(u8) aligned to 4bytes */
+ * b) num_chars * sizeof(u8) aligned to 4bytes
+ */
u8 payload[0];
} __packed;
@@ -1307,7 +1309,8 @@ struct htt_frag_desc_bank_id {
} __packed;
/* real is 16 but it wouldn't fit in the max htt message size
- * so we use a conservatively safe value for now */
+ * so we use a conservatively safe value for now
+ */
#define HTT_FRAG_DESC_BANK_MAX 4
#define HTT_FRAG_DESC_BANK_CFG_INFO_PDEV_ID_MASK 0x03
@@ -1684,12 +1687,14 @@ struct ath10k_htt {
DECLARE_KFIFO_PTR(txdone_fifo, struct htt_tx_done);
/* set if host-fw communication goes haywire
- * used to avoid further failures */
+ * used to avoid further failures
+ */
bool rx_confused;
atomic_t num_mpdus_ready;
/* This is used to group tx/rx completions separately and process them
- * in batches to reduce cache stalls */
+ * in batches to reduce cache stalls
+ */
struct sk_buff_head rx_compl_q;
struct sk_buff_head rx_in_ord_compl_q;
struct sk_buff_head tx_fetch_ind_q;
@@ -1725,11 +1730,13 @@ struct ath10k_htt {
/* This structure layout is programmed via rx ring setup
* so that FW knows how to transfer the rx descriptor to the host.
- * Buffers like this are placed on the rx ring. */
+ * Buffers like this are placed on the rx ring.
+ */
struct htt_rx_desc {
union {
/* This field is filled on the host using the msdu buffer
- * from htt_rx_indication */
+ * from htt_rx_indication
+ */
struct fw_rx_desc_base fw_desc;
u32 pad;
} __packed;
@@ -1760,7 +1767,8 @@ struct htt_rx_desc {
#define HTT_RX_MSDU_SIZE (HTT_RX_BUF_SIZE - (int)sizeof(struct htt_rx_desc))
/* Refill a bunch of RX buffers for each refill round so that FW/HW can handle
- * aggregated traffic more nicely. */
+ * aggregated traffic more nicely.
+ */
#define ATH10K_HTT_MAX_NUM_REFILL 100
/*
diff --git a/drivers/net/wireless/ath/ath10k/hw.h b/drivers/net/wireless/ath/ath10k/hw.h
index f0fda0f..5343376 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -293,7 +293,8 @@ void ath10k_hw_fill_survey_time(struct ath10k *ar, struct survey_info *survey,
* - raw appears in nwifi decap, raw and nwifi appear in ethernet decap
* - raw have FCS, nwifi doesn't
* - ethernet frames have 802.11 header decapped and parts (base hdr, cipher
- * param, llc/snap) are aligned to 4byte boundaries each */
+ * param, llc/snap) are aligned to 4byte boundaries each
+ */
enum ath10k_hw_txrx_mode {
ATH10K_HW_TXRX_RAW = 0,
diff --git a/drivers/net/wireless/ath/ath10k/rx_desc.h b/drivers/net/wireless/ath/ath10k/rx_desc.h
index 034e7a5..c1022a1 100644
--- a/drivers/net/wireless/ath/ath10k/rx_desc.h
+++ b/drivers/net/wireless/ath/ath10k/rx_desc.h
@@ -439,19 +439,22 @@ struct rx_mpdu_end {
* c) A-MSDU subframe header (14 bytes) if appliable
* d) LLC/SNAP (RFC1042, 8 bytes)
*
- * In case of A-MSDU only first frame in sequence contains (a) and (b). */
+ * In case of A-MSDU only first frame in sequence contains (a) and (b).
+ */
enum rx_msdu_decap_format {
RX_MSDU_DECAP_RAW = 0,
/* Note: QoS frames are reported as non-QoS. The rx_hdr_status in
- * htt_rx_desc contains the original decapped 802.11 header. */
+ * htt_rx_desc contains the original decapped 802.11 header.
+ */
RX_MSDU_DECAP_NATIVE_WIFI = 1,
/* Payload contains an ethernet header (struct ethhdr). */
RX_MSDU_DECAP_ETHERNET2_DIX = 2,
/* Payload contains two 48-bit addresses and 2-byte length (14 bytes
- * total), followed by an RFC1042 header (8 bytes). */
+ * total), followed by an RFC1042 header (8 bytes).
+ */
RX_MSDU_DECAP_8023_SNAP_LLC = 3
};
@@ -867,7 +870,7 @@ struct rx_ppdu_start {
*
* reserved_9
* Reserved: HW should fill with 0, FW should ignore.
-*/
+ */
#define RX_PPDU_END_FLAGS_PHY_ERR (1 << 0)
#define RX_PPDU_END_FLAGS_RX_LOCATION (1 << 1)
@@ -1207,7 +1210,7 @@ struct rx_ppdu_end {
* Every time HW sets this bit in memory FW/SW must clear this
* bit in memory. FW will initialize all the ppdu_done dword
* to 0.
-*/
+ */
#define FW_RX_DESC_INFO0_DISCARD (1 << 0)
#define FW_RX_DESC_INFO0_FORWARD (1 << 1)
diff --git a/drivers/net/wireless/ath/ath10k/targaddrs.h b/drivers/net/wireless/ath/ath10k/targaddrs.h
index a47cab4..cbac9e42 100644
--- a/drivers/net/wireless/ath/ath10k/targaddrs.h
+++ b/drivers/net/wireless/ath/ath10k/targaddrs.h
@@ -268,13 +268,13 @@ struct host_interest {
#define HI_OPTION_FW_BRIDGE_SHIFT 0x04
/*
-Fw Mode/SubMode Mask
-|-----------------------------------------------------------------------------|
-| SUB | SUB | SUB | SUB | | | | |
-|MODE[3] | MODE[2] | MODE[1] | MODE[0] | MODE[3] | MODE[2] | MODE[1] | MODE[0]|
-| (2) | (2) | (2) | (2) | (2) | (2) | (2) | (2) |
-|-----------------------------------------------------------------------------|
-*/
+ * Fw Mode/SubMode Mask
+ *-----------------------------------------------------------------------------
+ * SUB | SUB | SUB | SUB | | | |
+ *MODE[3] | MODE[2] | MODE[1] | MODE[0] | MODE[3] | MODE[2] | MODE[1] | MODE[0]
+ * (2) | (2) | (2) | (2) | (2) | (2) | (2) | (2)
+ *-----------------------------------------------------------------------------
+ */
#define HI_OPTION_FW_MODE_BITS 0x2
#define HI_OPTION_FW_MODE_MASK 0x3
#define HI_OPTION_FW_MODE_SHIFT 0xC
@@ -428,8 +428,9 @@ Fw Mode/SubMode Mask
#define HI_PWR_SAVE_LPL_ENABLED 0x1
/*b1-b3 reserved*/
/*b4-b5 : dev0 LPL type : 0 - none
- 1- Reduce Pwr Search
- 2- Reduce Pwr Listen*/
+ * 1- Reduce Pwr Search
+ * 2- Reduce Pwr Listen
+ */
/*b6-b7 : dev1 LPL type and so on for Max 8 devices*/
#define HI_PWR_SAVE_LPL_DEV0_LSB 4
#define HI_PWR_SAVE_LPL_DEV_MASK 0x3
diff --git a/drivers/net/wireless/ath/ath10k/wmi-ops.h b/drivers/net/wireless/ath/ath10k/wmi-ops.h
index c7956e1..2fc3f24 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-ops.h
+++ b/drivers/net/wireless/ath/ath10k/wmi-ops.h
@@ -390,7 +390,8 @@ ath10k_wmi_mgmt_tx(struct ath10k *ar, struct sk_buff *msdu)
return ret;
/* FIXME There's no ACK event for Management Tx. This probably
- * shouldn't be called here either. */
+ * shouldn't be called here either.
+ */
info->flags |= IEEE80211_TX_STAT_ACK;
ieee80211_tx_status_irqsafe(ar->hw, msdu);
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
index 386aa51..427220c 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -1038,7 +1038,8 @@ enum wmi_cmd_id {
WMI_STA_UAPSD_AUTO_TRIG_CMDID,
/* STA Keep alive parameter configuration,
- Requires WMI_SERVICE_STA_KEEP_ALIVE */
+ * Requires WMI_SERVICE_STA_KEEP_ALIVE
+ */
WMI_STA_KEEPALIVE_CMD,
/* misc command group */
@@ -1774,7 +1775,8 @@ static inline const char *ath10k_wmi_phymode_str(enum wmi_phy_mode mode)
break;
/* no default handler to allow compiler to check that the
- * enum is fully handled */
+ * enum is fully handled
+ */
};
return "<unknown>";
@@ -2974,7 +2976,8 @@ struct wmi_start_scan_arg {
/* When set, DFS channels will not be scanned */
#define WMI_SCAN_BYPASS_DFS_CHN 0x40
/* Different FW scan engine may choose to bail out on errors.
- * Allow the driver to have influence over that. */
+ * Allow the driver to have influence over that.
+ */
#define WMI_SCAN_CONTINUE_ON_ERROR 0x80
/* WMI_SCAN_CLASS_MASK must be the same value as IEEE80211_SCAN_CLASS_MASK */
@@ -4447,14 +4450,16 @@ enum wmi_vdev_subtype_10_4 {
/* values for vdev_start_request flags */
/*
* Indicates that AP VDEV uses hidden ssid. only valid for
- * AP/GO */
+ * AP/GO
+ */
#define WMI_VDEV_START_HIDDEN_SSID (1 << 0)
/*
* Indicates if robust management frame/management frame
* protection is enabled. For GO/AP vdevs, it indicates that
* it may support station/client associations with RMF enabled.
* For STA/client vdevs, it indicates that sta will
- * associate with AP with RMF enabled. */
+ * associate with AP with RMF enabled.
+ */
#define WMI_VDEV_START_PMF_ENABLED (1 << 1)
struct wmi_p2p_noa_descriptor {
@@ -4814,7 +4819,8 @@ enum wmi_vdev_param {
* An associated STA is considered unresponsive if there is no recent
* TX/RX activity and downlink frames are buffered for it. Once a STA
* exceeds the maximum unresponsive time, the AP will send a
- * WMI_STA_KICKOUT event to the host so the STA can be deleted. */
+ * WMI_STA_KICKOUT event to the host so the STA can be deleted.
+ */
WMI_VDEV_PARAM_AP_KEEPALIVE_MAX_UNRESPONSIVE_TIME_SECS,
/* Enable NAWDS : MCAST INSPECT Enable, NAWDS Flag set */
@@ -4941,7 +4947,8 @@ enum wmi_10x_vdev_param {
* An associated STA is considered unresponsive if there is no recent
* TX/RX activity and downlink frames are buffered for it. Once a STA
* exceeds the maximum unresponsive time, the AP will send a
- * WMI_10X_STA_KICKOUT event to the host so the STA can be deleted. */
+ * WMI_10X_STA_KICKOUT event to the host so the STA can be deleted.
+ */
WMI_10X_VDEV_PARAM_AP_KEEPALIVE_MAX_UNRESPONSIVE_TIME_SECS,
/* Enable NAWDS : MCAST INSPECT Enable, NAWDS Flag set */
@@ -5605,12 +5612,14 @@ struct wmi_tim_info_arg {
struct wmi_p2p_noa_info {
/* Bit 0 - Flag to indicate an update in NOA schedule
- Bits 7-1 - Reserved */
+ * Bits 7-1 - Reserved
+ */
u8 changed;
/* NOA index */
u8 index;
/* Bit 0 - Opp PS state of the AP
- Bits 1-7 - Ctwindow in TUs */
+ * Bits 1-7 - Ctwindow in TUs
+ */
u8 ctwindow_oppps;
/* Number of NOA descriptors */
u8 num_descriptors;
@@ -6000,7 +6009,8 @@ struct wmi_main_peer_assoc_complete_cmd {
struct wmi_common_peer_assoc_complete_cmd cmd;
/* HT Operation Element of the peer. Five bytes packed in 2
- * INT32 array and filled from lsb to msb. */
+ * INT32 array and filled from lsb to msb.
+ */
__le32 peer_ht_info[2];
} __packed;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v2] rtl8187: Enable monitor mode to fix multicast reception
From: Larry Finger @ 2017-02-20 16:18 UTC (permalink / raw)
To: Rafał Miłecki, Nils Holland, linux-wireless; +Cc: Kalle Valo
In-Reply-To: <6dafa711-2118-ed6d-4b55-2640a3b852e5@gmail.com>
On 02/20/2017 12:35 AM, Rafał Miłecki wrote:
> On 02/20/2017 12:59 AM, Nils Holland wrote:
>> The rtl8187 cards don't seem to receive multicast frames, which,
>> among other things, makes them fail to receive RAs in IPv6 networks.
>> The cause seems to be that the RTL818X_RX_CONF_MULTICAST flag doesn't
>> have the desired effect.
>
> AFAIU you have RTL8187B chipset card only, but above message describes this as
> generic issue (including RTL8187 and RTL8187L).
>
> Larry: were you able to reproduce this problem using RTL8187L? Is this
> workaround needed for that chipset as well? I couldn't find clear statement.
Yes, the RTL8187L has the same problem as the RTL8187B. The fix is needed for both.
Larry
^ permalink raw reply
* Re: [RFC 1/5] iwlwifi: fix drv cleanup on opmode registration failure
From: Luis R. Rodriguez @ 2017-02-20 17:32 UTC (permalink / raw)
To: Grumbach, Emmanuel
Cc: Luis R. Rodriguez, Berg, Johannes, Coelho, Luciano, tj@kernel.org,
arjan@linux.intel.com, ming.lei@canonical.com, zajec5@gmail.com,
jeyu@redhat.com, rusty@rustcorp.com.au, pmladek@suse.com,
gregkh@linuxfoundation.org, linuxwifi,
linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <0BA3FCBA62E2DC44AF3030971E174FB3A8F4AD47@hasmsx107.ger.corp.intel.com>
On Sun, Feb 19, 2017 at 09:16:01AM +0000, Grumbach, Emmanuel wrote:
> > This should in theory fix a detangled drv from the drv list should either of the
> > opmode modules loaded and handled registration for the drv.
> >
> > The path of having the opmode registration deal with the drv opmode start is
> > actually the more common path. The other path, from the async callback is
> > rathe rare (1/8 or so times for me) -- it happens when the the opmode
> > driver's init routine completed prior to the driver's async callback opmode
> > start call.
>
> I'd claim it should never happen unless you have several devices on the system using the same
> opmode, or unless you do:
> modprobe iwlwifi #which will load iwl{d,m}vm
> rmmod iwl{d,m}vm #and do _not_ remove iwlwifi
> modprobe iwlwifi
That is indeed one way one can easily reproduce this. There are however other
ways too. Try a loop of
modprobe -r iwlmvm (which removes iwlwifi) followed by modprobe iwlmvm;
while this check for which path is taken, or better yet check if the
list of drvs is empty on opmode registration. Every now and then I see
the list is empty.
I have a feeling this is then also a rare rarely observed by your QA team
as well, so this code then is also stitching together a set of sequence
calls for both paths.
> > Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
> > ---
>
> Luca is OOO, but this looks fine to me.
Reviewed-by ?
Luis
^ permalink raw reply
* Re: [PATCH v2] rtl8187: Enable monitor mode to fix multicast reception
From: Rafał Miłecki @ 2017-02-20 17:50 UTC (permalink / raw)
To: Larry Finger, Nils Holland, linux-wireless; +Cc: Kalle Valo
In-Reply-To: <33f6e879-541f-ef45-f533-98b44e6aa2a9@lwfinger.net>
On 02/20/2017 05:18 PM, Larry Finger wrote:
> On 02/20/2017 12:35 AM, Rafał Miłecki wrote:
>> On 02/20/2017 12:59 AM, Nils Holland wrote:
>>> The rtl8187 cards don't seem to receive multicast frames, which,
>>> among other things, makes them fail to receive RAs in IPv6 networks.
>>> The cause seems to be that the RTL818X_RX_CONF_MULTICAST flag doesn't
>>> have the desired effect.
>>
>> AFAIU you have RTL8187B chipset card only, but above message describes this as
>> generic issue (including RTL8187 and RTL8187L).
>>
>> Larry: were you able to reproduce this problem using RTL8187L? Is this
>> workaround needed for that chipset as well? I couldn't find clear statement.
>
> Yes, the RTL8187L has the same problem as the RTL8187B. The fix is needed for both.
OK, thanks for clarifying!
^ permalink raw reply
* [PATCH 2/2] uapi: fix linux/nfc.h userspace compilation errors
From: Dmitry V. Levin @ 2017-02-20 18:16 UTC (permalink / raw)
To: Lauro Ramos Venancio, Aloisio Almeida Jr, Samuel Ortiz
Cc: linux-wireless, linux-kernel
Replace sa_family_t with __kernel_sa_family_t to fix the following
linux/nfc.h userspace compilation errors:
/usr/include/linux/nfc.h:264:2: error: unknown type name 'sa_family_t'
sa_family_t sa_family;
/usr/include/linux/nfc.h:272:2: error: unknown type name 'sa_family_t'
sa_family_t sa_family;
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
---
include/uapi/linux/nfc.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/uapi/linux/nfc.h b/include/uapi/linux/nfc.h
index f8ccc12..1b6d54a 100644
--- a/include/uapi/linux/nfc.h
+++ b/include/uapi/linux/nfc.h
@@ -261,7 +261,7 @@ enum nfc_sdp_attr {
#define NFC_SE_ENABLED 0x1
struct sockaddr_nfc {
- sa_family_t sa_family;
+ __kernel_sa_family_t sa_family;
__u32 dev_idx;
__u32 target_idx;
__u32 nfc_protocol;
@@ -269,7 +269,7 @@ struct sockaddr_nfc {
#define NFC_LLCP_MAX_SERVICE_NAME 63
struct sockaddr_nfc_llcp {
- sa_family_t sa_family;
+ __kernel_sa_family_t sa_family;
__u32 dev_idx;
__u32 target_idx;
__u32 nfc_protocol;
--
ldv
^ permalink raw reply related
* [PATCH 1/2] uapi: fix definition of struct sockaddr_nfc_llcp on x32 and mips n32
From: Dmitry V. Levin @ 2017-02-20 18:15 UTC (permalink / raw)
To: Lauro Ramos Venancio, Aloisio Almeida Jr, Samuel Ortiz,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin
Cc: linux-wireless, x86, linux-mips, linux-kernel
Replace size_t with __kernel_size_t to fix definition of struct
sockaddr_nfc_llcp on architectures like x32 and mips n32 where
sizeof(size_t) < sizeof(__kernel_size_t).
This also fixes the following linux/nfc.h userspace compilation error:
/usr/include/linux/nfc.h:279:2: error: unknown type name 'size_t'
size_t service_name_len;
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
---
include/uapi/linux/nfc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/uapi/linux/nfc.h b/include/uapi/linux/nfc.h
index 399f39f..f8ccc12 100644
--- a/include/uapi/linux/nfc.h
+++ b/include/uapi/linux/nfc.h
@@ -276,7 +276,7 @@ struct sockaddr_nfc_llcp {
__u8 dsap; /* Destination SAP, if known */
__u8 ssap; /* Source SAP to be bound to */
char service_name[NFC_LLCP_MAX_SERVICE_NAME]; /* Service name URI */;
- size_t service_name_len;
+ __kernel_size_t service_name_len;
};
/* NFC socket protocols */
--
ldv
^ permalink raw reply related
* Re: [PATCH 1/2] uapi: fix definition of struct sockaddr_nfc_llcp on x32 and mips n32
From: Dmitry V. Levin @ 2017-02-20 21:28 UTC (permalink / raw)
To: Lauro Ramos Venancio, Aloisio Almeida Jr, Samuel Ortiz,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin
Cc: linux-wireless, x86, linux-mips, linux-kernel
In-Reply-To: <20170220181533.GA11185@altlinux.org>
On Mon, Feb 20, 2017 at 09:15:33PM +0300, Dmitry V. Levin wrote:
> Replace size_t with __kernel_size_t to fix definition of struct
> sockaddr_nfc_llcp on architectures like x32 and mips n32 where
> sizeof(size_t) < sizeof(__kernel_size_t).
>
> This also fixes the following linux/nfc.h userspace compilation error:
>
> /usr/include/linux/nfc.h:279:2: error: unknown type name 'size_t'
> size_t service_name_len;
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
> ---
> include/uapi/linux/nfc.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/uapi/linux/nfc.h b/include/uapi/linux/nfc.h
> index 399f39f..f8ccc12 100644
> --- a/include/uapi/linux/nfc.h
> +++ b/include/uapi/linux/nfc.h
> @@ -276,7 +276,7 @@ struct sockaddr_nfc_llcp {
> __u8 dsap; /* Destination SAP, if known */
> __u8 ssap; /* Source SAP to be bound to */
> char service_name[NFC_LLCP_MAX_SERVICE_NAME]; /* Service name URI */;
> - size_t service_name_len;
> + __kernel_size_t service_name_len;
> };
>
> /* NFC socket protocols */
Unfortunately, this is not the right fix for the problem.
It was definitely a bad idea to use architecture dependent types
in the definition of struct sockaddr_nfc_llcp. Somebody will have
to implement a compat layer to make it work properly with x86, x32,
and other compat personalities.
--
ldv
^ permalink raw reply
* Monitor mode 'cook' flag meaning
From: Thomas d'Otreppe @ 2017-02-20 23:22 UTC (permalink / raw)
To: linux-wireless
I've been looking through the different flags for monitor mode in iw.
Most of them are rather obvious (and well explained) but what is
exactly 'cooked mode'?
I looked up in Google and in the linux-wireless wiki (nothing in
there) and I only found explanations in 2 patches (most likely still
in the source code) which are still vague:
- A monitor interface in "cooked" mode will see all frames that
mac80211 has not used internally
- report frames after processing. Overrides all other flags.
Thinking about what the first one says, it doesn't seem any different
than just fcsfail. I don't even see when control or otherbss should be
needed since 'none' is already providing them.
Am I correct? Or is it related to transmitting frames? And in this case, how?
Thanks in advance,
Thomas
^ permalink raw reply
* Re: Monitor mode 'cook' flag meaning
From: Johannes Berg @ 2017-02-20 23:26 UTC (permalink / raw)
To: Thomas d'Otreppe, linux-wireless
In-Reply-To: <CALs6+XLDZLmc6JWMPun4sT+W_M4Cqh47LcK+HjiuZ8gKFLkbTA@mail.gmail.com>
On Mon, 2017-02-20 at 16:22 -0700, Thomas d'Otreppe wrote:
> I've been looking through the different flags for monitor mode in iw.
> Most of them are rather obvious (and well explained) but what is
> exactly 'cooked mode'?
>
> I looked up in Google and in the linux-wireless wiki (nothing in
> there) and I only found explanations in 2 patches (most likely still
> in the source code) which are still vague:
> - A monitor interface in "cooked" mode will see all frames that
> mac80211 has not used internally
> - report frames after processing. Overrides all other flags.
>
> Thinking about what the first one says, it doesn't seem any different
> than just fcsfail.
No, that's the wrong idea. "cook" means that e.g. auth frames that
mac80211 didn't actually look at will be sent there.
Anyway, ignore cooked mode. It's only for ancient hostapd versions.
> I don't even see when control or otherbss should be needed since
> 'none' is already providing them.
Those are hw-dependent.
johannes
^ permalink raw reply
* Re: [PATCH v6 1/3] cfg80211: Accept multiple RSSI thresholds for CQM
From: Andrew Zaborowski @ 2017-02-21 1:44 UTC (permalink / raw)
To: Kalle Valo; +Cc: Johannes Berg, linux-wireless
In-Reply-To: <87vasb96ep.fsf@purkki.adurom.net>
Hi,
On 15 February 2017 at 09:58, Kalle Valo <kvalo@codeaurora.org> wrote:
> Johannes Berg <johannes@sipsolutions.net> writes:
>> On Fri, 2017-02-10 at 10:02 +0100, Andrew Zaborowski wrote:
>>> Change the SET CQM command's RSSI threshold attribute to accept any
>>> number of thresholds as a sorted array. The API should be backwards
>>> compatible so that if one s32 threshold value is passed, the old
>>> mechanism is enabled. The netlink event generated is the same in
>>> both cases.
>>
>> I've applied this now, thanks for your patience :)
>>
>> I got a bit confused - and then fixed it up - patchwork has giving your
>> name as "Andrzej Zaborowski" which apparently you didn't really want
>> (any more). I've fixed it for these patches to be as the patches you
>> sent, but no guarantees I've done this before or will remember to do
>> that in the future - if you can somehow change your name in patchwork
>> (patchwork.kernel.org) that would be good.
Thanks, changed it for consistency now.
>
> IIRC if you haven't registered to patchwork.kernel.org it's possible to
> change the name easily. But after registration the user needs to contact
> helpdesk to change the name.
Indeed I was able to set name on registration today but can see no way
to modify it. The project's mailing list has a thread about a patch
that's about to be backported to the patchwork.kernel.org version
though, https://github.com/getpatchwork/patchwork/commit/d365402fb98dfb2c4aea4b58346096f85bdfa0c3
Best regards
^ permalink raw reply
* Re: Monitor mode 'cook' flag meaning
From: Thomas d'Otreppe @ 2017-02-21 1:46 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1487633211.484.1.camel@sipsolutions.net>
Do you have any example of devices where control or otherbss would be
useful? Would both be for FullMAC devices?
Thanks,
Thomas
On Mon, Feb 20, 2017 at 4:26 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Mon, 2017-02-20 at 16:22 -0700, Thomas d'Otreppe wrote:
>> I've been looking through the different flags for monitor mode in iw.
>> Most of them are rather obvious (and well explained) but what is
>> exactly 'cooked mode'?
>>
>> I looked up in Google and in the linux-wireless wiki (nothing in
>> there) and I only found explanations in 2 patches (most likely still
>> in the source code) which are still vague:
>> - A monitor interface in "cooked" mode will see all frames that
>> mac80211 has not used internally
>> - report frames after processing. Overrides all other flags.
>>
>> Thinking about what the first one says, it doesn't seem any different
>> than just fcsfail.
>
> No, that's the wrong idea. "cook" means that e.g. auth frames that
> mac80211 didn't actually look at will be sent there.
>
> Anyway, ignore cooked mode. It's only for ancient hostapd versions.
>
>> I don't even see when control or otherbss should be needed since
>> 'none' is already providing them.
>
> Those are hw-dependent.
>
> johannes
^ permalink raw reply
* Re: [RFC 2/5] iwlwifi: fix request_module() use
From: Luis R. Rodriguez @ 2017-02-21 2:23 UTC (permalink / raw)
To: Grumbach, Emmanuel
Cc: Luis R. Rodriguez, Berg, Johannes, Coelho, Luciano, tj@kernel.org,
arjan@linux.intel.com, ming.lei@canonical.com, zajec5@gmail.com,
jeyu@redhat.com, rusty@rustcorp.com.au, pmladek@suse.com,
gregkh@linuxfoundation.org, linuxwifi,
linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <0BA3FCBA62E2DC44AF3030971E174FB3A8F4AE27@hasmsx107.ger.corp.intel.com>
On Sun, Feb 19, 2017 at 09:47:59AM +0000, Grumbach, Emmanuel wrote:
> >
> > The return value of request_module() being 0 does not mean that the driver
> > which was requested has loaded. To properly check that the driver was
> > loaded each driver can use internal mechanisms to vet the driver is now
> > present. The helper try_then_request_module() was added to help with
> > this, allowing drivers to specify their own validation as the first argument.
> >
> > On iwlwifi the use case is a bit more complicated given that the value we
> > need to check for is protected with a mutex later used on the
> > module_init() of the module we are asking for. If we were to lock and
> > request_module() we'd deadlock. iwlwifi needs its own wrapper then so it
> > can handle its special locking requirements.
> >
> > Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
>
> I don't see the problem with the current code. We don't assume that everything has been
> loaded immediately after request_module returns. We just free the intermediate firmware
> structures that won't be using anymore. What happens here is that after request_module
> returns, we patiently wait until it is loaded, and when that happens, iwl{d,m}vm's init function
> will be called.
Right I get that.
The code today complains if its respective opmode module was not loaded
if request_module() did not return 0. As the commit log explains, relying
on a return code of 0 to ensure a module loads is not sufficient. So the
current print is almost pointless, so best we either:
a) just remove the print and use instead request_module_nowait() (this is more
in alignment of what your code actually does today; or
b) fix the request_module() use so that the error print matches the expected
and proper recommended use of request_module() (what this patch does)
I prefer a) actually but I had to show what b) looked like first :)
The only issue with a) is today we have no *slim* way to let drivers
load a module asynchronously and then later verify it did get loaded.
>From a *quick* look this grammatical form of request_module_nowait() and
a verifier is essentially is not widely popular or not present at all
today. A verifier seems reasonable if you use request_module_nowait()
though and want to be pedantic about ensuring the module is there.
What this might look like for iwlwifi? Something like this:
diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-drv.c b/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
index be466a074c1d..8059e1dab061 100644
--- a/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
@@ -137,11 +137,16 @@ static struct iwlwifi_opmode_table {
const char *name; /* name: iwldvm, iwlmvm, etc */
const struct iwl_op_mode_ops *ops; /* pointer to op_mode ops */
struct list_head drv; /* list of devices using this op_mode */
+ bool load_requested; /* Do we need to load a driver ? */
+ struct iwl_drv *drv_req; /* Device that set load_requested */
} iwlwifi_opmode_table[] = { /* ops set when driver is initialized */
[DVM_OP_MODE] = { .name = "iwldvm", .ops = NULL },
[MVM_OP_MODE] = { .name = "iwlmvm", .ops = NULL },
};
+static void iwlwifi_load_opmode(struct work_struct *work);
+static DECLARE_DELAYED_WORK(iwl_opload_work, iwlwifi_load_opmode);
+
#define IWL_DEFAULT_SCAN_CHANNELS 40
/*
@@ -1231,6 +1236,43 @@ static void _iwl_op_mode_stop(struct iwl_drv *drv)
}
}
+static void iwlwifi_load_opmode(struct work_struct *work)
+{
+ struct iwl_drv *drv = NULL;
+ struct iwlwifi_opmode_table *op;
+ unsigned int i;
+
+ mutex_lock(&iwlwifi_opmode_table_mtx);
+ for (i = 0; i < ARRAY_SIZE(iwlwifi_opmode_table); i++) {
+ op = &iwlwifi_opmode_table[i];
+ if (!op->load_requested)
+ continue;
+ drv = op->drv_req;
+
+ if (!op->ops && drv) {
+ IWL_ERR(drv,
+ "failed to load module %s, is dynamic loading enabled?\n",
+ op->name);
+ complete(&drv->request_firmware_complete);
+ device_release_driver(drv->trans->dev);
+ mutex_unlock(&iwlwifi_opmode_table_mtx);
+ return;
+ }
+
+ op->load_requested = false;
+ op->drv_req = NULL;
+ }
+ mutex_unlock(&iwlwifi_opmode_table_mtx);
+
+
+ /*
+ * Complete the firmware request last so that
+ * a driver unbind (stop) doesn't run while we
+ * are doing the opmode start().
+ */
+ complete(&drv->request_firmware_complete);
+}
+
/**
* iwl_req_fw_callback - callback when firmware was loaded
*
@@ -1250,7 +1292,6 @@ static void iwl_req_fw_callback(const struct firmware *ucode_raw, void *context)
size_t trigger_tlv_sz[FW_DBG_TRIGGER_MAX];
u32 api_ver;
int i;
- bool load_module = false;
bool usniffer_images = false;
fw->ucode_capa.max_probe_length = IWL_DEFAULT_MAX_PROBE_LENGTH;
@@ -1455,31 +1496,26 @@ static void iwl_req_fw_callback(const struct firmware *ucode_raw, void *context)
goto out_unbind;
}
} else {
- load_module = true;
+ op->load_requested = true;
+ op->drv_req = drv;
}
mutex_unlock(&iwlwifi_opmode_table_mtx);
/*
- * Complete the firmware request last so that
- * a driver unbind (stop) doesn't run while we
- * are doing the start() above.
- */
- complete(&drv->request_firmware_complete);
-
- /*
* Load the module last so we don't block anything
* else from proceeding if the module fails to load
* or hangs loading.
+ *
+ * Always try loading it, even if we were built-in as
+ * in built-in cases this will be a no-op and so will
+ * the verifier check.
*/
- if (load_module) {
- err = request_module("%s", op->name);
-#ifdef CONFIG_IWLWIFI_OPMODE_MODULAR
- if (err)
- IWL_ERR(drv,
- "failed to load module %s (error %d), is dynamic loading enabled?\n",
- op->name, err);
-#endif
- }
+ err = request_module_nowait("%s", op->name);
+ if (err)
+ goto out_unbind;
+
+ schedule_delayed_work(&iwl_opload_work, HZ);
+
goto free;
try_again:
So consider this for your driver -- if you agree today's print is rather
pointless upon failure then you'd be OK in just using request_module_nowait()
and removing the print -- and not adding a verifier step 2 like the above.
Only -- it seems you want a verifier.
So you have 2 options with a suboptions:
1) keep sync request and add the verifier -- as in the original patch in this e-mail
2) use async request and
2a) add verifier
2b) ignore the verifier
I don't see why you'd want 2b) is what I'm trying to say and the point of this
path is to show what a 1) would look like.
The point of this email also is to highlight what it would look like in general
if we wanted verifiers for module request for async_schedule() calls, given
they cannot use request_module() and *must* use request_module_nowait() and
that ultimately begs the question if they want verifiers or not as well.
For iwlwifi and wireless this is only generally relevant for the async
callback for firmware requests, but it seems only iwlwifi uses this form.
I used async_schedule() for the driver data API which I'm developing,
and as such 2a or a solution for 1) was needed in such a way it was
compatible.
> That one is the one that continues the flow by calling:
>
> ret = iwl_opmode_register("iwlmvm", &iwl_mvm_ops);
>
> (for the iwlmvm case).
>
> Where am I wrong here?
You are right, but note the 2 possible ways in which the alternative path
can be taken in the prior code we discussed, this should ensure we complain
if upon a load the module is really not present. From what I recall from
my testing it turns out though that in practice this *still* is still allowing
for the case where iwlmvm loads prior to iwlwifi's async fw callback code
checks for the opmode. One can test this with a loop of:
modprobe -r iwlmvm; while true; do modprobe iwlmvm; modprobe -r iwlmvm; dmesg -c && echo ; done
Prior to this add a check for an empty list on the opmode registration, if its
empty then we've hit the path discussed. In the loop above we are *triggering*
the load of iwlmvm first, that's why it *can* load first. If we wanted to ensure
iwlmvm and other other opmode load second we can add a simply symbol dependency
from the opmodes to the iwlwifi driver.
Luis
^ permalink raw reply related
* [openwrt-devel] [linux-wireless] 802.11s mesh network can not recover after connectivity goes low and back up
From: Xuebing Wang @ 2017-02-21 6:55 UTC (permalink / raw)
To: linux-wireless, OpenWrt Development List
Hi Community,
I am using several routers (Atheros AR9331 + OpenWRT) to build a 802.11s
mesh network. I am having an issue.
- Linux kernel: 3.18.29
- OpenWRT version / branch: chaos_calmer
- Hardware platform: AR9331 with ath9k driver.
Description of the issue:
- When connectivity of a mesh node is low and connection to other nodes
is lost. After connectivity is back up again, ping other nodes won't get
this node to recover to connect to its peers.
- Test setup: most routers are in one room, with one specific router in
another room to simulate low connectivity.
- I use 'iw wlan0 set txpower limit 0' to simulate low connectivity.
- It's not easy to reproduce, occurrence rate is low.
- I sometimes put a laptop to the isolated router and "ssh into this
laptop" to generate some WiFi traffic (possible collisions).
Does anyone see the similar issue? Thanks.
xuebing wang
^ permalink raw reply
* RE: [RFC 2/5] iwlwifi: fix request_module() use
From: Grumbach, Emmanuel @ 2017-02-21 7:16 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Berg, Johannes, Coelho, Luciano, tj@kernel.org,
arjan@linux.intel.com, ming.lei@canonical.com, zajec5@gmail.com,
jeyu@redhat.com, rusty@rustcorp.com.au, pmladek@suse.com,
gregkh@linuxfoundation.org, linuxwifi,
linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20170221022337.GG31264@wotan.suse.de>
>
> On Sun, Feb 19, 2017 at 09:47:59AM +0000, Grumbach, Emmanuel wrote:
> > >
> > > The return value of request_module() being 0 does not mean that the
> > > driver which was requested has loaded. To properly check that the
> > > driver was loaded each driver can use internal mechanisms to vet the
> > > driver is now present. The helper try_then_request_module() was
> > > added to help with this, allowing drivers to specify their own validation as
> the first argument.
> > >
> > > On iwlwifi the use case is a bit more complicated given that the
> > > value we need to check for is protected with a mutex later used on
> > > the
> > > module_init() of the module we are asking for. If we were to lock
> > > and
> > > request_module() we'd deadlock. iwlwifi needs its own wrapper then
> > > so it can handle its special locking requirements.
> > >
> > > Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
> >
> > I don't see the problem with the current code. We don't assume that
> > everything has been loaded immediately after request_module returns.
> > We just free the intermediate firmware structures that won't be using
> > anymore. What happens here is that after request_module returns, we
> > patiently wait until it is loaded, and when that happens, iwl{d,m}vm's init
> function will be called.
>
> Right I get that.
>
> The code today complains if its respective opmode module was not loaded if
> request_module() did not return 0. As the commit log explains, relying on a
> return code of 0 to ensure a module loads is not sufficient. So the current
> print is almost pointless, so best we either:
>
> a) just remove the print and use instead request_module_nowait() (this is
> more
> in alignment of what your code actually does today; or
>
> b) fix the request_module() use so that the error print matches the
> expected
> and proper recommended use of request_module() (what this patch does)
>
> I prefer a) actually but I had to show what b) looked like first :)
>
Me too. Let's do the simple thing. After all, it's been working for 5 years now (maybe more?)
and I don't see a huge need to verify that the opmode module has been loaded.
It is very unlikely to fail anyway, and in the case it did fail, it's not that we can do much
from iwlwifi point of view. iwlwifi will stay loaded and sit idle since no opmode will
be there to start using the hardware. We will keep having the device claimed, and will
keep the interrupt registered and all that. No WiFi for you, but no harm caused either.
^ permalink raw reply
* Re: Monitor mode 'cook' flag meaning
From: Johannes Berg @ 2017-02-21 8:37 UTC (permalink / raw)
To: Thomas d'Otreppe; +Cc: linux-wireless
In-Reply-To: <CALs6+X+p_bANrbXjuQpbRWj_qpK7ssERMMKRdVDzH1yEOvT5fA@mail.gmail.com>
(please quote properly)
On Mon, 2017-02-20 at 18:46 -0700, Thomas d'Otreppe wrote:
> Do you have any example of devices where control or otherbss would be
> useful? Would both be for FullMAC devices?
No, I don't really know.
johannes
^ permalink raw reply
* Re: [PATCH v6 1/3] cfg80211: Accept multiple RSSI thresholds for CQM
From: Kalle Valo @ 2017-02-21 8:48 UTC (permalink / raw)
To: Andrew Zaborowski; +Cc: Johannes Berg, linux-wireless
In-Reply-To: <CAOq732LwAs6bG5dPMuBWA7MnSMLSRyySEq-2y2niDU0ZsFRNfA@mail.gmail.com>
Andrew Zaborowski <andrew.zaborowski@intel.com> writes:
> Hi,
>
> On 15 February 2017 at 09:58, Kalle Valo <kvalo@codeaurora.org> wrote:
>> Johannes Berg <johannes@sipsolutions.net> writes:
>>> On Fri, 2017-02-10 at 10:02 +0100, Andrew Zaborowski wrote:
>>>> Change the SET CQM command's RSSI threshold attribute to accept any
>>>> number of thresholds as a sorted array. The API should be backwards
>>>> compatible so that if one s32 threshold value is passed, the old
>>>> mechanism is enabled. The netlink event generated is the same in
>>>> both cases.
>>>
>>> I've applied this now, thanks for your patience :)
>>>
>>> I got a bit confused - and then fixed it up - patchwork has giving your
>>> name as "Andrzej Zaborowski" which apparently you didn't really want
>>> (any more). I've fixed it for these patches to be as the patches you
>>> sent, but no guarantees I've done this before or will remember to do
>>> that in the future - if you can somehow change your name in patchwork
>>> (patchwork.kernel.org) that would be good.
>
> Thanks, changed it for consistency now.
>
>>
>> IIRC if you haven't registered to patchwork.kernel.org it's possible to
>> change the name easily. But after registration the user needs to contact
>> helpdesk to change the name.
>
> Indeed I was able to set name on registration today but can see no way
> to modify it. The project's mailing list has a thread about a patch
> that's about to be backported to the patchwork.kernel.org version
> though,
> https://github.com/getpatchwork/patchwork/commit/d365402fb98dfb2c4aea4b58346096f85bdfa0c3
Great, that's exactly the right way to fix this. Thanks for letting us
now.
--
Kalle Valo
^ permalink raw reply
* [PATCH] ath10k: Remove return statement from a void function
From: Marcin Rokicki @ 2017-02-21 9:04 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless
The empty 'return;' statement in a void function should be
used to return from somewhere else then the end.
Signed-off-by: Marcin Rokicki <marcin.rokicki@tieto.com>
---
drivers/net/wireless/ath/ath10k/core.c | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index 59729aa..d65850e 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -2268,7 +2268,7 @@ static void ath10k_core_register_work(struct work_struct *work)
status = ath10k_core_probe_fw(ar);
if (status) {
ath10k_err(ar, "could not probe fw (%d)\n", status);
- goto err;
+ return;
}
status = ath10k_mac_register(ar);
@@ -2307,11 +2307,10 @@ static void ath10k_core_register_work(struct work_struct *work)
ath10k_mac_unregister(ar);
err_release_fw:
ath10k_core_free_firmware_files(ar);
-err:
- /* TODO: It's probably a good idea to release device from the driver
- * but calling device_release_driver() here will cause a deadlock.
- */
- return;
+
+/* TODO: It's probably a good idea to release device from the driver
+ * but calling device_release_driver() here will cause a deadlock.
+ */
}
int ath10k_core_register(struct ath10k *ar, u32 chip_id)
--
2.7.4
^ permalink raw reply related
* wpa psk offloading
From: Arend Van Spriel @ 2017-02-21 9:20 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Kalle Valo, Avery Pennarun
Hi Johannes,
Internally I am asked to look at "pmk plumbing" patches allowing
firmware to deal with 4-way handshake. Now I noticed this topic being
discussed during last wireless workshop in Santa Fe [1].
I do not recall any follow-up after that. At least no concrete patches,
right? Also in wpa_supplicant there is already a solution using QCA
vendor command. Should we aim to adopt just that or are there
issues/requirements not covered by that.
Regards,
Arend
[1]
https://docs.google.com/document/u/1/d/e/2PACX-1vQXbVQ-3zQt3Bcr3OWfwzbw_C49tTvf0ed8Hmf7b20E6tXc3a40tWZmPku49iGDE-OhgxNmO_lkkHEn/pub#h.kj1rq2w7lxdv
^ permalink raw reply
* ath10k regression on XPS13
From: Kalle Valo @ 2017-02-21 9:32 UTC (permalink / raw)
To: Linus Torvalds
Cc: Jiri Kosina, Linux Kernel Mailing List, ath10k, linux-wireless,
davem
In-Reply-To: <CA+55aFxLmgA7drrGfUJmCRPT-A74ROYf6GQHFGO5pzVjZ0dL7Q@mail.gmail.com>
(Changing subject, adding Dave and relevant lists)
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Mon, Feb 20, 2017 at 7:20 AM, Jiri Kosina <jikos@kernel.org> wrote:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid.git for-linus
>>
>> to receive HID subsystem updates for 4.11:
>
> The touchpad on my XPS13 no longer works. It might not be this pull
> request, and I'll bisect the exact cause, but this pull seems the most
> likely culprit.
>
> Just an early heads-up,
While talking about XPS13 also a heads-up from me as we have a nasty
regression in ath10k on XPS13 with QCA6174 (though not sure if you have
QCA6174, recent models seem to have that) which completely breaks driver
initialisation an error:
"ath10k_pci 0000:3a:00.0: failed to fetch board data for
bus=pci,vendor=168c,device=003e,subsystem-vendor=1a56,subsystem-device=1535,variant=RV_0520
from ath10k/QCA6174/hw3.0/board-2.bin"
https://bugzilla.kernel.org/show_bug.cgi?id=185621#c9
This is caused by this commit which I believe Dave will be sending to
you soon:
f2593cb1b291 ath10k: Search SMBIOS for OEM board file extension
As a workaround I recommend updating ath10k/QCA6174/hw3.0/board-2.bin
from this link _before_ updating the kernel:
https://github.com/kvalo/ath10k-firmware/blob/8d15818b0f9c7b09f743538ac2d3e1409779f52a/QCA6174/hw3.0/board-2.bin
We are working on a fix so that ath10k continues to work with older
board-2.bin, but that might take a day or two still.
--
Kalle Valo
^ permalink raw reply
* Re: wpa psk offloading
From: Johannes Berg @ 2017-02-21 9:42 UTC (permalink / raw)
To: Arend Van Spriel; +Cc: linux-wireless, Kalle Valo, Avery Pennarun
In-Reply-To: <11aeb0b3-5c44-32d5-c73a-c809f3d53c9f@broadcom.com>
On Tue, 2017-02-21 at 10:20 +0100, Arend Van Spriel wrote:
> Hi Johannes,
>
> Internally I am asked to look at "pmk plumbing" patches allowing
> firmware to deal with 4-way handshake. Now I noticed this topic being
> discussed during last wireless workshop in Santa Fe [1].
>
> I do not recall any follow-up after that. At least no concrete
> patches, right? Also in wpa_supplicant there is already a solution
> using QCA vendor command. Should we aim to adopt just that or are
> there issues/requirements not covered by that.
I don't think we should adopt a QCA vendor command as the official
solution :)
We do have a patch internally, I'll send it out - we just haven't
managed to release the driver for it yet.
johannes
^ permalink raw reply
* Re: [PATCH] ath10k: Remove return statement from a void function
From: Arend Van Spriel @ 2017-02-21 9:44 UTC (permalink / raw)
To: Marcin Rokicki, ath10k; +Cc: linux-wireless
In-Reply-To: <1487667873-3493-1-git-send-email-marcin.rokicki@tieto.com>
On 21-2-2017 10:04, Marcin Rokicki wrote:
> The empty 'return;' statement in a void function should be
> used to return from somewhere else then the end.
>
> Signed-off-by: Marcin Rokicki <marcin.rokicki@tieto.com>
> ---
> drivers/net/wireless/ath/ath10k/core.c | 11 +++++------
> 1 file changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
> index 59729aa..d65850e 100644
> --- a/drivers/net/wireless/ath/ath10k/core.c
> +++ b/drivers/net/wireless/ath/ath10k/core.c
> @@ -2268,7 +2268,7 @@ static void ath10k_core_register_work(struct work_struct *work)
> status = ath10k_core_probe_fw(ar);
> if (status) {
> ath10k_err(ar, "could not probe fw (%d)\n", status);
> - goto err;
> + return;
The subject seems misleading as you add a return here. Also removing the
goto will break the desired behavior as expressed in the TODO below.
> }
>
> status = ath10k_mac_register(ar);
> @@ -2307,11 +2307,10 @@ static void ath10k_core_register_work(struct work_struct *work)
> ath10k_mac_unregister(ar);
> err_release_fw:
> ath10k_core_free_firmware_files(ar);
> -err:
> - /* TODO: It's probably a good idea to release device from the driver
> - * but calling device_release_driver() here will cause a deadlock.
> - */
> - return;
So to me removing this return statement and no more is sufficient for
this patch. Just leave the label and TODO comment in place or fix it
properly by scheduling a "release driver" work here or whatever is
needed to prevent the deadlock.
Regards,
Arend
> +
> +/* TODO: It's probably a good idea to release device from the driver
> + * but calling device_release_driver() here will cause a deadlock.
> + */
> }
>
> int ath10k_core_register(struct ath10k *ar, u32 chip_id)
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox