* Re: [PATCH v4 5/5] brcmfmac: sdio: Don't tune while the card is off
From: Arend Van Spriel @ 2019-06-17 10:52 UTC (permalink / raw)
To: Douglas Anderson, Ulf Hansson, Kalle Valo, Adrian Hunter
Cc: brcm80211-dev-list.pdl, linux-rockchip, Double Lo, briannorris,
linux-wireless, Naveen Gupta, Madhan Mohan R, mka, Wright Feng,
Chi-Hsien Lin, netdev, brcm80211-dev-list, Franky Lin,
linux-kernel, Hante Meuleman, YueHaibing, David S. Miller
In-Reply-To: <20190613234153.59309-6-dianders@chromium.org>
On 6/14/2019 1:41 AM, Douglas Anderson wrote:
> When Broadcom SDIO cards are idled they go to sleep and a whole
> separate subsystem takes over their SDIO communication. This is the
> Always-On-Subsystem (AOS) and it can't handle tuning requests.
>
> Specifically, as tested on rk3288-veyron-minnie (which reports having
> BCM4354/1 in dmesg), if I force a retune in brcmf_sdio_kso_control()
> when "on = 1" (aka we're transition from sleep to wake) by whacking:
> bus->sdiodev->func1->card->host->need_retune = 1
> ...then I can often see tuning fail. In this case dw_mmc reports "All
> phases bad!"). Note that I don't get 100% failure, presumably because
> sometimes the card itself has already transitioned away from the AOS
> itself by the time we try to wake it up. If I force retuning when "on
> = 0" (AKA force retuning right before sending the command to go to
> sleep) then retuning is always OK.
>
> NOTE: we need _both_ this patch and the patch to avoid triggering
> tuning due to CRC errors in the sleep/wake transition, AKA ("brcmfmac:
> sdio: Disable auto-tuning around commands expected to fail"). Though
> both patches handle issues with Broadcom's AOS, the problems are
> distinct:
> 1. We want to defer (but not ignore) asynchronous (like
> timer-requested) tuning requests till the card is awake. However,
> we want to ignore CRC errors during the transition, we don't want
> to queue deferred tuning request.
> 2. You could imagine that the AOS could implement retuning but we
> could still get errors while transitioning in and out of the AOS.
> Similarly you could imagine a seamless transition into and out of
> the AOS (with no CRC errors) even if the AOS couldn't handle
> tuning.
>
> ALSO NOTE: presumably there is never a desperate need to retune in
> order to wake up the card, since doing so is impossible. Luckily the
> only way the card can get into sleep state is if we had a good enough
> tuning to send it a sleep command, so presumably that "good enough"
> tuning is enough to wake us up, at least with a few retries.
The term "sleep command" is a bit confusing. There actually is a CMD14
defined in the eSD spec, but that is not what we are using (unless we
program the chip to do so) here. It is simply a specific register access
using CMD52.
Apart from that....
Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
>
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
I think the stable version is mostly determined by change in MMC/SDIO so
4.18 as mentioned Adrian seems most sensible. bcm4354 support was
introduced in 3.14 and there were some earlier devices (4335) using same
sleep mechanism.
Regards,
Arend
^ permalink raw reply
* Re: [PATCH v4 3/5] brcmfmac: sdio: Disable auto-tuning around commands expected to fail
From: Arend Van Spriel @ 2019-06-17 10:35 UTC (permalink / raw)
To: Douglas Anderson, Ulf Hansson, Kalle Valo, Adrian Hunter
Cc: brcm80211-dev-list.pdl, linux-rockchip, Double Lo, briannorris,
linux-wireless, Naveen Gupta, Madhan Mohan R, mka, Wright Feng,
Chi-Hsien Lin, netdev, brcm80211-dev-list, Hans de Goede,
Franky Lin, linux-kernel, Hante Meuleman, YueHaibing,
David S. Miller
In-Reply-To: <20190613234153.59309-4-dianders@chromium.org>
On 6/14/2019 1:41 AM, Douglas Anderson wrote:
> There are certain cases, notably when transitioning between sleep and
> active state, when Broadcom SDIO WiFi cards will produce errors on the
> SDIO bus. This is evident from the source code where you can see that
> we try commands in a loop until we either get success or we've tried
> too many times. The comment in the code reinforces this by saying
> "just one write attempt may fail"
>
> Unfortunately these failures sometimes end up causing an "-EILSEQ"
> back to the core which triggers a retuning of the SDIO card and that
> blocks all traffic to the card until it's done.
>
> Let's disable retuning around the commands we expect might fail.
>
> Fixes: bd11e8bd03ca ("mmc: core: Flag re-tuning is needed on CRC errors")
Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
^ permalink raw reply
* Re: [PATCH] mmc: core: Prevent processing SDIO IRQs when the card is suspended
From: Ulf Hansson @ 2019-06-17 9:56 UTC (permalink / raw)
To: Doug Anderson
Cc: Linux MMC List, Adrian Hunter, Brian Norris, Shawn Lin,
Guenter Roeck, Heiko Stuebner, Kalle Valo, linux-wireless, # 4.0+
In-Reply-To: <CAD=FV=Ujb=_jEFMdxLPW6tYwb9DZo5-RZ8BVuyq5DdFQ5jJbQw@mail.gmail.com>
On Fri, 14 Jun 2019 at 17:42, Doug Anderson <dianders@chromium.org> wrote:
>
> Hi,
>
> On Fri, Jun 14, 2019 at 4:56 AM Ulf Hansson <ulf.hansson@linaro.org> wrote:
> >
> > > I was more worried about the safety of mmc_card_set_suspended()
> > > itself. That is:
> > >
> > > #define mmc_card_set_suspended(c) ((c)->state |= MMC_STATE_SUSPENDED)
> > >
> > > ...so it's doing a read-modify-write of "state". Is that safe to do
> > > without any type of locking?
> >
> > In this case, yes I think so.
> >
> > The point is, it really doesn't matter if the reader (work or thread),
> > reads a non-updated value, because the synchronization is managed by
> > the later mmc_claim_host() and the cancel_delayed_work_sync().
>
> If this were just an "int" then perhaps, but this is a bitfield. So
> if someone else updates the bitfield at the same time then we can
> fully clobber their modification or they can clobber ours, right?
>
> task 1: load "state" from memory into CPU register on cpu0
> task 2: load "state" from memory into CPU register on cpu1
> task 1: OR in MMC_CARD_REMOVED
> task 1: write "state" from CPU register on cpu0
> task 2: OR in MMC_STATE_SUSPENDED
> task 2: write "state" from CPU register on cpu1
>
> ...so now we've clobbered MMC_CARD_REMOVED. ...or am I just being
> paranoid here and everything else in "state" is somehow guaranteed to
> not be touched at the same time this function is running?
I understand your concern. It's not obvious by looking at the code,
but yes, there should be no other writing to the "state" at the same
time mmc_sdio_supend() is running.
MMC_CARD_REMOVED for example, is set from _mmc_detect_card_removed(),
but because the detect work (mmc_recan()) has been disabled and the
block device driver has been suspended, it can't be called.
Anyway, perhaps we get reasons to add a lock to the card struct when
going forward, but at this point I think we are fine.
Kind regards
Uffe
^ permalink raw reply
* [PATCH] rt2x00: fix rx queue hang
From: Soeren Moch @ 2019-06-17 9:46 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: Soeren Moch, Helmut Schaa, Kalle Valo, David S. Miller,
linux-wireless, netdev, linux-kernel, stable
Since commit ed194d136769 ("usb: core: remove local_irq_save() around
->complete() handler") the handlers rt2x00usb_interrupt_rxdone() and
rt2x00usb_interrupt_txdone() are not running with interrupts disabled
anymore. So these handlers are not guaranteed to run completely before
workqueue processing starts. So only mark entries ready for workqueue
processing after proper accounting in the dma done queue.
Note that rt2x00usb_work_rxdone() processes all available entries, not
only such for which queue_work() was called.
This fixes a regression on a RT5370 based wifi stick in AP mode, which
suddenly stopped data transmission after some period of heavy load. Also
stopping the hanging hostapd resulted in the error message "ieee80211
phy0: rt2x00queue_flush_queue: Warning - Queue 14 failed to flush".
Other operation modes are probably affected as well, this just was
the used testcase.
Fixes: ed194d136769 ("usb: core: remove local_irq_save() around ->complete() handler")
Cc: Stanislaw Gruszka <sgruszka@redhat.com>
Cc: Helmut Schaa <helmut.schaa@googlemail.com>
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: stable@vger.kernel.org # 4.20+
Signed-off-by: Soeren Moch <smoch@web.de>
---
drivers/net/wireless/ralink/rt2x00/rt2x00dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c b/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c
index 1b08b01db27b..9c102a501ee6 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c
@@ -263,9 +263,9 @@ EXPORT_SYMBOL_GPL(rt2x00lib_dmastart);
void rt2x00lib_dmadone(struct queue_entry *entry)
{
- set_bit(ENTRY_DATA_STATUS_PENDING, &entry->flags);
clear_bit(ENTRY_OWNER_DEVICE_DATA, &entry->flags);
rt2x00queue_index_inc(entry, Q_INDEX_DMA_DONE);
+ set_bit(ENTRY_DATA_STATUS_PENDING, &entry->flags);
}
EXPORT_SYMBOL_GPL(rt2x00lib_dmadone);
--
2.17.1
^ permalink raw reply related
* [PATCH v2] lib80211: use crypto API ccm(aes) transform for CCMP processing
From: Ard Biesheuvel @ 2019-06-17 9:19 UTC (permalink / raw)
To: linux-wireless; +Cc: linux-crypto, herbert, ebiggers, johannes, Ard Biesheuvel
Instead of open coding the CCM aead mode in the driver, and invoking
the AES block cipher block by block, use a ccm(aes) aead transform
which already encapsulates this functionality. This is a cleaner use
of the crypto API, and permits optimized implementations to be used,
which are typically much faster and deal more efficiently with the
SIMD register file, which usually needs to be preserved/restored in
order to use special AES instructions.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
v2: Address lots of style related issues flagged by Eric. Still untested on
actual hardware.
net/wireless/Kconfig | 2 +
net/wireless/lib80211_crypt_ccmp.c | 197 +++++++++-----------
2 files changed, 87 insertions(+), 112 deletions(-)
diff --git a/net/wireless/Kconfig b/net/wireless/Kconfig
index 6310ddede220..cf8ba192249e 100644
--- a/net/wireless/Kconfig
+++ b/net/wireless/Kconfig
@@ -216,6 +216,8 @@ config LIB80211_CRYPT_WEP
config LIB80211_CRYPT_CCMP
tristate
+ select CRYPTO_AES
+ select CRYPTO_CCM
config LIB80211_CRYPT_TKIP
tristate
diff --git a/net/wireless/lib80211_crypt_ccmp.c b/net/wireless/lib80211_crypt_ccmp.c
index 55214fe925b2..7297646c084a 100644
--- a/net/wireless/lib80211_crypt_ccmp.c
+++ b/net/wireless/lib80211_crypt_ccmp.c
@@ -26,6 +26,7 @@
#include <linux/ieee80211.h>
#include <linux/crypto.h>
+#include <crypto/aead.h>
#include <net/lib80211.h>
@@ -52,20 +53,13 @@ struct lib80211_ccmp_data {
int key_idx;
- struct crypto_cipher *tfm;
+ struct crypto_aead *tfm;
/* scratch buffers for virt_to_page() (crypto API) */
- u8 tx_b0[AES_BLOCK_LEN], tx_b[AES_BLOCK_LEN],
- tx_e[AES_BLOCK_LEN], tx_s0[AES_BLOCK_LEN];
- u8 rx_b0[AES_BLOCK_LEN], rx_b[AES_BLOCK_LEN], rx_a[AES_BLOCK_LEN];
+ u8 tx_aad[2 * AES_BLOCK_LEN];
+ u8 rx_aad[2 * AES_BLOCK_LEN];
};
-static inline void lib80211_ccmp_aes_encrypt(struct crypto_cipher *tfm,
- const u8 pt[16], u8 ct[16])
-{
- crypto_cipher_encrypt_one(tfm, ct, pt);
-}
-
static void *lib80211_ccmp_init(int key_idx)
{
struct lib80211_ccmp_data *priv;
@@ -75,7 +69,7 @@ static void *lib80211_ccmp_init(int key_idx)
goto fail;
priv->key_idx = key_idx;
- priv->tfm = crypto_alloc_cipher("aes", 0, 0);
+ priv->tfm = crypto_alloc_aead("ccm(aes)", 0, CRYPTO_ALG_ASYNC);
if (IS_ERR(priv->tfm)) {
priv->tfm = NULL;
goto fail;
@@ -86,7 +80,7 @@ static void *lib80211_ccmp_init(int key_idx)
fail:
if (priv) {
if (priv->tfm)
- crypto_free_cipher(priv->tfm);
+ crypto_free_aead(priv->tfm);
kfree(priv);
}
@@ -97,25 +91,16 @@ static void lib80211_ccmp_deinit(void *priv)
{
struct lib80211_ccmp_data *_priv = priv;
if (_priv && _priv->tfm)
- crypto_free_cipher(_priv->tfm);
+ crypto_free_aead(_priv->tfm);
kfree(priv);
}
-static inline void xor_block(u8 * b, u8 * a, size_t len)
-{
- int i;
- for (i = 0; i < len; i++)
- b[i] ^= a[i];
-}
-
-static void ccmp_init_blocks(struct crypto_cipher *tfm,
- struct ieee80211_hdr *hdr,
- u8 * pn, size_t dlen, u8 * b0, u8 * auth, u8 * s0)
+static int ccmp_init_iv_and_aad(const struct ieee80211_hdr *hdr,
+ const u8 *pn, u8 *iv, u8 *aad)
{
u8 *pos, qc = 0;
size_t aad_len;
int a4_included, qc_included;
- u8 aad[2 * AES_BLOCK_LEN];
a4_included = ieee80211_has_a4(hdr->frame_control);
qc_included = ieee80211_is_data_qos(hdr->frame_control);
@@ -131,17 +116,19 @@ static void ccmp_init_blocks(struct crypto_cipher *tfm,
aad_len += 2;
}
- /* CCM Initial Block:
- * Flag (Include authentication header, M=3 (8-octet MIC),
- * L=1 (2-octet Dlen))
- * Nonce: 0x00 | A2 | PN
- * Dlen */
- b0[0] = 0x59;
- b0[1] = qc;
- memcpy(b0 + 2, hdr->addr2, ETH_ALEN);
- memcpy(b0 + 8, pn, CCMP_PN_LEN);
- b0[14] = (dlen >> 8) & 0xff;
- b0[15] = dlen & 0xff;
+ /* In CCM, the initial vectors (IV) used for CTR mode encryption and CBC
+ * mode authentication are not allowed to collide, yet both are derived
+ * from the same vector. We only set L := 1 here to indicate that the
+ * data size can be represented in (L+1) bytes. The CCM layer will take
+ * care of storing the data length in the top (L+1) bytes and setting
+ * and clearing the other bits as is required to derive the two IVs.
+ */
+ iv[0] = 0x1;
+
+ /* Nonce: QC | A2 | PN */
+ iv[1] = qc;
+ memcpy(iv + 2, hdr->addr2, ETH_ALEN);
+ memcpy(iv + 8, pn, CCMP_PN_LEN);
/* AAD:
* FC with bits 4..6 and 11..13 masked to zero; 14 is always one
@@ -151,31 +138,20 @@ static void ccmp_init_blocks(struct crypto_cipher *tfm,
* QC (if present)
*/
pos = (u8 *) hdr;
- aad[0] = 0; /* aad_len >> 8 */
- aad[1] = aad_len & 0xff;
- aad[2] = pos[0] & 0x8f;
- aad[3] = pos[1] & 0xc7;
- memcpy(aad + 4, hdr->addr1, 3 * ETH_ALEN);
+ aad[0] = pos[0] & 0x8f;
+ aad[1] = pos[1] & 0xc7;
+ memcpy(aad + 2, hdr->addr1, 3 * ETH_ALEN);
pos = (u8 *) & hdr->seq_ctrl;
- aad[22] = pos[0] & 0x0f;
- aad[23] = 0; /* all bits masked */
- memset(aad + 24, 0, 8);
+ aad[20] = pos[0] & 0x0f;
+ aad[21] = 0; /* all bits masked */
+ memset(aad + 22, 0, 8);
if (a4_included)
- memcpy(aad + 24, hdr->addr4, ETH_ALEN);
+ memcpy(aad + 22, hdr->addr4, ETH_ALEN);
if (qc_included) {
- aad[a4_included ? 30 : 24] = qc;
+ aad[a4_included ? 28 : 22] = qc;
/* rest of QC masked */
}
-
- /* Start with the first block and AAD */
- lib80211_ccmp_aes_encrypt(tfm, b0, auth);
- xor_block(auth, aad, AES_BLOCK_LEN);
- lib80211_ccmp_aes_encrypt(tfm, auth, auth);
- xor_block(auth, &aad[AES_BLOCK_LEN], AES_BLOCK_LEN);
- lib80211_ccmp_aes_encrypt(tfm, auth, auth);
- b0[0] &= 0x07;
- b0[14] = b0[15] = 0;
- lib80211_ccmp_aes_encrypt(tfm, b0, s0);
+ return aad_len;
}
static int lib80211_ccmp_hdr(struct sk_buff *skb, int hdr_len,
@@ -218,13 +194,13 @@ static int lib80211_ccmp_hdr(struct sk_buff *skb, int hdr_len,
static int lib80211_ccmp_encrypt(struct sk_buff *skb, int hdr_len, void *priv)
{
struct lib80211_ccmp_data *key = priv;
- int data_len, i, blocks, last, len;
- u8 *pos, *mic;
struct ieee80211_hdr *hdr;
- u8 *b0 = key->tx_b0;
- u8 *b = key->tx_b;
- u8 *e = key->tx_e;
- u8 *s0 = key->tx_s0;
+ struct aead_request *req;
+ struct scatterlist sg[2];
+ u8 *aad = key->tx_aad;
+ u8 iv[AES_BLOCK_LEN];
+ int len, data_len, aad_len;
+ int ret;
if (skb_tailroom(skb) < CCMP_MIC_LEN || skb->len < hdr_len)
return -1;
@@ -234,31 +210,28 @@ static int lib80211_ccmp_encrypt(struct sk_buff *skb, int hdr_len, void *priv)
if (len < 0)
return -1;
- pos = skb->data + hdr_len + CCMP_HDR_LEN;
+ req = aead_request_alloc(key->tfm, GFP_ATOMIC);
+ if (!req)
+ return -ENOMEM;
+
hdr = (struct ieee80211_hdr *)skb->data;
- ccmp_init_blocks(key->tfm, hdr, key->tx_pn, data_len, b0, b, s0);
-
- blocks = DIV_ROUND_UP(data_len, AES_BLOCK_LEN);
- last = data_len % AES_BLOCK_LEN;
-
- for (i = 1; i <= blocks; i++) {
- len = (i == blocks && last) ? last : AES_BLOCK_LEN;
- /* Authentication */
- xor_block(b, pos, len);
- lib80211_ccmp_aes_encrypt(key->tfm, b, b);
- /* Encryption, with counter */
- b0[14] = (i >> 8) & 0xff;
- b0[15] = i & 0xff;
- lib80211_ccmp_aes_encrypt(key->tfm, b0, e);
- xor_block(pos, e, len);
- pos += len;
- }
+ aad_len = ccmp_init_iv_and_aad(hdr, key->tx_pn, iv, aad);
- mic = skb_put(skb, CCMP_MIC_LEN);
- for (i = 0; i < CCMP_MIC_LEN; i++)
- mic[i] = b[i] ^ s0[i];
+ skb_put(skb, CCMP_MIC_LEN);
- return 0;
+ sg_init_table(sg, 2);
+ sg_set_buf(&sg[0], aad, aad_len);
+ sg_set_buf(&sg[1], skb->data + hdr_len + CCMP_HDR_LEN,
+ data_len + CCMP_MIC_LEN);
+
+ aead_request_set_callback(req, 0, NULL, NULL);
+ aead_request_set_ad(req, aad_len);
+ aead_request_set_crypt(req, sg, sg, data_len, iv);
+
+ ret = crypto_aead_encrypt(req);
+ aead_request_free(req);
+
+ return ret;
}
/*
@@ -287,13 +260,13 @@ static int lib80211_ccmp_decrypt(struct sk_buff *skb, int hdr_len, void *priv)
struct lib80211_ccmp_data *key = priv;
u8 keyidx, *pos;
struct ieee80211_hdr *hdr;
- u8 *b0 = key->rx_b0;
- u8 *b = key->rx_b;
- u8 *a = key->rx_a;
+ struct aead_request *req;
+ struct scatterlist sg[2];
+ u8 *aad = key->rx_aad;
+ u8 iv[AES_BLOCK_LEN];
u8 pn[6];
- int i, blocks, last, len;
- size_t data_len = skb->len - hdr_len - CCMP_HDR_LEN - CCMP_MIC_LEN;
- u8 *mic = skb->data + skb->len - CCMP_MIC_LEN;
+ int aad_len, ret;
+ size_t data_len = skb->len - hdr_len - CCMP_HDR_LEN;
if (skb->len < hdr_len + CCMP_HDR_LEN + CCMP_MIC_LEN) {
key->dot11RSNAStatsCCMPFormatErrors++;
@@ -341,28 +314,26 @@ static int lib80211_ccmp_decrypt(struct sk_buff *skb, int hdr_len, void *priv)
return -4;
}
- ccmp_init_blocks(key->tfm, hdr, pn, data_len, b0, a, b);
- xor_block(mic, b, CCMP_MIC_LEN);
-
- blocks = DIV_ROUND_UP(data_len, AES_BLOCK_LEN);
- last = data_len % AES_BLOCK_LEN;
-
- for (i = 1; i <= blocks; i++) {
- len = (i == blocks && last) ? last : AES_BLOCK_LEN;
- /* Decrypt, with counter */
- b0[14] = (i >> 8) & 0xff;
- b0[15] = i & 0xff;
- lib80211_ccmp_aes_encrypt(key->tfm, b0, b);
- xor_block(pos, b, len);
- /* Authentication */
- xor_block(a, pos, len);
- lib80211_ccmp_aes_encrypt(key->tfm, a, a);
- pos += len;
- }
+ req = aead_request_alloc(key->tfm, GFP_ATOMIC);
+ if (!req)
+ return -ENOMEM;
- if (memcmp(mic, a, CCMP_MIC_LEN) != 0) {
- net_dbg_ratelimited("CCMP: decrypt failed: STA=%pM\n",
- hdr->addr2);
+ aad_len = ccmp_init_iv_and_aad(hdr, pn, iv, aad);
+
+ sg_init_table(sg, 2);
+ sg_set_buf(&sg[0], aad, aad_len);
+ sg_set_buf(&sg[1], pos, data_len);
+
+ aead_request_set_callback(req, 0, NULL, NULL);
+ aead_request_set_ad(req, aad_len);
+ aead_request_set_crypt(req, sg, sg, data_len, iv);
+
+ ret = crypto_aead_decrypt(req);
+ aead_request_free(req);
+
+ if (ret) {
+ net_dbg_ratelimited("CCMP: decrypt failed: STA=%pM (%d)\n",
+ hdr->addr2, ret);
key->dot11RSNAStatsCCMPDecryptErrors++;
return -5;
}
@@ -381,7 +352,7 @@ static int lib80211_ccmp_set_key(void *key, int len, u8 * seq, void *priv)
{
struct lib80211_ccmp_data *data = priv;
int keyidx;
- struct crypto_cipher *tfm = data->tfm;
+ struct crypto_aead *tfm = data->tfm;
keyidx = data->key_idx;
memset(data, 0, sizeof(*data));
@@ -398,7 +369,9 @@ static int lib80211_ccmp_set_key(void *key, int len, u8 * seq, void *priv)
data->rx_pn[4] = seq[1];
data->rx_pn[5] = seq[0];
}
- crypto_cipher_setkey(data->tfm, data->key, CCMP_TK_LEN);
+ if (crypto_aead_setauthsize(data->tfm, CCMP_MIC_LEN) ||
+ crypto_aead_setkey(data->tfm, data->key, CCMP_TK_LEN))
+ return -1;
} else if (len == 0)
data->key_set = 0;
else
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v4 4/5] mmc: core: Add sdio_retune_hold_now() and sdio_retune_release()
From: Adrian Hunter @ 2019-06-17 8:46 UTC (permalink / raw)
To: Doug Anderson, Ulf Hansson, Arend van Spriel
Cc: Kalle Valo, brcm80211-dev-list.pdl, open list:ARM/Rockchip SoC...,
Double Lo, Brian Norris, linux-wireless, Naveen Gupta,
Madhan Mohan R, Matthias Kaehlcke, Wright Feng, Chi-Hsien Lin,
netdev, brcm80211-dev-list, linux-mmc@vger.kernel.org,
Linux Kernel Mailing List, Thomas Gleixner, Greg Kroah-Hartman,
Avri Altman
In-Reply-To: <CAD=FV=Wuj=gANR2im_o4ZnoLEB+U6FqzKe4noLdQyi1vw+K2xw@mail.gmail.com>
On 14/06/19 7:38 PM, Doug Anderson wrote:
> Hi,
>
> On Fri, Jun 14, 2019 at 5:10 AM Ulf Hansson <ulf.hansson@linaro.org> wrote:
>>
>> On Fri, 14 Jun 2019 at 01:42, Douglas Anderson <dianders@chromium.org> wrote:
>>>
>>> We want SDIO drivers to be able to temporarily stop retuning when the
>>> driver knows that the SDIO card is not in a state where retuning will
>>> work (maybe because the card is asleep). We'll move the relevant
>>> functions to a place where drivers can call them.
>>>
>>> Signed-off-by: Douglas Anderson <dianders@chromium.org>
>>
>> This looks good to me.
>>
>> BTW, seems like this series is best funneled via my mmc tree, no? In
>> such case, I need acks for the brcmfmac driver patches.
>
> For patch #1 I think it could just go in directly to the wireless
> tree. It should be fine to land the rest of the patches separately.
>
> For patch #2 - #5 then what you say makes sense to me. I suppose
> you'd want at least a Reviewed-by from Arend and an Ack from Kalle on
> the Broadcom patches?
>
> I'd also suggest that we Cc stable explicitly when applying. That's
> easy for #2 and #3 since they have a Fixes tag. For #4 and #5 I guess
> the question is how far back to go. Maybe Adrian has an opinion here
> since I think he's the one who experienced these problems.
V4 seemed to apply cleanly back to v4.18
^ permalink raw reply
* [PATCH v2] wireless: airo: switch to skcipher interface
From: Ard Biesheuvel @ 2019-06-17 8:43 UTC (permalink / raw)
To: linux-wireless
Cc: linux-crypto, herbert, ebiggers, kvalo, johannes, linux,
Ard Biesheuvel
The AIRO driver applies a ctr(aes) on a buffer of considerable size
(2400 bytes), and instead of invoking the crypto API to handle this
in its entirety, it open codes the counter manipulation and invokes
the AES block cipher directly.
Let's fix this, by switching to the sync skcipher API instead.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
v2: - fix Kconfig dependencies
- zero the output buffer and use it as input instead of the zero page
drivers/net/wireless/cisco/Kconfig | 2 +
drivers/net/wireless/cisco/airo.c | 57 ++++++++++----------
2 files changed, 29 insertions(+), 30 deletions(-)
diff --git a/drivers/net/wireless/cisco/Kconfig b/drivers/net/wireless/cisco/Kconfig
index 7329830ed7cc..01e173ede894 100644
--- a/drivers/net/wireless/cisco/Kconfig
+++ b/drivers/net/wireless/cisco/Kconfig
@@ -17,6 +17,7 @@ config AIRO
depends on CFG80211 && ISA_DMA_API && (PCI || BROKEN)
select WIRELESS_EXT
select CRYPTO
+ select CRYPTO_BLKCIPHER
select WEXT_SPY
select WEXT_PRIV
---help---
@@ -40,6 +41,7 @@ config AIRO_CS
select WEXT_PRIV
select CRYPTO
select CRYPTO_AES
+ select CRYPTO_CTR
---help---
This is the standard Linux driver to support Cisco/Aironet PCMCIA
802.11 wireless cards. This driver is the same as the Aironet
diff --git a/drivers/net/wireless/cisco/airo.c b/drivers/net/wireless/cisco/airo.c
index 3f5a14112c6b..9342ffbe1e81 100644
--- a/drivers/net/wireless/cisco/airo.c
+++ b/drivers/net/wireless/cisco/airo.c
@@ -49,6 +49,9 @@
#include <linux/kthread.h>
#include <linux/freezer.h>
+#include <crypto/aes.h>
+#include <crypto/skcipher.h>
+
#include <net/cfg80211.h>
#include <net/iw_handler.h>
@@ -951,7 +954,7 @@ typedef struct {
} mic_statistics;
typedef struct {
- u32 coeff[((EMMH32_MSGLEN_MAX)+3)>>2];
+ __be32 coeff[((EMMH32_MSGLEN_MAX)+3)>>2];
u64 accum; // accumulated mic, reduced to u32 in final()
int position; // current position (byte offset) in message
union {
@@ -1216,7 +1219,7 @@ struct airo_info {
struct iw_spy_data spy_data;
struct iw_public_data wireless_data;
/* MIC stuff */
- struct crypto_cipher *tfm;
+ struct crypto_sync_skcipher *tfm;
mic_module mod[2];
mic_statistics micstats;
HostRxDesc rxfids[MPI_MAX_FIDS]; // rx/tx/config MPI350 descriptors
@@ -1291,14 +1294,14 @@ static int flashrestart(struct airo_info *ai,struct net_device *dev);
static int RxSeqValid (struct airo_info *ai,miccntx *context,int mcast,u32 micSeq);
static void MoveWindow(miccntx *context, u32 micSeq);
static void emmh32_setseed(emmh32_context *context, u8 *pkey, int keylen,
- struct crypto_cipher *tfm);
+ struct crypto_sync_skcipher *tfm);
static void emmh32_init(emmh32_context *context);
static void emmh32_update(emmh32_context *context, u8 *pOctets, int len);
static void emmh32_final(emmh32_context *context, u8 digest[4]);
static int flashpchar(struct airo_info *ai,int byte,int dwelltime);
static void age_mic_context(miccntx *cur, miccntx *old, u8 *key, int key_len,
- struct crypto_cipher *tfm)
+ struct crypto_sync_skcipher *tfm)
{
/* If the current MIC context is valid and its key is the same as
* the MIC register, there's nothing to do.
@@ -1359,7 +1362,7 @@ static int micsetup(struct airo_info *ai) {
int i;
if (ai->tfm == NULL)
- ai->tfm = crypto_alloc_cipher("aes", 0, 0);
+ ai->tfm = crypto_alloc_sync_skcipher("ctr(aes)", 0, 0);
if (IS_ERR(ai->tfm)) {
airo_print_err(ai->dev->name, "failed to load transform for AES");
@@ -1624,37 +1627,31 @@ static void MoveWindow(miccntx *context, u32 micSeq)
/* mic accumulate */
#define MIC_ACCUM(val) \
- context->accum += (u64)(val) * context->coeff[coeff_position++];
-
-static unsigned char aes_counter[16];
+ context->accum += (u64)(val) * be32_to_cpu(context->coeff[coeff_position++]);
/* expand the key to fill the MMH coefficient array */
static void emmh32_setseed(emmh32_context *context, u8 *pkey, int keylen,
- struct crypto_cipher *tfm)
+ struct crypto_sync_skcipher *tfm)
{
/* take the keying material, expand if necessary, truncate at 16-bytes */
/* run through AES counter mode to generate context->coeff[] */
- int i,j;
- u32 counter;
- u8 *cipher, plain[16];
-
- crypto_cipher_setkey(tfm, pkey, 16);
- counter = 0;
- for (i = 0; i < ARRAY_SIZE(context->coeff); ) {
- aes_counter[15] = (u8)(counter >> 0);
- aes_counter[14] = (u8)(counter >> 8);
- aes_counter[13] = (u8)(counter >> 16);
- aes_counter[12] = (u8)(counter >> 24);
- counter++;
- memcpy (plain, aes_counter, 16);
- crypto_cipher_encrypt_one(tfm, plain, plain);
- cipher = plain;
- for (j = 0; (j < 16) && (i < ARRAY_SIZE(context->coeff)); ) {
- context->coeff[i++] = ntohl(*(__be32 *)&cipher[j]);
- j += 4;
- }
- }
+ SYNC_SKCIPHER_REQUEST_ON_STACK(req, tfm);
+ struct scatterlist sg;
+ u8 iv[AES_BLOCK_SIZE] = {};
+ int ret;
+
+ crypto_sync_skcipher_setkey(tfm, pkey, 16);
+
+ memset(context->coeff, 0, sizeof(context->coeff));
+ sg_init_one(&sg, context->coeff, sizeof(context->coeff));
+
+ skcipher_request_set_sync_tfm(req, tfm);
+ skcipher_request_set_callback(req, 0, NULL, NULL);
+ skcipher_request_set_crypt(req, &sg, &sg, sizeof(context->coeff), iv);
+
+ ret = crypto_skcipher_encrypt(req);
+ WARN_ON_ONCE(ret);
}
/* prepare for calculation of a new mic */
@@ -2415,7 +2412,7 @@ void stop_airo_card( struct net_device *dev, int freeres )
ai->shared, ai->shared_dma);
}
}
- crypto_free_cipher(ai->tfm);
+ crypto_free_sync_skcipher(ai->tfm);
del_airo_dev(ai);
free_netdev( dev );
}
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v4 4/5] mmc: core: Add sdio_retune_hold_now() and sdio_retune_release()
From: Adrian Hunter @ 2019-06-17 8:34 UTC (permalink / raw)
To: Douglas Anderson, Ulf Hansson, Kalle Valo, Arend van Spriel
Cc: brcm80211-dev-list.pdl, linux-rockchip, Double Lo, briannorris,
linux-wireless, Naveen Gupta, Madhan Mohan R, mka, Wright Feng,
Chi-Hsien Lin, netdev, brcm80211-dev-list, linux-mmc,
linux-kernel, Thomas Gleixner, Greg Kroah-Hartman, Avri Altman
In-Reply-To: <20190613234153.59309-5-dianders@chromium.org>
On 14/06/19 2:41 AM, Douglas Anderson wrote:
> We want SDIO drivers to be able to temporarily stop retuning when the
> driver knows that the SDIO card is not in a state where retuning will
> work (maybe because the card is asleep). We'll move the relevant
> functions to a place where drivers can call them.
>
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
> ---
>
> Changes in v4:
> - Moved retune hold/release to SDIO API (Adrian).
>
> Changes in v3:
> - ("mmc: core: Export mmc_retune_hold_now() mmc_retune_release()") new for v3.
>
> Changes in v2: None
>
> drivers/mmc/core/sdio_io.c | 40 +++++++++++++++++++++++++++++++++++
> include/linux/mmc/sdio_func.h | 3 +++
> 2 files changed, 43 insertions(+)
>
> diff --git a/drivers/mmc/core/sdio_io.c b/drivers/mmc/core/sdio_io.c
> index f822a9630b0e..1b6fe737bd72 100644
> --- a/drivers/mmc/core/sdio_io.c
> +++ b/drivers/mmc/core/sdio_io.c
> @@ -15,6 +15,7 @@
> #include "sdio_ops.h"
> #include "core.h"
> #include "card.h"
> +#include "host.h"
>
> /**
> * sdio_claim_host - exclusively claim a bus for a certain SDIO function
> @@ -770,3 +771,42 @@ void sdio_retune_crc_enable(struct sdio_func *func)
> func->card->host->retune_crc_disable = false;
> }
> EXPORT_SYMBOL_GPL(sdio_retune_crc_enable);
> +
> +/**
> + * sdio_retune_hold_now - start deferring retuning requests till release
> + * @func: SDIO function attached to host
> + *
> + * This function can be called if it's currently a bad time to do
> + * a retune of the SDIO card. Retune requests made during this time
> + * will be held and we'll actually do the retune sometime after the
> + * release.
> + *
> + * This function could be useful if an SDIO card is in a power state
> + * where it can respond to a small subset of commands that doesn't
> + * include the retuning command. Care should be taken when using
> + * this function since (presumably) the retuning request we might be
> + * deferring was made for a good reason.
> + *
> + * This function should be called while the host is claimed.
> + */
> +void sdio_retune_hold_now(struct sdio_func *func)
> +{
> + mmc_retune_hold_now(func->card->host);
> +}
> +EXPORT_SYMBOL_GPL(sdio_retune_hold_now);
> +
> +/**
> + * sdio_retune_release - signal that it's OK to retune now
> + * @func: SDIO function attached to host
> + *
> + * This is the complement to sdio_retune_hold_now(). Calling this
> + * function won't make a retune happen right away but will allow
> + * them to be scheduled normally.
> + *
> + * This function should be called while the host is claimed.
> + */
> +void sdio_retune_release(struct sdio_func *func)
> +{
> + mmc_retune_release(func->card->host);
> +}
> +EXPORT_SYMBOL_GPL(sdio_retune_release);
> diff --git a/include/linux/mmc/sdio_func.h b/include/linux/mmc/sdio_func.h
> index 4820e6d09dac..5a177f7a83c3 100644
> --- a/include/linux/mmc/sdio_func.h
> +++ b/include/linux/mmc/sdio_func.h
> @@ -170,4 +170,7 @@ extern int sdio_set_host_pm_flags(struct sdio_func *func, mmc_pm_flag_t flags);
> extern void sdio_retune_crc_disable(struct sdio_func *func);
> extern void sdio_retune_crc_enable(struct sdio_func *func);
>
> +extern void sdio_retune_hold_now(struct sdio_func *func);
> +extern void sdio_retune_release(struct sdio_func *func);
> +
> #endif /* LINUX_MMC_SDIO_FUNC_H */
>
^ permalink raw reply
* Re: [PATCH v4 3/5] brcmfmac: sdio: Disable auto-tuning around commands expected to fail
From: Adrian Hunter @ 2019-06-17 8:33 UTC (permalink / raw)
To: Douglas Anderson, Ulf Hansson, Kalle Valo, Arend van Spriel
Cc: brcm80211-dev-list.pdl, linux-rockchip, Double Lo, briannorris,
linux-wireless, Naveen Gupta, Madhan Mohan R, mka, Wright Feng,
Chi-Hsien Lin, netdev, brcm80211-dev-list, Hans de Goede,
Franky Lin, linux-kernel, Hante Meuleman, YueHaibing,
David S. Miller
In-Reply-To: <20190613234153.59309-4-dianders@chromium.org>
On 14/06/19 2:41 AM, Douglas Anderson wrote:
> There are certain cases, notably when transitioning between sleep and
> active state, when Broadcom SDIO WiFi cards will produce errors on the
> SDIO bus. This is evident from the source code where you can see that
> we try commands in a loop until we either get success or we've tried
> too many times. The comment in the code reinforces this by saying
> "just one write attempt may fail"
>
> Unfortunately these failures sometimes end up causing an "-EILSEQ"
> back to the core which triggers a retuning of the SDIO card and that
> blocks all traffic to the card until it's done.
>
> Let's disable retuning around the commands we expect might fail.
>
> Fixes: bd11e8bd03ca ("mmc: core: Flag re-tuning is needed on CRC errors")
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
> ---
>
> Changes in v4:
> - Adjust to API rename (Adrian, Ulf).
>
> Changes in v3:
> - Expect errors for all of brcmf_sdio_kso_control() (Adrian).
>
> Changes in v2: None
>
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> index 4a750838d8cd..ee76593259a7 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> @@ -667,6 +667,8 @@ brcmf_sdio_kso_control(struct brcmf_sdio *bus, bool on)
>
> brcmf_dbg(TRACE, "Enter: on=%d\n", on);
>
> + sdio_retune_crc_disable(bus->sdiodev->func1);
> +
> wr_val = (on << SBSDIO_FUNC1_SLEEPCSR_KSO_SHIFT);
> /* 1st KSO write goes to AOS wake up core if device is asleep */
> brcmf_sdiod_writeb(bus->sdiodev, SBSDIO_FUNC1_SLEEPCSR, wr_val, &err);
> @@ -727,6 +729,8 @@ brcmf_sdio_kso_control(struct brcmf_sdio *bus, bool on)
> if (try_cnt > MAX_KSO_ATTEMPTS)
> brcmf_err("max tries: rd_val=0x%x err=%d\n", rd_val, err);
>
> + sdio_retune_crc_enable(bus->sdiodev->func1);
> +
> return err;
> }
>
>
^ permalink raw reply
* Re: use exact allocation for dma coherent memory
From: Christoph Hellwig @ 2019-06-17 8:33 UTC (permalink / raw)
To: Dan Carpenter
Cc: Christoph Hellwig, Maarten Lankhorst, Maxime Ripard, Sean Paul,
David Airlie, Daniel Vetter, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Ian Abbott, H Hartley Sweeten, devel, linux-s390,
Intel Linux Wireless, linux-rdma, netdev, intel-gfx,
linux-wireless, linux-kernel, dri-devel, linux-mm, iommu,
moderated list:ARM PORT, linux-media
In-Reply-To: <20190617082148.GF28859@kadam>
> drivers/infiniband/hw/cxgb4/qp.c
> 129 static int alloc_host_sq(struct c4iw_rdev *rdev, struct t4_sq *sq)
> 130 {
> 131 sq->queue = dma_alloc_coherent(&(rdev->lldi.pdev->dev), sq->memsize,
> 132 &(sq->dma_addr), GFP_KERNEL);
> 133 if (!sq->queue)
> 134 return -ENOMEM;
> 135 sq->phys_addr = virt_to_phys(sq->queue);
> 136 dma_unmap_addr_set(sq, mapping, sq->dma_addr);
> 137 return 0;
> 138 }
>
> Is this a bug?
Yes. This will blow up badly on many platforms, as sq->queue
might be vmapped, ioremapped, come from a pool without page backing.
^ permalink raw reply
* Re: [PATCH] wireless: airo: switch to skcipher interface
From: Ard Biesheuvel @ 2019-06-17 8:32 UTC (permalink / raw)
To: Eric Biggers
Cc: <linux-wireless@vger.kernel.org>, Kalle Valo,
open list:HARDWARE RANDOM NUMBER GENERATOR CORE, linux,
Herbert Xu
In-Reply-To: <20190616194322.GC923@sol.localdomain>
On Sun, 16 Jun 2019 at 21:43, Eric Biggers <ebiggers@kernel.org> wrote:
>
> On Sun, Jun 16, 2019 at 09:03:58PM +0200, Ard Biesheuvel wrote:
> > >
> > > Otherwise this patch looks correct to me.
> > >
> > > The actual crypto in this driver, on the other hand, looks very outdated and
> > > broken. Apparently it's implementing some Cisco proprietary extension to WEP
> > > that uses a universal hashing based MAC, where the hash key is generated from
> > > AES-CTR. But the MAC is only 32 bits, and the universal hash (MMH) is
> > > implemented incorrectly: there's an off-by-one error in emmh32_final() in the
> > > code that is supposed to be an optimized version of 'sum % ((1ULL << 32) + 15)'.
> > >
> >
> > I stared at that code for a bit, and I don't see the problem.
> >
>
> I'm fairly certain that the line:
>
> if (utmp > 0x10000000fLL)
>
> is supposed to be:
>
> if (utmp >= 0x10000000fLL)
>
Ah yes, I see what you mean. 0x10000000f % 0x10000000f == 0 not 15
(after truncation). So yes, that is definitely a bug.
> Since it's doing mod 0x10000000f. It's supposed to be an optimized
> implementation of 'val = (u32)(context->accum % 0x10000000f)' where 0x10000000f
> is the prime number 2^32 + 15. It's meant to be the MMH algorithm: Section 3.2
> of https://link.springer.com/content/pdf/10.1007/BFb0052345.pdf. But there are
> values of 'accum' where it gives the wrong result, e.g. 14137323879880455377.
>
> Possibly this is a bug in the Cisco MIC protocol itself so can't be fixed.
>
Highly unlikely. But also highly irrelevant :-)
> > > Do we know whether anyone is actually using this, or is this just another old
> > > driver that's sitting around unused?
> > >
> >
> > Excellent question. I take it this is pre-802.11b hardware, and so
> > even the OpenWRT people are unlikely to still be using this.
>
I'd be fine with dropping this driver. I am just trying to get rid of
(ab)use of the crypto cipher interface, so either we change it or we
drop it.
^ permalink raw reply
* Re: [PATCH v4 2/5] mmc: core: API to temporarily disable retuning for SDIO CRC errors
From: Adrian Hunter @ 2019-06-17 8:30 UTC (permalink / raw)
To: Douglas Anderson, Ulf Hansson, Kalle Valo, Arend van Spriel
Cc: brcm80211-dev-list.pdl, linux-rockchip, Double Lo, briannorris,
linux-wireless, Naveen Gupta, Madhan Mohan R, mka, Wright Feng,
Chi-Hsien Lin, netdev, brcm80211-dev-list, Jiong Wu,
Ritesh Harjani, Allison Randal, linux-mmc, linux-kernel,
Thomas Gleixner, Greg Kroah-Hartman, Shawn Lin, Wolfram Sang,
Avri Altman
In-Reply-To: <20190613234153.59309-3-dianders@chromium.org>
On 14/06/19 2:41 AM, Douglas Anderson wrote:
> Normally when the MMC core sees an "-EILSEQ" error returned by a host
> controller then it will trigger a retuning of the card. This is
> generally a good idea.
>
> However, if a command is expected to sometimes cause transfer errors
> then these transfer errors shouldn't cause a re-tuning. This
> re-tuning will be a needless waste of time. One example case where a
> transfer is expected to cause errors is when transitioning between
> idle (sometimes referred to as "sleep" in Broadcom code) and active
> state on certain Broadcom WiFi SDIO cards. Specifically if the card
> was already transitioning between states when the command was sent it
> could cause an error on the SDIO bus.
>
> Let's add an API that the SDIO function drivers can call that will
> temporarily disable the auto-tuning functionality. Then we can add a
> call to this in the Broadcom WiFi driver and any other driver that
> might have similar needs.
>
> NOTE: this makes the assumption that the card is already tuned well
> enough that it's OK to disable the auto-retuning during one of these
> error-prone situations. Presumably the driver code performing the
> error-prone transfer knows how to recover / retry from errors. ...and
> after we can get back to a state where transfers are no longer
> error-prone then we can enable the auto-retuning again. If we truly
> find ourselves in a case where the card needs to be retuned sometimes
> to handle one of these error-prone transfers then we can always try a
> few transfers first without auto-retuning and then re-try with
> auto-retuning if the first few fail.
>
> Without this change on rk3288-veyron-minnie I periodically see this in
> the logs of a machine just sitting there idle:
> dwmmc_rockchip ff0d0000.dwmmc: Successfully tuned phase to XYZ
>
> Fixes: bd11e8bd03ca ("mmc: core: Flag re-tuning is needed on CRC errors")
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
Not withstanding Ulf's comments:
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
> ---
>
> Changes in v4:
> - Moved to SDIO API only (Adrian, Ulf).
> - Renamed to make it less generic, now retune_crc_disable (Ulf).
> - Function header makes it clear host must be claimed (Ulf).
> - No more WARN_ON (Ulf).
>
> Changes in v3:
> - Took out the spinlock since I believe this is all in one context.
>
> Changes in v2:
> - Updated commit message to clarify based on discussion of v1.
>
> drivers/mmc/core/core.c | 5 +++--
> drivers/mmc/core/sdio_io.c | 36 +++++++++++++++++++++++++++++++++++
> include/linux/mmc/core.h | 2 ++
> include/linux/mmc/host.h | 1 +
> include/linux/mmc/sdio_func.h | 3 +++
> 5 files changed, 45 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
> index 6db36dc870b5..9020cb2490f7 100644
> --- a/drivers/mmc/core/core.c
> +++ b/drivers/mmc/core/core.c
> @@ -144,8 +144,9 @@ void mmc_request_done(struct mmc_host *host, struct mmc_request *mrq)
> int err = cmd->error;
>
> /* Flag re-tuning needed on CRC errors */
> - if ((cmd->opcode != MMC_SEND_TUNING_BLOCK &&
> - cmd->opcode != MMC_SEND_TUNING_BLOCK_HS200) &&
> + if (cmd->opcode != MMC_SEND_TUNING_BLOCK &&
> + cmd->opcode != MMC_SEND_TUNING_BLOCK_HS200 &&
> + !host->retune_crc_disable &&
> (err == -EILSEQ || (mrq->sbc && mrq->sbc->error == -EILSEQ) ||
> (mrq->data && mrq->data->error == -EILSEQ) ||
> (mrq->stop && mrq->stop->error == -EILSEQ)))
> diff --git a/drivers/mmc/core/sdio_io.c b/drivers/mmc/core/sdio_io.c
> index f79f0b0caab8..f822a9630b0e 100644
> --- a/drivers/mmc/core/sdio_io.c
> +++ b/drivers/mmc/core/sdio_io.c
> @@ -734,3 +734,39 @@ int sdio_set_host_pm_flags(struct sdio_func *func, mmc_pm_flag_t flags)
> return 0;
> }
> EXPORT_SYMBOL_GPL(sdio_set_host_pm_flags);
> +
> +/**
> + * sdio_retune_crc_disable - temporarily disable retuning on CRC errors
> + * @func: SDIO function attached to host
> + *
> + * If the SDIO card is known to be in a state where it might produce
> + * CRC errors on the bus in response to commands (like if we know it is
> + * transitioning between power states), an SDIO function driver can
> + * call this function to temporarily disable the SD/MMC core behavior of
> + * triggering an automatic retuning.
> + *
> + * This function should be called while the host is claimed and the host
> + * should remain claimed until sdio_retune_crc_enable() is called.
> + * Specifically, the expected sequence of calls is:
> + * - sdio_claim_host()
> + * - sdio_retune_crc_disable()
> + * - some number of calls like sdio_writeb() and sdio_readb()
> + * - sdio_release_host()
> + */
> +void sdio_retune_crc_disable(struct sdio_func *func)
> +{
> + func->card->host->retune_crc_disable = true;
> +}
> +EXPORT_SYMBOL_GPL(sdio_retune_crc_disable);
> +
> +/**
> + * sdio_retune_crc_enable - reneable retuning on CRC errors
> + * @func: SDIO function attached to host
> + *
> + * This is the compement to sdio_retune_crc_disable().
> + */
> +void sdio_retune_crc_enable(struct sdio_func *func)
> +{
> + func->card->host->retune_crc_disable = false;
> +}
> +EXPORT_SYMBOL_GPL(sdio_retune_crc_enable);
> diff --git a/include/linux/mmc/core.h b/include/linux/mmc/core.h
> index 134a6483347a..02a13abf0cda 100644
> --- a/include/linux/mmc/core.h
> +++ b/include/linux/mmc/core.h
> @@ -178,6 +178,8 @@ int mmc_wait_for_cmd(struct mmc_host *host, struct mmc_command *cmd,
>
> int mmc_hw_reset(struct mmc_host *host);
> int mmc_sw_reset(struct mmc_host *host);
> +void mmc_expect_errors_begin(struct mmc_host *host);
> +void mmc_expect_errors_end(struct mmc_host *host);
> void mmc_set_data_timeout(struct mmc_data *data, const struct mmc_card *card);
>
> #endif /* LINUX_MMC_CORE_H */
> diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
> index 43d0f0c496f6..ecb7972e2423 100644
> --- a/include/linux/mmc/host.h
> +++ b/include/linux/mmc/host.h
> @@ -398,6 +398,7 @@ struct mmc_host {
> unsigned int retune_now:1; /* do re-tuning at next req */
> unsigned int retune_paused:1; /* re-tuning is temporarily disabled */
> unsigned int use_blk_mq:1; /* use blk-mq */
> + unsigned int retune_crc_disable:1; /* don't trigger retune upon crc */
>
> int rescan_disable; /* disable card detection */
> int rescan_entered; /* used with nonremovable devices */
> diff --git a/include/linux/mmc/sdio_func.h b/include/linux/mmc/sdio_func.h
> index e9dfdd501cd1..4820e6d09dac 100644
> --- a/include/linux/mmc/sdio_func.h
> +++ b/include/linux/mmc/sdio_func.h
> @@ -167,4 +167,7 @@ extern void sdio_f0_writeb(struct sdio_func *func, unsigned char b,
> extern mmc_pm_flag_t sdio_get_host_pm_caps(struct sdio_func *func);
> extern int sdio_set_host_pm_flags(struct sdio_func *func, mmc_pm_flag_t flags);
>
> +extern void sdio_retune_crc_disable(struct sdio_func *func);
> +extern void sdio_retune_crc_enable(struct sdio_func *func);
> +
> #endif /* LINUX_MMC_SDIO_FUNC_H */
>
^ permalink raw reply
* Re: [PATCH v4 5/5] brcmfmac: sdio: Don't tune while the card is off
From: Adrian Hunter @ 2019-06-17 8:28 UTC (permalink / raw)
To: Douglas Anderson, Ulf Hansson, Kalle Valo, Arend van Spriel
Cc: brcm80211-dev-list.pdl, linux-rockchip, Double Lo, briannorris,
linux-wireless, Naveen Gupta, Madhan Mohan R, mka, Wright Feng,
Chi-Hsien Lin, netdev, brcm80211-dev-list, Franky Lin,
linux-kernel, Hante Meuleman, YueHaibing, David S. Miller
In-Reply-To: <20190613234153.59309-6-dianders@chromium.org>
On 14/06/19 2:41 AM, Douglas Anderson wrote:
> When Broadcom SDIO cards are idled they go to sleep and a whole
> separate subsystem takes over their SDIO communication. This is the
> Always-On-Subsystem (AOS) and it can't handle tuning requests.
>
> Specifically, as tested on rk3288-veyron-minnie (which reports having
> BCM4354/1 in dmesg), if I force a retune in brcmf_sdio_kso_control()
> when "on = 1" (aka we're transition from sleep to wake) by whacking:
> bus->sdiodev->func1->card->host->need_retune = 1
> ...then I can often see tuning fail. In this case dw_mmc reports "All
> phases bad!"). Note that I don't get 100% failure, presumably because
> sometimes the card itself has already transitioned away from the AOS
> itself by the time we try to wake it up. If I force retuning when "on
> = 0" (AKA force retuning right before sending the command to go to
> sleep) then retuning is always OK.
>
> NOTE: we need _both_ this patch and the patch to avoid triggering
> tuning due to CRC errors in the sleep/wake transition, AKA ("brcmfmac:
> sdio: Disable auto-tuning around commands expected to fail"). Though
> both patches handle issues with Broadcom's AOS, the problems are
> distinct:
> 1. We want to defer (but not ignore) asynchronous (like
> timer-requested) tuning requests till the card is awake. However,
> we want to ignore CRC errors during the transition, we don't want
> to queue deferred tuning request.
> 2. You could imagine that the AOS could implement retuning but we
> could still get errors while transitioning in and out of the AOS.
> Similarly you could imagine a seamless transition into and out of
> the AOS (with no CRC errors) even if the AOS couldn't handle
> tuning.
>
> ALSO NOTE: presumably there is never a desperate need to retune in
> order to wake up the card, since doing so is impossible. Luckily the
> only way the card can get into sleep state is if we had a good enough
> tuning to send it a sleep command, so presumably that "good enough"
> tuning is enough to wake us up, at least with a few retries.
>
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
> ---
>
> Changes in v4:
> - Adjust to API rename (Adrian).
>
> Changes in v3:
> - ("brcmfmac: sdio: Don't tune while the card is off") new for v3.
>
> Changes in v2: None
>
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> index ee76593259a7..629140b6d7e2 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> @@ -669,6 +669,10 @@ brcmf_sdio_kso_control(struct brcmf_sdio *bus, bool on)
>
> sdio_retune_crc_disable(bus->sdiodev->func1);
>
> + /* Cannot re-tune if device is asleep; defer till we're awake */
> + if (on)
> + sdio_retune_hold_now(bus->sdiodev->func1);
> +
> wr_val = (on << SBSDIO_FUNC1_SLEEPCSR_KSO_SHIFT);
> /* 1st KSO write goes to AOS wake up core if device is asleep */
> brcmf_sdiod_writeb(bus->sdiodev, SBSDIO_FUNC1_SLEEPCSR, wr_val, &err);
> @@ -729,6 +733,9 @@ brcmf_sdio_kso_control(struct brcmf_sdio *bus, bool on)
> if (try_cnt > MAX_KSO_ATTEMPTS)
> brcmf_err("max tries: rd_val=0x%x err=%d\n", rd_val, err);
>
> + if (on)
> + sdio_retune_release(bus->sdiodev->func1);
> +
> sdio_retune_crc_enable(bus->sdiodev->func1);
>
> return err;
>
^ permalink raw reply
* Re: use exact allocation for dma coherent memory
From: Dan Carpenter @ 2019-06-17 8:21 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Maarten Lankhorst, Maxime Ripard, Sean Paul, David Airlie,
Daniel Vetter, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Ian Abbott, H Hartley Sweeten, devel, linux-s390,
Intel Linux Wireless, linux-rdma, netdev, intel-gfx,
linux-wireless, linux-kernel, dri-devel, linux-mm, iommu,
moderated list:ARM PORT, linux-media
In-Reply-To: <20190614134726.3827-1-hch@lst.de>
I once wrote a Smatch check based on a commit message that said we can't
pass dma_alloc_coherent() pointers to virt_to_phys(). But then I never
felt like I understood the rules enough to actually report the warnings
as bugs.
drivers/platform/x86/dcdbas.c:108 smi_data_buf_realloc() error: 'buf' came from dma_alloc_coherent() so we can't do virt_to_phys()
drivers/net/caif/caif_virtio.c:414 cfv_create_genpool() error: 'cfv->alloc_addr' came from dma_alloc_coherent() so we can't do virt_to_phys()
drivers/infiniband/hw/cxgb4/qp.c:135 alloc_host_sq() error: 'sq->queue' came from dma_alloc_coherent() so we can't do virt_to_phys()
drivers/infiniband/hw/cxgb4/qp.c:272 create_qp() error: 'wq->rq.queue' came from dma_alloc_coherent() so we can't do virt_to_phys()
drivers/infiniband/hw/cxgb4/qp.c:2628 alloc_srq_queue() error: 'wq->queue' came from dma_alloc_coherent() so we can't do virt_to_phys()
drivers/infiniband/hw/ocrdma/ocrdma_verbs.c:494 ocrdma_alloc_ucontext() error: 'ctx->ah_tbl.va' came from dma_alloc_coherent() so we can't do virt_to_phys()
drivers/infiniband/hw/cxgb4/qp.c
129 static int alloc_host_sq(struct c4iw_rdev *rdev, struct t4_sq *sq)
130 {
131 sq->queue = dma_alloc_coherent(&(rdev->lldi.pdev->dev), sq->memsize,
132 &(sq->dma_addr), GFP_KERNEL);
133 if (!sq->queue)
134 return -ENOMEM;
135 sq->phys_addr = virt_to_phys(sq->queue);
136 dma_unmap_addr_set(sq, mapping, sq->dma_addr);
137 return 0;
138 }
Is this a bug?
regards,
dan carpenter
^ permalink raw reply
* Re: wpa_supplicant 2.8 fails in brcmf_cfg80211_set_pmk
From: Chi-Hsien Lin @ 2019-06-17 8:04 UTC (permalink / raw)
To: Stefan Wahren, Stanley Hsu, Arend van Spriel, Franky Lin,
Hante Meuleman, Wright Feng, linux-wireless@vger.kernel.org,
brcm80211-dev-list.pdl@broadcom.com, brcm80211-dev-list
In-Reply-To: <9da02861-9151-9700-2c09-b312d74155fa@gmx.net>
[-- Attachment #1: Type: text/plain, Size: 725 bytes --]
(+Stanley)
On 06/16/2019 1:21, Stefan Wahren wrote:
> Am 15.06.19 um 19:01 schrieb Stefan Wahren:
>> Hi,
>>
>> i was able to reproduce an (maybe older issue) with 4-way handshake
>> offloading for 802.1X in the brcmfmac driver. My setup consists of
>> Raspberry Pi 3 B (current linux-next, arm64/defconfig) on STA side and a
>> Raspberry Pi 3 A+ (Linux 4.19) on AP side.
>
> Looks like Raspberry Pi isn't the only affected platform [3], [4].
>
> [3] - https://bugzilla.redhat.com/show_bug.cgi?id=1665608
> [4] - https://bugzilla.kernel.org/show_bug.cgi?id=202521
Stefan,
Could you please try the attached patch for your wpa_supplicant? We'll
upstream if it works for you.
Regards,
Chi-hsien Lin
[-- Attachment #2: 0001-wpa_supplicant-Fix-802.1X-4-way-handshake-offload-in.patch --]
[-- Type: text/plain, Size: 1644 bytes --]
From 9774dfbf62f41080267ebb0943015a9f6d1dc0cf Mon Sep 17 00:00:00 2001
From: Chung-Hsien Hsu <stanley.hsu@cypress.com>
Date: Mon, 20 May 2019 17:10:39 +0800
Subject: [PATCH] wpa_supplicant: Fix 802.1X 4-way handshake offload indication
Commit d896874f8689 ("nl80211: Indicate 802.1X 4-way handshake
offload in connect") used the req_key_mgmt_offload flag to
indicate to the driver that it should offload the 802.1X handshake.
However, the flag will be updated according to th configuration of
proactive key caching and OKC if key management offload is considered
(it is enabled by default now). Do not update the flag if it has been
set for 802.1X 4-way handshake offload.
Signed-off-by: Chung-Hsien Hsu <stanley.hsu@cypress.com>
---
wpa_supplicant/wpa_supplicant.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/wpa_supplicant/wpa_supplicant.c b/wpa_supplicant/wpa_supplicant.c
index 96a3691cf3cf..66ee268d861c 100644
--- a/wpa_supplicant/wpa_supplicant.c
+++ b/wpa_supplicant/wpa_supplicant.c
@@ -3221,8 +3221,10 @@ static void wpas_start_assoc_cb(struct wpa_radio_work *work, int deinit)
params.key_mgmt_suite == WPA_KEY_MGMT_IEEE8021X_SUITE_B ||
params.key_mgmt_suite == WPA_KEY_MGMT_IEEE8021X_SUITE_B_192))
params.req_key_mgmt_offload = 1;
+ else
+ params.req_key_mgmt_offload = 0;
- if (wpa_s->conf->key_mgmt_offload) {
+ if (wpa_s->conf->key_mgmt_offload && !params.req_key_mgmt_offload) {
if (params.key_mgmt_suite == WPA_KEY_MGMT_IEEE8021X ||
params.key_mgmt_suite == WPA_KEY_MGMT_IEEE8021X_SHA256 ||
params.key_mgmt_suite == WPA_KEY_MGMT_IEEE8021X_SUITE_B ||
--
2.1.0
^ permalink raw reply related
* Re: [PATCH v4 2/5] mmc: core: API to temporarily disable retuning for SDIO CRC errors
From: Ulf Hansson @ 2019-06-17 7:53 UTC (permalink / raw)
To: Doug Anderson
Cc: Kalle Valo, Adrian Hunter, Arend van Spriel,
brcm80211-dev-list.pdl, open list:ARM/Rockchip SoC..., Double Lo,
Brian Norris, linux-wireless, Naveen Gupta, Madhan Mohan R,
Matthias Kaehlcke, Wright Feng, Chi-Hsien Lin, netdev,
brcm80211-dev-list, Jiong Wu, Ritesh Harjani, Allison Randal,
linux-mmc@vger.kernel.org, Linux Kernel Mailing List,
Thomas Gleixner, Greg Kroah-Hartman, Shawn Lin, Wolfram Sang,
Avri Altman
In-Reply-To: <CAD=FV=UA9i1eEi3Mx0WF-DnCnr4O4-MfOxa=axZOJtXzxbV7Tw@mail.gmail.com>
[...]
> > > --- a/include/linux/mmc/sdio_func.h
> > > +++ b/include/linux/mmc/sdio_func.h
> > > @@ -167,4 +167,7 @@ extern void sdio_f0_writeb(struct sdio_func *func, unsigned char b,
> > > extern mmc_pm_flag_t sdio_get_host_pm_caps(struct sdio_func *func);
> > > extern int sdio_set_host_pm_flags(struct sdio_func *func, mmc_pm_flag_t flags);
> > >
> > > +extern void sdio_retune_crc_disable(struct sdio_func *func);
> > > +extern void sdio_retune_crc_enable(struct sdio_func *func);
> > > +
> > > #endif /* LINUX_MMC_SDIO_FUNC_H */
> > > --
> > > 2.22.0.rc2.383.gf4fbbf30c2-goog
> > >
> >
> > Besides the minor comments, this looks good to me.
>
> Thank you for the reviews!
>
> I'll plan to send a v5 on my Monday with the fixes assuming no new
> heated discussion starts up. If it's less work for you, I'm also
> happy if you just want to make the trivial fixes yourself when
> applying.
It really doesn't matter to me, feel free to pick the option you
prefer. At this point I am just awaiting acks for the broadcom patces
and some clarity of what stable releases we should target for
non-tagged patches.
Kind regards
Uffe
^ permalink raw reply
* Re: [PATCH] wl18xx: Fix Wunused-const-variable
From: Kalle Valo @ 2019-06-17 7:44 UTC (permalink / raw)
To: Nick Desaulniers
Cc: Nathan Huckleberry, eliad, arik, David S. Miller, linux-wireless,
netdev, LKML, clang-built-linux
In-Reply-To: <CAKwvOd=jFYn=7NGPD8UDx3_g30qD+40bCjzmWJJSzmb6pNUusQ@mail.gmail.com>
Nick Desaulniers <ndesaulniers@google.com> writes:
> On Fri, Jun 14, 2019 at 10:17 AM 'Nathan Huckleberry' via Clang Built
> Linux <clang-built-linux@googlegroups.com> wrote:
>>
>> Clang produces the following warning
>>
>> drivers/net/wireless/ti/wl18xx/main.c:1850:43: warning: unused variable
>> 'wl18xx_iface_ap_cl_limits' [-Wunused-const-variable] static const struct
>> ieee80211_iface_limit wl18xx_iface_ap_cl_limits[] = { ^
>> drivers/net/wireless/ti/wl18xx/main.c:1869:43: warning: unused variable
>> 'wl18xx_iface_ap_go_limits' [-Wunused-const-variable] static const struct
>> ieee80211_iface_limit wl18xx_iface_ap_go_limits[] = { ^
>>
>> The commit that added these variables never used them. Removing them.
>
> Previous thread, for context:
> https://groups.google.com/forum/#!topic/clang-built-linux/1Lu1GT9ic94
>
> Looking at drivers/net/wireless/ti/wl18xx/main.c, there 4 globally
> declared `struct ieee80211_iface_limit` but as your patch notes, only
> 2 are used. The thing is, their uses are in a `struct
> ieee80211_iface_limit []`.
>
> Looking at
> $ git blame drivers/net/wireless/ti/wl18xx/main.c -L 1850
> points to
> commit 7845af35e0de ("wlcore: add p2p device support")
> Adding Eliad and Arik to the thread; it's not clear to me what the
> these variables were supposed to do, but seeing as the code in
> question was already dead, this is no functional change from a user's
> perspective. With that in mind:
> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
>
> So I'd at least add the tag.
> Fixes: 7845af35e0de ("wlcore: add p2p device support")
I can't see any functional changes when applying this patch so I don't
think a fixes line is needed, it's just cleanup.
--
Kalle Valo
^ permalink raw reply
* [PATCH] ath10k: add mic bytes for pmf management packet
From: Wen Gong @ 2019-06-17 7:37 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless
For PMF case, the action,deauth,disassoc management need to encrypt
by hardware, it need to reserve 8 bytes for encryption, otherwise
the packet will be sent out with error format, then PMF case will
fail.
After add the 8 bytes, it will pass the PMF case.
Tested with QCA6174 SDIO with firmware
WLAN.RMH.4.4.1-00005-QCARMSWP-1.
Signed-off-by: Wen Gong <wgong@codeaurora.org>
---
drivers/net/wireless/ath/ath10k/htt_tx.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/htt_tx.c b/drivers/net/wireless/ath/ath10k/htt_tx.c
index d8e9cc0..7bef9d9 100644
--- a/drivers/net/wireless/ath/ath10k/htt_tx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_tx.c
@@ -1236,6 +1236,7 @@ static int ath10k_htt_tx_hl(struct ath10k_htt *htt, enum ath10k_hw_txrx_mode txm
struct ath10k *ar = htt->ar;
int res, data_len;
struct htt_cmd_hdr *cmd_hdr;
+ struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)msdu->data;
struct htt_data_tx_desc *tx_desc;
struct ath10k_skb_cb *skb_cb = ATH10K_SKB_CB(msdu);
struct sk_buff *tmp_skb;
@@ -1245,6 +1246,13 @@ static int ath10k_htt_tx_hl(struct ath10k_htt *htt, enum ath10k_hw_txrx_mode txm
u8 flags0 = 0;
u16 flags1 = 0;
+ if ((ieee80211_is_action(hdr->frame_control) ||
+ ieee80211_is_deauth(hdr->frame_control) ||
+ ieee80211_is_disassoc(hdr->frame_control)) &&
+ ieee80211_has_protected(hdr->frame_control)) {
+ skb_put(msdu, IEEE80211_CCMP_MIC_LEN);
+ }
+
data_len = msdu->len;
switch (txmode) {
--
1.9.1
^ permalink raw reply related
* [PATCH] ath10k: add new hw_ops for sdio chip
From: Wen Gong @ 2019-06-17 7:37 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless
It report error message while suspend/resume test.
dmesg log:
[ 150.749962] ath10k_sdio mmc1:0001:1: hif read32 not supported
[ 150.755728] ath10k_sdio mmc1:0001:1: failed to set coverage class: expected integer microsecond value in register
Reason is sdio chip does not support set_coverage_class as well as
pcie chip, remove the set_coverage_class handler will avoid it.
callstack of the error message:
OUTLINED_FUNCTION_6+0xc/0x14 [ath10k_core]
ath10k_mac_op_set_coverage_class+0x2c/0x40 [ath10k_core]
ieee80211_reconfig+0x5d0/0x108c [mac80211]
ieee80211_resume+0x34/0x6c [mac80211]
wiphy_resume+0xbc/0x13c [cfg80211]
dpm_run_callback+0xa4/0x168
device_resume+0x1d4/0x200
async_resume+0x1c/0x34
async_run_entry_fn+0x48/0xf8
process_one_work+0x178/0x2f8
worker_thread+0x1d8/0x2cc
kthread+0x11c/0x12c
ret_from_fork+0x10/0x18
the error log will not happen after this patch applied.
Tested with QCA6174 SDIO with firmware
WLAN.RMH.4.4.1-00007-QCARMSWP-1.
Signed-off-by: Wen Gong <wgong@codeaurora.org>
---
drivers/net/wireless/ath/ath10k/core.c | 2 +-
drivers/net/wireless/ath/ath10k/hw.c | 4 ++++
drivers/net/wireless/ath/ath10k/hw.h | 1 +
3 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index 76504bc..3c6d921 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -101,7 +101,7 @@
.board_size = QCA6174_BOARD_DATA_SZ,
.board_ext_size = QCA6174_BOARD_EXT_DATA_SZ,
},
- .hw_ops = &qca6174_ops,
+ .hw_ops = &qca6174_sdio_ops,
.hw_clk = qca6174_clk,
.target_cpu_freq = 176000000,
.decap_align_bytes = 4,
diff --git a/drivers/net/wireless/ath/ath10k/hw.c b/drivers/net/wireless/ath/ath10k/hw.c
index ad082b7..a6a38c9 100644
--- a/drivers/net/wireless/ath/ath10k/hw.c
+++ b/drivers/net/wireless/ath/ath10k/hw.c
@@ -1153,6 +1153,10 @@ static bool ath10k_qca99x0_rx_desc_msdu_limit_error(struct htt_rx_desc *rxd)
.is_rssi_enable = ath10k_htt_tx_rssi_enable,
};
+const struct ath10k_hw_ops qca6174_sdio_ops = {
+ .enable_pll_clk = ath10k_hw_qca6174_enable_pll_clock,
+};
+
const struct ath10k_hw_ops wcn3990_ops = {
.tx_data_rssi_pad_bytes = ath10k_get_htt_tx_data_rssi_pad,
.is_rssi_enable = ath10k_htt_tx_rssi_enable_wcn3990,
diff --git a/drivers/net/wireless/ath/ath10k/hw.h b/drivers/net/wireless/ath/ath10k/hw.h
index 54c01f1..3a6f87e 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -626,6 +626,7 @@ struct ath10k_hw_ops {
extern const struct ath10k_hw_ops qca988x_ops;
extern const struct ath10k_hw_ops qca99x0_ops;
extern const struct ath10k_hw_ops qca6174_ops;
+extern const struct ath10k_hw_ops qca6174_sdio_ops;
extern const struct ath10k_hw_ops wcn3990_ops;
extern const struct ath10k_hw_clk_params qca6174_clk[];
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v3 4/7] lib/hexdump.c: Replace ascii bool in hex_dump_to_buffer with flags
From: Jani Nikula @ 2019-06-17 7:39 UTC (permalink / raw)
To: Alastair D'Silva, alastair
Cc: Joonas Lahtinen, Rodrigo Vivi, David Airlie, Daniel Vetter,
Dan Carpenter, Karsten Keil, Jassi Brar, Tom Lendacky,
David S. Miller, Jose Abreu, Kalle Valo, Stanislaw Gruszka,
Benson Leung, Enric Balletbo i Serra, James E.J. Bottomley,
Martin K. Petersen, Greg Kroah-Hartman, Alexander Viro,
Petr Mladek, Sergey Senozhatsky, Steven Rostedt, David Laight,
Andrew Morton, intel-gfx, dri-devel, linux-kernel, netdev, ath10k,
linux-wireless, linux-scsi, linux-fbdev, devel, linux-fsdevel
In-Reply-To: <20190617020430.8708-5-alastair@au1.ibm.com>
On Mon, 17 Jun 2019, "Alastair D'Silva" <alastair@au1.ibm.com> wrote:
> From: Alastair D'Silva <alastair@d-silva.org>
>
> In order to support additional features in hex_dump_to_buffer, replace
> the ascii bool parameter with flags.
>
> Signed-off-by: Alastair D'Silva <alastair@d-silva.org>
> ---
> drivers/gpu/drm/i915/intel_engine_cs.c | 2 +-
> drivers/isdn/hardware/mISDN/mISDNisar.c | 6 ++++--
> drivers/mailbox/mailbox-test.c | 2 +-
> drivers/net/ethernet/amd/xgbe/xgbe-drv.c | 2 +-
> drivers/net/ethernet/synopsys/dwc-xlgmac-common.c | 2 +-
> drivers/net/wireless/ath/ath10k/debug.c | 3 ++-
> drivers/net/wireless/intel/iwlegacy/3945-mac.c | 2 +-
> drivers/platform/chrome/wilco_ec/debugfs.c | 2 +-
> drivers/scsi/scsi_logging.c | 8 +++-----
> drivers/staging/fbtft/fbtft-core.c | 2 +-
> fs/seq_file.c | 3 ++-
> include/linux/printk.h | 8 ++++----
> lib/hexdump.c | 15 ++++++++-------
> lib/test_hexdump.c | 5 +++--
> 14 files changed, 33 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c b/drivers/gpu/drm/i915/intel_engine_cs.c
> index eea9bec04f1b..5df5fffdb848 100644
> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> @@ -1340,7 +1340,7 @@ static void hexdump(struct drm_printer *m, const void *buf, size_t len)
> WARN_ON_ONCE(hex_dump_to_buffer(buf + pos, len - pos,
> rowsize, sizeof(u32),
> line, sizeof(line),
> - false) >= sizeof(line));
> + 0) >= sizeof(line));
> drm_printf(m, "[%04zx] %s\n", pos, line);
>
> prev = buf + pos;
On i915,
Acked-by: Jani Nikula <jani.nikula@intel.com>
--
Jani Nikula, Intel Open Source Graphics Center
^ permalink raw reply
* Re: [PATCH v3] {nl,mac}80211: allow 4addr AP operation on crypto controlled devices
From: Stefan Lippers-Hollmann @ 2019-06-17 7:36 UTC (permalink / raw)
To: Johannes Berg; +Cc: Tom Psyborg, Manikanta Pubbisetty, linux-wireless
In-Reply-To: <e13d86030df7a5222ee144d85bbeec400ed8fa07.camel@sipsolutions.net>
Hi
On 2019-06-17, Johannes Berg wrote:
> On Mon, 2019-06-17 at 07:07 +0200, Stefan Lippers-Hollmann wrote:
[...]
> > I've tested (and left it running/ monitored) for two days without
> > any problems between QCA9984 (ZyXEL nbg6817/ ipq8065, WDS-AP, affected
> > before 33d915d9e8ce811d8958915ccd18d71a66c7c495 "{nl,mac}80211: allow
> > 4addr AP operation on crypto controlled devices" went in) and AR9340
> > (TP-Link TL-WDR3600/ AR9344, WDS-Client, not affected by this issue),
> > both under current (~2 days old) OpenWrt master[1] (ipq806x/ ath79,
> > respectively). This patch is working fine and fixes the previous
> > problems with 4addr on ath10k (QCA9984).
>
> "This patch" is v3 then, presumably? I just checked, and it looks like I
> indeed applied v3.
I've tested:
https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git/commit/?id=33d915d9e8ce811d8958915ccd18d71a66c7c495
And applied it to OpenWrt's (v4.19 based) backports package:
https://github.com/openwrt/openwrt/pull/2139/commits/425ab52a0d451938c87ebafdf247b86fa563ad36
> So basically you're saying it works as affected, since you were
> previously affected by the unavailability of 4addr interfaces on ath10k
> hardware, which are now available, right?
Yes, QCA9984/ ath10k[1] as 4addr/ WDS-AP was affected starting with
(backports-) kernel 4.18 and above. I've tested v1 and the version
you merged with
https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git/commit/?id=33d915d9e8ce811d8958915ccd18d71a66c7c495
both versions of this patch fix the problem for me and survived a
slightly over 2 day stress test.
Regards
Stefan Lippers-Hollmann
[1] ath10k_pci 0001:01:00.0: firmware ver 10.4-3.9.0.2-00044 api 5 features no-p2p,mfp,peer-flow-ctrl,btcoex-param,allows-mesh-bcast,no-ps crc32 c3e1b393
^ permalink raw reply
* Re: [PATCH v3] {nl,mac}80211: allow 4addr AP operation on crypto controlled devices
From: Johannes Berg @ 2019-06-17 7:06 UTC (permalink / raw)
To: Stefan Lippers-Hollmann; +Cc: Tom Psyborg, Manikanta Pubbisetty, linux-wireless
In-Reply-To: <20190617070747.562b9388@mir>
On Mon, 2019-06-17 at 07:07 +0200, Stefan Lippers-Hollmann wrote:
> Hi
>
> On 2019-06-12, Johannes Berg wrote:
> > On Thu, 2019-06-06 at 20:41 +0200, Tom Psyborg wrote:
> > >
> > > Applying this patch instead of v1 broke WDS operation between two
> > > Litebeam AC Gen2 devices:
> >
> > I'm confused, and not even sure which version I applied now.
> >
> > Manikanta, can you please check this and which version I have and which
> > changes I might need?
>
> I've tested (and left it running/ monitored) for two days without
> any problems between QCA9984 (ZyXEL nbg6817/ ipq8065, WDS-AP, affected
> before 33d915d9e8ce811d8958915ccd18d71a66c7c495 "{nl,mac}80211: allow
> 4addr AP operation on crypto controlled devices" went in) and AR9340
> (TP-Link TL-WDR3600/ AR9344, WDS-Client, not affected by this issue),
> both under current (~2 days old) OpenWrt master[1] (ipq806x/ ath79,
> respectively). This patch is working fine and fixes the previous
> problems with 4addr on ath10k (QCA9984).
"This patch" is v3 then, presumably? I just checked, and it looks like I
indeed applied v3.
So basically you're saying it works as affected, since you were
previously affected by the unavailability of 4addr interfaces on ath10k
hardware, which are now available, right?
Tom, I notice you're using a very old base kernel ("backports-4.19.32-
1") - are you sure you were even able to apply this patch correctly?
johannes
^ permalink raw reply
* [RFC PATCH v5] rtl8xxxu: Improve TX performance of RTL8723BU on rtl8xxxu driver
From: Chris Chiu @ 2019-06-17 6:56 UTC (permalink / raw)
To: jes.sorensen, kvalo, davem; +Cc: linux-wireless, netdev, linux-kernel, linux
We have 3 laptops which connect the wifi by the same RTL8723BU.
The PCI VID/PID of the wifi chip is 10EC:B720 which is supported.
They have the same problem with the in-kernel rtl8xxxu driver, the
iperf (as a client to an ethernet-connected server) gets ~1Mbps.
Nevertheless, the signal strength is reported as around -40dBm,
which is quite good. From the wireshark capture, the tx rate for each
data and qos data packet is only 1Mbps. Compare to the Realtek driver
at https://github.com/lwfinger/rtl8723bu, the same iperf test gets
~12Mbps or better. The signal strength is reported similarly around
-40dBm. That's why we want to improve.
After reading the source code of the rtl8xxxu driver and Realtek's, the
major difference is that Realtek's driver has a watchdog which will keep
monitoring the signal quality and updating the rate mask just like the
rtl8xxxu_gen2_update_rate_mask() does if signal quality changes.
And this kind of watchdog also exists in rtlwifi driver of some specific
chips, ex rtl8192ee, rtl8188ee, rtl8723ae, rtl8821ae...etc. They have
the same member function named dm_watchdog and will invoke the
corresponding dm_refresh_rate_adaptive_mask to adjust the tx rate
mask.
With this commit, the tx rate of each data and qos data packet will
be 39Mbps (MCS4) with the 0xF00000 as the tx rate mask. The 20th bit
to 23th bit means MCS4 to MCS7. It means that the firmware still picks
the lowest rate from the rate mask and explains why the tx rate of
data and qos data is always lowest 1Mbps because the default rate mask
passed is always 0xFFFFFFF ranges from the basic CCK rate, OFDM rate,
and MCS rate. However, with Realtek's driver, the tx rate observed from
wireshark under the same condition is almost 65Mbps or 72Mbps.
I believe the firmware of RTL8723BU may need fix. And I think we
can still bring in the dm_watchdog as rtlwifi to improve from the
driver side. Please leave precious comments for my commits and
suggest what I can do better. Or suggest if there's any better idea
to fix this. Thanks.
Signed-off-by: Chris Chiu <chiu@endlessm.com>
---
Notes:
v2:
- Fix errors and warnings complained by checkpatch.pl
- Replace data structure rate_adaptive by 2 member variables
- Make rtl8xxxu_wireless_mode non-static
- Runs refresh_rate_mask() only in station mode
v3:
- Remove ugly rtl8xxxu_watchdog data structure
- Make sure only one vif exists
v4:
- Move cancel_delayed_work from rtl8xxxu_disconnect to rtl8xxxu_stop
- Clear priv->vif in rtl8xxxu_remove_interface
- Add rateid as the function argument of update_rate_mask
- Rephrase the comment for priv->vif more explicit.
v5:
- Make refresh_rate_mask() generic for all sub-drivers.
- Add definitions for SNR related to help determine rssi_level
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu.h | 55 ++++-
.../wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 226 +++++++++++++++++-
2 files changed, 274 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
index 8828baf26e7b..1498a8c94d5f 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
@@ -1195,6 +1195,48 @@ struct rtl8723bu_c2h {
struct rtl8xxxu_fileops;
+/*mlme related.*/
+enum wireless_mode {
+ WIRELESS_MODE_UNKNOWN = 0,
+ /* Sub-Element */
+ WIRELESS_MODE_B = BIT(0),
+ WIRELESS_MODE_G = BIT(1),
+ WIRELESS_MODE_A = BIT(2),
+ WIRELESS_MODE_N_24G = BIT(3),
+ WIRELESS_MODE_N_5G = BIT(4),
+ WIRELESS_AUTO = BIT(5),
+ WIRELESS_MODE_AC = BIT(6),
+ WIRELESS_MODE_MAX = 0x7F,
+};
+
+/* from rtlwifi/wifi.h */
+enum ratr_table_mode_new {
+ RATEID_IDX_BGN_40M_2SS = 0,
+ RATEID_IDX_BGN_40M_1SS = 1,
+ RATEID_IDX_BGN_20M_2SS_BN = 2,
+ RATEID_IDX_BGN_20M_1SS_BN = 3,
+ RATEID_IDX_GN_N2SS = 4,
+ RATEID_IDX_GN_N1SS = 5,
+ RATEID_IDX_BG = 6,
+ RATEID_IDX_G = 7,
+ RATEID_IDX_B = 8,
+ RATEID_IDX_VHT_2SS = 9,
+ RATEID_IDX_VHT_1SS = 10,
+ RATEID_IDX_MIX1 = 11,
+ RATEID_IDX_MIX2 = 12,
+ RATEID_IDX_VHT_3SS = 13,
+ RATEID_IDX_BGN_3SS = 14,
+};
+
+#define RTL8XXXU_RATR_STA_INIT 0
+#define RTL8XXXU_RATR_STA_HIGH 1
+#define RTL8XXXU_RATR_STA_MID 2
+#define RTL8XXXU_RATR_STA_LOW 3
+
+#define RTL8XXXU_NOISE_FLOOR_MIN -95
+#define RTL8XXXU_SNR_THRESH_HIGH 50
+#define RTL8XXXU_SNR_THRESH_LOW 20
+
struct rtl8xxxu_priv {
struct ieee80211_hw *hw;
struct usb_device *udev;
@@ -1299,6 +1341,13 @@ struct rtl8xxxu_priv {
u8 pi_enabled:1;
u8 no_pape:1;
u8 int_buf[USB_INTR_CONTENT_LENGTH];
+ u8 rssi_level;
+ /*
+ * Only one virtual interface permitted because only STA mode
+ * is supported and no iface_combinations are providec.
+ */
+ struct ieee80211_vif *vif;
+ struct delayed_work ra_watchdog;
};
struct rtl8xxxu_rx_urb {
@@ -1334,7 +1383,7 @@ struct rtl8xxxu_fileops {
void (*set_tx_power) (struct rtl8xxxu_priv *priv, int channel,
bool ht40);
void (*update_rate_mask) (struct rtl8xxxu_priv *priv,
- u32 ramask, int sgi);
+ u32 ramask, u8 rateid, int sgi);
void (*report_connect) (struct rtl8xxxu_priv *priv,
u8 macid, bool connect);
void (*fill_txdesc) (struct ieee80211_hw *hw, struct ieee80211_hdr *hdr,
@@ -1419,9 +1468,9 @@ void rtl8xxxu_gen2_config_channel(struct ieee80211_hw *hw);
void rtl8xxxu_gen1_usb_quirks(struct rtl8xxxu_priv *priv);
void rtl8xxxu_gen2_usb_quirks(struct rtl8xxxu_priv *priv);
void rtl8xxxu_update_rate_mask(struct rtl8xxxu_priv *priv,
- u32 ramask, int sgi);
+ u32 ramask, u8 rateid, int sgi);
void rtl8xxxu_gen2_update_rate_mask(struct rtl8xxxu_priv *priv,
- u32 ramask, int sgi);
+ u32 ramask, u8 rateid, int sgi);
void rtl8xxxu_gen1_report_connect(struct rtl8xxxu_priv *priv,
u8 macid, bool connect);
void rtl8xxxu_gen2_report_connect(struct rtl8xxxu_priv *priv,
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index 039e5ca9d2e4..474dea2291a9 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -4311,7 +4311,8 @@ static void rtl8xxxu_sw_scan_complete(struct ieee80211_hw *hw,
rtl8xxxu_write8(priv, REG_BEACON_CTRL, val8);
}
-void rtl8xxxu_update_rate_mask(struct rtl8xxxu_priv *priv, u32 ramask, int sgi)
+void rtl8xxxu_update_rate_mask(struct rtl8xxxu_priv *priv,
+ u32 ramask, u8 rateid, int sgi)
{
struct h2c_cmd h2c;
@@ -4331,7 +4332,7 @@ void rtl8xxxu_update_rate_mask(struct rtl8xxxu_priv *priv, u32 ramask, int sgi)
}
void rtl8xxxu_gen2_update_rate_mask(struct rtl8xxxu_priv *priv,
- u32 ramask, int sgi)
+ u32 ramask, u8 rateid, int sgi)
{
struct h2c_cmd h2c;
u8 bw = 0;
@@ -4345,7 +4346,7 @@ void rtl8xxxu_gen2_update_rate_mask(struct rtl8xxxu_priv *priv,
h2c.b_macid_cfg.ramask3 = (ramask >> 24) & 0xff;
h2c.ramask.arg = 0x80;
- h2c.b_macid_cfg.data1 = 0;
+ h2c.b_macid_cfg.data1 = rateid;
if (sgi)
h2c.b_macid_cfg.data1 |= BIT(7);
@@ -4485,6 +4486,40 @@ static void rtl8xxxu_set_basic_rates(struct rtl8xxxu_priv *priv, u32 rate_cfg)
rtl8xxxu_write8(priv, REG_INIRTS_RATE_SEL, rate_idx);
}
+static u16
+rtl8xxxu_wireless_mode(struct ieee80211_hw *hw, struct ieee80211_sta *sta)
+{
+ u16 network_type = WIRELESS_MODE_UNKNOWN;
+ u32 rate_mask;
+
+ rate_mask = (sta->supp_rates[0] & 0xfff) |
+ (sta->ht_cap.mcs.rx_mask[0] << 12) |
+ (sta->ht_cap.mcs.rx_mask[0] << 20);
+
+ if (hw->conf.chandef.chan->band == NL80211_BAND_5GHZ) {
+ if (sta->vht_cap.vht_supported)
+ network_type = WIRELESS_MODE_AC;
+ else if (sta->ht_cap.ht_supported)
+ network_type = WIRELESS_MODE_N_5G;
+
+ network_type |= WIRELESS_MODE_A;
+ } else {
+ if (sta->vht_cap.vht_supported)
+ network_type = WIRELESS_MODE_AC;
+ else if (sta->ht_cap.ht_supported)
+ network_type = WIRELESS_MODE_N_24G;
+
+ if (sta->supp_rates[0] <= 0xf)
+ network_type |= WIRELESS_MODE_B;
+ else if (sta->supp_rates[0] & 0xf)
+ network_type |= (WIRELESS_MODE_B | WIRELESS_MODE_G);
+ else
+ network_type |= WIRELESS_MODE_G;
+ }
+
+ return network_type;
+}
+
static void
rtl8xxxu_bss_info_changed(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
struct ieee80211_bss_conf *bss_conf, u32 changed)
@@ -4527,7 +4562,10 @@ rtl8xxxu_bss_info_changed(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
sgi = 1;
rcu_read_unlock();
- priv->fops->update_rate_mask(priv, ramask, sgi);
+ priv->vif = vif;
+ priv->rssi_level = RTL8XXXU_RATR_STA_INIT;
+
+ priv->fops->update_rate_mask(priv, ramask, 0, sgi);
rtl8xxxu_write8(priv, REG_BCN_MAX_ERR, 0xff);
@@ -5471,6 +5509,10 @@ static int rtl8xxxu_add_interface(struct ieee80211_hw *hw,
switch (vif->type) {
case NL80211_IFTYPE_STATION:
+ if (!priv->vif)
+ priv->vif = vif;
+ else
+ return -EOPNOTSUPP;
rtl8xxxu_stop_tx_beacon(priv);
val8 = rtl8xxxu_read8(priv, REG_BEACON_CTRL);
@@ -5494,6 +5536,9 @@ static void rtl8xxxu_remove_interface(struct ieee80211_hw *hw,
struct rtl8xxxu_priv *priv = hw->priv;
dev_dbg(&priv->udev->dev, "%s\n", __func__);
+
+ if (priv->vif)
+ priv->vif = NULL;
}
static int rtl8xxxu_config(struct ieee80211_hw *hw, u32 changed)
@@ -5779,6 +5824,174 @@ rtl8xxxu_ampdu_action(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
return 0;
}
+static u8 rtl8xxxu_signal_to_snr(int signal)
+{
+ if (signal < RTL8XXXU_NOISE_FLOOR_MIN)
+ signal = RTL8XXXU_NOISE_FLOOR_MIN;
+ return (u8)(signal - RTL8XXXU_NOISE_FLOOR_MIN);
+}
+
+static void rtl8xxxu_refresh_rate_mask(struct rtl8xxxu_priv *priv,
+ int signal, struct ieee80211_sta *sta)
+{
+ struct ieee80211_hw *hw = priv->hw;
+ u16 wireless_mode;
+ u8 rssi_level, ratr_idx;
+ u8 txbw_40mhz;
+ u8 snr, snr_thresh_high, snr_thresh_low;
+ u8 go_up_gap = 5;
+
+ rssi_level = priv->rssi_level;
+ snr = rtl8xxxu_signal_to_snr(signal);
+ snr_thresh_high = RTL8XXXU_SNR_THRESH_HIGH;
+ snr_thresh_low = RTL8XXXU_SNR_THRESH_LOW;
+ txbw_40mhz = (hw->conf.chandef.width == NL80211_CHAN_WIDTH_40) ? 1 : 0;
+
+ switch (rssi_level) {
+ case RTL8XXXU_RATR_STA_MID:
+ snr_thresh_high += go_up_gap;
+ break;
+ case RTL8XXXU_RATR_STA_LOW:
+ snr_thresh_high += go_up_gap;
+ snr_thresh_low += go_up_gap;
+ break;
+ default:
+ break;
+ }
+
+ if (snr > snr_thresh_high)
+ rssi_level = RTL8XXXU_RATR_STA_HIGH;
+ else if (snr > snr_thresh_low)
+ rssi_level = RTL8XXXU_RATR_STA_MID;
+ else
+ rssi_level = RTL8XXXU_RATR_STA_LOW;
+
+ if (rssi_level != priv->rssi_level) {
+ int sgi = 0;
+ u32 rate_bitmap = 0;
+
+ rcu_read_lock();
+ rate_bitmap = (sta->supp_rates[0] & 0xfff) |
+ (sta->ht_cap.mcs.rx_mask[0] << 12) |
+ (sta->ht_cap.mcs.rx_mask[1] << 20);
+ if (sta->ht_cap.cap &
+ (IEEE80211_HT_CAP_SGI_40 | IEEE80211_HT_CAP_SGI_20))
+ sgi = 1;
+ rcu_read_unlock();
+
+ wireless_mode = rtl8xxxu_wireless_mode(hw, sta);
+ switch (wireless_mode) {
+ case WIRELESS_MODE_B:
+ ratr_idx = RATEID_IDX_B;
+ if (rate_bitmap & 0x0000000c)
+ rate_bitmap &= 0x0000000d;
+ else
+ rate_bitmap &= 0x0000000f;
+ break;
+ case WIRELESS_MODE_A:
+ case WIRELESS_MODE_G:
+ ratr_idx = RATEID_IDX_G;
+ if (rssi_level == RTL8XXXU_RATR_STA_HIGH)
+ rate_bitmap &= 0x00000f00;
+ else
+ rate_bitmap &= 0x00000ff0;
+ break;
+ case (WIRELESS_MODE_B | WIRELESS_MODE_G):
+ ratr_idx = RATEID_IDX_BG;
+ if (rssi_level == RTL8XXXU_RATR_STA_HIGH)
+ rate_bitmap &= 0x00000f00;
+ else if (rssi_level == RTL8XXXU_RATR_STA_MID)
+ rate_bitmap &= 0x00000ff0;
+ else
+ rate_bitmap &= 0x00000ff5;
+ break;
+ case WIRELESS_MODE_N_24G:
+ case WIRELESS_MODE_N_5G:
+ case (WIRELESS_MODE_G | WIRELESS_MODE_N_24G):
+ case (WIRELESS_MODE_A | WIRELESS_MODE_N_5G):
+ if (priv->tx_paths == 2 && priv->rx_paths == 2)
+ ratr_idx = RATEID_IDX_GN_N2SS;
+ else
+ ratr_idx = RATEID_IDX_GN_N1SS;
+ case (WIRELESS_MODE_B | WIRELESS_MODE_G | WIRELESS_MODE_N_24G):
+ case (WIRELESS_MODE_B | WIRELESS_MODE_N_24G):
+ if (txbw_40mhz) {
+ if (priv->tx_paths == 2 && priv->rx_paths == 2)
+ ratr_idx = RATEID_IDX_BGN_40M_2SS;
+ else
+ ratr_idx = RATEID_IDX_BGN_40M_1SS;
+ } else {
+ if (priv->tx_paths == 2 && priv->rx_paths == 2)
+ ratr_idx = RATEID_IDX_BGN_20M_2SS_BN;
+ else
+ ratr_idx = RATEID_IDX_BGN_20M_1SS_BN;
+ }
+
+ if (priv->tx_paths == 2 && priv->rx_paths == 2) {
+ if (rssi_level == RTL8XXXU_RATR_STA_HIGH) {
+ rate_bitmap &= 0x0f8f0000;
+ } else if (rssi_level == RTL8XXXU_RATR_STA_MID) {
+ rate_bitmap &= 0x0f8ff000;
+ } else {
+ if (txbw_40mhz)
+ rate_bitmap &= 0x0f8ff015;
+ else
+ rate_bitmap &= 0x0f8ff005;
+ }
+ } else {
+ if (rssi_level == RTL8XXXU_RATR_STA_HIGH) {
+ rate_bitmap &= 0x000f0000;
+ } else if (rssi_level == RTL8XXXU_RATR_STA_MID) {
+ rate_bitmap &= 0x000ff000;
+ } else {
+ if (txbw_40mhz)
+ rate_bitmap &= 0x000ff015;
+ else
+ rate_bitmap &= 0x000ff005;
+ }
+ }
+ break;
+ default:
+ ratr_idx = RATEID_IDX_BGN_40M_2SS;
+ rate_bitmap &= 0x0fffffff;
+ break;
+ }
+
+ priv->rssi_level = rssi_level;
+ priv->fops->update_rate_mask(priv, rate_bitmap, ratr_idx, sgi);
+ }
+}
+
+static void rtl8xxxu_watchdog_callback(struct work_struct *work)
+{
+ struct ieee80211_vif *vif;
+ struct rtl8xxxu_priv *priv;
+
+ priv = container_of(work, struct rtl8xxxu_priv, ra_watchdog.work);
+ vif = priv->vif;
+
+ if (vif && vif->type == NL80211_IFTYPE_STATION) {
+ int signal;
+ struct ieee80211_sta *sta;
+
+ rcu_read_lock();
+ sta = ieee80211_find_sta(vif, vif->bss_conf.bssid);
+ if (!sta) {
+ struct device *dev = &priv->udev->dev;
+
+ dev_info(dev, "%s: no sta found\n", __func__);
+ rcu_read_unlock();
+ return;
+ }
+ rcu_read_unlock();
+
+ signal = ieee80211_ave_rssi(vif);
+ rtl8xxxu_refresh_rate_mask(priv, signal, sta);
+ }
+
+ schedule_delayed_work(&priv->ra_watchdog, 2 * HZ);
+}
+
static int rtl8xxxu_start(struct ieee80211_hw *hw)
{
struct rtl8xxxu_priv *priv = hw->priv;
@@ -5835,6 +6048,8 @@ static int rtl8xxxu_start(struct ieee80211_hw *hw)
ret = rtl8xxxu_submit_rx_urb(priv, rx_urb);
}
+
+ schedule_delayed_work(&priv->ra_watchdog, 2 * HZ);
exit:
/*
* Accept all data and mgmt frames
@@ -5886,6 +6101,8 @@ static void rtl8xxxu_stop(struct ieee80211_hw *hw)
if (priv->usb_interrupts)
rtl8xxxu_write32(priv, REG_USB_HIMR, 0);
+ cancel_delayed_work_sync(&priv->ra_watchdog);
+
rtl8xxxu_free_rx_resources(priv);
rtl8xxxu_free_tx_resources(priv);
}
@@ -6058,6 +6275,7 @@ static int rtl8xxxu_probe(struct usb_interface *interface,
INIT_LIST_HEAD(&priv->rx_urb_pending_list);
spin_lock_init(&priv->rx_urb_lock);
INIT_WORK(&priv->rx_urb_wq, rtl8xxxu_rx_urb_work);
+ INIT_DELAYED_WORK(&priv->ra_watchdog, rtl8xxxu_watchdog_callback);
usb_set_intfdata(interface, hw);
--
2.21.0
^ permalink raw reply related
* Re: [PATCH 2/2] mwifiex: use 'total_ie_len' in mwifiex_update_bss_desc_with_ie()
From: Takashi Iwai @ 2019-06-17 6:14 UTC (permalink / raw)
To: Brian Norris
Cc: Ganapathi Bhat, Nishant Sarmukadam, Amitkumar Karwar, Xinming Hu,
linux-kernel, linux-wireless, Takashi Iwai, Guenter Roeck
In-Reply-To: <20190615001321.241808-2-briannorris@chromium.org>
On Sat, 15 Jun 2019 02:13:21 +0200,
Brian Norris wrote:
>
> This is clearer than copy/pasting the magic number '+ 2' around, and it
> even saves the need for one existing comment.
>
> Cc: Takashi Iwai <tiwai@suse.de>
> Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
thanks,
Takashi
^ permalink raw reply
* Re: [PATCH 5.2 1/2] mwifiex: Don't abort on small, spec-compliant vendor IEs
From: Takashi Iwai @ 2019-06-17 6:12 UTC (permalink / raw)
To: Brian Norris
Cc: Ganapathi Bhat, Nishant Sarmukadam, Amitkumar Karwar, Xinming Hu,
linux-kernel, linux-wireless, Takashi Iwai, Guenter Roeck
In-Reply-To: <20190615001321.241808-1-briannorris@chromium.org>
On Sat, 15 Jun 2019 02:13:20 +0200,
Brian Norris wrote:
>
> Per the 802.11 specification, vendor IEs are (at minimum) only required
> to contain an OUI. A type field is also included in ieee80211.h (struct
> ieee80211_vendor_ie) but doesn't appear in the specification. The
> remaining fields (subtype, version) are a convention used in WMM
> headers.
>
> Thus, we should not reject vendor-specific IEs that have only the
> minimum length (3 bytes) -- we should skip over them (since we only want
> to match longer IEs, that match either WMM or WPA formats). We can
> reject elements that don't have the minimum-required 3 byte OUI.
>
> While we're at it, move the non-standard subtype and version fields into
> the WMM structs, to avoid this confusion in the future about generic
> "vendor header" attributes.
>
> Fixes: 685c9b7750bf ("mwifiex: Abort at too short BSS descriptor element")
> Cc: Takashi Iwai <tiwai@suse.de>
> Signed-off-by: Brian Norris <briannorris@chromium.org>
> ---
> It appears that commit 685c9b7750bf is on its way to 5.2, so I labeled
> this bugfix for 5.2 as well.
Thanks for catching this.
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Takashi
^ 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