* Re: [PATCH v3] ath10k: Fix crash during rmmod when probe firmware fails
From: Mohammed Shafi Shajakhan @ 2017-02-06 10:04 UTC (permalink / raw)
To: Valo, Kalle
Cc: Shajakhan, Mohammed Shafi (Mohammed Shafi),
ath10k@lists.infradead.org, linux-wireless@vger.kernel.org
In-Reply-To: <871svr8d83.fsf@kamboji.qca.qualcomm.com>
Hi Kalle,
the change suggested by you helps, and the device probe, scan
is successful as well. Still good to have this change part of your
basic sanity and regression testing !
regards,
shafi
On Wed, Jan 25, 2017 at 01:46:28PM +0000, Valo, Kalle wrote:
> Kalle Valo <kvalo@qca.qualcomm.com> writes:
>
> > Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> writes:
> >
> >> From: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
> >>
> >> This fixes the below crash when ath10k probe firmware fails,
> >> NAPI polling tries to access a rx ring resource which was never
> >> allocated, fix this by disabling NAPI right away once the probe
> >> firmware fails by calling 'ath10k_hif_stop'. Its good to note
> >> that the error is never propogated to 'ath10k_pci_probe' when
> >> ath10k_core_register fails, so calling 'ath10k_hif_stop' to cleanup
> >> PCI related things seems to be ok
> >>
> >> BUG: unable to handle kernel NULL pointer dereference at (null)
> >> IP: __ath10k_htt_rx_ring_fill_n+0x19/0x230 [ath10k_core]
> >> __ath10k_htt_rx_ring_fill_n+0x19/0x230 [ath10k_core]
> >>
> >> Call Trace:
> >>
> >> [<ffffffffa113ec62>] ath10k_htt_rx_msdu_buff_replenish+0x42/0x90
> >> [ath10k_core]
> >> [<ffffffffa113f393>] ath10k_htt_txrx_compl_task+0x433/0x17d0
> >> [ath10k_core]
> >> [<ffffffff8114406d>] ? __wake_up_common+0x4d/0x80
> >> [<ffffffff811349ec>] ? cpu_load_update+0xdc/0x150
> >> [<ffffffffa119301d>] ? ath10k_pci_read32+0xd/0x10 [ath10k_pci]
> >> [<ffffffffa1195b17>] ath10k_pci_napi_poll+0x47/0x110 [ath10k_pci]
> >> [<ffffffff817863af>] net_rx_action+0x20f/0x370
> >>
> >> Reported-by: Ben Greear <greearb@candelatech.com>
> >> Fixes: 3c97f5de1f28 ("ath10k: implement NAPI support")
> >> Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
> >
> > Is there an easy way to reproduce this bug? I don't see it on my x86
> > laptop with qca988x and I call rmmod all the time. I would like to test
> > this myself.
> >
> >> --- a/drivers/net/wireless/ath/ath10k/core.c
> >> +++ b/drivers/net/wireless/ath/ath10k/core.c
> >> @@ -2164,6 +2164,7 @@ static int ath10k_core_probe_fw(struct ath10k *ar)
> >> ath10k_core_free_firmware_files(ar);
> >>
> >> err_power_down:
> >> + ath10k_hif_stop(ar);
> >> ath10k_hif_power_down(ar);
> >>
> >> return ret;
> >
> > This breaks the symmetry, we should not be calling ath10k_hif_stop() if
> > we haven't called ath10k_hif_start() from the same function. This can
> > just create a bigger mess later, for example with other bus support like
> > sdio or usb. In theory it should enough that we call
> > ath10k_hif_power_down() and pci.c does the rest correctly "behind the
> > scenes".
> >
> > I investigated this a bit and I think the real cause is that we call
> > napi_enable() from ath10k_pci_hif_power_up() and napi_disable() from
> > ath10k_pci_hif_stop(). Does anyone remember why?
> >
> > I was expecting that we would call napi_enable()/napi_disable() either
> > in ath10k_hif_power_up/down() or ath10k_hif_start()/stop(), but not
> > mixed like it's currently.
>
> So below is something I was thinking of, now napi_enable() is called
> from ath10k_hif_start() and napi_disable() from ath10k_hif_stop(). Would
> that work?
>
> --- a/drivers/net/wireless/ath/ath10k/pci.c
> +++ b/drivers/net/wireless/ath/ath10k/pci.c
> @@ -1648,6 +1648,8 @@ static int ath10k_pci_hif_start(struct ath10k *ar)
>
> ath10k_dbg(ar, ATH10K_DBG_BOOT, "boot hif start\n");
>
> + napi_enable(&ar->napi);
> +
> ath10k_pci_irq_enable(ar);
> ath10k_pci_rx_post(ar);
>
> @@ -2532,7 +2534,6 @@ static int ath10k_pci_hif_power_up(struct ath10k *ar)
> ath10k_err(ar, "could not wake up target CPU: %d\n", ret);
> goto err_ce;
> }
> - napi_enable(&ar->napi);
>
> return 0;
>
> --
> Kalle Valo
^ permalink raw reply
* Re: [PATCH v2 0/2] mac80211: use crypto shash for AES cmac
From: Ard Biesheuvel @ 2017-02-06 10:08 UTC (permalink / raw)
To: Malinen, Jouni
Cc: johannes@sipsolutions.net, linux-wireless@vger.kernel.org,
netdev@vger.kernel.org, davem@davemloft.net
In-Reply-To: <20170206100100.GA5905@jouni.qca.qualcomm.com>
On 6 February 2017 at 10:01, Malinen, Jouni <jouni@qca.qualcomm.com> wrote:
> On Sun, Feb 05, 2017 at 03:23:26PM +0000, Ard Biesheuvel wrote:
>> NOTE: Jouni has been so kind to test patch #2, and confirmed that it is working.
>> I have not tested patch #1 myself, mainly because the test methodology
>> requires downloading Ubuntu installer images, and I am currently on a
>> metered 3G connection (and will be for another couple of weeks)
>
> These v2 patches pass the test cases as well.
>
Thanks!
> (And you don't really need Ubuntu to run the hwsim test cases; any
> reasonably recent distribution that is capable of running kvm should
> work.)
>
Well, now that you have done my testing for me, I am not sure I will
get around to trying the VM.
Thanks,
Ard.
^ permalink raw reply
* Re: rtlwifi: rtl8192c_common: "BUG: KASAN: slab-out-of-bounds"
From: Johannes Berg @ 2017-02-06 10:29 UTC (permalink / raw)
To: Larry Finger, Dmitry Osipenko, Chaoming Li
Cc: linux-wireless, Linux Kernel Mailing List
In-Reply-To: <edbcbe3f-9b5d-cead-5885-27bc55ef550b@lwfinger.net>
On Sat, 2017-02-04 at 12:41 -0600, Larry Finger wrote:
> On 02/04/2017 10:58 AM, Dmitry Osipenko wrote:
> > Seems the problem is caused by rtl92c_dm_*() casting .priv to
> > "struct
> > rtl_pci_priv", while it is "struct rtl_usb_priv".
>
> Those routines are shared by rtl8192ce and rtl8192cu, thus we need to
> make that
> difference in cast to be immaterial. I think we need to move "struct
> bt_coexist_info" to the beginning of both rtlpci_priv and
> rtl_usb_priv. Then it
> should not matter.
I think you really should consider putting a struct rtl_common into
that or something, and getting rid of all the casting that causes this
problem to start with?
johannes
^ permalink raw reply
* [PATCH v3 0/2] mac80211: use crypto shash for AES cmac
From: Ard Biesheuvel @ 2017-02-06 10:49 UTC (permalink / raw)
To: johannes, linux-wireless; +Cc: davem, netdev, jouni, Ard Biesheuvel
This is something I spotted while working on AES in various modes for
ARM and arm64.
The mac80211 aes_cmac code reimplements the CMAC algorithm based on the
core AES cipher, which is rather restrictive in how platforms can satisfy
the dependency on this algorithm. For instance, SIMD implementations may
have a considerable setup time, which cannot be amortized over the entire
input when calling into the crypto API one block at a time. Also, it prevents
the use of more secure fixed time implementations, since not all AES drivers
expose the cipher interface.
So switch aes_cmac to use a cmac(aes) shash. Before updating the aes_cmac code
in patch #2, the FILS AEAD code is moved to using a cmac(aes) shash supplied by
the crypto API so that we can remove the open coded version entirely in the
second patch.
v3: - use more idiomatic SHASH_DESC_ON_STACK to allocate the shash descriptors
- replace compound literal zero vectors with explicitly defined ones
- drop a redundant memcpy() in #2
Ard Biesheuvel (2):
mac80211: fils_aead: Use crypto api CMAC shash rather than bare cipher
mac80211: aes-cmac: switch to shash CMAC driver
net/mac80211/Kconfig | 1 +
net/mac80211/aes_cmac.c | 126 ++++----------------
net/mac80211/aes_cmac.h | 15 +--
net/mac80211/fils_aead.c | 74 +++++-------
net/mac80211/key.h | 2 +-
5 files changed, 66 insertions(+), 152 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH v3 1/2] mac80211: fils_aead: Use crypto api CMAC shash rather than bare cipher
From: Ard Biesheuvel @ 2017-02-06 10:49 UTC (permalink / raw)
To: johannes, linux-wireless; +Cc: davem, netdev, jouni, Ard Biesheuvel
In-Reply-To: <1486378168-31028-1-git-send-email-ard.biesheuvel@linaro.org>
Switch the FILS AEAD code to use a cmac(aes) shash instantiated by the
crypto API rather than reusing the open coded implementation in
aes_cmac_vector(). This makes the code more understandable, and allows
platforms to implement cmac(aes) in a more secure (*) and efficient way
than is typically possible when using the AES cipher directly.
So replace the crypto_cipher by a crypto_shash, and update the aes_s2v()
routine to call the shash interface directly.
* In particular, the generic table based AES implementation is sensitive
to known-plaintext timing attacks on the key, to which AES based MAC
algorithms are especially vulnerable, given that their plaintext is not
usually secret. Time invariant alternatives are available (e.g., based
on SIMD algorithms), but may incur a setup cost that is prohibitive when
operating on a single block at a time, which is why they don't usually
expose the cipher API.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
net/mac80211/Kconfig | 1 +
net/mac80211/aes_cmac.h | 4 --
net/mac80211/fils_aead.c | 74 +++++++++-----------
3 files changed, 34 insertions(+), 45 deletions(-)
diff --git a/net/mac80211/Kconfig b/net/mac80211/Kconfig
index 3891cbd2adea..76e30f4797fb 100644
--- a/net/mac80211/Kconfig
+++ b/net/mac80211/Kconfig
@@ -6,6 +6,7 @@ config MAC80211
select CRYPTO_AES
select CRYPTO_CCM
select CRYPTO_GCM
+ select CRYPTO_CMAC
select CRC32
---help---
This option enables the hardware independent IEEE 802.11
diff --git a/net/mac80211/aes_cmac.h b/net/mac80211/aes_cmac.h
index c827e1d5de8b..3702041f44fd 100644
--- a/net/mac80211/aes_cmac.h
+++ b/net/mac80211/aes_cmac.h
@@ -11,10 +11,6 @@
#include <linux/crypto.h>
-void gf_mulx(u8 *pad);
-void aes_cmac_vector(struct crypto_cipher *tfm, size_t num_elem,
- const u8 *addr[], const size_t *len, u8 *mac,
- size_t mac_len);
struct crypto_cipher *ieee80211_aes_cmac_key_setup(const u8 key[],
size_t key_len);
void ieee80211_aes_cmac(struct crypto_cipher *tfm, const u8 *aad,
diff --git a/net/mac80211/fils_aead.c b/net/mac80211/fils_aead.c
index 5c3af5eb4052..3cfb1e2ab7ac 100644
--- a/net/mac80211/fils_aead.c
+++ b/net/mac80211/fils_aead.c
@@ -9,66 +9,58 @@
#include <crypto/aes.h>
#include <crypto/algapi.h>
+#include <crypto/hash.h>
#include <crypto/skcipher.h>
#include "ieee80211_i.h"
#include "aes_cmac.h"
#include "fils_aead.h"
-static int aes_s2v(struct crypto_cipher *tfm,
+static void gf_mulx(u8 *pad)
+{
+ u64 a = get_unaligned_be64(pad);
+ u64 b = get_unaligned_be64(pad + 8);
+
+ put_unaligned_be64((a << 1) | (b >> 63), pad);
+ put_unaligned_be64((b << 1) ^ ((a >> 63) ? 0x87 : 0), pad + 8);
+}
+
+static int aes_s2v(struct crypto_shash *tfm,
size_t num_elem, const u8 *addr[], size_t len[], u8 *v)
{
- u8 d[AES_BLOCK_SIZE], tmp[AES_BLOCK_SIZE];
+ u8 d[AES_BLOCK_SIZE], tmp[AES_BLOCK_SIZE] = {};
+ SHASH_DESC_ON_STACK(desc, tfm);
size_t i;
- const u8 *data[2];
- size_t data_len[2], data_elems;
+
+ desc->tfm = tfm;
/* D = AES-CMAC(K, <zero>) */
- memset(tmp, 0, AES_BLOCK_SIZE);
- data[0] = tmp;
- data_len[0] = AES_BLOCK_SIZE;
- aes_cmac_vector(tfm, 1, data, data_len, d, AES_BLOCK_SIZE);
+ crypto_shash_digest(desc, tmp, AES_BLOCK_SIZE, d);
for (i = 0; i < num_elem - 1; i++) {
/* D = dbl(D) xor AES_CMAC(K, Si) */
gf_mulx(d); /* dbl */
- aes_cmac_vector(tfm, 1, &addr[i], &len[i], tmp,
- AES_BLOCK_SIZE);
+ crypto_shash_digest(desc, addr[i], len[i], tmp);
crypto_xor(d, tmp, AES_BLOCK_SIZE);
}
+ crypto_shash_init(desc);
+
if (len[i] >= AES_BLOCK_SIZE) {
/* len(Sn) >= 128 */
- size_t j;
- const u8 *pos;
-
/* T = Sn xorend D */
-
- /* Use a temporary buffer to perform xorend on Sn (addr[i]) to
- * avoid modifying the const input argument.
- */
- data[0] = addr[i];
- data_len[0] = len[i] - AES_BLOCK_SIZE;
- pos = addr[i] + data_len[0];
- for (j = 0; j < AES_BLOCK_SIZE; j++)
- tmp[j] = pos[j] ^ d[j];
- data[1] = tmp;
- data_len[1] = AES_BLOCK_SIZE;
- data_elems = 2;
+ crypto_shash_update(desc, addr[i], len[i] - AES_BLOCK_SIZE);
+ crypto_xor(d, addr[i] + len[i] - AES_BLOCK_SIZE,
+ AES_BLOCK_SIZE);
} else {
/* len(Sn) < 128 */
/* T = dbl(D) xor pad(Sn) */
gf_mulx(d); /* dbl */
- memset(tmp, 0, AES_BLOCK_SIZE);
- memcpy(tmp, addr[i], len[i]);
- tmp[len[i]] = 0x80;
- crypto_xor(d, tmp, AES_BLOCK_SIZE);
- data[0] = d;
- data_len[0] = sizeof(d);
- data_elems = 1;
+ crypto_xor(d, addr[i], len[i]);
+ d[len[i]] ^= 0x80;
}
/* V = AES-CMAC(K, T) */
- aes_cmac_vector(tfm, data_elems, data, data_len, v, AES_BLOCK_SIZE);
+ crypto_shash_finup(desc, d, AES_BLOCK_SIZE, v);
return 0;
}
@@ -80,7 +72,7 @@ static int aes_siv_encrypt(const u8 *key, size_t key_len,
size_t len[], u8 *out)
{
u8 v[AES_BLOCK_SIZE];
- struct crypto_cipher *tfm;
+ struct crypto_shash *tfm;
struct crypto_skcipher *tfm2;
struct skcipher_request *req;
int res;
@@ -95,14 +87,14 @@ static int aes_siv_encrypt(const u8 *key, size_t key_len,
/* S2V */
- tfm = crypto_alloc_cipher("aes", 0, 0);
+ tfm = crypto_alloc_shash("cmac(aes)", 0, 0);
if (IS_ERR(tfm))
return PTR_ERR(tfm);
/* K1 for S2V */
- res = crypto_cipher_setkey(tfm, key, key_len);
+ res = crypto_shash_setkey(tfm, key, key_len);
if (!res)
res = aes_s2v(tfm, num_elem, addr, len, v);
- crypto_free_cipher(tfm);
+ crypto_free_shash(tfm);
if (res)
return res;
@@ -157,7 +149,7 @@ static int aes_siv_decrypt(const u8 *key, size_t key_len,
size_t num_elem, const u8 *addr[], size_t len[],
u8 *out)
{
- struct crypto_cipher *tfm;
+ struct crypto_shash *tfm;
struct crypto_skcipher *tfm2;
struct skcipher_request *req;
struct scatterlist src[1], dst[1];
@@ -210,14 +202,14 @@ static int aes_siv_decrypt(const u8 *key, size_t key_len,
/* S2V */
- tfm = crypto_alloc_cipher("aes", 0, 0);
+ tfm = crypto_alloc_shash("cmac(aes)", 0, 0);
if (IS_ERR(tfm))
return PTR_ERR(tfm);
/* K1 for S2V */
- res = crypto_cipher_setkey(tfm, key, key_len);
+ res = crypto_shash_setkey(tfm, key, key_len);
if (!res)
res = aes_s2v(tfm, num_elem, addr, len, check);
- crypto_free_cipher(tfm);
+ crypto_free_shash(tfm);
if (res)
return res;
if (memcmp(check, frame_iv, AES_BLOCK_SIZE) != 0)
--
2.7.4
^ permalink raw reply related
* [PATCH v3 2/2] mac80211: aes-cmac: switch to shash CMAC driver
From: Ard Biesheuvel @ 2017-02-06 10:49 UTC (permalink / raw)
To: johannes, linux-wireless; +Cc: davem, netdev, jouni, Ard Biesheuvel
In-Reply-To: <1486378168-31028-1-git-send-email-ard.biesheuvel@linaro.org>
Instead of open coding the CMAC algorithm in the mac80211 driver using
byte wide xors and calls into the crypto layer for each block of data,
instantiate a cmac(aes) synchronous hash and pass all the data into it
directly. This does not only simplify the code, it also allows the use
of more efficient and more secure implementations, especially on
platforms where SIMD ciphers have a considerable setup cost.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
net/mac80211/aes_cmac.c | 126 ++++----------------
net/mac80211/aes_cmac.h | 11 +-
net/mac80211/key.h | 2 +-
3 files changed, 32 insertions(+), 107 deletions(-)
diff --git a/net/mac80211/aes_cmac.c b/net/mac80211/aes_cmac.c
index d0bd5fff5f0a..2fb65588490c 100644
--- a/net/mac80211/aes_cmac.c
+++ b/net/mac80211/aes_cmac.c
@@ -22,126 +22,50 @@
#define CMAC_TLEN_256 16 /* CMAC TLen = 128 bits (16 octets) */
#define AAD_LEN 20
+static const u8 zero[CMAC_TLEN_256];
-void gf_mulx(u8 *pad)
-{
- int i, carry;
-
- carry = pad[0] & 0x80;
- for (i = 0; i < AES_BLOCK_SIZE - 1; i++)
- pad[i] = (pad[i] << 1) | (pad[i + 1] >> 7);
- pad[AES_BLOCK_SIZE - 1] <<= 1;
- if (carry)
- pad[AES_BLOCK_SIZE - 1] ^= 0x87;
-}
-
-void aes_cmac_vector(struct crypto_cipher *tfm, size_t num_elem,
- const u8 *addr[], const size_t *len, u8 *mac,
- size_t mac_len)
-{
- u8 cbc[AES_BLOCK_SIZE], pad[AES_BLOCK_SIZE];
- const u8 *pos, *end;
- size_t i, e, left, total_len;
-
- memset(cbc, 0, AES_BLOCK_SIZE);
-
- total_len = 0;
- for (e = 0; e < num_elem; e++)
- total_len += len[e];
- left = total_len;
-
- e = 0;
- pos = addr[0];
- end = pos + len[0];
-
- while (left >= AES_BLOCK_SIZE) {
- for (i = 0; i < AES_BLOCK_SIZE; i++) {
- cbc[i] ^= *pos++;
- if (pos >= end) {
- e++;
- pos = addr[e];
- end = pos + len[e];
- }
- }
- if (left > AES_BLOCK_SIZE)
- crypto_cipher_encrypt_one(tfm, cbc, cbc);
- left -= AES_BLOCK_SIZE;
- }
-
- memset(pad, 0, AES_BLOCK_SIZE);
- crypto_cipher_encrypt_one(tfm, pad, pad);
- gf_mulx(pad);
-
- if (left || total_len == 0) {
- for (i = 0; i < left; i++) {
- cbc[i] ^= *pos++;
- if (pos >= end) {
- e++;
- pos = addr[e];
- end = pos + len[e];
- }
- }
- cbc[left] ^= 0x80;
- gf_mulx(pad);
- }
-
- for (i = 0; i < AES_BLOCK_SIZE; i++)
- pad[i] ^= cbc[i];
- crypto_cipher_encrypt_one(tfm, pad, pad);
- memcpy(mac, pad, mac_len);
-}
-
-
-void ieee80211_aes_cmac(struct crypto_cipher *tfm, const u8 *aad,
+void ieee80211_aes_cmac(struct crypto_shash *tfm, const u8 *aad,
const u8 *data, size_t data_len, u8 *mic)
{
- const u8 *addr[3];
- size_t len[3];
- u8 zero[CMAC_TLEN];
+ SHASH_DESC_ON_STACK(desc, tfm);
+ u8 out[AES_BLOCK_SIZE];
- memset(zero, 0, CMAC_TLEN);
- addr[0] = aad;
- len[0] = AAD_LEN;
- addr[1] = data;
- len[1] = data_len - CMAC_TLEN;
- addr[2] = zero;
- len[2] = CMAC_TLEN;
+ desc->tfm = tfm;
- aes_cmac_vector(tfm, 3, addr, len, mic, CMAC_TLEN);
+ crypto_shash_init(desc);
+ crypto_shash_update(desc, aad, AAD_LEN);
+ crypto_shash_update(desc, data, data_len - CMAC_TLEN);
+ crypto_shash_finup(desc, zero, CMAC_TLEN, out);
+
+ memcpy(mic, out, CMAC_TLEN);
}
-void ieee80211_aes_cmac_256(struct crypto_cipher *tfm, const u8 *aad,
+void ieee80211_aes_cmac_256(struct crypto_shash *tfm, const u8 *aad,
const u8 *data, size_t data_len, u8 *mic)
{
- const u8 *addr[3];
- size_t len[3];
- u8 zero[CMAC_TLEN_256];
+ SHASH_DESC_ON_STACK(desc, tfm);
- memset(zero, 0, CMAC_TLEN_256);
- addr[0] = aad;
- len[0] = AAD_LEN;
- addr[1] = data;
- len[1] = data_len - CMAC_TLEN_256;
- addr[2] = zero;
- len[2] = CMAC_TLEN_256;
+ desc->tfm = tfm;
- aes_cmac_vector(tfm, 3, addr, len, mic, CMAC_TLEN_256);
+ crypto_shash_init(desc);
+ crypto_shash_update(desc, aad, AAD_LEN);
+ crypto_shash_update(desc, data, data_len - CMAC_TLEN_256);
+ crypto_shash_finup(desc, zero, CMAC_TLEN_256, mic);
}
-struct crypto_cipher *ieee80211_aes_cmac_key_setup(const u8 key[],
- size_t key_len)
+struct crypto_shash *ieee80211_aes_cmac_key_setup(const u8 key[],
+ size_t key_len)
{
- struct crypto_cipher *tfm;
+ struct crypto_shash *tfm;
- tfm = crypto_alloc_cipher("aes", 0, CRYPTO_ALG_ASYNC);
+ tfm = crypto_alloc_shash("cmac(aes)", 0, 0);
if (!IS_ERR(tfm))
- crypto_cipher_setkey(tfm, key, key_len);
+ crypto_shash_setkey(tfm, key, key_len);
return tfm;
}
-
-void ieee80211_aes_cmac_key_free(struct crypto_cipher *tfm)
+void ieee80211_aes_cmac_key_free(struct crypto_shash *tfm)
{
- crypto_free_cipher(tfm);
+ crypto_free_shash(tfm);
}
diff --git a/net/mac80211/aes_cmac.h b/net/mac80211/aes_cmac.h
index 3702041f44fd..fef531f42003 100644
--- a/net/mac80211/aes_cmac.h
+++ b/net/mac80211/aes_cmac.h
@@ -10,13 +10,14 @@
#define AES_CMAC_H
#include <linux/crypto.h>
+#include <crypto/hash.h>
-struct crypto_cipher *ieee80211_aes_cmac_key_setup(const u8 key[],
- size_t key_len);
-void ieee80211_aes_cmac(struct crypto_cipher *tfm, const u8 *aad,
+struct crypto_shash *ieee80211_aes_cmac_key_setup(const u8 key[],
+ size_t key_len);
+void ieee80211_aes_cmac(struct crypto_shash *tfm, const u8 *aad,
const u8 *data, size_t data_len, u8 *mic);
-void ieee80211_aes_cmac_256(struct crypto_cipher *tfm, const u8 *aad,
+void ieee80211_aes_cmac_256(struct crypto_shash *tfm, const u8 *aad,
const u8 *data, size_t data_len, u8 *mic);
-void ieee80211_aes_cmac_key_free(struct crypto_cipher *tfm);
+void ieee80211_aes_cmac_key_free(struct crypto_shash *tfm);
#endif /* AES_CMAC_H */
diff --git a/net/mac80211/key.h b/net/mac80211/key.h
index 4aa20cef0859..ebdb80b85dc3 100644
--- a/net/mac80211/key.h
+++ b/net/mac80211/key.h
@@ -93,7 +93,7 @@ struct ieee80211_key {
} ccmp;
struct {
u8 rx_pn[IEEE80211_CMAC_PN_LEN];
- struct crypto_cipher *tfm;
+ struct crypto_shash *tfm;
u32 replays; /* dot11RSNAStatsCMACReplays */
u32 icverrors; /* dot11RSNAStatsCMACICVErrors */
} aes_cmac;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v4 3/3] mt76: add driver code for MT76x2e
From: Stanislaw Gruszka @ 2017-02-06 11:25 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, kvalo
In-Reply-To: <20170202115208.8614-4-nbd@nbd.name>
On Thu, Feb 02, 2017 at 12:52:08PM +0100, Felix Fietkau wrote:
> This is a 2x2 PCIe 802.11ac chipset by MediaTek
>
> Signed-off-by: Felix Fietkau <nbd@nbd.name>
Driver looks great to me, though I think it could be better commented.
I have some minor issues, but if they need to be fixed, it could be done
by incremental patches after apply this one to the tree.
Reviewed-by: Stanislaw Gruszka <sgruszka@redhat.com>
> +enum dma_msg_port {
> + WLAN_PORT,
> + CPU_RX_PORT,
> + CPU_TX_PORT,
> + HOST_PORT,
> + VIRTUAL_CPU_RX_PORT,
> + VIRTUAL_CPU_TX_PORT,
> + DISCARD,
> +};
Not used ?
> +void mt76x2_set_tx_ackto(struct mt76x2_dev *dev)
> +{
> + u8 ackto, sifs, slottime = dev->slottime;
> +
> + slottime += 3 * dev->coverage_class;
> +
> + sifs = mt76_get_field(dev, MT_XIFS_TIME_CFG,
> + MT_XIFS_TIME_CFG_OFDM_SIFS);
> +
> + ackto = slottime + sifs;
> + mt76_rmw_field(dev, MT_TX_TIMEOUT_CFG,
> + MT_TX_TIMEOUT_CFG_ACKTO, ackto);
> +}
Interesting, if this correct way to configure the TX_TIMEOUT_CFG_ACKTO
we will also need this in rt2x00. Vendor drivers use 32 for this setting
and do not change it.
Note we have also EXP_ACT_TIME and EXP_CTS_TIME registers, which stay
with default settings, but perhaps should be changed depending on
channel properties as well.
> +static u32
> +mt76x2_tx_power_mask(u8 v1, u8 v2, u8 v3, u8 v4)
> +{
> + u32 val = 0;
> +
> + val |= (v1 & (BIT(6) - 1)) << 0;
> + val |= (v2 & (BIT(6) - 1)) << 8;
> + val |= (v3 & (BIT(6) - 1)) << 16;
> + val |= (v4 & (BIT(6) - 1)) << 24;
> + return val;
> +}
TX_PWR_CFG registers consist of eight 4bit entries, masking
two entries with 0x3f does not seems to be correct.
> + mt76_wr(dev, MT_TX_PWR_CFG_3,
> + mt76x2_tx_power_mask(t.ht[12], t.ht[14], t.ht[0], t.ht[2]));
> + mt76_wr(dev, MT_TX_PWR_CFG_4,
> + mt76x2_tx_power_mask(t.ht[4], t.ht[6], 0, 0));
> + mt76_wr(dev, MT_TX_PWR_CFG_7,
> + mt76x2_tx_power_mask(t.ofdm[6], t.vht[8], t.ht[6], t.vht[8]));
> + mt76_wr(dev, MT_TX_PWR_CFG_8,
> + mt76x2_tx_power_mask(t.ht[14], t.vht[8], t.vht[8], 0));
> + mt76_wr(dev, MT_TX_PWR_CFG_9,
> + mt76x2_tx_power_mask(t.ht[6], t.vht[8], t.vht[8], 0));
Looks like some of arguments instead of t.vht[x] accidentally become t.ht[x],
for example t.vht[6] is never used.
> +static void
> +mt76x2_configure_tx_delay(struct mt76x2_dev *dev, enum nl80211_band band, u8 bw)
> +{
> + u32 cfg0, cfg1;
> +
> + if (mt76x2_ext_pa_enabled(dev, band)) {
> + cfg0 = bw ? 0x000b0c01 : 0x00101101;
> + cfg1 = 0x00011414;
> + } else {
> + cfg0 = bw ? 0x000b0b01 : 0x00101001;
> + cfg1 = 0x00021414;
> + }
> + mt76_wr(dev, MT_TX_SW_CFG0, cfg0);
> + mt76_wr(dev, MT_TX_SW_CFG1, cfg1);
> +
> + mt76_rmw_field(dev, MT_XIFS_TIME_CFG, MT_XIFS_TIME_CFG_CCK_SIFS,
> + 13 + (bw ? 1 : 0));
> +}
SIFS for 2GHz should be 10us and for 5GHz 16us. Setting SIFS to 13
or 14 looks wrong for 2GHz band. Can be correct for 5GHz assuming
we have some internal delays configured on TX_SW_CFG registers.
But again this is interesting for rt2x00, where we stay with
defaults, but looks we should configure XIFS_TIME_CFG based on
channel.
> + if (chandef->width >= NL80211_CHAN_WIDTH_40)
> + sifs++;
> +
> + mt76_rmw_field(dev, MT_XIFS_TIME_CFG, MT_XIFS_TIME_CFG_OFDM_SIFS, sifs);
This probably should be set together with MT_XIFS_TIME_CFG_CCK_SIFS in
mt76x2_configure_tx_delay().
> +static int mt76x2_insert_hdr_pad(struct sk_buff *skb)
> +{
> + int len = ieee80211_get_hdrlen_from_skb(skb);
> + int ret;
> +
> + if (len % 4 == 0)
> + return 0;
> +
> + if (skb_headroom(skb) < 2) {
> + ret = pskb_expand_head(skb, 2, 0, GFP_ATOMIC);
> + if (ret != 0)
> + return ret;
This should not be needed if hw->extra_tx_headroom is set properly.
> + if (info->flags & IEEE80211_TX_CTL_RATE_CTRL_PROBE)
> + qsel = 0;
For better understating: qsel = MT_QSEL_MGMT;
> +void mt76x2_pre_tbtt_tasklet(unsigned long arg)
> +{
> + struct mt76x2_dev *dev = (struct mt76x2_dev *) arg;
> + struct mt76_queue *q = &dev->mt76.q_tx[MT_TXQ_PSD];
> + struct beacon_bc_data data = {};
> + struct sk_buff *skb;
> + int i, nframes;
> +
> + data.dev = dev;
> + __skb_queue_head_init(&data.q);
> +
> + ieee80211_iterate_active_interfaces_atomic(mt76_hw(dev),
This symbol, not like most of other mac80211 symbols, is exported via
EXPORT_SYMBOL_GPL(), so I'm not sure if it can be used on dual licensed
file, perhaps licence of this file should be changed to GPL only.
Stanislaw
^ permalink raw reply
* Submitted patches for 4.11 NOW
From: Kalle Valo @ 2017-02-06 11:41 UTC (permalink / raw)
To: linux-wireless
Hi,
Linus is hinting that he might release the final 4.10 next Sunday. So if
you want have patches with new features in 4.11 better post them NOW to
not the miss the merge window.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 01/11 V2] rtlwifi: Fix programing CAM content sequence.
From: Kalle Valo @ 2017-02-06 11:50 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless, Ping-Ke Shih, shaofu
In-Reply-To: <20170120212716.29887-2-Larry.Finger@lwfinger.net>
Larry Finger <Larry.Finger@lwfinger.net> writes:
> From: Ping-Ke Shih <pkshih@realtek.com>
>
> There is a potential race condition when the control byte of a CAM
> entry is written first. Write in reverse order to correct the condition.
>
> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
> Signed-off-by: shaofu <shaofu@realtek.com>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> ---
> V2 - no changes
Weird, I don't see any of the v2 patches in patchwork:
https://patchwork.kernel.org/project/linux-wireless/list/?state=*&page=1
I do see other recent patches from you Larry, but not this set. Can you
resubmit, please?
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v4 3/3] mt76: add driver code for MT76x2e
From: Felix Fietkau @ 2017-02-06 11:52 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: linux-wireless, kvalo
In-Reply-To: <20170206112508.GA9255@redhat.com>
On 2017-02-06 12:25, Stanislaw Gruszka wrote:
> On Thu, Feb 02, 2017 at 12:52:08PM +0100, Felix Fietkau wrote:
>> This is a 2x2 PCIe 802.11ac chipset by MediaTek
>>
>> Signed-off-by: Felix Fietkau <nbd@nbd.name>
> Driver looks great to me, though I think it could be better commented.
> I have some minor issues, but if they need to be fixed, it could be done
> by incremental patches after apply this one to the tree.
>
> Reviewed-by: Stanislaw Gruszka <sgruszka@redhat.com>
Thanks for the review.
>> +enum dma_msg_port {
>> + WLAN_PORT,
>> + CPU_RX_PORT,
>> + CPU_TX_PORT,
>> + HOST_PORT,
>> + VIRTUAL_CPU_RX_PORT,
>> + VIRTUAL_CPU_TX_PORT,
>> + DISCARD,
>> +};
> Not used ?
Yeah, I guess it can be removed.
>> +void mt76x2_set_tx_ackto(struct mt76x2_dev *dev)
>> +{
>> + u8 ackto, sifs, slottime = dev->slottime;
>> +
>> + slottime += 3 * dev->coverage_class;
>> +
>> + sifs = mt76_get_field(dev, MT_XIFS_TIME_CFG,
>> + MT_XIFS_TIME_CFG_OFDM_SIFS);
>> +
>> + ackto = slottime + sifs;
>> + mt76_rmw_field(dev, MT_TX_TIMEOUT_CFG,
>> + MT_TX_TIMEOUT_CFG_ACKTO, ackto);
>> +}
> Interesting, if this correct way to configure the TX_TIMEOUT_CFG_ACKTO
> we will also need this in rt2x00. Vendor drivers use 32 for this setting
> and do not change it.
I don't think vendor drivers even have support for coverage class.
> Note we have also EXP_ACT_TIME and EXP_CTS_TIME registers, which stay
> with default settings, but perhaps should be changed depending on
> channel properties as well.
>
>> +static u32
>> +mt76x2_tx_power_mask(u8 v1, u8 v2, u8 v3, u8 v4)
>> +{
>> + u32 val = 0;
>> +
>> + val |= (v1 & (BIT(6) - 1)) << 0;
>> + val |= (v2 & (BIT(6) - 1)) << 8;
>> + val |= (v3 & (BIT(6) - 1)) << 16;
>> + val |= (v4 & (BIT(6) - 1)) << 24;
>> + return val;
>> +}
> TX_PWR_CFG registers consist of eight 4bit entries, masking
> two entries with 0x3f does not seems to be correct.
No, these registers consist of four 6bit entries. Both the vendor driver
and the datasheet describe them this way.
>> + mt76_wr(dev, MT_TX_PWR_CFG_3,
>> + mt76x2_tx_power_mask(t.ht[12], t.ht[14], t.ht[0], t.ht[2]));
>> + mt76_wr(dev, MT_TX_PWR_CFG_4,
>> + mt76x2_tx_power_mask(t.ht[4], t.ht[6], 0, 0));
>> + mt76_wr(dev, MT_TX_PWR_CFG_7,
>> + mt76x2_tx_power_mask(t.ofdm[6], t.vht[8], t.ht[6], t.vht[8]));
>> + mt76_wr(dev, MT_TX_PWR_CFG_8,
>> + mt76x2_tx_power_mask(t.ht[14], t.vht[8], t.vht[8], 0));
>> + mt76_wr(dev, MT_TX_PWR_CFG_9,
>> + mt76x2_tx_power_mask(t.ht[6], t.vht[8], t.vht[8], 0));
> Looks like some of arguments instead of t.vht[x] accidentally become t.ht[x],
> for example t.vht[6] is never used.
There are not enough register fields for all rates individually, so they
overlap. This looks a bit confusing and random, but I did check it
carefully against the vendor driver and the datasheet.
>> +static void
>> +mt76x2_configure_tx_delay(struct mt76x2_dev *dev, enum nl80211_band band, u8 bw)
>> +{
>> + u32 cfg0, cfg1;
>> +
>> + if (mt76x2_ext_pa_enabled(dev, band)) {
>> + cfg0 = bw ? 0x000b0c01 : 0x00101101;
>> + cfg1 = 0x00011414;
>> + } else {
>> + cfg0 = bw ? 0x000b0b01 : 0x00101001;
>> + cfg1 = 0x00021414;
>> + }
>> + mt76_wr(dev, MT_TX_SW_CFG0, cfg0);
>> + mt76_wr(dev, MT_TX_SW_CFG1, cfg1);
>> +
>> + mt76_rmw_field(dev, MT_XIFS_TIME_CFG, MT_XIFS_TIME_CFG_CCK_SIFS,
>> + 13 + (bw ? 1 : 0));
>> +}
> SIFS for 2GHz should be 10us and for 5GHz 16us. Setting SIFS to 13
> or 14 looks wrong for 2GHz band. Can be correct for 5GHz assuming
> we have some internal delays configured on TX_SW_CFG registers.
This is a CCK-only SIFS value (there's a separate one for OFDM).
> But again this is interesting for rt2x00, where we stay with
> defaults, but looks we should configure XIFS_TIME_CFG based on
> channel.
I think many of these might be mt76x2 specific tweaks, so be careful
with applying any of that to rt2x00.
>> + if (chandef->width >= NL80211_CHAN_WIDTH_40)
>> + sifs++;
>> +
>> + mt76_rmw_field(dev, MT_XIFS_TIME_CFG, MT_XIFS_TIME_CFG_OFDM_SIFS, sifs);
> This probably should be set together with MT_XIFS_TIME_CFG_CCK_SIFS in
> mt76x2_configure_tx_delay().
Will look into that.
>> +static int mt76x2_insert_hdr_pad(struct sk_buff *skb)
>> +{
>> + int len = ieee80211_get_hdrlen_from_skb(skb);
>> + int ret;
>> +
>> + if (len % 4 == 0)
>> + return 0;
>> +
>> + if (skb_headroom(skb) < 2) {
>> + ret = pskb_expand_head(skb, 2, 0, GFP_ATOMIC);
>> + if (ret != 0)
>> + return ret;
> This should not be needed if hw->extra_tx_headroom is set properly.
Thanks, will send a follow-up cleanup patch if this one is accepted.
>> + if (info->flags & IEEE80211_TX_CTL_RATE_CTRL_PROBE)
>> + qsel = 0;
> For better understating: qsel = MT_QSEL_MGMT;
Right.
>> +void mt76x2_pre_tbtt_tasklet(unsigned long arg)
>> +{
>> + struct mt76x2_dev *dev = (struct mt76x2_dev *) arg;
>> + struct mt76_queue *q = &dev->mt76.q_tx[MT_TXQ_PSD];
>> + struct beacon_bc_data data = {};
>> + struct sk_buff *skb;
>> + int i, nframes;
>> +
>> + data.dev = dev;
>> + __skb_queue_head_init(&data.q);
>> +
>> + ieee80211_iterate_active_interfaces_atomic(mt76_hw(dev),
> This symbol, not like most of other mac80211 symbols, is exported via
> EXPORT_SYMBOL_GPL(), so I'm not sure if it can be used on dual licensed
> file, perhaps licence of this file should be changed to GPL only.
Technically only the resulting binary will become GPL. I still want to
keep the source code of the entire driver ISC licensed to make it easier
for the BSDs to copy code from it.
- Felix
^ permalink raw reply
* Re: [PATCH v3] ath10k: Fix crash during rmmod when probe firmware fails
From: Shajakhan, Mohammed Shafi (Mohammed Shafi) @ 2017-02-06 12:21 UTC (permalink / raw)
To: Michael Ney, Mohammed Shafi Shajakhan
Cc: Valo, Kalle, linux-wireless@vger.kernel.org,
ath10k@lists.infradead.org
In-Reply-To: <2DBE5232-FF3F-4B0E-8739-B6E82361316C@vorklift.com>
Hi,=0A=
=0A=
even with the below patch applied ?=0A=
https://patchwork.kernel.org/patch/9452265/=0A=
=0A=
regards=0A=
shafi=0A=
________________________________________=0A=
From: Michael Ney <neym@vorklift.com>=0A=
Sent: 06 February 2017 17:46=0A=
To: Mohammed Shafi Shajakhan=0A=
Cc: Valo, Kalle; linux-wireless@vger.kernel.org; ath10k@lists.infradead.org=
; Shajakhan, Mohammed Shafi (Mohammed Shafi)=0A=
Subject: Re: [PATCH v3] ath10k: Fix crash during rmmod when probe firmware =
fails=0A=
=0A=
Symmetry is still broken on firmware crash (at least with 6174). ath10k_pci=
_hif_stop gets called twice, once from the driver restart (warm restart) an=
d once from ieee80211 start (cold restart), resulting in napi_synchrionize/=
napi_disable getting called twice and sticking the driver in an infinite wa=
it loop (napi_synchronize waits until NAPI_STATE_SCHED is off, while napi_d=
isable leaves NAPI_STATE_SCHED to on when leaving).=0A=
=0A=
=0A=
> On Feb 6, 2017, at 5:04 AM, Mohammed Shafi Shajakhan <mohammed@codeaurora=
.org> wrote:=0A=
>=0A=
> Hi Kalle,=0A=
>=0A=
> the change suggested by you helps, and the device probe, scan=0A=
> is successful as well. Still good to have this change part of your=0A=
> basic sanity and regression testing !=0A=
>=0A=
> regards,=0A=
> shafi=0A=
>=0A=
> On Wed, Jan 25, 2017 at 01:46:28PM +0000, Valo, Kalle wrote:=0A=
>> Kalle Valo <kvalo@qca.qualcomm.com> writes:=0A=
>>=0A=
>>> Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> writes:=0A=
>>>=0A=
>>>> From: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>=0A=
>>>>=0A=
>>>> This fixes the below crash when ath10k probe firmware fails,=0A=
>>>> NAPI polling tries to access a rx ring resource which was never=0A=
>>>> allocated, fix this by disabling NAPI right away once the probe=0A=
>>>> firmware fails by calling 'ath10k_hif_stop'. Its good to note=0A=
>>>> that the error is never propogated to 'ath10k_pci_probe' when=0A=
>>>> ath10k_core_register fails, so calling 'ath10k_hif_stop' to cleanup=0A=
>>>> PCI related things seems to be ok=0A=
>>>>=0A=
>>>> BUG: unable to handle kernel NULL pointer dereference at (null)=0A=
>>>> IP: __ath10k_htt_rx_ring_fill_n+0x19/0x230 [ath10k_core]=0A=
>>>> __ath10k_htt_rx_ring_fill_n+0x19/0x230 [ath10k_core]=0A=
>>>>=0A=
>>>> Call Trace:=0A=
>>>>=0A=
>>>> [<ffffffffa113ec62>] ath10k_htt_rx_msdu_buff_replenish+0x42/0x90=0A=
>>>> [ath10k_core]=0A=
>>>> [<ffffffffa113f393>] ath10k_htt_txrx_compl_task+0x433/0x17d0=0A=
>>>> [ath10k_core]=0A=
>>>> [<ffffffff8114406d>] ? __wake_up_common+0x4d/0x80=0A=
>>>> [<ffffffff811349ec>] ? cpu_load_update+0xdc/0x150=0A=
>>>> [<ffffffffa119301d>] ? ath10k_pci_read32+0xd/0x10 [ath10k_pci]=0A=
>>>> [<ffffffffa1195b17>] ath10k_pci_napi_poll+0x47/0x110 [ath10k_pci]=0A=
>>>> [<ffffffff817863af>] net_rx_action+0x20f/0x370=0A=
>>>>=0A=
>>>> Reported-by: Ben Greear <greearb@candelatech.com>=0A=
>>>> Fixes: 3c97f5de1f28 ("ath10k: implement NAPI support")=0A=
>>>> Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>=0A=
>>>=0A=
>>> Is there an easy way to reproduce this bug? I don't see it on my x86=0A=
>>> laptop with qca988x and I call rmmod all the time. I would like to test=
=0A=
>>> this myself.=0A=
>>>=0A=
>>>> --- a/drivers/net/wireless/ath/ath10k/core.c=0A=
>>>> +++ b/drivers/net/wireless/ath/ath10k/core.c=0A=
>>>> @@ -2164,6 +2164,7 @@ static int ath10k_core_probe_fw(struct ath10k *a=
r)=0A=
>>>> ath10k_core_free_firmware_files(ar);=0A=
>>>>=0A=
>>>> err_power_down:=0A=
>>>> + ath10k_hif_stop(ar);=0A=
>>>> ath10k_hif_power_down(ar);=0A=
>>>>=0A=
>>>> return ret;=0A=
>>>=0A=
>>> This breaks the symmetry, we should not be calling ath10k_hif_stop() if=
=0A=
>>> we haven't called ath10k_hif_start() from the same function. This can=
=0A=
>>> just create a bigger mess later, for example with other bus support lik=
e=0A=
>>> sdio or usb. In theory it should enough that we call=0A=
>>> ath10k_hif_power_down() and pci.c does the rest correctly "behind the=
=0A=
>>> scenes".=0A=
>>>=0A=
>>> I investigated this a bit and I think the real cause is that we call=0A=
>>> napi_enable() from ath10k_pci_hif_power_up() and napi_disable() from=0A=
>>> ath10k_pci_hif_stop(). Does anyone remember why?=0A=
>>>=0A=
>>> I was expecting that we would call napi_enable()/napi_disable() either=
=0A=
>>> in ath10k_hif_power_up/down() or ath10k_hif_start()/stop(), but not=0A=
>>> mixed like it's currently.=0A=
>>=0A=
>> So below is something I was thinking of, now napi_enable() is called=0A=
>> from ath10k_hif_start() and napi_disable() from ath10k_hif_stop(). Would=
=0A=
>> that work?=0A=
>>=0A=
>> --- a/drivers/net/wireless/ath/ath10k/pci.c=0A=
>> +++ b/drivers/net/wireless/ath/ath10k/pci.c=0A=
>> @@ -1648,6 +1648,8 @@ static int ath10k_pci_hif_start(struct ath10k *ar)=
=0A=
>>=0A=
>> ath10k_dbg(ar, ATH10K_DBG_BOOT, "boot hif start\n");=0A=
>>=0A=
>> + napi_enable(&ar->napi);=0A=
>> +=0A=
>> ath10k_pci_irq_enable(ar);=0A=
>> ath10k_pci_rx_post(ar);=0A=
>>=0A=
>> @@ -2532,7 +2534,6 @@ static int ath10k_pci_hif_power_up(struct ath10k *=
ar)=0A=
>> ath10k_err(ar, "could not wake up target CPU: %d\n", ret);=
=0A=
>> goto err_ce;=0A=
>> }=0A=
>> - napi_enable(&ar->napi);=0A=
>>=0A=
>> return 0;=0A=
>>=0A=
>> --=0A=
>> Kalle Valo=0A=
>=0A=
> _______________________________________________=0A=
> ath10k mailing list=0A=
> ath10k@lists.infradead.org=0A=
> http://lists.infradead.org/mailman/listinfo/ath10k=0A=
=0A=
^ permalink raw reply
* Re: [PATCH v3] ath10k: Fix crash during rmmod when probe firmware fails
From: Michael Ney @ 2017-02-06 12:16 UTC (permalink / raw)
To: Mohammed Shafi Shajakhan
Cc: Valo, Kalle, linux-wireless@vger.kernel.org,
ath10k@lists.infradead.org,
Shajakhan, Mohammed Shafi (Mohammed Shafi)
In-Reply-To: <20170206100448.GA13894@atheros-ThinkPad-T61>
Symmetry is still broken on firmware crash (at least with 6174). ath10k_pci_hif_stop gets called twice, once from the driver restart (warm restart) and once from ieee80211 start (cold restart), resulting in napi_synchrionize/napi_disable getting called twice and sticking the driver in an infinite wait loop (napi_synchronize waits until NAPI_STATE_SCHED is off, while napi_disable leaves NAPI_STATE_SCHED to on when leaving).
> On Feb 6, 2017, at 5:04 AM, Mohammed Shafi Shajakhan <mohammed@codeaurora.org> wrote:
>
> Hi Kalle,
>
> the change suggested by you helps, and the device probe, scan
> is successful as well. Still good to have this change part of your
> basic sanity and regression testing !
>
> regards,
> shafi
>
> On Wed, Jan 25, 2017 at 01:46:28PM +0000, Valo, Kalle wrote:
>> Kalle Valo <kvalo@qca.qualcomm.com> writes:
>>
>>> Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> writes:
>>>
>>>> From: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
>>>>
>>>> This fixes the below crash when ath10k probe firmware fails,
>>>> NAPI polling tries to access a rx ring resource which was never
>>>> allocated, fix this by disabling NAPI right away once the probe
>>>> firmware fails by calling 'ath10k_hif_stop'. Its good to note
>>>> that the error is never propogated to 'ath10k_pci_probe' when
>>>> ath10k_core_register fails, so calling 'ath10k_hif_stop' to cleanup
>>>> PCI related things seems to be ok
>>>>
>>>> BUG: unable to handle kernel NULL pointer dereference at (null)
>>>> IP: __ath10k_htt_rx_ring_fill_n+0x19/0x230 [ath10k_core]
>>>> __ath10k_htt_rx_ring_fill_n+0x19/0x230 [ath10k_core]
>>>>
>>>> Call Trace:
>>>>
>>>> [<ffffffffa113ec62>] ath10k_htt_rx_msdu_buff_replenish+0x42/0x90
>>>> [ath10k_core]
>>>> [<ffffffffa113f393>] ath10k_htt_txrx_compl_task+0x433/0x17d0
>>>> [ath10k_core]
>>>> [<ffffffff8114406d>] ? __wake_up_common+0x4d/0x80
>>>> [<ffffffff811349ec>] ? cpu_load_update+0xdc/0x150
>>>> [<ffffffffa119301d>] ? ath10k_pci_read32+0xd/0x10 [ath10k_pci]
>>>> [<ffffffffa1195b17>] ath10k_pci_napi_poll+0x47/0x110 [ath10k_pci]
>>>> [<ffffffff817863af>] net_rx_action+0x20f/0x370
>>>>
>>>> Reported-by: Ben Greear <greearb@candelatech.com>
>>>> Fixes: 3c97f5de1f28 ("ath10k: implement NAPI support")
>>>> Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
>>>
>>> Is there an easy way to reproduce this bug? I don't see it on my x86
>>> laptop with qca988x and I call rmmod all the time. I would like to test
>>> this myself.
>>>
>>>> --- a/drivers/net/wireless/ath/ath10k/core.c
>>>> +++ b/drivers/net/wireless/ath/ath10k/core.c
>>>> @@ -2164,6 +2164,7 @@ static int ath10k_core_probe_fw(struct ath10k *ar)
>>>> ath10k_core_free_firmware_files(ar);
>>>>
>>>> err_power_down:
>>>> + ath10k_hif_stop(ar);
>>>> ath10k_hif_power_down(ar);
>>>>
>>>> return ret;
>>>
>>> This breaks the symmetry, we should not be calling ath10k_hif_stop() if
>>> we haven't called ath10k_hif_start() from the same function. This can
>>> just create a bigger mess later, for example with other bus support like
>>> sdio or usb. In theory it should enough that we call
>>> ath10k_hif_power_down() and pci.c does the rest correctly "behind the
>>> scenes".
>>>
>>> I investigated this a bit and I think the real cause is that we call
>>> napi_enable() from ath10k_pci_hif_power_up() and napi_disable() from
>>> ath10k_pci_hif_stop(). Does anyone remember why?
>>>
>>> I was expecting that we would call napi_enable()/napi_disable() either
>>> in ath10k_hif_power_up/down() or ath10k_hif_start()/stop(), but not
>>> mixed like it's currently.
>>
>> So below is something I was thinking of, now napi_enable() is called
>> from ath10k_hif_start() and napi_disable() from ath10k_hif_stop(). Would
>> that work?
>>
>> --- a/drivers/net/wireless/ath/ath10k/pci.c
>> +++ b/drivers/net/wireless/ath/ath10k/pci.c
>> @@ -1648,6 +1648,8 @@ static int ath10k_pci_hif_start(struct ath10k *ar)
>>
>> ath10k_dbg(ar, ATH10K_DBG_BOOT, "boot hif start\n");
>>
>> + napi_enable(&ar->napi);
>> +
>> ath10k_pci_irq_enable(ar);
>> ath10k_pci_rx_post(ar);
>>
>> @@ -2532,7 +2534,6 @@ static int ath10k_pci_hif_power_up(struct ath10k *ar)
>> ath10k_err(ar, "could not wake up target CPU: %d\n", ret);
>> goto err_ce;
>> }
>> - napi_enable(&ar->napi);
>>
>> return 0;
>>
>> --
>> Kalle Valo
>
> _______________________________________________
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply
* Re: [PATCH 01/11 V3] rtlwifi: Fix programing CAM content sequence.
From: Kalle Valo @ 2017-02-06 12:45 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless, Ping-Ke Shih, shaofu
In-Reply-To: <20170120212716.29887-2-Larry.Finger@lwfinger.net>
Larry Finger <Larry.Finger@lwfinger.net> writes:
> From: Ping-Ke Shih <pkshih@realtek.com>
>
> There is a potential race condition when the control byte of a CAM
> entry is written first. Write in reverse order to correct the condition.
>
> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
> Signed-off-by: shaofu <shaofu@realtek.com>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> ---
> V2 - no changes
> V3 - no changes
I missed in my reply to v2 that you had already sent v3 from this
patchset. Strange that I don't see this v3 patchset either in patchwork,
only v1.
Try submitting v4 in case it was just a temporary glitch in patchwork.
But if that doesn't help I'll apply these manually.
--
Kalle Valo
^ permalink raw reply
* ANNOUNCE: Netdev 2.1 update Feb 06
From: Jamal Hadi Salim @ 2017-02-06 13:02 UTC (permalink / raw)
To: netdev@vger.kernel.org
Cc: netfilter-devel, netfilter, info, linux-wireless, tech-committee,
David Miller, Stephen Jaworski, Rob Echlin, lwn
A few announcements:
- We expect to open up registration and announce hotel and location
this week.
- We are pleased to announce the first netdev 2.1 sponsor!
Many thanks to Mellanox who has been a strong supporter of the netdev
community. Mellanox is first to cross the netdev2.1 sponsor line with a
silver.
The Call for Proposals is still open, submit early
to avoid the hazards of last minute traffic. Refer to:
http://netdevconf.org/2.1/submit-proposal.html
cheers,
jamal
^ permalink raw reply
* Re: [PATCH v4 3/3] mt76: add driver code for MT76x2e
From: Stanislaw Gruszka @ 2017-02-06 13:14 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, kvalo
In-Reply-To: <3f9febb5-696e-884b-7c9a-76866f3e55e9@nbd.name>
On Mon, Feb 06, 2017 at 12:52:56PM +0100, Felix Fietkau wrote:
> >> +void mt76x2_set_tx_ackto(struct mt76x2_dev *dev)
> >> +{
> >> + u8 ackto, sifs, slottime = dev->slottime;
> >> +
> >> + slottime += 3 * dev->coverage_class;
> >> +
> >> + sifs = mt76_get_field(dev, MT_XIFS_TIME_CFG,
> >> + MT_XIFS_TIME_CFG_OFDM_SIFS);
> >> +
> >> + ackto = slottime + sifs;
> >> + mt76_rmw_field(dev, MT_TX_TIMEOUT_CFG,
> >> + MT_TX_TIMEOUT_CFG_ACKTO, ackto);
> >> +}
> > Interesting, if this correct way to configure the TX_TIMEOUT_CFG_ACKTO
> > we will also need this in rt2x00. Vendor drivers use 32 for this setting
> > and do not change it.
> I don't think vendor drivers even have support for coverage class.
Even not supporting coverage class (default is 0 anyway) this results
on different setting depending on slot time and sifs. My understanding
is that this is correct approach, compared to constant value used by
vendor.
> >> +static u32
> >> +mt76x2_tx_power_mask(u8 v1, u8 v2, u8 v3, u8 v4)
> >> +{
> >> + u32 val = 0;
> >> +
> >> + val |= (v1 & (BIT(6) - 1)) << 0;
> >> + val |= (v2 & (BIT(6) - 1)) << 8;
> >> + val |= (v3 & (BIT(6) - 1)) << 16;
> >> + val |= (v4 & (BIT(6) - 1)) << 24;
> >> + return val;
> >> +}
> > TX_PWR_CFG registers consist of eight 4bit entries, masking
> > two entries with 0x3f does not seems to be correct.
> No, these registers consist of four 6bit entries. Both the vendor driver
> and the datasheet describe them this way.
That different compared to old devices. I assumed those registers would
not change meaning in MT76, but I guess I was wrong.
> >> +mt76x2_configure_tx_delay(struct mt76x2_dev *dev, enum nl80211_band band, u8 bw)
> >> +{
> >> + u32 cfg0, cfg1;
> >> +
> >> + if (mt76x2_ext_pa_enabled(dev, band)) {
> >> + cfg0 = bw ? 0x000b0c01 : 0x00101101;
> >> + cfg1 = 0x00011414;
> >> + } else {
> >> + cfg0 = bw ? 0x000b0b01 : 0x00101001;
> >> + cfg1 = 0x00021414;
> >> + }
> >> + mt76_wr(dev, MT_TX_SW_CFG0, cfg0);
> >> + mt76_wr(dev, MT_TX_SW_CFG1, cfg1);
> >> +
> >> + mt76_rmw_field(dev, MT_XIFS_TIME_CFG, MT_XIFS_TIME_CFG_CCK_SIFS,
> >> + 13 + (bw ? 1 : 0));
> >> +}
> > SIFS for 2GHz should be 10us and for 5GHz 16us. Setting SIFS to 13
> > or 14 looks wrong for 2GHz band. Can be correct for 5GHz assuming
> > we have some internal delays configured on TX_SW_CFG registers.
> This is a CCK-only SIFS value (there's a separate one for OFDM).
CCK can be used only on 5GHz? OFDM only on 2GHz? I thought any rates can
be used on both bands. Or maybe this settings is just named wrongly
i.e. CCK_SIFS mean sifs for 5GHz and OFDM_SIFS - sifs for 2GHz ?
Stanislaw
^ permalink raw reply
* [PATCH] Print text for disassociation reason.
From: Arkadiusz Miskiewicz @ 2017-02-06 13:53 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
Hi.
Don't know why it wasn't printed there with ieee80211_get_reason_code_strin=
g in first
place. Works for me:
kernel: wlan0: disassociated from 04:b0:20:33:ff:1f (Reason: 34=3DDISASSOC_=
LOW_ACK)
ps. can't send patch in normal way due to postmaster@vger weirdness, so ins=
erted
below
=46rom c9b55bb44fe0b902f376a41fa930c9a67a438511 Mon Sep 17 00:00:00 2001
=46rom: =3D?UTF-8?q?Arkadiusz=3D20Mi=3DC5=3D9Bkiewicz?=3D <arekm@maven.pl>
Date: Mon, 6 Feb 2017 14:45:15 +0100
Subject: [PATCH] Print text for disassociation reason.
MIME-Version: 1.0
Content-Type: text/plain; charset=3DUTF-8
Content-Transfer-Encoding: 8bit
When disassociation happens only numeric reason is printed
in ieee80211_rx_mgmt_disassoc(). Add text variant, too.
Signed-off-by: Arkadiusz Mi=C5=9Bkiewicz <arekm@maven.pl>
=2D--
net/mac80211/mlme.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 098ce9b179ee..fcf8d0aa66ec 100644
=2D-- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -2801,8 +2801,9 @@ static void ieee80211_rx_mgmt_disassoc(struct ieee802=
11_sub_if_data *sdata,
=20
reason_code =3D le16_to_cpu(mgmt->u.disassoc.reason_code);
=20
=2D sdata_info(sdata, "disassociated from %pM (Reason: %u)\n",
=2D mgmt->sa, reason_code);
+ sdata_info(sdata, "disassociated from %pM (Reason: %u=3D%s)\n",
+ mgmt->sa, reason_code,
+ ieee80211_get_reason_code_string(reason_code));
=20
ieee80211_set_disassoc(sdata, 0, 0, false, NULL);
=20
=2D-=20
2.11.0
=2D-=20
Arkadiusz Mi=C5=9Bkiewicz, arekm / ( maven.pl | pld-linux.org )
^ permalink raw reply
* Re: [PATCH 14/25] iwlwifi: mvm: overwrite skb info later
From: Kalle Valo @ 2017-02-06 14:01 UTC (permalink / raw)
To: Luca Coelho; +Cc: linux-wireless, Johannes Berg, Luca Coelho
In-Reply-To: <20170203143812.7525-15-luca@coelho.fi>
Luca Coelho <luca@coelho.fi> writes:
> From: Johannes Berg <johannes.berg@intel.com>
>
> We don't really need clear the skb's status area nor store the
> dev_cmd into it until we really commit to the frame by handing
> it to the transport - defer those operations until just before
> we do that.
>
> This doesn't entirely fix the bug with frames not getting sent
> out after having been deferred due to DQA, because it doesn't
> restore the info->driver_data[0] place that was already set to
> zero (or another value) by the A-MSDU logic.
>
> Fixes: commit 24afba7690e4 ("iwlwifi: mvm: support bss dynamic alloc/dealloc of queues")
s/commit // :)
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 15/25] iwlwifi: mvm/pcie: adjust A-MSDU tx_cmd length in PCIe
From: Kalle Valo @ 2017-02-06 14:05 UTC (permalink / raw)
To: Luca Coelho; +Cc: linux-wireless, Johannes Berg, Luca Coelho
In-Reply-To: <20170203143812.7525-16-luca@coelho.fi>
Luca Coelho <luca@coelho.fi> writes:
> From: Johannes Berg <johannes.berg@intel.com>
>
> Instead of setting the tx_cmd length in the mvm code, which is
> complicated by the fact that DQA may want to temporarily store
> the SKB on the side, adjust the length in the PCIe code which
> also knows about this since it's responsible for duplicating
> all those headers that are account for in this code.
>
> As the PCIe code already relies on the tx_cmd->len field, this
> doesn't really introduce any new dependencies.
>
> To make this possible we need to move the memcpy() of the TX
> command until after it was updated.
>
> This does even simplify the code though, since the PCIe code
> already does a lot of manipulations to build A-MSDUs correctly
> and changing the length becomes a simple operation to see how
> much was added/removed, rather than predicting it.
>
> Fixes: commit 24afba7690e4 ("iwlwifi: mvm: support bss dynamic alloc/dealloc of queues")
Ditto.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 15/25] iwlwifi: mvm/pcie: adjust A-MSDU tx_cmd length in PCIe
From: Luca Coelho @ 2017-02-06 14:31 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Johannes Berg
In-Reply-To: <87zihz8leo.fsf@codeaurora.org>
On Mon, 2017-02-06 at 16:05 +0200, Kalle Valo wrote:
> Luca Coelho <luca@coelho.fi> writes:
>
> > From: Johannes Berg <johannes.berg@intel.com>
> >
> > Instead of setting the tx_cmd length in the mvm code, which is
> > complicated by the fact that DQA may want to temporarily store
> > the SKB on the side, adjust the length in the PCIe code which
> > also knows about this since it's responsible for duplicating
> > all those headers that are account for in this code.
> >
> > As the PCIe code already relies on the tx_cmd->len field, this
> > doesn't really introduce any new dependencies.
> >
> > To make this possible we need to move the memcpy() of the TX
> > command until after it was updated.
> >
> > This does even simplify the code though, since the PCIe code
> > already does a lot of manipulations to build A-MSDUs correctly
> > and changing the length becomes a simple operation to see how
> > much was added/removed, rather than predicting it.
> >
> > Fixes: commit 24afba7690e4 ("iwlwifi: mvm: support bss dynamic alloc/dealloc of queues")
>
> Ditto.
Oh no! I copied this from another commit, that's why... I'll fix these
two.
And sorry for the trouble (again!)
--
Luca.
^ permalink raw reply
* Re: [PATCH v2 1/2] cfg80211: Add support to set tx power for a station associated
From: Johannes Berg @ 2017-02-06 14:38 UTC (permalink / raw)
To: Ben Greear, Ashok Raj Nagarajan
Cc: Ashok Raj Nagarajan, linux-wireless, ath10k
In-Reply-To: <00887d68-80b7-cf80-e426-e3772d8122f1@candelatech.com>
> You use value '0' to mean set to default values, as far as I can
> tell.
I think you're confusing the internal API and the userspace API - at a
userspace level you have to set NL80211_ATTR_STA_TX_POWER_SETTING to
NL80211_TX_POWER_AUTOMATIC to revert back to defaults, no?
For perfect backwards compatibility we should ignore it if not
supported, but that doesn't really make sense - I think we should
reject it and handle errors elsewhere in the not supported case.
johannes
^ permalink raw reply
* pull-request: wireless-drivers 2017-02-06
From: Kalle Valo @ 2017-02-06 15:19 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, linux-kernel
Hi Dave,
one more fix I still would like to get to 4.10 if possible. Please let
me know if there are any problems.
Kalle
The following changes since commit 2b1d530cb3157f828fcaadd259613f59db3c6d1c:
MAINTAINERS: ath9k-devel is closed (2017-01-28 09:15:50 +0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git tags/wireless-drivers-for-davem-2017-02-06
for you to fetch changes up to 52f5631a4c056ad01682393be56d2be237e81610:
rtlwifi: rtl8192ce: Fix loading of incorrect firmware (2017-01-31 09:05:25 +0200)
----------------------------------------------------------------
wireless-drivers fixes for 4.10
Only one important fix for rtlwifi which fixes a regression introduced
in 4.9 and which caused problems for many users.
----------------------------------------------------------------
Jurij Smakov (1):
rtlwifi: rtl8192ce: Fix loading of incorrect firmware
drivers/net/wireless/realtek/rtlwifi/rtl8192ce/sw.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
^ permalink raw reply
* Re: rtlwifi: rtl8192c_common: "BUG: KASAN: slab-out-of-bounds"
From: Larry Finger @ 2017-02-06 15:45 UTC (permalink / raw)
To: Johannes Berg, Dmitry Osipenko, Chaoming Li
Cc: linux-wireless, Linux Kernel Mailing List
In-Reply-To: <1486376979.14226.9.camel@sipsolutions.net>
On 02/06/2017 04:29 AM, Johannes Berg wrote:
> On Sat, 2017-02-04 at 12:41 -0600, Larry Finger wrote:
>> On 02/04/2017 10:58 AM, Dmitry Osipenko wrote:
>>> Seems the problem is caused by rtl92c_dm_*() casting .priv to
>>> "struct
>>> rtl_pci_priv", while it is "struct rtl_usb_priv".
>>
>> Those routines are shared by rtl8192ce and rtl8192cu, thus we need to
>> make that
>> difference in cast to be immaterial. I think we need to move "struct
>> bt_coexist_info" to the beginning of both rtlpci_priv and
>> rtl_usb_priv. Then it
>> should not matter.
>
> I think you really should consider putting a struct rtl_common into
> that or something, and getting rid of all the casting that causes this
> problem to start with?
The fix you suggest is prepared and will be submitted soon. As it is much more
invasive with ~150 insertions and ~160 deletions, I decided not to have it be
the one that is pushed to all stable kernels from 4.0 onward.
Larry
^ permalink raw reply
* Re: pull-request: mac80211 2017-02-06
From: David Miller @ 2017-02-06 15:55 UTC (permalink / raw)
To: johannes; +Cc: netdev, linux-wireless
In-Reply-To: <20170206083637.31792-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Mon, 6 Feb 2017 09:36:36 +0100
> I know it's super late, but I was travelling last week and the
> whole FILS AEAD thing only played out over the weekend anyway.
> Since the FILS code is all new in this cycle, it'd be good to
> have the fixes, and the others are a bit older but still would
> be good to fix sooner rather than later, I think.
>
> Please pull and let me know if there's any problem.
Ok, pulled, thanks Johannes.
^ permalink raw reply
* MODULE_FIRMWARE() for fallback ucode files?
From: Takashi Iwai @ 2017-02-06 16:12 UTC (permalink / raw)
To: Johannes Berg, Emmanuel Grumbach, Luca Coelho,
Intel Linux Wireless
Cc: linux-wireless, linux-kernel
Hi,
currently iwlwifi driver lists only the latest firmware files in
MODULE_FIRMWARE() although the driver may read other older files.
And this confuses the openSUSE installer, since the installation image
is created based on the module information and copies only the
firmwares listed there. A bug report is found at:
https://bugzilla.suse.com/show_bug.cgi?id=1021082
Would it be better to list up all firmware files? Or how can we
inform user-space which firmware files would be possibly loaded?
In anyway, the current situation is messy. The driver declares the
firmware files that don't exist in the common linux-firmware git
tree. If we list up only the latest API version, we should guarantee
that these files are landed in the official tree before upstreaming.
thanks,
Takashi
^ permalink raw reply
* Re: pull-request: wireless-drivers 2017-02-06
From: David Miller @ 2017-02-06 16:21 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <874m07ny7b.fsf@kamboji.qca.qualcomm.com>
From: Kalle Valo <kvalo@codeaurora.org>
Date: Mon, 06 Feb 2017 17:19:52 +0200
> one more fix I still would like to get to 4.10 if possible. Please let
> me know if there are any problems.
This is fine, pulled, thanks Kalle.
^ 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