Re: [PATCH 4/4] iw:In case of memory allocation failure by nlmsg_alloc() cqm will pass to NLA_PUT_U32. it should not happen.
On Fri, 2015-06-26 at 09:14 +, Amit Khatri wrote: Hi Johannes, Subject: [PATCH 4/4] iw:In case of memory allocation failure by nlmsg_alloc() cqm will pass to NLA_PUT_U32. it should not happen. Same here - use a single-line subject such as iw: check nlmsg_allocation() and put more detail in the the body. johannes -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] iw: Static analyser report that attr may be NULL so either we can remove condition check statement or add goto at end of this function.
On Fri, 2015-06-26 at 09:12 +, Amit Khatri wrote: Hi Johannes, Subject: [PATCH 3/4] iw: Static analyser report that attr may be NULL so either we can remove condition check statement or add goto at end of this function. That's far far too much for the subject. Please submit properly formatted patches with a single-line subject and a more detailed description in the body. + out: + ; /*empty statement to avoid compiler error */ } Just doing return; instead of goto out; would seem more reasonable than all these contortions? johannes -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] iw: fixes to Android.mk to include iw in AOSP builds
On Thu, 2015-07-30 at 14:35 -0700, Filipe Brandenburger wrote: Hi, I'm working on including iw on Android AOSP eng builds and it turns out we need some fixes to Android.mk to make it build on a current AOSP tree. We have a very similar patch internally as well (that I was still evualating/reviewing) but it was less complete, so I've applied this despite Arik's objections. I think that if anyone needs to build against older Android, which is very well possible, we can partially revert this and maybe provide some environment variable they can control from their BSP, but until somebody really shows up with that I'll leave it as is and assume that older Android builds will also use older iw. johannes -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mac80211: Fix oops in OCB mode when receiving data when not joined
On Wed, 2015-08-05 at 15:38 +0200, Bertold Van den Bergh wrote: The current implementation in ocb.c can cause a kernel oops when the interface is up, but no ocb has been joined. When data is received with the broadcast BSSID rx_no_sta is called. This function uses uninitialized variables because the join function has not yet been used. Signed-off-by: Bertold Van den Bergh bertold.vandenbe...@esat.kuleuven.be --- net/mac80211/ocb.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/net/mac80211/ocb.c b/net/mac80211/ocb.c index 573b81a..5da2bd3 100644 --- a/net/mac80211/ocb.c +++ b/net/mac80211/ocb.c @@ -50,6 +50,9 @@ void ieee80211_ocb_rx_no_sta(struct ieee80211_sub_if_data *sdata, struct sta_info *sta; int band; + if (!ifocb-joined) + return; Wouldn't it make more sense to put this check into ieee80211_accept_frame() and, in addition to not doing any station processing, simply dropping the frame completely? Like such: --- a/net/mac80211/rx.c +++ b/net/mac80211/rx.c @@ -3314,6 +3314,8 @@ static bool ieee80211_accept_frame(struct ieee80211_rx_data *rx) } return true; case NL80211_IFTYPE_OCB: + if (!sdata-u.ocb.joined) + return false; if (!bssid) return false; if (ieee80211_is_beacon(hdr-frame_control)) johannes -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mac80211: make local-tx_headroom a multiple of 4
On Thu, 2015-07-30 at 14:14 +0200, Felix Fietkau wrote: This ensures that mac80211 generated management frames and beacons are aligned before being passed to the driver I'm not convinced this is appropriate. Drivers may or may not require alignment, so I don't really see why we should in general enforce that? Having less headroom requirement is better in general. johannes -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] iw: Avoid possible memory leak for cb. cb got memory from nl_cb_alloc() but not doing free
On Fri, 2015-06-26 at 09:10 +, Amit Khatri wrote: Hi Johannes, Subject: [PATCH 2/4] iw: Avoid possible memory leak for cb. cb got memory from nl_cb_alloc() but not doing free Please fix your submission process to not mangle patches. I've applied patch 1 in this series and fixed it up manually, but having the subject again inside the email just makes it harder for me to pick up the patches. Signed-off-by: Amit Khatri amit.kha...@samsung.com Signed-off-by: Rahul Jain rahul.j...@samsung.com --- iw.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/iw.c b/iw.c index dc99566..1e913b6 100644 --- a/iw.c +++ b/iw.c @@ -477,8 +477,8 @@ static int __handle_cmd(struct nl80211_state *state, enum id_input idby, while (err 0) nl_recvmsgs(state-nl_sock, cb); out: - nl_cb_put(cb); out_free_msg: + nl_cb_put(cb); Please don't leave two equivalent labels, remove one of them and replace the users. johannes -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] average: provide macro to create static EWMA
From: Johannes Berg johannes.b...@intel.com
Having the EWMA parameters stored in the runtime struct imposes
memory requirements for the constant values that could just be
inlined in the code. This particularly makes sense if there are
a lot of such structs, for example in mac80211 in the station
table where each station has a number of these in an array, and
there can be many stations.
Provide a macro DECLARE_EWMA() that declares the necessary struct
and inline functions to access it with the parameters hard-coded;
using this also means the user no longer needs to 'select AVERAGE'
as it's entirely self-contained.
In the mac80211 case, on x86-64, this actually slightly *reduces*
code size, while also saving 80 bytes of runtime memory per sta.
Signed-off-by: Johannes Berg johannes.b...@intel.com
---
As the next patch relies on this, I'll take this through my tree
unless I hear objections.
---
include/linux/average.h | 39 +++
1 file changed, 39 insertions(+)
diff --git a/include/linux/average.h b/include/linux/average.h
index c6028fd742c1..802adeab7037 100644
--- a/include/linux/average.h
+++ b/include/linux/average.h
@@ -27,4 +27,43 @@ static inline unsigned long ewma_read(const struct ewma *avg)
return avg-internal avg-factor;
}
+#define DECLARE_EWMA(name, _factor, _weight) \
+ struct ewma_##name {\
+ unsigned long internal; \
+ }; \
+ static inline void ewma_##name##_init(struct ewma_##name *e)\
+ { \
+ BUILD_BUG_ON(!__builtin_constant_p(_factor)); \
+ BUILD_BUG_ON(!__builtin_constant_p(_weight)); \
+ BUILD_BUG_ON(!is_power_of_2(_factor)); \
+ BUILD_BUG_ON(!is_power_of_2(_weight)); \
+ e-internal = 0;\
+ } \
+ static inline unsigned long \
+ ewma_##name##_read(struct ewma_##name *e) \
+ { \
+ BUILD_BUG_ON(!__builtin_constant_p(_factor)); \
+ BUILD_BUG_ON(!__builtin_constant_p(_weight)); \
+ BUILD_BUG_ON(!is_power_of_2(_factor)); \
+ BUILD_BUG_ON(!is_power_of_2(_weight)); \
+ return e-internal ilog2(_factor); \
+ } \
+ static inline void ewma_##name##_add(struct ewma_##name *e, \
+unsigned long val) \
+ { \
+ unsigned long internal = ACCESS_ONCE(e-internal); \
+ unsigned long weight = ilog2(_weight); \
+ unsigned long factor = ilog2(_factor); \
+ \
+ BUILD_BUG_ON(!__builtin_constant_p(_factor)); \
+ BUILD_BUG_ON(!__builtin_constant_p(_weight)); \
+ BUILD_BUG_ON(!is_power_of_2(_factor)); \
+ BUILD_BUG_ON(!is_power_of_2(_weight)); \
+ \
+ ACCESS_ONCE(e-internal) = internal ? \
+ (((internal weight) - internal) +\
+ (val factor)) weight :\
+ (val factor);\
+ }
+
#endif /* _LINUX_AVERAGE_H */
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] iwlwifi: mvm: don't set K1/K2 for AES-CMAC
From: Johannes Berg johannes.b...@intel.com
According to firmware engineers, the firmware has never required
these fields and the values have always been calculated, they were
just leftovers from a previous implementation.
Therefore remove the unnecessary calculation.
Reviewed-by: Emmanuel Grumbach emmanuel.grumb...@intel.com
Signed-off-by: Johannes Berg johannes.b...@intel.com
---
I'll apply this to my tree to remove the mac80211 function.
---
drivers/net/wireless/iwlwifi/mvm/fw-api-sta.h | 4 ++--
drivers/net/wireless/iwlwifi/mvm/sta.c| 2 --
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/mvm/fw-api-sta.h
b/drivers/net/wireless/iwlwifi/mvm/fw-api-sta.h
index 21dd5b771660..493a8bdfbc9e 100644
--- a/drivers/net/wireless/iwlwifi/mvm/fw-api-sta.h
+++ b/drivers/net/wireless/iwlwifi/mvm/fw-api-sta.h
@@ -366,8 +366,8 @@ struct iwl_mvm_rm_sta_cmd {
* ( MGMT_MCAST_KEY = 0x1f )
* @ctrl_flags: %iwl_sta_key_flag
* @IGTK:
- * @K1: IGTK master key
- * @K2: IGTK sub key
+ * @K1: unused
+ * @K2: unused
* @sta_id: station ID that support IGTK
* @key_id:
* @receive_seq_cnt: initial RSC/PN needed for replay check
diff --git a/drivers/net/wireless/iwlwifi/mvm/sta.c
b/drivers/net/wireless/iwlwifi/mvm/sta.c
index d68dc697a4a0..3d2fbf1bc226 100644
--- a/drivers/net/wireless/iwlwifi/mvm/sta.c
+++ b/drivers/net/wireless/iwlwifi/mvm/sta.c
@@ -1277,8 +1277,6 @@ static int iwl_mvm_send_sta_igtk(struct iwl_mvm *mvm,
const u8 *pn;
memcpy(igtk_cmd.IGTK, keyconf-key, keyconf-keylen);
- ieee80211_aes_cmac_calculate_k1_k2(keyconf,
- igtk_cmd.K1, igtk_cmd.K2);
ieee80211_get_key_rx_seq(keyconf, 0, seq);
pn = seq.aes_cmac.pn;
igtk_cmd.receive_seq_cnt = cpu_to_le64(((u64) pn[5] 0) |
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/10] mac80211: remove ieee80211_aes_cmac_calculate_k1_k2()
On Fri, 2015-07-17 at 15:43 +0200, Johannes Berg wrote: On Wed, 2015-07-08 at 15:41 +0300, Emmanuel Grumbach wrote: From: Johannes Berg johannes.b...@intel.com The iwlwifi driver was the only driver that used this, but as it turns out it never needed it, so we can remove it. I'm not applying this for now since it depends on the iwlwifi patch to remove usage thereof :) I think we said I'd apply that one also through my tree, but since it's not urgent I'll sort it out later. Which I've done now - so this is also in now. johannes -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ath10k: initialize fw_features var
Michal Kazior michal.kaz...@tieto.com writes: If firmware did not have any feature flags set the var would be left with values found on the stack (i.e. garbage) yielding print string like this: (...) features \xffa6m:^R\xfffbԂ\xffc4^E Fixes: b27bc5a40f91 (ath10k: dump fw features during probing) Signed-off-by: Michal Kazior michal.kaz...@tieto.com Thanks, applied. -- Kalle Valo -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ath10k: refactor phyerr event handlers
Raja Mani rm...@qti.qualcomm.com writes: Existing phyerr event handlers directly uses phyerr header format (ie, struct wmi_phyerr and struct wmi_phyerr_event) in the code exactly on how firmware packs it. This is the problem in 10.4 fw specific phyerr event handling where it uses different phyerror header format. Before adding 10.4 specific handler, little bit of refactor is done in existing phyerr handlers. Two new abstracted structures (struct wmi_phyerr_ev_hdr_arg and struct wmi_phyerr_ev_arg) are introduced to remove dependency of using firmware specific header format in the code. So that firmware specific phyerror handlers can populate values to abstracted structures and the following code can use abstracted struct for further operation. .pull_phyerr_hdr is added newly to pull common phyerr header info like tsf, buf_len, number of phyerr packed. Existing .pull_phyerr handler is changed and called to parse every sub phyerrs in the event. Validated these refactoring on qca988x hw2.0 using fw 10.2.4 version. Signed-off-by: Raja Mani rm...@qti.qualcomm.com Thanks, applied. -- Kalle Valo -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ath10k: Support different txbf configuration schemes
Vivek Natarajan natar...@qti.qualcomm.com writes: qca61x4 uses the vdev param as a sole sufficient configuration for txbf while qca99x0 enables txbf during peer assoc by combining the vdev param value with peer assoc's vht capabilities This patch gets the appropriate txbf configuration scheme before passing the wmi command to enable the same in the firmware. Signed-off-by: Vivek Natarajan natar...@qti.qualcomm.com Thanks, both patches applied. -- Kalle Valo -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ath10k: remove futile fragmentation threshold config
Michal Kazior michal.kaz...@tieto.com writes: Commit 1010ba4c5d1c (ath10k: unregister and remove frag_threshold callback) didn't remove all instances of (futile) fragmentation threshold configuration. No known firmware supports the parameter so don't even bother setting it. Signed-off-by: Michal Kazior michal.kaz...@tieto.com Thanks, both patches applied. -- Kalle Valo -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] iw: Avoid NULL attr value to pass in nla_data.
value of attr may be NULL so check before passing
to function.
Signed-off-by: Amit Khatri amit.kha...@samsung.com
Signed-off-by: Rahul Jain rahul.j...@samsung.com
---
event.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/event.c b/event.c
index 5fb5afc..5d0bfde 100644
--- a/event.c
+++ b/event.c
@@ -49,8 +49,10 @@ static void print_frame(struct print_event_args *args,
struct nlattr *attr)
char macbuf[6*3];
uint16_t tmp;
- if (!attr)
+ if (!attr) {
printf( [no frame]);
+ return;
+ }
frame = nla_data(attr);
len = nla_len(attr);
--
1.9.1
ath10k: first qca6174 hw2.1 firmware released
Hi, I just pushed the first qca6174 hw2.1 firmware to ath10k-firmware.git: https://github.com/kvalo/ath10k-firmware/commit/7f7e7dda33676ced293de477b03711199ffe5256 Please test and provide feedback. -- Kalle Valo -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ath10k: fix hw reconfig on wow failure
Michal Kazior michal.kaz...@tieto.com writes: When WoWLAN resume fails with retval 1 mac80211 will attempt to reconfig the device in a similar manner when hw restart is requested. This wasn't handled properly and yielded call trace warnings and the device ended up not working. Signed-off-by: Michal Kazior michal.kaz...@tieto.com Thanks, applied. -- Kalle Valo -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] iw: check nlmsg_allocation
In case of memory allocation failure by nlmsg_alloc() cqm will pass to NLA_PUT_U32. it should not happen Signed-off-by: Amit Khatri amit.kha...@samsung.com Signed-off-by: Rahul Jain rahul.j...@samsung.com --- cqm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/cqm.c b/cqm.c index 36e..412d77b 100644 --- a/cqm.c +++ b/cqm.c @@ -34,6 +34,8 @@ static int iw_cqm_rssi(struct nl80211_state *state, /* connection quality monitor attributes */ cqm = nlmsg_alloc(); + if(!cqm) + return -ENOMEM; NLA_PUT_U32(cqm, NL80211_ATTR_CQM_RSSI_THOLD, thold); NLA_PUT_U32(cqm, NL80211_ATTR_CQM_RSSI_HYST, hyst); -- 1.9.1
[PATCH 3/3] iw: Avoid possible memory leak for cb
cb got memory from nl_cb_alloc() but not doing free
during error case and use same lable to go out from function.
Signed-off-by: Amit Khatri amit.kha...@samsung.com
Signed-off-by: Rahul Jain rahul.j...@samsung.com
---
iw.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/iw.c b/iw.c
index ec56736..a2c2795 100644
--- a/iw.c
+++ b/iw.c
@@ -476,13 +476,13 @@ static int __handle_cmd(struct nl80211_state *state, enum
id_input idby,
err = cmd-handler(state, msg, argc, argv, idby);
if (err)
- goto out;
+ goto out_free_msg;
nl_socket_set_cb(state-nl_sock, s_cb);
err = nl_send_auto_complete(state-nl_sock, msg);
if (err 0)
- goto out;
+ goto out_free_msg;
err = 1;
@@ -493,9 +493,9 @@ static int __handle_cmd(struct nl80211_state *state, enum
id_input idby,
while (err 0)
nl_recvmsgs(state-nl_sock, cb);
- out:
- nl_cb_put(cb);
+
out_free_msg:
+ nl_cb_put(cb);
nlmsg_free(msg);
return err;
nla_put_failure:
--
1.9.1
N�r��yb�X��ǧv�^�){.n�+{��*ޕ�,�{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
Re: [PATCH 1/2] ath10k: don't remove peer that doesn't exist
Michal Kazior michal.kaz...@tieto.com writes: If peer creation failed during offchannel Tx the driver attempted to delete the peer nonetheless. This caused the ar-num_peers counter to be incorrectly decremented. This subsequently could cause the counter to drop below 0 and also eventually lead to firmware crash because host would think there are less peer entries created in firmware then there really were. Signed-off-by: Michal Kazior michal.kaz...@tieto.com Thanks, applied. -- Kalle Valo -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] net: rfkill: add rfkill_find_type function
On Wed, 2015-08-05 at 16:39 +0300, Heikki Krogerus wrote:
+static const char *rfkill_types[NUM_RFKILL_TYPES] = {
+ [RFKILL_TYPE_WLAN] = wlan,
+ [RFKILL_TYPE_BLUETOOTH] = bluetooth,
+ [RFKILL_TYPE_UWB] = ultrawideband,
+ [RFKILL_TYPE_WIMAX] = wimax,
+ [RFKILL_TYPE_WWAN] = wwan,
+ [RFKILL_TYPE_GPS] = gps,
+ [RFKILL_TYPE_FM]= fm,
+ [RFKILL_TYPE_NFC] = nfc,
+};
+
+enum rfkill_type rfkill_find_type(const char *name)
+{
+ int i;
+
+ BUILD_BUG_ON(NUM_RFKILL_TYPES != RFKILL_TYPE_NFC + 1);
That BUILD_BUG_ON() is now less useful - previously it pointed to the
code that needed to change, now you're left wondering if you don't look
up since it isn't quite that obvious from the code what this does.
Something like
BUILD_BUG_ON(rfkill_types[NUM_RFKILL_TYPES - 1] == NULL);
would be better. As we only add here, that would be safe enough - I've
done something similar in the past that a bit more complicated.
With that and the static inline fixed (which maybe you could even
remove) I'm fine with all these rfkill patches, but I'm not sure how to
merge them since they affect all kinds of other trees. If desired, I
can apply them, but an ACK from the tegra maintainer would be good :)
johannes
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] mac80211: remove always true condition
On Mon, 2015-07-27 at 11:11 +0300, Dan Carpenter wrote: The outside if statement checks that IEEE80211_TX_INTFL_MLME_CONN_TX is set so this condition is always true. Checking twice upsets the static checkers. Yeah, this was left over in some refactoring - thanks, applied. johannes -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] bcma: switch GPIO portions to use GPIOLIB_IRQCHIP
On Sun, Aug 2, 2015 at 8:00 PM, Hauke Mehrtens ha...@hauke-m.de wrote: From: Linus Walleij linus.wall...@linaro.org This switches the BCMA GPIO driver to use GPIOLIB_IRQCHIP to handle its interrupts instead of rolling its own copy of the irqdomain handling etc. Signed-off-by: Linus Walleij linus.wall...@linaro.org Signed-off-by: Hauke Mehrtens ha...@hauke-m.de --- I fixed some bugs in the original patch, some of them are compile errors and others caused some runtime problems. This patch worked on my BCM4708 based device, I was able to receive an IRQ for a GPIO change (button press). Thanks a *LOT* for spending the effort of fixing up my uglyhack. I think this should go through the wireless tree. @Linus could you please check if the changes I did are correct? LooksGoodToMe(TM) Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ath10k: refactor phyerr event handlers
Kalle Valo kv...@qca.qualcomm.com writes: Raja Mani rm...@qti.qualcomm.com writes: Existing phyerr event handlers directly uses phyerr header format (ie, struct wmi_phyerr and struct wmi_phyerr_event) in the code exactly on how firmware packs it. This is the problem in 10.4 fw specific phyerr event handling where it uses different phyerror header format. Before adding 10.4 specific handler, little bit of refactor is done in existing phyerr handlers. Two new abstracted structures (struct wmi_phyerr_ev_hdr_arg and struct wmi_phyerr_ev_arg) are introduced to remove dependency of using firmware specific header format in the code. So that firmware specific phyerror handlers can populate values to abstracted structures and the following code can use abstracted struct for further operation. .pull_phyerr_hdr is added newly to pull common phyerr header info like tsf, buf_len, number of phyerr packed. Existing .pull_phyerr handler is changed and called to parse every sub phyerrs in the event. Validated these refactoring on qca988x hw2.0 using fw 10.2.4 version. Signed-off-by: Raja Mani rm...@qti.qualcomm.com Thanks, applied. Actually I'll take it back, I dropped these as I see new warnings: drivers/net/wireless/ath/ath10k/wmi.c:3625:33: warning: restricted __le32 degrades to integer drivers/net/wireless/ath/ath10k/wmi.c:3627:38: warning: restricted __le32 degrades to integer drivers/net/wireless/ath/ath10k/wmi.c:3599:5: warning: symbol 'ath10k_wmi_10_4_op_pull_phyerr_ev' was not declared. Should it be static? -- Kalle Valo -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ath9k_htc: drv_init: match wait_for_completion_timeout return type
Return type of wait_for_completion_timeout is unsigned long not int. As time_left is exclusively used for wait_for_completion_timeout here its type is simply changed to unsigned long. API conformance testing for completions with coccinelle spatches are being used to locate API usage inconsistencies: ./drivers/net/wireless/ath/ath9k/htc_drv_init.c:81 int return assigned to unsigned long Patch was compile tested with x86_64_defconfig + CONFIG_ATH_CARDS=m, CONFIG_ATH9K_HTC=m Patch is against 4.1-rc3 (localversion-next is -next-20150514) Signed-off-by: Nicholas Mc Guire hof...@osadl.org Thanks, applied to wireless-drivers-next.git. Kalle Valo -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [NEXT,1/6] rtlwifi: rtl8192ce: rtl8192cu: Fix endian issue
Commit e996db69833a (rtlwifi: rtl8192c: Add init codes for fw_version
and fw_subversion) added initialization for fw_version, but failed to
note that the variable in the firmware header is little-endian. The
following Sparse warning results:
CHECK drivers/net/wireless/rtlwifi/rtl8192c/fw_common.c
drivers/net/wireless/rtlwifi/rtl8192c/fw_common.c:242:36: warning: incorrect
type in assignment (different base types)
drivers/net/wireless/rtlwifi/rtl8192c/fw_common.c:242:36:expected
unsigned short [unsigned] [usertype] fw_version
drivers/net/wireless/rtlwifi/rtl8192c/fw_common.c:242:36:got restricted
__le16 [usertype] version
When fixing this problem, I noticed that several of the drivers contain
nearly identical copies of the firmware header struct, and that only the one
used in rtl8192c{e,u} had correct endian notation. The struct has been
moved into a common header, and the other drivers will be fixed in
subsequant patches.
Signed-off-by: Larry Finger larry.fin...@lwfinger.net
Thanks, 6 patches applied to wireless-drivers-next.git:
e41c51359918 rtlwifi: rtl8192ce: rtl8192cu: Fix endian issue
7c24d086ef9c rtlwifi: rtl8723ae: rtl8723be: rtl8723com: Fix firmware header
endian issues
253f10abb7c2 rtlwifi: rtl8821ae: Fix firmware endian issues
b290b57d18aa rtlwifi: rtl8192de: Fix firmware header endian issues
201b63c7c907 rtlwifi: rtl888ee: Fix firmware header endian issues
8d882bcf8274 rtlwifi: rtl8192ee: Fix firmware header endian issues
Kalle Valo
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFT 1/2] ath10k: add qca6164 support
This adds additional 0x0041 PCI Device ID
definition to ath10k for QCA6164 which is a 1
spatial stream sibling of the QCA6174 (which is 2
spatial stream chip).
The QCA6164 needs a dedicated board.bin file which
is different than the one used for QCA6174. If the
board.bin is wrong the device will crash early
while trying to boot firmware. The register dump
will look like this:
ath10k_pci :02:00.0: firmware register dump:
ath10k_pci :02:00.0: [00]: 0x0501 0x15B3 0x000A012D 0x00955B31
...
Note the value 0x000A012D.
Special credit goes to Alan Liu
alan...@qca.qualcomm.com for providing support
help which enabled me to come up with this patch.
Signed-off-by: Michal Kazior michal.kaz...@tieto.com
---
drivers/net/wireless/ath/ath10k/core.c | 11 +++
drivers/net/wireless/ath/ath10k/core.h | 1 +
drivers/net/wireless/ath/ath10k/pci.c | 13 +
3 files changed, 25 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/core.c
b/drivers/net/wireless/ath/ath10k/core.c
index 25510679fd2e..1ea16d044645 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -231,6 +231,17 @@ static int ath10k_init_configure_target(struct ath10k *ar)
return ret;
}
+ /* Some devices have a special sanity check that verifies the PCI
+* Device ID is written to this host interest var. It is known to be
+* required to boot QCA6164.
+*/
+ ret = ath10k_bmi_write32(ar, hi_hci_uart_pwr_mgmt_params_ext,
+ar-dev_id);
+ if (ret) {
+ ath10k_err(ar, failed to set pwr_mgmt_params: %d\n, ret);
+ return ret;
+ }
+
return 0;
}
diff --git a/drivers/net/wireless/ath/ath10k/core.h
b/drivers/net/wireless/ath/ath10k/core.h
index 6a387bac27b0..91d4409dee0b 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -554,6 +554,7 @@ struct ath10k {
u8 mac_addr[ETH_ALEN];
enum ath10k_hw_rev hw_rev;
+ u16 dev_id;
u32 chip_id;
u32 target_version;
u8 fw_version_major;
diff --git a/drivers/net/wireless/ath/ath10k/pci.c
b/drivers/net/wireless/ath/ath10k/pci.c
index f00b251ec9ce..49a7538325e3 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -58,11 +58,13 @@ MODULE_PARM_DESC(reset_mode, 0: auto, 1: warm only
(default: 0));
#define ATH10K_PCI_NUM_WARM_RESET_ATTEMPTS 3
#define QCA988X_2_0_DEVICE_ID (0x003c)
+#define QCA6164_2_1_DEVICE_ID (0x0041)
#define QCA6174_2_1_DEVICE_ID (0x003e)
#define QCA99X0_2_0_DEVICE_ID (0x0040)
static const struct pci_device_id ath10k_pci_id_table[] = {
{ PCI_VDEVICE(ATHEROS, QCA988X_2_0_DEVICE_ID) }, /* PCI-E QCA988X V2 */
+ { PCI_VDEVICE(ATHEROS, QCA6164_2_1_DEVICE_ID) }, /* PCI-E QCA6164 V2.1
*/
{ PCI_VDEVICE(ATHEROS, QCA6174_2_1_DEVICE_ID) }, /* PCI-E QCA6174 V2.1
*/
{ PCI_VDEVICE(ATHEROS, QCA99X0_2_0_DEVICE_ID) }, /* PCI-E QCA99X0 V2 */
{0}
@@ -74,11 +76,19 @@ static const struct ath10k_pci_supp_chip
ath10k_pci_supp_chips[] = {
* because of that.
*/
{ QCA988X_2_0_DEVICE_ID, QCA988X_HW_2_0_CHIP_ID_REV },
+
+ { QCA6164_2_1_DEVICE_ID, QCA6174_HW_2_1_CHIP_ID_REV },
+ { QCA6164_2_1_DEVICE_ID, QCA6174_HW_2_2_CHIP_ID_REV },
+ { QCA6164_2_1_DEVICE_ID, QCA6174_HW_3_0_CHIP_ID_REV },
+ { QCA6164_2_1_DEVICE_ID, QCA6174_HW_3_1_CHIP_ID_REV },
+ { QCA6164_2_1_DEVICE_ID, QCA6174_HW_3_2_CHIP_ID_REV },
+
{ QCA6174_2_1_DEVICE_ID, QCA6174_HW_2_1_CHIP_ID_REV },
{ QCA6174_2_1_DEVICE_ID, QCA6174_HW_2_2_CHIP_ID_REV },
{ QCA6174_2_1_DEVICE_ID, QCA6174_HW_3_0_CHIP_ID_REV },
{ QCA6174_2_1_DEVICE_ID, QCA6174_HW_3_1_CHIP_ID_REV },
{ QCA6174_2_1_DEVICE_ID, QCA6174_HW_3_2_CHIP_ID_REV },
+
{ QCA99X0_2_0_DEVICE_ID, QCA99X0_HW_2_0_CHIP_ID_REV },
};
@@ -1810,6 +1820,7 @@ static int ath10k_pci_get_num_banks(struct ath10k *ar)
case QCA988X_2_0_DEVICE_ID:
case QCA99X0_2_0_DEVICE_ID:
return 1;
+ case QCA6164_2_1_DEVICE_ID:
case QCA6174_2_1_DEVICE_ID:
switch (MS(ar-chip_id, SOC_CHIP_ID_REV)) {
case QCA6174_HW_1_0_CHIP_ID_REV:
@@ -2898,6 +2909,7 @@ static int ath10k_pci_probe(struct pci_dev *pdev,
case QCA988X_2_0_DEVICE_ID:
hw_rev = ATH10K_HW_QCA988X;
break;
+ case QCA6164_2_1_DEVICE_ID:
case QCA6174_2_1_DEVICE_ID:
hw_rev = ATH10K_HW_QCA6174;
break;
@@ -2922,6 +2934,7 @@ static int ath10k_pci_probe(struct pci_dev *pdev,
ar_pci-pdev = pdev;
ar_pci-dev = pdev-dev;
ar_pci-ar = ar;
+ ar-dev_id = pci_dev-device;
if (pdev-subsystem_vendor || pdev-subsystem_device)
scnprintf(ar-spec_board_id, sizeof(ar-spec_board_id),
--
2.1.4
--
To
Re: [PATCH 2/5] net: rfkill: add rfkill_find_type function
Hi,
On Thu, Aug 13, 2015 at 11:27:46AM +0200, Johannes Berg wrote:
On Wed, 2015-08-05 at 16:39 +0300, Heikki Krogerus wrote:
+static const char *rfkill_types[NUM_RFKILL_TYPES] = {
+ [RFKILL_TYPE_WLAN] = wlan,
+ [RFKILL_TYPE_BLUETOOTH] = bluetooth,
+ [RFKILL_TYPE_UWB] = ultrawideband,
+ [RFKILL_TYPE_WIMAX] = wimax,
+ [RFKILL_TYPE_WWAN] = wwan,
+ [RFKILL_TYPE_GPS] = gps,
+ [RFKILL_TYPE_FM]= fm,
+ [RFKILL_TYPE_NFC] = nfc,
+};
+
+enum rfkill_type rfkill_find_type(const char *name)
+{
+ int i;
+
+ BUILD_BUG_ON(NUM_RFKILL_TYPES != RFKILL_TYPE_NFC + 1);
That BUILD_BUG_ON() is now less useful - previously it pointed to the
code that needed to change, now you're left wondering if you don't look
up since it isn't quite that obvious from the code what this does.
Something like
BUILD_BUG_ON(rfkill_types[NUM_RFKILL_TYPES - 1] == NULL);
would be better. As we only add here, that would be safe enough - I've
done something similar in the past that a bit more complicated.
OK, I'll change it.
With that and the static inline fixed (which maybe you could even
remove) I'm fine with all these rfkill patches, but I'm not sure how to
merge them since they affect all kinds of other trees. If desired, I
can apply them, but an ACK from the tegra maintainer would be good :)
Andy and Mika are preparing some changes to the device property
handling. I'll wait for their proposal and prepare next version these
after that.
Thanks,
--
heikki
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net/wireless: enable wiphy device to suspend/resume asynchronously
On Thu, 2015-07-30 at 08:55 +0300, Emmanuel Grumbach wrote: On Thu, Jul 30, 2015 at 8:18 AM, Fu, Zhonghui zhonghui...@linux.intel.com wrote: Enable wiphy device to suspend/resume asynchronously. This can improve system suspend/resume speed. How will that impact the timing with respect to the suspend call coming from the bus? I think that a few drivers rely on the suspend call of the wiphy device happening before the suspend call to the bus device. Yes, we can't do this for precisely this reason unless we have a way to somehow keep the dependency between the two - possibly by also marking the other one as async (although I don't know if the async framework in general has any FIFO guarantees, which would be required for this.) I've dropped the patch. johannes -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mac80211: fix invalid read in minstrel_sort_best_tp_rates()
On Tue, 2015-07-28 at 10:30 +0200, Adrien Schildknecht wrote: At the last iteration of the loop, j may equal zero and thus tp_list[j - 1] causes an invalid read. Changed the logic of the loop so that j - 1 is always = 0. Signed-off-by: Adrien Schildknecht adrien+...@schischi.me Applied, I added Cc stable. johannes -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v3,1/3] mwifiex: add support for 8997 chipset
From: Zhaoyang Liu li...@marvell.com This patch adds support for 8997 chipset to mwifiex with SDIO/PCIe/USB interface. The corresponding firmware image files are located in: mrvl/sd8997_uapsta.bin mrvl/pcie8997_uapsta.bin mrvl/usb8997_uapsta.bin Signed-off-by: Zhaoyang Liu li...@marvell.com Signed-off-by: Cathy Luo c...@marvell.com Signed-off-by: Amitkumar Karwar akar...@marvell.com Thanks, 3 patches applied to wireless-drivers-next.git: 6d85ef00d9df mwifiex: add support for 8997 chipset eee7f1961b9d mwifiex: add firmware dump support for SD8997 2375fa2b36fe mwifiex: fix unable to connect hidden SSID AP on DFS channel Kalle Valo -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] cfg80211: Handle minimum bandwidth for quarter and half rates
On Fri, 2015-07-17 at 15:28 +0200, Matthias May wrote: The goal of this patch is to improve regd handling of quarter and half rates. The original assumption of 20MHz wide channels is with the introduction of quarter and half rates no longer true. With this patch we no longer disable all channels that don't fit into the 20MHz grid, but instead set the appropriate flags to disable operation on specific bandwidths. Applied. johannes -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] mac80211: Create STA when transmitting to unknown station in OCB mode
On Wed, 2015-08-05 at 16:02 +0200, Bertold Van den Bergh wrote: Create a new STA when requested to unicast a frame to an unknown station. This is needed to make ratecontrol work in the case where data is sent from sta A to B and sta B never replies. Currently, sta B will stay unknown to mac80211 and the default rate will always be used. Signed-off-by: Bertold Van den Bergh bertold.vandenbe...@esat.kuleuven.be --- net/mac80211/tx.c | 4 1 file changed, 4 insertions(+) diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c index 84e0e8c..eb8dba6 100644 --- a/net/mac80211/tx.c +++ b/net/mac80211/tx.c @@ -1209,6 +1209,10 @@ ieee80211_tx_prepare(struct ieee80211_sub_if_data *sdata, } else tx-flags |= IEEE80211_TX_UNICAST; + if ((sdata-vif.type == NL80211_IFTYPE_OCB) (!tx-sta) + (tx-flags IEEE80211_TX_UNICAST)) + ieee80211_ocb_rx_no_sta(sdata, NULL, hdr-addr1, 0); It seems that this could be in a place that's already OCB specific, perhaps earlier. Also, it seems you should then actually use the station and assign it to tx-sta, and rename the function to be more indicative of what it's doing now. And code-style wise - you don't need all those parentheses. johannes -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] mac80211: Set txrc.bss to true for OCB interfaces
On Wed, 2015-08-05 at 16:02 +0200, Bertold Van den Bergh wrote: To make mac80211 accept the multicast rate requested by the user the rate control should be told that it is operating in BSS mode. Without this, the default rate is selected in rate_control_send_low (!pubsta and !txrc-bss) Applied 1 and 2, although the 'bss' variable is somewhat misnamed I guess. johannes -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ath9k_htc: match wait_for_completion_timeout return type
Return type of wait_for_completion_timeout is unsigned long not int. As time_left is exclusively used for wait_for_completion_timeout here its type is simply changed to unsigned long. API conformance testing for completions with coccinelle spatches are being used to locate API usage inconsistencies: ./drivers/net/wireless/ath/ath9k/htc_hst.c:171 int return assigned to unsigned long ./drivers/net/wireless/ath/ath9k/htc_hst.c:277 int return assigned to unsigned long ./drivers/net/wireless/ath/ath9k/htc_hst.c:206 int return assigned to unsigned long Patch was compile tested with x86_64_defconfig + CONFIG_ATH_CARDS=m, CONFIG_ATH9K_HTC=m Patch is against 4.1-rc3 (localversion-next is -next-20150514) Signed-off-by: Nicholas Mc Guire hof...@osadl.org Thanks, applied to wireless-drivers-next.git. Kalle Valo -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] iw: Avoid possible memory leak for cb
This patch doesn't look correct - in the case that 'cb' fails to allocate, the existing code is actually correct. In the case that s_cb fails to allocate, it's clearly incorrect, but that means the two conditions need to be disentangled, no? Also, I've applied the other two patches despite them being severely mangled - please try to improve your submission process so the patches can apply - perhaps send them to yourself and see if 'git am' can handle them to figure out what's wrong. johannes -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2/3] brcmfmac: dhd_sdio.c: use existing atomic_or primitive
There's already a generic implementation so use that instead. Thanks, applied to wireless-drivers-next.git. Kalle Valo -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mac80211_hwsim: unregister genetlink family properly
On Fri, 2015-08-07 at 16:54 +0800, Su Kang Yin wrote: During hwsim_init_netlink(), we should call genl_unregister_family() if failed on netlink_register_notifier() since the genetlink is already registered. Applied. johannes -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] mac80211: Make OCB mode set BSSID
On Wed, 2015-08-05 at 16:02 +0200, Bertold Van den Bergh wrote: Perform the BSS_CHANGED_BSSID action when joining an OCB network. This is required to set the broadcast BSSID in some network drivers. Also applied 4 and 5. johannes -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ath9k_htc: wmi: match wait_for_completion_timeout return type
Return type of wait_for_completion_timeout is unsigned long not int. As time_left is exclusively used for wait_for_completion_timeout here its type is simply changed to unsigned long. API conformance testing for completions with coccinelle spatches are being used to locate API usage inconsistencies: ./drivers/net/wireless/ath/ath9k/wmi.c:331 int return assigned to unsigned long Patch was compile tested with x86_64_defconfig + CONFIG_ATH_CARDS=m, CONFIG_ATH9K_HTC=m Patch is against 4.1-rc3 (localversion-next is -next-20150514) Signed-off-by: Nicholas Mc Guire hof...@osadl.org Thanks, applied to wireless-drivers-next.git. Kalle Valo -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ath9k: match wait_for_completion_timeout return type
Return type of wait_for_completion_timeout is unsigned long not int. As time_left is exclusively used for wait_for_completion_timeout here its type is simply changed to unsigned long. API conformance testing for completions with coccinelle spatches are being used to locate API usage inconsistencies: ./drivers/net/wireless/ath/ath9k/link.c:197 int return assigned to unsigned long Patch was compile tested with x86_64_defconfig + CONFIG_ATH_CARDS=m, Patch is against 4.1-rc3 (localversion-next is -next-20150514) Signed-off-by: Nicholas Mc Guire hof...@osadl.org Thanks, applied to wireless-drivers-next.git. Kalle Valo -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] wireless-regdb: add 2.4GHz regulatory rules for Cuba (CU)
On Tue, Aug 11, 2015 at 03:29:55PM +0200, Xose Vazquez Perez wrote: Resolución 127, 2011 - Reglamento Banda 2,4 GHz.: http://www.mincom.gob.cu/sites/default/files/marcoregulatorio/R%20127-11%20Reglamento%20banda%202,4%20GHz.pdf Cc: Seth Forshee seth.fors...@canonical.com Cc: linux-wireless@vger.kernel.org Cc: wireless-re...@lists.infradead.org Signed-off-by: Xose Vazquez Perez xose.vazq...@gmail.com --- db.txt | 7 +++ 1 file changed, 7 insertions(+) diff --git a/db.txt b/db.txt index 982db34..2edbf90 100644 --- a/db.txt +++ b/db.txt @@ -275,6 +275,13 @@ country CR: DFS-FCC (5490 - 5730 @ 20), (24), DFS (5735 - 5835 @ 20), (30) +# http://www.mincom.gob.cu/?q=marcoregulatorio +# - Redes Informáticas +# Resolución 127, 2011 - Reglamento Banda 2,4 GHz. +country CU: DFS-FCC + (2400 - 2456 @ 40), (200 mW) + (2456 - 2483.5 @ 40), (200 mW) + Based on the Google translation of the document you linked to, I don't see anything which would prevent merging these rules into one rule. Am I missing something? Thanks, Seth -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] ath10k: handle 10.4 firmware phyerr event
Header format of 10.4 firmware phyerr event is not alligned
with pre 10.4 firmware. Introduce new wmi handlers to parse
10.4 firmware specific phyerror event header.
With changes covered in this patch, radar detection works on
qca9x0 hw 2.0 which uses 10.4 firmware.
Signed-off-by: Raja Mani rm...@qti.qualcomm.com
---
v2 changes:
- Fixed below sparse warnings,
wmi.c:3620:33: warning: restricted __le32 degrades to integer
wmi.c:3622:38: warning: restricted __le32 degrades to integer
wmi.c:3594:5: warning: symbol 'ath10k_wmi_10_4_op_pull_phyerr_ev' was not
declared. Should it be static?
drivers/net/wireless/ath/ath10k/wmi.c | 64 +++
drivers/net/wireless/ath/ath10k/wmi.h | 20 +++
2 files changed, 84 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c
b/drivers/net/wireless/ath/ath10k/wmi.c
index 37dfa34..aad16eb 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -3527,6 +3527,26 @@ static int ath10k_wmi_op_pull_phyerr_ev_hdr(struct
ath10k *ar,
return 0;
}
+static int ath10k_wmi_10_4_op_pull_phyerr_ev_hdr(struct ath10k *ar,
+struct sk_buff *skb,
+struct wmi_phyerr_hdr_arg *arg)
+{
+ struct wmi_10_4_phyerr_event *ev = (void *)skb-data;
+
+ if (skb-len sizeof(*ev))
+ return -EPROTO;
+
+ /* 10.4 firmware always reports only one phyerr */
+ arg-num_phyerrs = 1;
+
+ arg-tsf_l32 = __le32_to_cpu(ev-tsf_l32);
+ arg-tsf_u32 = __le32_to_cpu(ev-tsf_u32);
+ arg-buf_len = skb-len;
+ arg-phyerrs = skb-data;
+
+ return 0;
+}
+
int ath10k_wmi_op_pull_phyerr_ev(struct ath10k *ar,
const void *phyerr_buf,
int left_len,
@@ -3571,6 +3591,45 @@ int ath10k_wmi_op_pull_phyerr_ev(struct ath10k *ar,
return 0;
}
+static int ath10k_wmi_10_4_op_pull_phyerr_ev(struct ath10k *ar,
+const void *phyerr_buf,
+int left_len,
+struct wmi_phyerr_ev_arg *arg)
+{
+ const struct wmi_10_4_phyerr_event *phyerr = phyerr_buf;
+ u32 phy_err_mask;
+ int i;
+
+ if (left_len sizeof(*phyerr)) {
+ ath10k_warn(ar, wrong phyerr event head len %d (need: =%d)\n,
+ left_len, sizeof(*phyerr));
+ return -EINVAL;
+ }
+
+ arg-tsf_timestamp = __le32_to_cpu(phyerr-tsf_timestamp);
+ arg-freq1 = __le16_to_cpu(phyerr-freq1);
+ arg-freq2 = __le16_to_cpu(phyerr-freq2);
+ arg-rssi_combined = phyerr-rssi_combined;
+ arg-chan_width_mhz = phyerr-chan_width_mhz;
+ arg-buf_len = __le32_to_cpu(phyerr-buf_len);
+ arg-buf = phyerr-buf;
+ arg-hdr_len = sizeof(*phyerr);
+
+ for (i = 0; i 4; i++)
+ arg-nf_chains[i] = __le16_to_cpu(phyerr-nf_chains[i]);
+
+ phy_err_mask = __le32_to_cpu(phyerr-phy_err_mask[0]);
+
+ if (phy_err_mask PHY_ERROR_10_4_SPECTRAL_SCAN_MASK)
+ arg-phy_err_code = PHY_ERROR_SPECTRAL_SCAN;
+ else if (phy_err_mask PHY_ERROR_10_4_RADAR_MASK)
+ arg-phy_err_code = PHY_ERROR_RADAR;
+ else
+ arg-phy_err_code = PHY_ERROR_UNKNOWN;
+
+ return 0;
+}
+
void ath10k_wmi_event_phyerr(struct ath10k *ar, struct sk_buff *skb)
{
struct wmi_phyerr_hdr_arg hdr_arg = {};
@@ -4528,6 +4587,9 @@ static void ath10k_wmi_10_4_op_rx(struct ath10k *ar,
struct sk_buff *skb)
case WMI_10_4_CHAN_INFO_EVENTID:
ath10k_wmi_event_chan_info(ar, skb);
break;
+ case WMI_10_4_PHYERR_EVENTID:
+ ath10k_wmi_event_phyerr(ar, skb);
+ break;
case WMI_10_4_READY_EVENTID:
ath10k_wmi_event_ready(ar, skb);
break;
@@ -6491,6 +6553,8 @@ static const struct wmi_ops wmi_10_4_ops = {
.pull_vdev_start = ath10k_wmi_op_pull_vdev_start_ev,
.pull_peer_kick = ath10k_wmi_op_pull_peer_kick_ev,
.pull_swba = ath10k_wmi_10_4_op_pull_swba_ev,
+ .pull_phyerr_hdr = ath10k_wmi_10_4_op_pull_phyerr_ev_hdr,
+ .pull_phyerr = ath10k_wmi_10_4_op_pull_phyerr_ev,
.pull_svc_rdy = ath10k_wmi_main_op_pull_svc_rdy_ev,
.pull_rdy = ath10k_wmi_op_pull_rdy_ev,
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h
b/drivers/net/wireless/ath/ath10k/wmi.h
index 0ed3cfe..c5d10db 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -2977,6 +2977,9 @@ struct wmi_10_4_mgmt_rx_event {
#define PHY_ERROR_GEN_FALSE_RADAR_EXT 0x24
#define PHY_ERROR_GEN_RADAR0x05
+#define PHY_ERROR_10_4_RADAR_MASK 0x4
+#define PHY_ERROR_10_4_SPECTRAL_SCAN_MASK 0x400
+
enum
Re: [PATCH 5/5] staging: wilc1000: use id value as argument
On Thu, Aug 13, 2015 at 01:41:23PM +0900, Tony Cho wrote:
+static u32 get_id_from_handler(tstrWILC_WFIDrv *handler)
+{
+ u32 id;
+
+ if (!handler)
+ return 0;
+
+ for (id = 0; id NUM_CONCURRENT_IFC; id++) {
+ if (wfidrv_list[id] == handler) {
+ id += 1;
+ break;
+ }
+ }
+
+ if (id NUM_CONCURRENT_IFC)
+ return 0;
+ else
+ return id;
+}
+
This still has an off by one bug. Just use zero offset arrays
throughout.
static int get_id_from_handler(tstrWILC_WFIDrv *handler)
{
int id;
if (!handler)
return -ENOBUFS;
for (id = 0; id NUM_CONCURRENT_IFC; id++) {
if (wfidrv_list[id] == handler)
return id;
}
return -ENOBUFS;
}
+static tstrWILC_WFIDrv *get_handler_from_id(u32 id)
+{
+ if (id 0 id = NUM_CONCURRENT_IFC)
+ return wfidrv_list[id - 1];
+ else
+ return NULL;
+}
static tstrWILC_WFIDrv *get_handler_from_id(int id)
{
if (id 0 || id = NUM_CONCURRENT_IFC)
return NULL;
return wfidrv_list[id];
}
regards,
dan carpenter
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: b43-phy0 ERROR: FOUND UNSUPPORTED PHY (Analog 12, Type 11 (AC), Revision 1)
On 13 August 2015 at 19:17, Hans de Goede hdego...@redhat.com wrote: I'm trying to help a Fedora user to get his wifi to work on a Lenovo Yoga 3 14, ad currently we are stuck with the b43 driving giving the error from $subject, is there anyone who can help with this ? Well, the $subject says everything. There is noone really working on it right now. -- Rafał -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] iw: fixes to Android.mk to include iw in AOSP builds
Hi Johannes, On Thu, Aug 13, 2015 at 2:01 AM, Johannes Berg johan...@sipsolutions.net wrote: We have a very similar patch internally as well (that I was still evualating/reviewing) but it was less complete, so I've applied this despite Arik's objections. Thank you! I think that if anyone needs to build against older Android, which is very well possible, we can partially revert this and maybe provide some environment variable they can control from their BSP, but until somebody really shows up with that I'll leave it as is and assume that older Android builds will also use older iw. Short term, yes, whoever wants to build this against KitKat can just revert this locally. Long term, considering this is in AOSP and is part of eng/userdebug builds, it's likely to be automatically available in future versions of Android. We ended up having to tweak the Android.mk again in the AOSP tree, since the current one is doing an include of the external Makefile, which in turns overrides the default clean rule and leaks some pattern rules such as %.o, etc. which affect the rest of Android build. For more details, please take a look at this Gerrit: https://android-review.googlesource.com/166104 I'm cc'ing Ying who spotted the problem and suggested the changes. One problem with the current approach is that there's duplication of the names of the source files between Android.mk and Makefile, I was thinking perhaps we could introduce a common.mk or sources.mk that's included from both and only has the variables that can be used by both? Suggestions are welcome. As mentioned in the initial thread, one option is to drop Android.mk from upstream altogether and maintain it in our AOSP downstream. Thanks! Filipe -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] iw: fixes to Android.mk to include iw in AOSP builds
On Thu, 2015-08-13 at 09:55 -0700, Filipe Brandenburger wrote: Long term, considering this is in AOSP and is part of eng/userdebug builds, it's likely to be automatically available in future versions of Android. Yeah, but most vendors don't actually build/run/ship AOSP nor necessarily an unmodified iw, so it's likely not all that helpful. We ended up having to tweak the Android.mk again in the AOSP tree, since the current one is doing an include of the external Makefile, which in turns overrides the default clean rule and leaks some pattern rules such as %.o, etc. which affect the rest of Android build. For more details, please take a look at this Gerrit: https://android-review.googlesource.com/166104 I'm cc'ing Ying who spotted the problem and suggested the changes. Thanks, but I'm not going to apply that patch in my tree - I don't want to have to worry about the duplication of LOCAL_SRC_FILES. One problem with the current approach is that there's duplication of the names of the source files between Android.mk and Makefile, I was thinking perhaps we could introduce a common.mk or sources.mk that's included from both and only has the variables that can be used by both? Suggestions are welcome. That seems reasonable. As mentioned in the initial thread, one option is to drop Android.mk from upstream altogether and maintain it in our AOSP downstream. Given what I just said above about vendor builds etc. not being AOSP, that probably wouldn't be all that helpful; I'm pretty sure it'd make our life more difficult so I don't really like that idea much. johannes -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ath9k_htc: do ani shortcalibratio if we got -ETIMEDOUT
From: Oleksij Rempel external.oleksij.rem...@de.bosch.com
current code will handle -ETIMEDOUT as success which is probalbly wrong.
According to this comment I assume it is safe to handle -ETIMEDOUT as false:
drivers/net/wireless/ath/ath9k/calib.c
290 /*
291 * We timed out waiting for the noisefloor to load, probably due to
an
292 * in-progress rx. Simply return here and allow the load plenty of
time
293 * to complete before the next calibration interval. We need to
avoid
294 * trying to load -50 (which happens below) while the previous load
is
295 * still in progress as this can cause rx deafness. Instead by
returning
296 * here, the baseband nf cal will just be capped by our present
297 * noisefloor until the next calibration timer.
298 */
Since no other error wariants are present, this patch is checking only
for (ret = 0).
Reported-by: Dan Carpenter dan.carpen...@oracle.com
Signed-off-by: Oleksij Rempel external.oleksij.rem...@de.bosch.com
---
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
index dab1323..172a9ff 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
@@ -794,8 +794,11 @@ void ath9k_htc_ani_work(struct work_struct *work)
common-ani.longcal_timer = timestamp;
}
- /* Short calibration applies only while caldone is false */
- if (!common-ani.caldone) {
+ /*
+* Short calibration applies only while caldone
+* is false or -ETIMEDOUT
+*/
+ if (common-ani.caldone = 0) {
if ((timestamp - common-ani.shortcal_timer) =
short_cal_interval) {
shortcal = true;
@@ -844,7 +847,11 @@ set_timer:
*/
cal_interval = ATH_LONG_CALINTERVAL;
cal_interval = min(cal_interval, (u32)ATH_ANI_POLLINTERVAL);
- if (!common-ani.caldone)
+ /*
+* Short calibration applies only while caldone
+* is false or -ETIMEDOUT
+*/
+ if (common-ani.caldone = 0)
cal_interval = min(cal_interval, (u32)short_cal_interval);
ieee80211_queue_delayed_work(common-hw, priv-ani_work,
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
set channel from radiotap headers during injection
I'd like to be able to set the channel information on a per-packet basis during monitor-mode injection. Specifically, I would like to be able to change the channel bandwidth down to half and quarter rates (my PHY supports this) based on the radiotap header information. Additionally, if its possible to change the channel itself that would be desirable. I've been able to add rate and FEC control to ieee80211_parse_tx_radiotap, but I'm not sure where to start with setting channel information. Has anyone been able to do this? If not, what do I need to set in order to get per-packet channel control? -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] bcma: switch GPIO portions to use GPIOLIB_IRQCHIP
From: Linus Walleij linus.wall...@linaro.org
This switches the BCMA GPIO driver to use GPIOLIB_IRQCHIP to
handle its interrupts instead of rolling its own copy of the
irqdomain handling etc.
Signed-off-by: Linus Walleij linus.wall...@linaro.org
Signed-off-by: Hauke Mehrtens ha...@hauke-m.de
---
changes since:
v2:
* use bcma_bus_get_host_dev()
v1:
* I fixed some bugs in the original patch, some of them are compile
errors and others caused some runtime problems.
drivers/bcma/Kconfig| 2 +-
drivers/bcma/driver_gpio.c | 92 ++---
include/linux/bcma/bcma_driver_chipcommon.h | 1 -
3 files changed, 31 insertions(+), 64 deletions(-)
diff --git a/drivers/bcma/Kconfig b/drivers/bcma/Kconfig
index be5fffb..023d448 100644
--- a/drivers/bcma/Kconfig
+++ b/drivers/bcma/Kconfig
@@ -92,7 +92,7 @@ config BCMA_DRIVER_GMAC_CMN
config BCMA_DRIVER_GPIO
bool BCMA GPIO driver
depends on BCMA GPIOLIB
- select IRQ_DOMAIN if BCMA_HOST_SOC
+ select GPIOLIB_IRQCHIP if BCMA_HOST_SOC
help
Driver to provide access to the GPIO pins of the bcma bus.
diff --git a/drivers/bcma/driver_gpio.c b/drivers/bcma/driver_gpio.c
index 5f6018e..504899a7 100644
--- a/drivers/bcma/driver_gpio.c
+++ b/drivers/bcma/driver_gpio.c
@@ -8,10 +8,8 @@
* Licensed under the GNU/GPL. See COPYING for details.
*/
-#include linux/gpio.h
-#include linux/irq.h
+#include linux/gpio/driver.h
#include linux/interrupt.h
-#include linux/irqdomain.h
#include linux/export.h
#include linux/bcma/bcma.h
@@ -79,19 +77,11 @@ static void bcma_gpio_free(struct gpio_chip *chip, unsigned
gpio)
}
#if IS_BUILTIN(CONFIG_BCM47XX) || IS_BUILTIN(CONFIG_ARCH_BCM_5301X)
-static int bcma_gpio_to_irq(struct gpio_chip *chip, unsigned gpio)
-{
- struct bcma_drv_cc *cc = bcma_gpio_get_cc(chip);
-
- if (cc-core-bus-hosttype == BCMA_HOSTTYPE_SOC)
- return irq_find_mapping(cc-irq_domain, gpio);
- else
- return -EINVAL;
-}
static void bcma_gpio_irq_unmask(struct irq_data *d)
{
- struct bcma_drv_cc *cc = irq_data_get_irq_chip_data(d);
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+ struct bcma_drv_cc *cc = bcma_gpio_get_cc(gc);
int gpio = irqd_to_hwirq(d);
u32 val = bcma_chipco_gpio_in(cc, BIT(gpio));
@@ -101,7 +91,8 @@ static void bcma_gpio_irq_unmask(struct irq_data *d)
static void bcma_gpio_irq_mask(struct irq_data *d)
{
- struct bcma_drv_cc *cc = irq_data_get_irq_chip_data(d);
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+ struct bcma_drv_cc *cc = bcma_gpio_get_cc(gc);
int gpio = irqd_to_hwirq(d);
bcma_chipco_gpio_intmask(cc, BIT(gpio), 0);
@@ -116,6 +107,7 @@ static struct irq_chip bcma_gpio_irq_chip = {
static irqreturn_t bcma_gpio_irq_handler(int irq, void *dev_id)
{
struct bcma_drv_cc *cc = dev_id;
+ struct gpio_chip *gc = cc-gpio;
u32 val = bcma_cc_read32(cc, BCMA_CC_GPIOIN);
u32 mask = bcma_cc_read32(cc, BCMA_CC_GPIOIRQ);
u32 pol = bcma_cc_read32(cc, BCMA_CC_GPIOPOL);
@@ -125,81 +117,58 @@ static irqreturn_t bcma_gpio_irq_handler(int irq, void
*dev_id)
if (!irqs)
return IRQ_NONE;
- for_each_set_bit(gpio, irqs, cc-gpio.ngpio)
- generic_handle_irq(bcma_gpio_to_irq(cc-gpio, gpio));
+ for_each_set_bit(gpio, irqs, gc-ngpio)
+ generic_handle_irq(irq_find_mapping(gc-irqdomain, gpio));
bcma_chipco_gpio_polarity(cc, irqs, val irqs);
return IRQ_HANDLED;
}
-static int bcma_gpio_irq_domain_init(struct bcma_drv_cc *cc)
+static int bcma_gpio_irq_init(struct bcma_drv_cc *cc)
{
struct gpio_chip *chip = cc-gpio;
- int gpio, hwirq, err;
+ int hwirq, err;
if (cc-core-bus-hosttype != BCMA_HOSTTYPE_SOC)
return 0;
- cc-irq_domain = irq_domain_add_linear(NULL, chip-ngpio,
- irq_domain_simple_ops, cc);
- if (!cc-irq_domain) {
- err = -ENODEV;
- goto err_irq_domain;
- }
- for (gpio = 0; gpio chip-ngpio; gpio++) {
- int irq = irq_create_mapping(cc-irq_domain, gpio);
-
- irq_set_chip_data(irq, cc);
- irq_set_chip_and_handler(irq, bcma_gpio_irq_chip,
-handle_simple_irq);
- }
-
hwirq = bcma_core_irq(cc-core, 0);
err = request_irq(hwirq, bcma_gpio_irq_handler, IRQF_SHARED, gpio,
cc);
if (err)
- goto err_req_irq;
+ return err;
bcma_chipco_gpio_intmask(cc, ~0, 0);
bcma_cc_set32(cc, BCMA_CC_IRQMASK, BCMA_CC_IRQ_GPIO);
- return 0;
-
-err_req_irq:
- for (gpio = 0; gpio chip-ngpio; gpio++) {
- int irq = irq_find_mapping(cc-irq_domain, gpio);
-
-
Re: [PATCH 1/2] average: provide macro to create static EWMA
From: Johannes Berg johan...@sipsolutions.net Date: Thu, 13 Aug 2015 11:11:48 +0200 From: Johannes Berg johannes.b...@intel.com Having the EWMA parameters stored in the runtime struct imposes memory requirements for the constant values that could just be inlined in the code. This particularly makes sense if there are a lot of such structs, for example in mac80211 in the station table where each station has a number of these in an array, and there can be many stations. Provide a macro DECLARE_EWMA() that declares the necessary struct and inline functions to access it with the parameters hard-coded; using this also means the user no longer needs to 'select AVERAGE' as it's entirely self-contained. In the mac80211 case, on x86-64, this actually slightly *reduces* code size, while also saving 80 bytes of runtime memory per sta. Signed-off-by: Johannes Berg johannes.b...@intel.com --- As the next patch relies on this, I'll take this through my tree unless I hear objections. This looks fine to me. -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] iwlwifi: out-of-bounds access in iwl_init_sband_channels
Both loops of this function compare data from the 'chan' array and then
check if the index is valid.
The 2 conditions should be inverted to avoid an out-of-bounds access.
Signed-off-by: Adrien Schildknecht adrien+...@schischi.me
---
drivers/net/wireless/iwlwifi/iwl-eeprom-parse.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-eeprom-parse.c
b/drivers/net/wireless/iwlwifi/iwl-eeprom-parse.c
index 21302b6..acc3d18 100644
--- a/drivers/net/wireless/iwlwifi/iwl-eeprom-parse.c
+++ b/drivers/net/wireless/iwlwifi/iwl-eeprom-parse.c
@@ -713,12 +713,12 @@ int iwl_init_sband_channels(struct iwl_nvm_data *data,
struct ieee80211_channel *chan = data-channels[0];
int n = 0, idx = 0;
- while (chan-band != band idx n_channels)
+ while (idx n_channels chan-band != band)
chan = data-channels[++idx];
sband-channels = data-channels[idx];
- while (chan-band == band idx n_channels) {
+ while (idx n_channels chan-band == band) {
chan = data-channels[++idx];
n++;
}
--
2.5.0
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Ath10 firmware crashing in Monitor mode(Sniffer mode)
On 08/13/2015 01:35 PM, s prasad wrote: Hi Ben, did you get a chance to look into this issue(injecting frames when device in monitor mode). Injection works in a limited fashion in my latest firmware. I'd like to figure out how to pass rate-ctrl (and other info?) down to the firmware on a per-pkt basis..but I don't see a way yet. Probably I have to hack the htt header or something like that to give some extra space. That sort of thing might allow a host-based rate-ctrl algorithm to be usedif someone is interested in working on the driver/kernel side of things for this effort let me know. I am not aware of any crashes related to monitor mode in my firmware..but if you can crash it, send me the crash dump and I'll take a look. Thanks, Ben -- Ben Greear gree...@candelatech.com Candela Technologies Inc http://www.candelatech.com -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] staging: wilc1000: Process WARN, INFO options of debug levels from user
On Wed, Aug 12, 2015 at 11:05:58PM +0530, Chandra S Gorentla wrote:
- if (copy_from_user(buffer, buf, count)) {
+ ret = simple_write_to_buffer(buffer, sizeof(buffer), ppos, buf, count);
This part doesn't make sense. Use copy_from_user(). Also it's not NUL
terminated so it leads to a read past the end of the array later. In
the original code, we just looked at the first char and didn't use
kstrtoint() so we didn't care about NUL termination.
regards,
dan carpenter
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] iwlwifi: out-of-bounds access in iwl_init_sband_channels
Hi,
On 08/14/2015 03:36 AM, Adrien Schildknecht wrote:
Both loops of this function compare data from the 'chan' array and then
check if the index is valid.
The 2 conditions should be inverted to avoid an out-of-bounds access.
Was that found by a static analyzer or any other automated tool, or was
that the result of your very careful review?
Signed-off-by: Adrien Schildknecht adrien+...@schischi.me
---
drivers/net/wireless/iwlwifi/iwl-eeprom-parse.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-eeprom-parse.c
b/drivers/net/wireless/iwlwifi/iwl-eeprom-parse.c
index 21302b6..acc3d18 100644
--- a/drivers/net/wireless/iwlwifi/iwl-eeprom-parse.c
+++ b/drivers/net/wireless/iwlwifi/iwl-eeprom-parse.c
@@ -713,12 +713,12 @@ int iwl_init_sband_channels(struct iwl_nvm_data *data,
struct ieee80211_channel *chan = data-channels[0];
int n = 0, idx = 0;
- while (chan-band != band idx n_channels)
+ while (idx n_channels chan-band != band)
chan = data-channels[++idx];
sband-channels = data-channels[idx];
- while (chan-band == band idx n_channels) {
+ while (idx n_channels chan-band == band) {
chan = data-channels[++idx];
n++;
}
Looks fine - I'll pick it up.
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] ath9k_htc: do ani shortcalibratio if we got -ETIMEDOUT
current code will handle -ETIMEDOUT as success which is probalbly wrong.
According to this comment I assume it is safe to handle -ETIMEDOUT as false:
drivers/net/wireless/ath/ath9k/calib.c
290 /*
291 * We timed out waiting for the noisefloor to load, probably due to
an
292 * in-progress rx. Simply return here and allow the load plenty of
time
293 * to complete before the next calibration interval. We need to
avoid
294 * trying to load -50 (which happens below) while the previous load
is
295 * still in progress as this can cause rx deafness. Instead by
returning
296 * here, the baseband nf cal will just be capped by our present
297 * noisefloor until the next calibration timer.
298 */
Since no other error wariants are present, this patch is checking only
for (ret = 0).
Reported-by: Dan Carpenter dan.carpen...@oracle.com
Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
index dab1323..172a9ff 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
@@ -794,8 +794,11 @@ void ath9k_htc_ani_work(struct work_struct *work)
common-ani.longcal_timer = timestamp;
}
- /* Short calibration applies only while caldone is false */
- if (!common-ani.caldone) {
+ /*
+* Short calibration applies only while caldone
+* is false or -ETIMEDOUT
+*/
+ if (common-ani.caldone = 0) {
if ((timestamp - common-ani.shortcal_timer) =
short_cal_interval) {
shortcal = true;
@@ -844,7 +847,11 @@ set_timer:
*/
cal_interval = ATH_LONG_CALINTERVAL;
cal_interval = min(cal_interval, (u32)ATH_ANI_POLLINTERVAL);
- if (!common-ani.caldone)
+ /*
+* Short calibration applies only while caldone
+* is false or -ETIMEDOUT
+*/
+ if (common-ani.caldone = 0)
cal_interval = min(cal_interval, (u32)short_cal_interval);
ieee80211_queue_delayed_work(common-hw, priv-ani_work,
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ath9k-devel] [PATCH] ath9k_htc: do ani shortcalibratio if we got -ETIMEDOUT
Opps wrong email address. I'll resend the patch
Am 13.08.2015 um 20:21 schrieb Oleksij Rempel:
From: Oleksij Rempel external.oleksij.rem...@de.bosch.com
current code will handle -ETIMEDOUT as success which is probalbly wrong.
According to this comment I assume it is safe to handle -ETIMEDOUT as false:
drivers/net/wireless/ath/ath9k/calib.c
290 /*
291 * We timed out waiting for the noisefloor to load, probably due
to an
292 * in-progress rx. Simply return here and allow the load plenty
of time
293 * to complete before the next calibration interval. We need to
avoid
294 * trying to load -50 (which happens below) while the previous
load is
295 * still in progress as this can cause rx deafness. Instead by
returning
296 * here, the baseband nf cal will just be capped by our present
297 * noisefloor until the next calibration timer.
298 */
Since no other error wariants are present, this patch is checking only
for (ret = 0).
Reported-by: Dan Carpenter dan.carpen...@oracle.com
Signed-off-by: Oleksij Rempel external.oleksij.rem...@de.bosch.com
---
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
index dab1323..172a9ff 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
@@ -794,8 +794,11 @@ void ath9k_htc_ani_work(struct work_struct *work)
common-ani.longcal_timer = timestamp;
}
- /* Short calibration applies only while caldone is false */
- if (!common-ani.caldone) {
+ /*
+ * Short calibration applies only while caldone
+ * is false or -ETIMEDOUT
+ */
+ if (common-ani.caldone = 0) {
if ((timestamp - common-ani.shortcal_timer) =
short_cal_interval) {
shortcal = true;
@@ -844,7 +847,11 @@ set_timer:
*/
cal_interval = ATH_LONG_CALINTERVAL;
cal_interval = min(cal_interval, (u32)ATH_ANI_POLLINTERVAL);
- if (!common-ani.caldone)
+ /*
+ * Short calibration applies only while caldone
+ * is false or -ETIMEDOUT
+ */
+ if (common-ani.caldone = 0)
cal_interval = min(cal_interval, (u32)short_cal_interval);
ieee80211_queue_delayed_work(common-hw, priv-ani_work,
--
Regards,
Oleksij
signature.asc
Description: OpenPGP digital signature
[PATCH v3] ath9k_htc: introduce support for different fw versions
Current kernel support only one fw name with theoretically only one
fw version located in “firmware/htc_[9271|7010].fw”. Which is ok so far we have
only one fw version (1.3). After we realised new fw 1.4, we faced compatibility
problem which was decided to solve by firmware name and location:
- new firmware is located now in firmware/ath9k_htc/htc_[9271|7010]-1.4.0.fw
- old version 1.3 should be on old place, so old kernel have no issues with it.
- new kernels including this patch should be able to try different supported
(min..max) fw version.
- new kernel should be able to support old fw location too. At least for now.
At same time this patch will add new module option which should allow user to
play with development fw version without replacing stable one. If user will
set “ath9k_htc use_dev_fw=1” module will try to find
firmware/ath9k_htc/htc_[9271|7010]-1.dev.0.fw first and if it fails, use stable
version: for example...1.4.0.fw.
Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
drivers/net/wireless/ath/ath9k/hif_usb.c | 106 --
drivers/net/wireless/ath/ath9k/hif_usb.h | 21 -
drivers/net/wireless/ath/ath9k/htc_drv_init.c | 4 +
3 files changed, 105 insertions(+), 26 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c
b/drivers/net/wireless/ath/ath9k/hif_usb.c
index 10c02f5..165dd20 100644
--- a/drivers/net/wireless/ath/ath9k/hif_usb.c
+++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
@@ -17,12 +17,8 @@
#include asm/unaligned.h
#include htc.h
-/* identify firmware images */
-#define FIRMWARE_AR7010_1_1 htc_7010.fw
-#define FIRMWARE_AR9271 htc_9271.fw
-
-MODULE_FIRMWARE(FIRMWARE_AR7010_1_1);
-MODULE_FIRMWARE(FIRMWARE_AR9271);
+MODULE_FIRMWARE(HTC_7010_MODULE_FW);
+MODULE_FIRMWARE(HTC_9271_MODULE_FW);
static struct usb_device_id ath9k_hif_usb_ids[] = {
{ USB_DEVICE(0x0cf3, 0x9271) }, /* Atheros */
@@ -1080,12 +1076,88 @@ static void ath9k_hif_usb_firmware_fail(struct
hif_device_usb *hif_dev)
device_unlock(parent);
}
+static void ath9k_hif_usb_firmware_cb(const struct firmware *fw, void
*context);
+
+/* taken from iwlwifi */
+static int ath9k_hif_request_firmware(struct hif_device_usb *hif_dev,
+ bool first)
+{
+ char index[8], *chip;
+ int ret;
+
+ if (first) {
+ if (htc_use_dev_fw) {
+ hif_dev-fw_minor_index = FIRMWARE_MINOR_IDX_MAX + 1;
+ sprintf(index, %s, dev);
+ } else {
+ hif_dev-fw_minor_index = FIRMWARE_MINOR_IDX_MAX;
+ sprintf(index, %d, hif_dev-fw_minor_index);
+ }
+ } else {
+ hif_dev-fw_minor_index--;
+ sprintf(index, %d, hif_dev-fw_minor_index);
+ }
+
+ /* test for FW 1.3 */
+ if (MAJOR_VERSION_REQ == 1 hif_dev-fw_minor_index == 3) {
+ const char *filename;
+
+ if (IS_AR7010_DEVICE(hif_dev-usb_device_id-driver_info))
+ filename = FIRMWARE_AR7010_1_1;
+ else
+ filename = FIRMWARE_AR9271;
+
+ /* expected fw locations:
+* - htc_9271.fw (stable version 1.3, depricated)
+*/
+ snprintf(hif_dev-fw_name, sizeof(hif_dev-fw_name),
+%s, filename);
+
+ } else if (hif_dev-fw_minor_index FIRMWARE_MINOR_IDX_MIN) {
+ dev_err(hif_dev-udev-dev, no suitable firmware found!\n);
+
+ return -ENOENT;
+ } else {
+ if (IS_AR7010_DEVICE(hif_dev-usb_device_id-driver_info))
+ chip = 7010;
+ else
+ chip = 9271;
+
+ /* expected fw locations:
+* - ath9k_htc/htc_9271-1.dev.0.fw (development version)
+* - ath9k_htc/htc_9271-1.4.0.fw (stable version)
+*/
+ snprintf(hif_dev-fw_name, sizeof(hif_dev-fw_name),
+%s/htc_%s-%d.%s.0.fw, HTC_FW_PATH,
+chip, MAJOR_VERSION_REQ, index);
+ }
+
+ ret = request_firmware_nowait(THIS_MODULE, true, hif_dev-fw_name,
+ hif_dev-udev-dev, GFP_KERNEL,
+ hif_dev, ath9k_hif_usb_firmware_cb);
+ if (ret) {
+ dev_err(hif_dev-udev-dev,
+ ath9k_htc: Async request for firmware %s failed\n,
+ hif_dev-fw_name);
+ return ret;
+ }
+
+ dev_info(hif_dev-udev-dev, ath9k_htc: Firmware %s requested\n,
+hif_dev-fw_name);
+
+ return ret;
+}
+
static void ath9k_hif_usb_firmware_cb(const struct firmware *fw, void *context)
{
struct hif_device_usb *hif_dev = context;
int ret;
if (!fw) {
+ ret = ath9k_hif_request_firmware(hif_dev,
Re: [PATCH 0/2] iw: fixes to Android.mk to include iw in AOSP builds
On Thu, 2015-08-13 at 12:48 -0700, enh wrote: i think you misunderstand what AOSP is. this code is currently in AOSP master, and thus in internal master, and thus in a future release. Great, but as I understand it, vendors are under no obligation to actually ship that code on their devices. If a vendor needs to have an iw that, for example, supports their own vendor commands (which, as I understand from the wifihal etc., Google is basically forcing vendors to have!), then the AOSP iw is useless and an own version needs to be built. johannes -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] iw: fixes to Android.mk to include iw in AOSP builds
On Thu, 2015-08-13 at 13:44 -0700, enh wrote: but given that our iw is your iw anyway... i don't understand the situation in which they'd be inconvenienced here? But it's not. We can reasonably expect everyone who actually cares to have local modifications to iw that they aren't publishing (and that I wouldn't apply anyway since it'd be for vendor commands) - and they need to build *that* iw, not our iw. The fact that libwifihal more or less wants you to do vendor extensions makes that all the more likely, since if you want to test those with iw then you need a modified iw. johannes -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Ath10 firmware crashing in Monitor mode(Sniffer mode)
Thank you Ben for immediate response, Don't mind, could you please share your firmware path. Sorry I didn't change old subject line. Thanks Regards, S Prasad On Aug 13, 2015, at 4:43 PM, Ben Greear gree...@candelatech.com wrote: On 08/13/2015 01:35 PM, s prasad wrote: Hi Ben, did you get a chance to look into this issue(injecting frames when device in monitor mode). Injection works in a limited fashion in my latest firmware. I'd like to figure out how to pass rate-ctrl (and other info?) down to the firmware on a per-pkt basis..but I don't see a way yet. Probably I have to hack the htt header or something like that to give some extra space. That sort of thing might allow a host-based rate-ctrl algorithm to be usedif someone is interested in working on the driver/kernel side of things for this effort let me know. I am not aware of any crashes related to monitor mode in my firmware..but if you can crash it, send me the crash dump and I'll take a look. Thanks, Ben -- Ben Greear gree...@candelatech.com Candela Technologies Inc http://www.candelatech.com -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ath10k: Fill in wmi 10.4 command handlers for addba/delba debug commands
WMI 10.4 uses the same command interface as QCA988X for addba/delba
debug wmi commands. Fill wmi_10_4_ops table with the functions used
for QCA988X for these commands.
With this change, the following debugfs entries can be used to
configure the aggregation mode and to send addba request,
addba response and delba respectively in manual aggregation mode
for QCA99X0 chip.
/sys/kernel/debug/ieee80211/phyX/netdev:wlanX/stations/XX:XX:XX:XX:XX:XX/aggr_mode
/sys/kernel/debug/ieee80211/phyX/netdev:wlanX/stations/XX:XX:XX:XX:XX:XX/addba
/sys/kernel/debug/ieee80211/phyX/netdev:wlanX/stations/XX:XX:XX:XX:XX:XX/addba_resp
/sys/kernel/debug/ieee80211/phyX/netdev:wlanX/stations/XX:XX:XX:XX:XX:XX/delba
Signed-off-by: Vasanthakumar Thiagarajan vthia...@qti.qualcomm.com
---
drivers/net/wireless/ath/ath10k/wmi.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c
b/drivers/net/wireless/ath/ath10k/wmi.c
index 36b8f71..9769936 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -6482,6 +6482,10 @@ static const struct wmi_ops wmi_10_4_ops = {
.gen_pktlog_enable = ath10k_wmi_op_gen_pktlog_enable,
.gen_pktlog_disable = ath10k_wmi_op_gen_pktlog_disable,
.gen_pdev_set_quiet_mode = ath10k_wmi_op_gen_pdev_set_quiet_mode,
+ .gen_addba_clear_resp = ath10k_wmi_op_gen_addba_clear_resp,
+ .gen_addba_send = ath10k_wmi_op_gen_addba_send,
+ .gen_addba_set_resp = ath10k_wmi_op_gen_addba_set_resp,
+ .gen_delba_send = ath10k_wmi_op_gen_delba_send,
/* shared with 10.2 */
.gen_peer_assoc = ath10k_wmi_10_2_op_gen_peer_assoc,
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
