* Re: [patch] nl80211: nl80211hdr_put() doesn't return an ERR_PTR
From: Johannes Berg @ 2013-08-14 11:56 UTC (permalink / raw)
To: Dan Carpenter; +Cc: John W. Linville, linux-wireless, kernel-janitors
In-Reply-To: <20130814115001.GB8044@elgon.mountain>
On Wed, 2013-08-14 at 14:50 +0300, Dan Carpenter wrote:
> There are a few places which check nl80211hdr_put() for an ERR_PTR
> but actually it returns NULL on error and never error values. In
> nl80211_testmode_dump() the return wasn't checked at all so I have added
> one.
Err, wow. How did we do this?!
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> ---
> This is static checker stuff and I don't know the code well. I was
> especially not sure if I got the check right in nl80211_testmode_dump().
> Please review that bit carefully.
Yes, looks fine. I'll apply this for 3.11, thanks.
johannes
^ permalink raw reply
* Re: [PATCH 3.11] cfg80211: don't request disconnect if not connected
From: Johannes Berg @ 2013-08-14 12:00 UTC (permalink / raw)
To: linux-wireless; +Cc: neilb
In-Reply-To: <1376378976-9588-1-git-send-email-johannes@sipsolutions.net>
On Tue, 2013-08-13 at 09:29 +0200, Johannes Berg wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> Neil Brown reports that with libertas, my recent cfg80211
> SME changes in commit ceca7b7121795ef81bd598a240d53a92566
> ("cfg80211: separate internal SME implementation") broke
> libertas suspend because it we now asked it to disconnect
> while already disconnected.
>
> The problematic change is in cfg80211_disconnect() as it
> previously checked the SME state and now calls the driver
> disconnect operation unconditionally.
>
> Fix this by checking if there's a current_bss indicating
> a connection, and do nothing if not.
Applied.
johannes
^ permalink raw reply
* [PATCHv2 1/2] mac80211: perform power save processing before decryption
From: Johan Almbladh @ 2013-08-14 13:29 UTC (permalink / raw)
To: johannes; +Cc: ordex, linux-wireless, Johan Almbladh
In-Reply-To: <1376323275.11514.26.camel@jlt4.sipsolutions.net>
This patch decouples the power save processing from the frame decryption
by running the decrypt rx handler after sta_process. In the case where
the decryption failed for some reason, the stack used to not process
the PM and MOREDATA bits for that frame. The stack now always performs
power save processing regardless of the decryption result. That means that
encrypted data frames and NULLFUNC frames are now handled in the same way
regarding power save processing, making the stack more robust.
Tested-by: Johan Almbladh <ja@anyfi.net>
Signed-off-by: Johan Almbladh <ja@anyfi.net>
---
net/mac80211/rx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 6b85f95..0f0017d 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -2939,10 +2939,10 @@ static void ieee80211_rx_handlers(struct ieee80211_rx_data *rx,
*/
rx->skb = skb;
- CALL_RXH(ieee80211_rx_h_decrypt)
CALL_RXH(ieee80211_rx_h_check_more_data)
CALL_RXH(ieee80211_rx_h_uapsd_and_pspoll)
CALL_RXH(ieee80211_rx_h_sta_process)
+ CALL_RXH(ieee80211_rx_h_decrypt)
CALL_RXH(ieee80211_rx_h_defragment)
CALL_RXH(ieee80211_rx_h_michael_mic_verify)
/* must be after MMIC verify so header is counted in MPDU mic */
--
1.7.9.5
^ permalink raw reply related
* [PATCHv2 2/2] mac80211: non-functional change of rx handler location
From: Johan Almbladh @ 2013-08-14 13:29 UTC (permalink / raw)
To: johannes; +Cc: ordex, linux-wireless, Johan Almbladh
In-Reply-To: <1376486987-23224-1-git-send-email-ja@anyfi.net>
This patch changes the location of the rx handler functions to match
the new order in which they are invoked.
Tested-by: Johan Almbladh <ja@anyfi.net>
Signed-off-by: Johan Almbladh <ja@anyfi.net>
---
net/mac80211/rx.c | 402 ++++++++++++++++++++++++++---------------------------
1 file changed, 201 insertions(+), 201 deletions(-)
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 0f0017d..a84f319 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -1055,207 +1055,6 @@ ieee80211_rx_h_check(struct ieee80211_rx_data *rx)
static ieee80211_rx_result debug_noinline
-ieee80211_rx_h_decrypt(struct ieee80211_rx_data *rx)
-{
- struct sk_buff *skb = rx->skb;
- struct ieee80211_rx_status *status = IEEE80211_SKB_RXCB(skb);
- struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data;
- int keyidx;
- int hdrlen;
- ieee80211_rx_result result = RX_DROP_UNUSABLE;
- struct ieee80211_key *sta_ptk = NULL;
- int mmie_keyidx = -1;
- __le16 fc;
-
- /*
- * Key selection 101
- *
- * There are four types of keys:
- * - GTK (group keys)
- * - IGTK (group keys for management frames)
- * - PTK (pairwise keys)
- * - STK (station-to-station pairwise keys)
- *
- * When selecting a key, we have to distinguish between multicast
- * (including broadcast) and unicast frames, the latter can only
- * use PTKs and STKs while the former always use GTKs and IGTKs.
- * Unless, of course, actual WEP keys ("pre-RSNA") are used, then
- * unicast frames can also use key indices like GTKs. Hence, if we
- * don't have a PTK/STK we check the key index for a WEP key.
- *
- * Note that in a regular BSS, multicast frames are sent by the
- * AP only, associated stations unicast the frame to the AP first
- * which then multicasts it on their behalf.
- *
- * There is also a slight problem in IBSS mode: GTKs are negotiated
- * with each station, that is something we don't currently handle.
- * The spec seems to expect that one negotiates the same key with
- * every station but there's no such requirement; VLANs could be
- * possible.
- */
-
- /*
- * No point in finding a key and decrypting if the frame is neither
- * addressed to us nor a multicast frame.
- */
- if (!(status->rx_flags & IEEE80211_RX_RA_MATCH))
- return RX_CONTINUE;
-
- /* start without a key */
- rx->key = NULL;
-
- if (rx->sta)
- sta_ptk = rcu_dereference(rx->sta->ptk);
-
- fc = hdr->frame_control;
-
- if (!ieee80211_has_protected(fc))
- mmie_keyidx = ieee80211_get_mmie_keyidx(rx->skb);
-
- if (!is_multicast_ether_addr(hdr->addr1) && sta_ptk) {
- rx->key = sta_ptk;
- if ((status->flag & RX_FLAG_DECRYPTED) &&
- (status->flag & RX_FLAG_IV_STRIPPED))
- return RX_CONTINUE;
- /* Skip decryption if the frame is not protected. */
- if (!ieee80211_has_protected(fc))
- return RX_CONTINUE;
- } else if (mmie_keyidx >= 0) {
- /* Broadcast/multicast robust management frame / BIP */
- if ((status->flag & RX_FLAG_DECRYPTED) &&
- (status->flag & RX_FLAG_IV_STRIPPED))
- return RX_CONTINUE;
-
- if (mmie_keyidx < NUM_DEFAULT_KEYS ||
- mmie_keyidx >= NUM_DEFAULT_KEYS + NUM_DEFAULT_MGMT_KEYS)
- return RX_DROP_MONITOR; /* unexpected BIP keyidx */
- if (rx->sta)
- rx->key = rcu_dereference(rx->sta->gtk[mmie_keyidx]);
- if (!rx->key)
- rx->key = rcu_dereference(rx->sdata->keys[mmie_keyidx]);
- } else if (!ieee80211_has_protected(fc)) {
- /*
- * The frame was not protected, so skip decryption. However, we
- * need to set rx->key if there is a key that could have been
- * used so that the frame may be dropped if encryption would
- * have been expected.
- */
- struct ieee80211_key *key = NULL;
- struct ieee80211_sub_if_data *sdata = rx->sdata;
- int i;
-
- if (ieee80211_is_mgmt(fc) &&
- is_multicast_ether_addr(hdr->addr1) &&
- (key = rcu_dereference(rx->sdata->default_mgmt_key)))
- rx->key = key;
- else {
- if (rx->sta) {
- for (i = 0; i < NUM_DEFAULT_KEYS; i++) {
- key = rcu_dereference(rx->sta->gtk[i]);
- if (key)
- break;
- }
- }
- if (!key) {
- for (i = 0; i < NUM_DEFAULT_KEYS; i++) {
- key = rcu_dereference(sdata->keys[i]);
- if (key)
- break;
- }
- }
- if (key)
- rx->key = key;
- }
- return RX_CONTINUE;
- } else {
- u8 keyid;
- /*
- * The device doesn't give us the IV so we won't be
- * able to look up the key. That's ok though, we
- * don't need to decrypt the frame, we just won't
- * be able to keep statistics accurate.
- * Except for key threshold notifications, should
- * we somehow allow the driver to tell us which key
- * the hardware used if this flag is set?
- */
- if ((status->flag & RX_FLAG_DECRYPTED) &&
- (status->flag & RX_FLAG_IV_STRIPPED))
- return RX_CONTINUE;
-
- hdrlen = ieee80211_hdrlen(fc);
-
- if (rx->skb->len < 8 + hdrlen)
- return RX_DROP_UNUSABLE; /* TODO: count this? */
-
- /*
- * no need to call ieee80211_wep_get_keyidx,
- * it verifies a bunch of things we've done already
- */
- skb_copy_bits(rx->skb, hdrlen + 3, &keyid, 1);
- keyidx = keyid >> 6;
-
- /* check per-station GTK first, if multicast packet */
- if (is_multicast_ether_addr(hdr->addr1) && rx->sta)
- rx->key = rcu_dereference(rx->sta->gtk[keyidx]);
-
- /* if not found, try default key */
- if (!rx->key) {
- rx->key = rcu_dereference(rx->sdata->keys[keyidx]);
-
- /*
- * RSNA-protected unicast frames should always be
- * sent with pairwise or station-to-station keys,
- * but for WEP we allow using a key index as well.
- */
- if (rx->key &&
- rx->key->conf.cipher != WLAN_CIPHER_SUITE_WEP40 &&
- rx->key->conf.cipher != WLAN_CIPHER_SUITE_WEP104 &&
- !is_multicast_ether_addr(hdr->addr1))
- rx->key = NULL;
- }
- }
-
- if (rx->key) {
- if (unlikely(rx->key->flags & KEY_FLAG_TAINTED))
- return RX_DROP_MONITOR;
-
- rx->key->tx_rx_count++;
- /* TODO: add threshold stuff again */
- } else {
- return RX_DROP_MONITOR;
- }
-
- switch (rx->key->conf.cipher) {
- case WLAN_CIPHER_SUITE_WEP40:
- case WLAN_CIPHER_SUITE_WEP104:
- result = ieee80211_crypto_wep_decrypt(rx);
- break;
- case WLAN_CIPHER_SUITE_TKIP:
- result = ieee80211_crypto_tkip_decrypt(rx);
- break;
- case WLAN_CIPHER_SUITE_CCMP:
- result = ieee80211_crypto_ccmp_decrypt(rx);
- break;
- case WLAN_CIPHER_SUITE_AES_CMAC:
- result = ieee80211_crypto_aes_cmac_decrypt(rx);
- break;
- default:
- /*
- * We can reach here only with HW-only algorithms
- * but why didn't it decrypt the frame?!
- */
- return RX_DROP_UNUSABLE;
- }
-
- /* the hdr variable is invalid after the decrypt handlers */
-
- /* either the frame has been decrypted or will be dropped */
- status->flag |= RX_FLAG_DECRYPTED;
-
- return result;
-}
-
-static ieee80211_rx_result debug_noinline
ieee80211_rx_h_check_more_data(struct ieee80211_rx_data *rx)
{
struct ieee80211_local *local;
@@ -1556,6 +1355,207 @@ ieee80211_rx_h_sta_process(struct ieee80211_rx_data *rx)
return RX_CONTINUE;
} /* ieee80211_rx_h_sta_process */
+static ieee80211_rx_result debug_noinline
+ieee80211_rx_h_decrypt(struct ieee80211_rx_data *rx)
+{
+ struct sk_buff *skb = rx->skb;
+ struct ieee80211_rx_status *status = IEEE80211_SKB_RXCB(skb);
+ struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data;
+ int keyidx;
+ int hdrlen;
+ ieee80211_rx_result result = RX_DROP_UNUSABLE;
+ struct ieee80211_key *sta_ptk = NULL;
+ int mmie_keyidx = -1;
+ __le16 fc;
+
+ /*
+ * Key selection 101
+ *
+ * There are four types of keys:
+ * - GTK (group keys)
+ * - IGTK (group keys for management frames)
+ * - PTK (pairwise keys)
+ * - STK (station-to-station pairwise keys)
+ *
+ * When selecting a key, we have to distinguish between multicast
+ * (including broadcast) and unicast frames, the latter can only
+ * use PTKs and STKs while the former always use GTKs and IGTKs.
+ * Unless, of course, actual WEP keys ("pre-RSNA") are used, then
+ * unicast frames can also use key indices like GTKs. Hence, if we
+ * don't have a PTK/STK we check the key index for a WEP key.
+ *
+ * Note that in a regular BSS, multicast frames are sent by the
+ * AP only, associated stations unicast the frame to the AP first
+ * which then multicasts it on their behalf.
+ *
+ * There is also a slight problem in IBSS mode: GTKs are negotiated
+ * with each station, that is something we don't currently handle.
+ * The spec seems to expect that one negotiates the same key with
+ * every station but there's no such requirement; VLANs could be
+ * possible.
+ */
+
+ /*
+ * No point in finding a key and decrypting if the frame is neither
+ * addressed to us nor a multicast frame.
+ */
+ if (!(status->rx_flags & IEEE80211_RX_RA_MATCH))
+ return RX_CONTINUE;
+
+ /* start without a key */
+ rx->key = NULL;
+
+ if (rx->sta)
+ sta_ptk = rcu_dereference(rx->sta->ptk);
+
+ fc = hdr->frame_control;
+
+ if (!ieee80211_has_protected(fc))
+ mmie_keyidx = ieee80211_get_mmie_keyidx(rx->skb);
+
+ if (!is_multicast_ether_addr(hdr->addr1) && sta_ptk) {
+ rx->key = sta_ptk;
+ if ((status->flag & RX_FLAG_DECRYPTED) &&
+ (status->flag & RX_FLAG_IV_STRIPPED))
+ return RX_CONTINUE;
+ /* Skip decryption if the frame is not protected. */
+ if (!ieee80211_has_protected(fc))
+ return RX_CONTINUE;
+ } else if (mmie_keyidx >= 0) {
+ /* Broadcast/multicast robust management frame / BIP */
+ if ((status->flag & RX_FLAG_DECRYPTED) &&
+ (status->flag & RX_FLAG_IV_STRIPPED))
+ return RX_CONTINUE;
+
+ if (mmie_keyidx < NUM_DEFAULT_KEYS ||
+ mmie_keyidx >= NUM_DEFAULT_KEYS + NUM_DEFAULT_MGMT_KEYS)
+ return RX_DROP_MONITOR; /* unexpected BIP keyidx */
+ if (rx->sta)
+ rx->key = rcu_dereference(rx->sta->gtk[mmie_keyidx]);
+ if (!rx->key)
+ rx->key = rcu_dereference(rx->sdata->keys[mmie_keyidx]);
+ } else if (!ieee80211_has_protected(fc)) {
+ /*
+ * The frame was not protected, so skip decryption. However, we
+ * need to set rx->key if there is a key that could have been
+ * used so that the frame may be dropped if encryption would
+ * have been expected.
+ */
+ struct ieee80211_key *key = NULL;
+ struct ieee80211_sub_if_data *sdata = rx->sdata;
+ int i;
+
+ if (ieee80211_is_mgmt(fc) &&
+ is_multicast_ether_addr(hdr->addr1) &&
+ (key = rcu_dereference(rx->sdata->default_mgmt_key)))
+ rx->key = key;
+ else {
+ if (rx->sta) {
+ for (i = 0; i < NUM_DEFAULT_KEYS; i++) {
+ key = rcu_dereference(rx->sta->gtk[i]);
+ if (key)
+ break;
+ }
+ }
+ if (!key) {
+ for (i = 0; i < NUM_DEFAULT_KEYS; i++) {
+ key = rcu_dereference(sdata->keys[i]);
+ if (key)
+ break;
+ }
+ }
+ if (key)
+ rx->key = key;
+ }
+ return RX_CONTINUE;
+ } else {
+ u8 keyid;
+ /*
+ * The device doesn't give us the IV so we won't be
+ * able to look up the key. That's ok though, we
+ * don't need to decrypt the frame, we just won't
+ * be able to keep statistics accurate.
+ * Except for key threshold notifications, should
+ * we somehow allow the driver to tell us which key
+ * the hardware used if this flag is set?
+ */
+ if ((status->flag & RX_FLAG_DECRYPTED) &&
+ (status->flag & RX_FLAG_IV_STRIPPED))
+ return RX_CONTINUE;
+
+ hdrlen = ieee80211_hdrlen(fc);
+
+ if (rx->skb->len < 8 + hdrlen)
+ return RX_DROP_UNUSABLE; /* TODO: count this? */
+
+ /*
+ * no need to call ieee80211_wep_get_keyidx,
+ * it verifies a bunch of things we've done already
+ */
+ skb_copy_bits(rx->skb, hdrlen + 3, &keyid, 1);
+ keyidx = keyid >> 6;
+
+ /* check per-station GTK first, if multicast packet */
+ if (is_multicast_ether_addr(hdr->addr1) && rx->sta)
+ rx->key = rcu_dereference(rx->sta->gtk[keyidx]);
+
+ /* if not found, try default key */
+ if (!rx->key) {
+ rx->key = rcu_dereference(rx->sdata->keys[keyidx]);
+
+ /*
+ * RSNA-protected unicast frames should always be
+ * sent with pairwise or station-to-station keys,
+ * but for WEP we allow using a key index as well.
+ */
+ if (rx->key &&
+ rx->key->conf.cipher != WLAN_CIPHER_SUITE_WEP40 &&
+ rx->key->conf.cipher != WLAN_CIPHER_SUITE_WEP104 &&
+ !is_multicast_ether_addr(hdr->addr1))
+ rx->key = NULL;
+ }
+ }
+
+ if (rx->key) {
+ if (unlikely(rx->key->flags & KEY_FLAG_TAINTED))
+ return RX_DROP_MONITOR;
+
+ rx->key->tx_rx_count++;
+ /* TODO: add threshold stuff again */
+ } else {
+ return RX_DROP_MONITOR;
+ }
+
+ switch (rx->key->conf.cipher) {
+ case WLAN_CIPHER_SUITE_WEP40:
+ case WLAN_CIPHER_SUITE_WEP104:
+ result = ieee80211_crypto_wep_decrypt(rx);
+ break;
+ case WLAN_CIPHER_SUITE_TKIP:
+ result = ieee80211_crypto_tkip_decrypt(rx);
+ break;
+ case WLAN_CIPHER_SUITE_CCMP:
+ result = ieee80211_crypto_ccmp_decrypt(rx);
+ break;
+ case WLAN_CIPHER_SUITE_AES_CMAC:
+ result = ieee80211_crypto_aes_cmac_decrypt(rx);
+ break;
+ default:
+ /*
+ * We can reach here only with HW-only algorithms
+ * but why didn't it decrypt the frame?!
+ */
+ return RX_DROP_UNUSABLE;
+ }
+
+ /* the hdr variable is invalid after the decrypt handlers */
+
+ /* either the frame has been decrypted or will be dropped */
+ status->flag |= RX_FLAG_DECRYPTED;
+
+ return result;
+}
+
static inline struct ieee80211_fragment_entry *
ieee80211_reassemble_add(struct ieee80211_sub_if_data *sdata,
unsigned int frag, unsigned int seq, int rx_queue,
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH v3] Documentation: dt: bindings: TI WiLink modules
From: Benoit Cousson @ 2013-08-14 14:43 UTC (permalink / raw)
To: Luciano Coelho
Cc: devicetree, linux-doc, mturquette, mark.rutland, balbi,
grant.likely, rob.herring, linux-kernel, linux-omap,
linux-wireless, linux-arm-kernel, tony, nm, laurent.pinchart
In-Reply-To: <1375215668-29171-1-git-send-email-coelho@ti.com>
Hi Luca,
On 30/07/2013 22:21, Luciano Coelho wrote:
> Add device tree bindings documentation for the TI WiLink modules.
> Currently only the WLAN part of the WiLink6, WiLink7 and WiLink8
> modules is supported.
>
> Signed-off-by: Luciano Coelho <coelho@ti.com>
> ---
>
> In v3, use IRQ_TYPE_LEVEL_HIGH in the example, as suggested by Laurent.
>
> .../devicetree/bindings/net/wireless/ti-wilink.txt | 68 ++++++++++++++++++++++
> 1 file changed, 68 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/wireless/ti-wilink.txt
>
> diff --git a/Documentation/devicetree/bindings/net/wireless/ti-wilink.txt b/Documentation/devicetree/bindings/net/wireless/ti-wilink.txt
> new file mode 100644
> index 0000000..aafebb1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/wireless/ti-wilink.txt
> @@ -0,0 +1,68 @@
> +TI WiLink Wireless Modules Device Tree Bindings
> +===============================================
> +
> +The WiLink modules provide wireless connectivity, such as WLAN,
> +Bluetooth, FM and NFC.
> +
> +There are several different modules available, which can be grouped by
> +their generation: WiLink6, WiLink7 and WiLink8. WiLink4 is not
> +currently supported with device tree.
> +
> +Currently, only the WLAN portion of the modules is supported with
> +device tree.
> +
> +Required properties:
> +--------------------
> +
> +- compatible: should be "ti,wilink6", "ti,wilink7" or "ti,wilink8"
> +- interrupt-parent: the interrupt controller
> +- interrupts: out-of-band WLAN interrupt
> + See the interrupt controller's bindings documentation for
> + detailed definition.
> +
> +Optional properties:
> +--------------------
> +
> +- clocks: list of clocks needed by the chip as follows:
> +
> + refclock: the internal WLAN reference clock frequency (required for
> + WiLink6 and WiLink7; not used for WiLink8).
> +
> + tcxoclock: the internal WLAN TCXO clock frequency (required for
> + WiLink7 not used for WiLink6 and WiLink8).
> +
> + The clocks must be defined and named accordingly. For example:
> +
> + clocks = <&refclock>
> + clock-names = "refclock";
> +
> + refclock: refclock {
> + compatible = "ti,wilink-clock";
> + #clock-cells = <0>;
> + clock-frequency = <38400000>;
> + };
> +
> + Some modules that contain the WiLink chip provide clocks in the
> + module itself. In this case, we define a "ti,wilink-clock" as shown
> + above. But any other clock could in theory be used, so the proper
> + clock definition should be used.
> +
> +
> +Example:
> +--------
> +
> +Example definition that can be used in OMAP4 Panda:
> +
> +wlan {
> + compatible = "ti,wilink6";
> + interrupt-parent = <&gpio2>;
> + interrupts = <21 IRQ_TYPE_LEVEL_HIGH>; /* gpio line 53 */
> + clocks = <&refclock>;
> + clock-names = "refclock";
> +
> + refclock: refclock {
> + compatible = "ti,wilink-clock";
> + #clock-cells = <0>;
> + clock-frequency = <38400000>;
> + };
> +};
Everything looks good beside the location of the wlan node...
It should not float at the root of the device tree. It is physically
attached to a SDIO bus and thus must be a child of the MMC controller
for a proper HW representation. That's moreover the best way to handle
properly the dependency between the MMC controller and the wilink driver.
Please note that this is easier do say than to do :-)
Regards,
Benoit
^ permalink raw reply
* Re: [PATCH v2 0/4] ath10k: cleanups
From: Kalle Valo @ 2013-08-14 15:00 UTC (permalink / raw)
To: Michal Kazior; +Cc: ath10k, linux-wireless
In-Reply-To: <1376373297-32369-1-git-send-email-michal.kazior@tieto.com>
Michal Kazior <michal.kazior@tieto.com> writes:
> Hi,
>
> This patchset contains a few non-functional clean
> ups.
>
> v2:
> * fix line over 80 chars
>
>
> Michal Kazior (4):
> ath10k: clean up monitor start code
> ath10k: use sizeof(*var) in kmalloc
> ath10k: clean up PCI completion states
> ath10k: print errcode when CE ring setup fails
Thanks, all four applied.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v2 0/4] ath10k: fixes
From: Kalle Valo @ 2013-08-14 15:02 UTC (permalink / raw)
To: Michal Kazior; +Cc: ath10k, linux-wireless
In-Reply-To: <1376373578-2180-1-git-send-email-michal.kazior@tieto.com>
Michal Kazior <michal.kazior@tieto.com> writes:
> Hi,
>
> This patchset contains some bugfixes and
> improvements.
>
> v2:
> * fix indentation
> * use a comment instead of a no-op if clause
>
Thanks, these three patches applied:
> ath10k: fix HTT service setup
> ath10k: implement 802.3 SNAP rx decap type A-MSDU handling
> ath10k: plug possible memory leak in WMI
This patch dropped per your request:
> ath10k: fix HTC endpoint worker starvation
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] ath10k: fix WEP in AP and IBSS mode
From: Kalle Valo @ 2013-08-14 15:06 UTC (permalink / raw)
To: Marek Puzyniak; +Cc: ath10k, linux-wireless
In-Reply-To: <1376387122-18075-1-git-send-email-marek.puzyniak@tieto.com>
Marek Puzyniak <marek.puzyniak@tieto.com> writes:
> WEP encoding was not working properly for AP and IBSS mode.
> TX frames were encrypted with default WEP tx key index set
> always to zero, what sometimes was wrong when different
> key index should be used. This patch allows to update
> WEP key index also for AP and IBSS mode.
> Problem detected during automated WEP tests.
>
> Signed-off-by: Marek Puzyniak <marek.puzyniak@tieto.com>
Thanks, applied.
--
Kalle Valo
^ permalink raw reply
* RE: [PATCH 28/30] iwlwifi: mvm: Change beacon abort escape time value
From: Bondar, Alexander @ 2013-08-14 15:11 UTC (permalink / raw)
To: Arik Nemtsov, Johannes Berg; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <CA+XVXfeoHkOwrj76MwSC9ad5igffng8QueT6cKu9ytsLu=C+Cw@mail.gmail.com>
Yes, it's a bug. Intention was 9.
Thanks.
> -----Original Message-----
> From: anamtsov@gmail.com [mailto:anamtsov@gmail.com] On Behalf Of
> Arik Nemtsov
> Sent: Monday, August 12, 2013 3:21 PM
> To: Johannes Berg
> Cc: linux-wireless@vger.kernel.org; Bondar, Alexander
> Subject: Re: [PATCH 28/30] iwlwifi: mvm: Change beacon abort escape time
> value
>
> On Fri, Jul 26, 2013 at 11:28 AM, Johannes Berg <johannes@sipsolutions.net>
> wrote:
> > From: Alexander Bondar <alexander.bondar@intel.com>
> >
> > Set beacon abort escape timer values - 6 beacons in D0 state,
> > 9 beacons in D3 and D0i3.
> >
> > Signed-off-by: Alexander Bondar <alexander.bondar@intel.com>
> > Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
> > Signed-off-by: Johannes Berg <johannes.berg@intel.com>
> > ---
> > drivers/net/wireless/iwlwifi/mvm/fw-api-power.h | 3 ++-
> > drivers/net/wireless/iwlwifi/mvm/power.c | 3 +++
> > 2 files changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/wireless/iwlwifi/mvm/fw-api-power.h
> > b/drivers/net/wireless/iwlwifi/mvm/fw-api-power.h
> > index 149347d..060e630 100644
> > --- a/drivers/net/wireless/iwlwifi/mvm/fw-api-power.h
> > +++ b/drivers/net/wireless/iwlwifi/mvm/fw-api-power.h
> > @@ -285,7 +285,8 @@ struct iwl_beacon_filter_cmd { #define
> > IWL_BF_ESCAPE_TIMER_MAX 1024 #define IWL_BF_ESCAPE_TIMER_MIN
> 0
> >
> > -#define IWL_BA_ESCAPE_TIMER_DEFAULT 3
> > +#define IWL_BA_ESCAPE_TIMER_DEFAULT 6 #define
> IWL_BA_ESCAPE_TIMER_D3
> > +6
>
> Did you mean 9 here?
> (Sorry for the late review)
---------------------------------------------------------------------
A member of the Intel Corporation group of companies
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
^ permalink raw reply
* [PATCH 2/4] ath9k: Identify first subframe in an A-MPDU
From: Sujith Manoharan @ 2013-08-14 15:45 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
In-Reply-To: <1376495157-18983-1-git-send-email-sujith@msujith.org>
From: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath9k/ar9003_mac.c | 1 +
drivers/net/wireless/ath/ath9k/mac.c | 4 ++--
drivers/net/wireless/ath/ath9k/mac.h | 2 ++
3 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_mac.c b/drivers/net/wireless/ath/ath9k/ar9003_mac.c
index 5163abd..f6c5c1b 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_mac.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_mac.c
@@ -491,6 +491,7 @@ int ath9k_hw_process_rxdesc_edma(struct ath_hw *ah, struct ath_rx_status *rxs,
rxs->rs_rate = MS(rxsp->status1, AR_RxRate);
rxs->rs_more = (rxsp->status2 & AR_RxMore) ? 1 : 0;
+ rxs->rs_firstaggr = (rxsp->status11 & AR_RxFirstAggr) ? 1 : 0;
rxs->rs_isaggr = (rxsp->status11 & AR_RxAggr) ? 1 : 0;
rxs->rs_moreaggr = (rxsp->status11 & AR_RxMoreAggr) ? 1 : 0;
rxs->rs_antenna = (MS(rxsp->status4, AR_RxAntenna) & 0x7);
diff --git a/drivers/net/wireless/ath/ath9k/mac.c b/drivers/net/wireless/ath/ath9k/mac.c
index 2ef05eb..a3eff09 100644
--- a/drivers/net/wireless/ath/ath9k/mac.c
+++ b/drivers/net/wireless/ath/ath9k/mac.c
@@ -583,9 +583,9 @@ int ath9k_hw_rxprocdesc(struct ath_hw *ah, struct ath_desc *ds,
rs->rs_rate = MS(ads.ds_rxstatus0, AR_RxRate);
rs->rs_more = (ads.ds_rxstatus1 & AR_RxMore) ? 1 : 0;
+ rs->rs_firstaggr = (ads.ds_rxstatus8 & AR_RxFirstAggr) ? 1 : 0;
rs->rs_isaggr = (ads.ds_rxstatus8 & AR_RxAggr) ? 1 : 0;
- rs->rs_moreaggr =
- (ads.ds_rxstatus8 & AR_RxMoreAggr) ? 1 : 0;
+ rs->rs_moreaggr = (ads.ds_rxstatus8 & AR_RxMoreAggr) ? 1 : 0;
rs->rs_antenna = MS(ads.ds_rxstatus3, AR_RxAntenna);
/* directly mapped flags for ieee80211_rx_status */
diff --git a/drivers/net/wireless/ath/ath9k/mac.h b/drivers/net/wireless/ath/ath9k/mac.h
index b02dfce..bfccace 100644
--- a/drivers/net/wireless/ath/ath9k/mac.h
+++ b/drivers/net/wireless/ath/ath9k/mac.h
@@ -140,6 +140,7 @@ struct ath_rx_status {
int8_t rs_rssi_ext1;
int8_t rs_rssi_ext2;
u8 rs_isaggr;
+ u8 rs_firstaggr;
u8 rs_moreaggr;
u8 rs_num_delims;
u8 rs_flags;
@@ -569,6 +570,7 @@ struct ar5416_desc {
#define AR_RxAggr 0x00020000
#define AR_PostDelimCRCErr 0x00040000
#define AR_RxStatusRsvd71 0x3ff80000
+#define AR_RxFirstAggr 0x20000000
#define AR_DecryptBusyErr 0x40000000
#define AR_KeyMiss 0x80000000
--
1.8.3.4
^ permalink raw reply related
* [PATCH 1/4] ath9k: Handle invalid RSSI
From: Sujith Manoharan @ 2013-08-14 15:45 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
From: Sujith Manoharan <c_manoha@qca.qualcomm.com>
The combined RSSI can be invalid which is indicated by
the value -128. Use RX_FLAG_NO_SIGNAL_VAL for such cases.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath9k/recv.c | 49 +++++++++++++++++++++++------------
1 file changed, 33 insertions(+), 16 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
index 3b47198..6ad7d61 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -885,29 +885,49 @@ static int ath9k_process_rate(struct ath_common *common,
static void ath9k_process_rssi(struct ath_common *common,
struct ieee80211_hw *hw,
- struct ath_rx_status *rx_stats)
+ struct ath_rx_status *rx_stats,
+ struct ieee80211_rx_status *rxs)
{
struct ath_softc *sc = hw->priv;
struct ath_hw *ah = common->ah;
int last_rssi;
int rssi = rx_stats->rs_rssi;
- if (!rx_stats->is_mybeacon ||
- ((ah->opmode != NL80211_IFTYPE_STATION) &&
- (ah->opmode != NL80211_IFTYPE_ADHOC)))
+ /*
+ * RSSI is not available for subframes in an A-MPDU.
+ */
+ if (rx_stats->rs_moreaggr) {
+ rxs->flag |= RX_FLAG_NO_SIGNAL_VAL;
+ return;
+ }
+
+ /*
+ * Check if the RSSI for the last subframe in an A-MPDU
+ * or an unaggregated frame is valid.
+ */
+ if (rx_stats->rs_rssi == ATH9K_RSSI_BAD) {
+ rxs->flag |= RX_FLAG_NO_SIGNAL_VAL;
return;
+ }
- if (rx_stats->rs_rssi != ATH9K_RSSI_BAD && !rx_stats->rs_moreaggr)
+ /*
+ * Update Beacon RSSI, this is used by ANI.
+ */
+ if (rx_stats->is_mybeacon &&
+ ((ah->opmode == NL80211_IFTYPE_STATION) ||
+ (ah->opmode == NL80211_IFTYPE_ADHOC))) {
ATH_RSSI_LPF(sc->last_rssi, rx_stats->rs_rssi);
+ last_rssi = sc->last_rssi;
+
+ if (likely(last_rssi != ATH_RSSI_DUMMY_MARKER))
+ rssi = ATH_EP_RND(last_rssi, ATH_RSSI_EP_MULTIPLIER);
+ if (rssi < 0)
+ rssi = 0;
- last_rssi = sc->last_rssi;
- if (likely(last_rssi != ATH_RSSI_DUMMY_MARKER))
- rssi = ATH_EP_RND(last_rssi, ATH_RSSI_EP_MULTIPLIER);
- if (rssi < 0)
- rssi = 0;
+ ah->stats.avgbrssi = rssi;
+ }
- /* Update Beacon RSSI, this is used by ANI. */
- ah->stats.avgbrssi = rssi;
+ rxs->signal = ah->noise + rx_stats->rs_rssi;
}
static void ath9k_process_tsf(struct ath_rx_status *rs,
@@ -1149,15 +1169,12 @@ static int ath9k_rx_skb_preprocess(struct ath_softc *sc,
goto exit;
}
- ath9k_process_rssi(common, hw, rx_stats);
+ ath9k_process_rssi(common, hw, rx_stats, rx_status);
rx_status->band = hw->conf.chandef.chan->band;
rx_status->freq = hw->conf.chandef.chan->center_freq;
- rx_status->signal = ah->noise + rx_stats->rs_rssi;
rx_status->antenna = rx_stats->rs_antenna;
rx_status->flag |= RX_FLAG_MACTIME_END;
- if (rx_stats->rs_moreaggr)
- rx_status->flag |= RX_FLAG_NO_SIGNAL_VAL;
#ifdef CONFIG_ATH9K_BTCOEX_SUPPORT
if (ieee80211_is_data_present(hdr->frame_control) &&
--
1.8.3.4
^ permalink raw reply related
* [PATCH 3/4] ath9k: Optimize LNA check
From: Sujith Manoharan @ 2013-08-14 15:45 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
In-Reply-To: <1376495157-18983-1-git-send-email-sujith@msujith.org>
From: Sujith Manoharan <c_manoha@qca.qualcomm.com>
The documentation for antenna diversity says:
"The decision of diversity is done at 802.11 preamble. So, for
11G/11B, for every MAC packet hardware will do a decision. But in
11N with aggregation, the decision is made only at the preamble and
all other MPDUs will use the same LNA as the first MPDU."
Make use of rs_firstaggr to avoid needlessly scanning for LNA
changes.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath9k/recv.c | 77 +++++++++++++++++++++--------------
1 file changed, 47 insertions(+), 30 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
index 6ad7d61..6161d14 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -1238,6 +1238,52 @@ static void ath9k_rx_skb_postprocess(struct ath_common *common,
rxs->flag &= ~RX_FLAG_DECRYPTED;
}
+/*
+ * Run the LNA combining algorithm only in these cases:
+ *
+ * Standalone WLAN cards with both LNA/Antenna diversity
+ * enabled in the EEPROM.
+ *
+ * WLAN+BT cards which are in the supported card list
+ * in ath_pci_id_table and the user has loaded the
+ * driver with "bt_ant_diversity" set to true.
+ */
+static void ath9k_antenna_check(struct ath_softc *sc,
+ struct ath_rx_status *rs)
+{
+ struct ath_hw *ah = sc->sc_ah;
+ struct ath9k_hw_capabilities *pCap = &ah->caps;
+ struct ath_common *common = ath9k_hw_common(ah);
+
+ if (!(ah->caps.hw_caps & ATH9K_HW_CAP_ANT_DIV_COMB))
+ return;
+
+ /*
+ * All MPDUs in an aggregate will use the same LNA
+ * as the first MPDU.
+ */
+ if (rs->rs_isaggr && !rs->rs_firstaggr)
+ return;
+
+ /*
+ * Change the default rx antenna if rx diversity
+ * chooses the other antenna 3 times in a row.
+ */
+ if (sc->rx.defant != rs->rs_antenna) {
+ if (++sc->rx.rxotherant >= 3)
+ ath_setdefantenna(sc, rs->rs_antenna);
+ } else {
+ sc->rx.rxotherant = 0;
+ }
+
+ if (pCap->hw_caps & ATH9K_HW_CAP_BT_ANT_DIV) {
+ if (common->bt_ant_diversity)
+ ath_ant_comb_scan(sc, rs);
+ } else {
+ ath_ant_comb_scan(sc, rs);
+ }
+}
+
static void ath9k_apply_ampdu_details(struct ath_softc *sc,
struct ath_rx_status *rs, struct ieee80211_rx_status *rxs)
{
@@ -1262,7 +1308,6 @@ int ath_rx_tasklet(struct ath_softc *sc, int flush, bool hp)
struct sk_buff *skb = NULL, *requeue_skb, *hdr_skb;
struct ieee80211_rx_status *rxs;
struct ath_hw *ah = sc->sc_ah;
- struct ath9k_hw_capabilities *pCap = &ah->caps;
struct ath_common *common = ath9k_hw_common(ah);
struct ieee80211_hw *hw = sc->hw;
int retval;
@@ -1398,35 +1443,7 @@ int ath_rx_tasklet(struct ath_softc *sc, int flush, bool hp)
ath_rx_ps(sc, skb, rs.is_mybeacon);
spin_unlock_irqrestore(&sc->sc_pm_lock, flags);
- /*
- * Run the LNA combining algorithm only in these cases:
- *
- * Standalone WLAN cards with both LNA/Antenna diversity
- * enabled in the EEPROM.
- *
- * WLAN+BT cards which are in the supported card list
- * in ath_pci_id_table and the user has loaded the
- * driver with "bt_ant_diversity" set to true.
- */
- if (ah->caps.hw_caps & ATH9K_HW_CAP_ANT_DIV_COMB) {
- /*
- * Change the default rx antenna if rx diversity
- * chooses the other antenna 3 times in a row.
- */
- if (sc->rx.defant != rs.rs_antenna) {
- if (++sc->rx.rxotherant >= 3)
- ath_setdefantenna(sc, rs.rs_antenna);
- } else {
- sc->rx.rxotherant = 0;
- }
-
- if (pCap->hw_caps & ATH9K_HW_CAP_BT_ANT_DIV) {
- if (common->bt_ant_diversity)
- ath_ant_comb_scan(sc, &rs);
- } else {
- ath_ant_comb_scan(sc, &rs);
- }
- }
+ ath9k_antenna_check(sc, &rs);
ath9k_apply_ampdu_details(sc, &rs, rxs);
--
1.8.3.4
^ permalink raw reply related
* [PATCH 4/4] ath9k: Use lockless variant to initialize RX fifo
From: Sujith Manoharan @ 2013-08-14 15:45 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
In-Reply-To: <1376495157-18983-1-git-send-email-sujith@msujith.org>
From: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Since the rx_fifo queue is accessed only using the various
lockless SKB queue routines, there is no need to initialize
the lock and __skb_queue_head_init() can be used.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath9k/recv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
index 6161d14..653f7fc 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -190,7 +190,7 @@ static void ath_rx_edma_cleanup(struct ath_softc *sc)
static void ath_rx_edma_init_queue(struct ath_rx_edma *rx_edma, int size)
{
- skb_queue_head_init(&rx_edma->rx_fifo);
+ __skb_queue_head_init(&rx_edma->rx_fifo);
rx_edma->rx_fifo_hwsize = size;
}
--
1.8.3.4
^ permalink raw reply related
* Re: carl9170: Problems setting up Virtual Interface
From: moony @ 2013-08-14 9:32 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <CAMJnVwm4Xp87pF7PHLP7vVqF-LYzsgeso7ZPzPwOC_39mwP_Kw@mail.gmail.com>
Alex <alex9434@...> writes:
>
> Great! I now get an additional interface:
> wlan1-wlan0 Link encap:Ethernet HWaddr <deleted>
> BROADCAST MULTICAST MTU:1500 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Hi Alex,
did you get this to work? I'm using the same driver and procedure, but when
I try to bring up the second interface (with ifup wifi1), I get the error
device or resource busy... The first always comes up.
I don't know if vif is enabled by default on the kernelmodule. I tried to
compile it by myself (there is an option for the number of vif, and the
default is 1), but stuck on errors or missing dependencies, yet.
Best regards,
moony
^ permalink raw reply
* Re: [RFT 00/13] brcmsmac: bcm4313 iPA related patches
From: Arend van Spriel @ 2013-08-14 18:16 UTC (permalink / raw)
To: David Herrmann
Cc: linux-wireless, Jonas Gorski, Maximilian Engelhardt, David Costa
In-Reply-To: <CANq1E4SOcT765CTFCR=xywBuMkOs5oru-NBqwHM=Jj_dfwtvkw@mail.gmail.com>
On 08/14/2013 12:33 PM, David Herrmann wrote:
> Hi
>
> On Tue, Aug 13, 2013 at 10:46 PM, Arend van Spriel <arend@broadcom.com> wrote:
>> On 08/13/2013 10:09 PM, David Herrmann wrote:
>>>
>>> Hi
>>>
>>> On Tue, Aug 13, 2013 at 10:03 PM, Arend van Spriel <arend@broadcom.com>
>>> wrote:
>>>>
>>>> This series replaces the patch "[PATCH 12/12] brcmsmac: support 4313iPA"
>>>> with Message-ID: <1376130450-29746-13-git-send-email-arend@broadcom.com>.
>>>>
>>>> It has been split up into individual patches. Please test this series
>>>> especially if you had issues with the original commit b6fc28a that was
>>>> reverted.
>>>>
>>>> Cc: Jonas Gorski <jogo@openwrt.org>
>>>> Cc: David Herrmann <dh.herrmann@gmail.com>
>>>> Cc: Maximilian Engelhardt <maxi@daemonizer.de>
>>>> Cc: David Costa <david@zarel.net>
>>>
>>>
>>> Is this available in a public branch that I can merge? And what should
>>> be used as base? 3.11-rc5? linux-next?
>>
>>
>> Indeed I should have mentioned. It applies on v3.11-rc5 for sure. Did not
>> try linux-next.
>
> All 13 patches applied cleanly on top of 3.11-rc5, everything works
> fine even after a dozen of reconnects to different networks. No
> additional delays.
>
> Consider this whole series:
> Tested-by: David Herrmann <dh.herrmann@gmail.com>
>
> card info: Broadcom Corporation BCM4313 802.11b/g/n (0a5c:219c)
> (builtin into my old Intel Atom N450 board)
> I tested with 802.11g networks. I have only a/g networks here. I don't
> know whether that matters.
As this series modifies the phy code, I would say no.
Thanks for verifying this works for you.
Regards,
Arend
^ permalink raw reply
* Re: issues with RTL8188CE device and rtl8192ce driver
From: Colleen Josephson @ 2013-08-14 21:39 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless
In-Reply-To: <520AF3BD.5020705@lwfinger.net>
> First, what chip is in your computer. Please send me the output of the
> command '/sbin/lspci -nnv'. Only the stanza for the RTL8188CE will be
> needed. There are at least 4 different chips that work with driver
> rtl8192ce.
03:00.0 Network controller [0280]: Realtek Semiconductor Co., Ltd.
RTL8188CE 802.11b/g/n WiFi Adapter [10ec:8176] (rev 01)
Subsystem: Realtek Semiconductor Co., Ltd. Device [10ec:8195]
Flags: bus master, fast devsel, latency 0, IRQ 17
I/O ports at 5000 [size=256]
Memory at f3800000 (64-bit, non-prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [70] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Virtual Channel
Capabilities: [160] Device Serial Number 01-91-81-fe-ff-4c-e0-00
Kernel driver in use: rtl8192ce
Kernel modules: rtl8192ce
> Second, what is the make/model of the access point that you are using? Is
> the firmware up to date?
There are two Meraki M16 access points (with up to date firmware).
> Third, what is the encryption method you are using, and what is the maximum
> rate for the connection? That will tell me if you are using 802.11g or
> 802.11n.
802.11g. The encryption is WPA & WPA2 Personal, and the maximum rate
is 54 Mbps.
^ permalink raw reply
* [PATCH] net: rfkill: Do not ignore errors from regulator_enable()
From: Luis Henriques @ 2013-08-14 22:10 UTC (permalink / raw)
To: linux-kernel
Cc: netdev, linux-wireless, David S. Miller, Johannes Berg,
John W. Linville
Function regulator_enable() may return an error that has to be checked.
This patch changes function rfkill_regulator_set_block() so that it checks
for the return code. Also, rfkill_data->reg_enabled is set to 'true' only
if there is no error.
This fixes the following compilation warning:
net/rfkill/rfkill-regulator.c:43:20: warning: ignoring return value of 'regulator_enable', declared with attribute warn_unused_result [-Wunused-result]
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
---
net/rfkill/rfkill-regulator.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/net/rfkill/rfkill-regulator.c b/net/rfkill/rfkill-regulator.c
index d11ac79..cf5b145 100644
--- a/net/rfkill/rfkill-regulator.c
+++ b/net/rfkill/rfkill-regulator.c
@@ -30,6 +30,7 @@ struct rfkill_regulator_data {
static int rfkill_regulator_set_block(void *data, bool blocked)
{
struct rfkill_regulator_data *rfkill_data = data;
+ int ret = 0;
pr_debug("%s: blocked: %d\n", __func__, blocked);
@@ -40,15 +41,16 @@ static int rfkill_regulator_set_block(void *data, bool blocked)
}
} else {
if (!rfkill_data->reg_enabled) {
- regulator_enable(rfkill_data->vcc);
- rfkill_data->reg_enabled = true;
+ ret = regulator_enable(rfkill_data->vcc);
+ if (!ret)
+ rfkill_data->reg_enabled = true;
}
}
pr_debug("%s: regulator_is_enabled after set_block: %d\n", __func__,
regulator_is_enabled(rfkill_data->vcc));
- return 0;
+ return ret;
}
static struct rfkill_ops rfkill_regulator_ops = {
--
1.8.3.2
^ permalink raw reply related
* [GIT] [3.12] NFC updates
From: Samuel Ortiz @ 2013-08-14 23:04 UTC (permalink / raw)
To: John W. Linville; +Cc: Linux NFC, Linux Wireless
Hi John,
This is the first NFC pull request for the 3.12 release.
With this one we have:
- A few pn533 improvements and minor fixes. Testing our pn533 driver
against Google's NCI stack triggered a few issues that we fixed now.
We also added Tx fragmentation support to this driver.
- More NFC secure element handling. We added a GET_SE netlink command
for getting all the discovered secure elements, and we defined 2
additional secure element netlink event (transaction and connectivity).
We also fixed a couple of typos and copy-paste bugs from the secure
element handling code.
- Firmware download support for the pn544 driver. This chipset can enter a
special mode where it's waiting for firmware blobs to replace the
already flashed one. We now support that mode.
The following changes since commit d1e2586f484dfc36eee2b2d3a6c6c77be67ca492:
mwifiex: fix build error when CONFIG_PM is not set (2013-08-12 14:36:55 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/sameo/nfc-next.git tags/nfc-next-3.12-1
for you to fetch changes up to 39525ee1dc78ca1f5f2fb1f764f7a141005fe440:
NFC: Update secure element state (2013-08-14 01:13:40 +0200)
----------------------------------------------------------------
Arron Wang (2):
NFC: Fix secure element state check
NFC: Update secure element state
Dan Carpenter (1):
NFC: hci: Fix enable/disable confusion
Eric Lapuyade (5):
NFC: Move nfc_fw_download_done() definition from private to public
NFC: pn544: i2c: Add firmware download mode power-on support
NFC: netlink: Add result of firmware operation to completion event
NFC: pn544: Add firmware operations hci ops
NFC: pn544: i2c: Add firmware download implementation for pn544
Olivier Guiter (3):
NFC: pn533: Add extended information frame decoding support
NFC: pn533: Split large Tx frames in chunks
NFC: pn533: Store the correct frame size (normal vs ext)
Samuel Ortiz (12):
MAINTAINERS: Change the NFC subsystem status to Supported
NFC: Document secure element addition/removal netlink events
NFC: Define secure element connectivity and transaction events
NFC: pn533: Fix hardware busy loop when establishing the LLCP link
NFC: pn533: Fix the pn533 polling loop
NFC: pn533: Request System code from SENSF_REQ
NFC: pn533: Unconditionaly select the highest p2p bit rate
NFC: pn533: Enable AUTO RFCA
NFC: Fix SE discovery failure warning condition
NFC: Add a GET_SE netlink API
NFC: pn533: Add delay between each poll frame
NFC: pn533: Add some polling entropy
Thierry Escande (1):
NFC: Fix missing static declarations
MAINTAINERS | 2 +-
drivers/nfc/nfcsim.c | 6 +-
drivers/nfc/pn533.c | 389 +++++++++++++++++++++++++++++++++++----------
drivers/nfc/pn544/i2c.c | 360 +++++++++++++++++++++++++++++++++++++++--
drivers/nfc/pn544/mei.c | 2 +-
drivers/nfc/pn544/pn544.c | 20 ++-
drivers/nfc/pn544/pn544.h | 7 +-
include/net/nfc/nfc.h | 3 +
include/uapi/linux/nfc.h | 20 +++
net/nfc/core.c | 22 ++-
net/nfc/hci/core.c | 2 +-
net/nfc/netlink.c | 95 ++++++++++-
net/nfc/nfc.h | 5 +-
13 files changed, 810 insertions(+), 123 deletions(-)
--
Intel Open Source Technology Centre
http://oss.intel.com/
^ permalink raw reply
* Re: [GIT] [3.12] NFC updates
From: Joe Perches @ 2013-08-15 3:07 UTC (permalink / raw)
To: Samuel Ortiz; +Cc: John W. Linville, Linux NFC, Linux Wireless
In-Reply-To: <20130814230448.GB11055@zurbaran>
On Thu, 2013-08-15 at 01:04 +0200, Samuel Ortiz wrote:
> Hi John,
>
> This is the first NFC pull request for the 3.12 release.
Any reason why these reformatting patches were
not applied?
https://lkml.org/lkml/2013/4/5/417
^ permalink raw reply
* Switching band of a dual-band WiFi device
From: Christian Gagneraud @ 2013-08-15 5:11 UTC (permalink / raw)
To: linux-wireless
Hi there,
I am using a TP-Link TL-WDN3200 on a ubuntu 13.04 (kernel
3.8.0-27-generic), and I have install relevant modules with
backports-3.11-rc3-1.
I would like to switch my WiFi stick to 5GHz, I tried iwconfig wlan0
freq 5G, but I get ENOTSUPP.
Is the freq settings suppose to handle this 2.4 vs 5GHz band or is it
only for selecting channel frequency within a given band?
Does linux-wireless provides a way for selecting 2.4 or 5GHz band?
"iw phy phy11 info" tells me that in band 2, all the frequencies are
disabled except:
* 5745 MHz [149] (30.0 dBm)
* 5755 MHz [151] (30.0 dBm)
* 5765 MHz [153] (30.0 dBm)
* 5775 MHz [155] (30.0 dBm)
* 5785 MHz [157] (30.0 dBm)
* 5795 MHz [159] (30.0 dBm)
* 5805 MHz [161] (30.0 dBm)
* 5825 MHz [165] (30.0 dBm)
As well, my understanding of WiFi might be a bit limited but, does a
dual-band WiFi device provides 2.4 and 5GHz services at the same time or
do I need to select one or the other myself? Or maybe I can just
enable/disable them manually (and separately)?
Hope someone can shed some light at this.
Regards,
Chris
^ permalink raw reply
* Re: Switching band of a dual-band WiFi device
From: Christian Gagneraud @ 2013-08-15 5:40 UTC (permalink / raw)
To: linux-wireless; +Cc: Siyu Qiu
In-Reply-To: <CA+J2US3uKD9xr9FOg5=tkwjx2ETQY9qmH305supcjGcVYHmRPQ@mail.gmail.com>
On 15/08/13 17:30, Siyu Qiu wrote:
> hi, do you mean that you take the wireless card from tplink and embed it
> into your pc ? Does it work ? Coz i want to put qca 9889 into pc but the
> info about network controller is :!!! unknown type 7f
Hi Siyu Qio,
I'm not sure to understand your question, but this is what I did
- went to the shop to buy this USB stick
- plugged it in a USB slot of my PC
And now I'm trying to understand if I can switch/enable/disable these 2
bands, and more importantly, do I really need to?
Right now, my feeling is that "it just works out of the box", I
shouldn't try to do this kind of things. I just try to understand this
dual-band thing.
Chris
PS: Can you reply on the mailing list instead of sending private email
please?
>
> On Aug 14, 2013 10:12 PM, "Christian Gagneraud" <chgans@gna.org
> <mailto:chgans@gna.org>> wrote:
>
> Hi there,
>
> I am using a TP-Link TL-WDN3200 on a ubuntu 13.04 (kernel
> 3.8.0-27-generic), and I have install relevant modules with
> backports-3.11-rc3-1.
>
> I would like to switch my WiFi stick to 5GHz, I tried iwconfig wlan0
> freq 5G, but I get ENOTSUPP.
> Is the freq settings suppose to handle this 2.4 vs 5GHz band or is
> it only for selecting channel frequency within a given band?
>
> Does linux-wireless provides a way for selecting 2.4 or 5GHz band?
>
> "iw phy phy11 info" tells me that in band 2, all the frequencies are
> disabled except:
> * 5745 MHz [149] (30.0 dBm)
> * 5755 MHz [151] (30.0 dBm)
> * 5765 MHz [153] (30.0 dBm)
> * 5775 MHz [155] (30.0 dBm)
> * 5785 MHz [157] (30.0 dBm)
> * 5795 MHz [159] (30.0 dBm)
> * 5805 MHz [161] (30.0 dBm)
> * 5825 MHz [165] (30.0 dBm)
>
> As well, my understanding of WiFi might be a bit limited but, does a
> dual-band WiFi device provides 2.4 and 5GHz services at the same
> time or do I need to select one or the other myself? Or maybe I can
> just enable/disable them manually (and separately)?
>
> Hope someone can shed some light at this.
>
> Regards,
> Chris
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> <mailto:majordomo@vger.kernel.org>
> More majordomo info at http://vger.kernel.org/__majordomo-info.html
> <http://vger.kernel.org/majordomo-info.html>
>
^ permalink raw reply
* Re: [PATCHv2 1/2] mac80211: perform power save processing before decryption
From: Kalle Valo @ 2013-08-15 6:08 UTC (permalink / raw)
To: Johan Almbladh; +Cc: johannes, ordex, linux-wireless
In-Reply-To: <1376486987-23224-1-git-send-email-ja@anyfi.net>
Johan Almbladh <ja@anyfi.net> writes:
> This patch decouples the power save processing from the frame decryption
> by running the decrypt rx handler after sta_process. In the case where
> the decryption failed for some reason, the stack used to not process
> the PM and MOREDATA bits for that frame. The stack now always performs
> power save processing regardless of the decryption result. That means that
> encrypted data frames and NULLFUNC frames are now handled in the same way
> regarding power save processing, making the stack more robust.
>
> Tested-by: Johan Almbladh <ja@anyfi.net>
> Signed-off-by: Johan Almbladh <ja@anyfi.net>
The idea of the Tested-by is that someone else than the patch author has
also tested the patch, like a bug reporter etc. The patch author should
always tests his/her code, so adding Tested-by for the author is moot.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCHv2 1/2] mac80211: perform power save processing before decryption
From: Johan Almbladh @ 2013-08-15 6:58 UTC (permalink / raw)
To: Kalle Valo; +Cc: Johan Almbladh, Johannes Berg, ordex, linux-wireless
In-Reply-To: <877gfnwkog.fsf@purkki.adurom.net>
Right, I got it.
Johan
On Thu, Aug 15, 2013 at 8:08 AM, Kalle Valo <kvalo@adurom.com> wrote:
> Johan Almbladh <ja@anyfi.net> writes:
>
>> This patch decouples the power save processing from the frame decryption
>> by running the decrypt rx handler after sta_process. In the case where
>> the decryption failed for some reason, the stack used to not process
>> the PM and MOREDATA bits for that frame. The stack now always performs
>> power save processing regardless of the decryption result. That means that
>> encrypted data frames and NULLFUNC frames are now handled in the same way
>> regarding power save processing, making the stack more robust.
>>
>> Tested-by: Johan Almbladh <ja@anyfi.net>
>> Signed-off-by: Johan Almbladh <ja@anyfi.net>
>
> The idea of the Tested-by is that someone else than the patch author has
> also tested the patch, like a bug reporter etc. The patch author should
> always tests his/her code, so adding Tested-by for the author is moot.
>
> --
> Kalle Valo
^ permalink raw reply
* Re: Kernel Panic with Linux 3.10-6
From: Arend van Spriel @ 2013-08-15 9:31 UTC (permalink / raw)
To: Pedram Navid; +Cc: brcm80211-dev-list, linux-wireless
In-Reply-To: <CAHgnS=pnv0AV7JoDq5MCFMsDO60g1a_av0b6F-UM6V0m-7e=eQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1132 bytes --]
On 08/15/2013 03:28 AM, Pedram Navid wrote:
> With the latest 3.10-6 kernel I am receiving frequent and consistent
> kernel panics. Downgrading to 3.9.5 resolves the issue.
Thanks, Pedram
I have had a couple of other report about this particular panic and did
some investigation. It is a divide-by-zero causing the panic. I do have
a patch to avoid that, but the root cause is something else. Is 3.10.6
you see this on the unmodified stable release?
The attached patch avoids the panic, but you will probably have crappy
connectivity.
Regards,
Arend
> Other users are also reporting this issue:
> https://bbs.archlinux.org/viewtopic.php?pid=1312140
>
> Hope this is the right place to post this. For reference, here is my
> card, using the brcmsmac module.
>
> 02:00.0 Network controller [0280]: Broadcom Corporation BCM4313
> 802.11b/g/n Wireless LAN Controller [14e4:4727] (rev 01)
> Subsystem: Broadcom Corporation Device [14e4:0510]
> Flags: bus master, fast devsel, latency 0, IRQ 17
> Memory at 56000000 (64-bit, non-prefetchable) [size=16K]
> Capabilities: <access denied>
> Kernel driver in use: bcma-pci-bridge
>
[-- Attachment #2: 0001-brcmsmac-avoid-kernel-panic-due-to-divide-by-zero-er.patch --]
[-- Type: text/plain, Size: 1447 bytes --]
>From aeca211f0bb6186eefb7f3a6ad98115e2256e53a Mon Sep 17 00:00:00 2001
From: Arend van Spriel <arend@broadcom.com>
Date: Mon, 12 Aug 2013 12:34:45 +0200
Subject: [PATCH] brcmsmac: avoid kernel panic due to divide-by-zero error
The patch avoid the kernel panic and adds a few error log messages.
Signed-off-by: Arend van Spriel <arend@broadcom.com>
---
drivers/net/wireless/brcm80211/brcmsmac/main.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/net/wireless/brcm80211/brcmsmac/main.c b/drivers/net/wireless/brcm80211/brcmsmac/main.c
index 9fd6f2f..ea92ea2 100644
--- a/drivers/net/wireless/brcm80211/brcmsmac/main.c
+++ b/drivers/net/wireless/brcm80211/brcmsmac/main.c
@@ -630,10 +630,21 @@ static uint brcms_c_calc_frame_time(struct brcms_c_info *wlc, u32 ratespec,
dur = PREN_PREAMBLE + (tot_streams * PREN_PREAMBLE_EXT);
if (preamble_type == BRCMS_MM_PREAMBLE)
dur += PREN_MM_EXT;
+
+ if (mcs > BRCMS_MAXMCS) {
+ brcms_err(wlc->hw->d11core, "wl%d: invalid mcs: %u\n",
+ wlc->pub->unit, mcs);
+ mcs = 0;
+ }
/* 1000Ndbps = kbps * 4 */
kNdps = mcs_2_rate(mcs, rspec_is40mhz(ratespec),
rspec_issgi(ratespec)) * 4;
+ if (kNdps == 0) {
+ brcms_err(wlc->hw->d11core, "wl%d: invalid zero rate: rspec=0x%x\n",
+ wlc->pub->unit, ratespec);
+ kNdps = 6500 * 4;
+ }
if (rspec_stc(ratespec) == 0)
nsyms =
CEIL((APHY_SERVICE_NBITS + 8 * mac_len +
--
1.7.10.4
^ permalink raw reply related
* Re: Switching band of a dual-band WiFi device
From: Simon Farnsworth @ 2013-08-15 9:03 UTC (permalink / raw)
To: Christian Gagneraud; +Cc: linux-wireless
In-Reply-To: <520C631F.6010806@gna.org>
[-- Attachment #1: Type: text/plain, Size: 2136 bytes --]
On Thursday 15 August 2013 17:11:59 Christian Gagneraud wrote:
> Hi there,
>
> I am using a TP-Link TL-WDN3200 on a ubuntu 13.04 (kernel
> 3.8.0-27-generic), and I have install relevant modules with
> backports-3.11-rc3-1.
>
> I would like to switch my WiFi stick to 5GHz, I tried iwconfig wlan0
> freq 5G, but I get ENOTSUPP.
> Is the freq settings suppose to handle this 2.4 vs 5GHz band or is it
> only for selecting channel frequency within a given band?
>
> Does linux-wireless provides a way for selecting 2.4 or 5GHz band?
Linux should automatically select the right frequency band, depending on
the frequencies in use by the device you're trying to communicate with.
Connect to an AP in the 5GHz band, and Linux should just use 5GHz
automatically.
>
> "iw phy phy11 info" tells me that in band 2, all the frequencies are
> disabled except:
> * 5745 MHz [149] (30.0 dBm)
> * 5755 MHz [151] (30.0 dBm)
> * 5765 MHz [153] (30.0 dBm)
> * 5775 MHz [155] (30.0 dBm)
> * 5785 MHz [157] (30.0 dBm)
> * 5795 MHz [159] (30.0 dBm)
> * 5805 MHz [161] (30.0 dBm)
> * 5825 MHz [165] (30.0 dBm)
>
That's showing you that, with Linux's understanding of the RF regulations in
your area, it can only transmit on certain frequencies.
> As well, my understanding of WiFi might be a bit limited but, does a
> dual-band WiFi device provides 2.4 and 5GHz services at the same time or
> do I need to select one or the other myself? Or maybe I can just
> enable/disable them manually (and separately)?
>
A dual-band WiFi device can only transmit and receive on one channel at a
time. The advantage of dual-band is that it can transmit and receive on either
the 5GHz band (which is less crowded), or the 2.4GHz band (which is more
commonly used). There's no need to select the band manually - it will just
use 5GHz when the other device (e.g. the AP) is using 5GHz.
--
Simon Farnsworth
Software Engineer
ONELAN Ltd
http://www.onelan.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ 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