Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp829102pxb; Tue, 3 Nov 2020 13:44:41 -0800 (PST) X-Google-Smtp-Source: ABdhPJy4o2WW0VHbMG4f9Vk4FIrT3F52/OmrIWSKjZ3KufsSfubXXpKJg1DKKEuA/LDuPbhIOXag X-Received: by 2002:a17:906:d92c:: with SMTP id rn12mr19312637ejb.472.1604439881666; Tue, 03 Nov 2020 13:44:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1604439881; cv=none; d=google.com; s=arc-20160816; b=CJquRA7dRA6Ncnw16X8ep/p5FCRO1mSTuJPqWjOIWczSUaqYhxglFZlu3N0IJMKXow bh3uCi72RdAqDK2vzeRAP+IMRJcd/Rsizr66d3+3cFoSC4XXbvre19l7qiyc9ixJjVay HgzIAT1M6GiHP2Pi2gomhtG/zM58Isn7DE9nYrtJS1SJfv62Mvej3g07DfmRwuoC2CZg 1rcYisN6GPS9cEri2kQvwBODFWZ+fiImh639gusDNvz9VPhn9y7NtOLvkjDe+TutUiy7 OE7SUShSFs8u8SbnZ7ET2Xim4MXpjnBiJt5apt1jbLQam/zBqGbrl96ytrJgkAcmmVd0 bTsw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=DPt1DajOK9k8Jph1hc/jXCR7f9GInlAEQ+Yt4rPn85M=; b=rFMJzSMyxLftQ0Fyp5VJqOk1LX+rakIdeWgF+HoxTlcN1z4SsE8lfavXfzUSSk5xDf bCWbZTb/2lOgkKPMZyllhHjXMVlyh4lUvD94D8mAscCLl1aDPkZIOpQ5DWUmB3Ywcb7Q 3jpaESJZWzuxGNJoMH/JKpz3h/+vf3pVQ9Xpw/M9A8Dx4rEJiclzy9bIx27WYIOm5uhI B2V5qQSzi1BcN1Wb0P/kDm5R00agZNm9/nDtuo4s6MMgPHpgEt7s2q7MB2s4CEBl5lJx JTltQvYW7eimr3rD5UMx+HIYKM7eggdwEOQhjDkB9rFEVB1y9+vdHYJzEB6ZJVv01oOs aLyg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=YHi15PVY; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h22si76317eje.314.2020.11.03.13.44.18; Tue, 03 Nov 2020 13:44:41 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=YHi15PVY; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732649AbgKCVmY (ORCPT + 99 others); Tue, 3 Nov 2020 16:42:24 -0500 Received: from mail.kernel.org ([198.145.29.99]:56248 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732347AbgKCUze (ORCPT ); Tue, 3 Nov 2020 15:55:34 -0500 Received: from localhost (83-86-74-64.cable.dynamic.v4.ziggo.nl [83.86.74.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 4BA162053B; Tue, 3 Nov 2020 20:55:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1604436933; bh=dCYLeY072XrE7+AikUkihMIe+SEKqmLlDz2iX5VssR0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=YHi15PVYyq7/v3PUWh1k3o/Ry164dRdsHWthJp0jpWQiucxGYy3QpI3ECqIXlVLRf VW2qZsVvj4dZpPFD3CI9ZLYhZtzsY2wRruIxxToKMz5gvmNJFLyPnsn2Wd9AR7OF3/ IHvW/xSwoobzTk4M2PR4wyADjp72CqNWf/3kXsJM= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Wen Gong , Kalle Valo , Sasha Levin Subject: [PATCH 5.4 036/214] ath10k: start recovery process when payload length exceeds max htc length for sdio Date: Tue, 3 Nov 2020 21:34:44 +0100 Message-Id: <20201103203253.463085472@linuxfoundation.org> X-Mailer: git-send-email 2.29.2 In-Reply-To: <20201103203249.448706377@linuxfoundation.org> References: <20201103203249.448706377@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Wen Gong [ Upstream commit 2fd3c8f34d08af0a6236085f9961866ad92ef9ec ] When simulate random transfer fail for sdio write and read, it happened "payload length exceeds max htc length" and recovery later sometimes. Test steps: 1. Add config and update kernel: CONFIG_FAIL_MMC_REQUEST=y CONFIG_FAULT_INJECTION=y CONFIG_FAULT_INJECTION_DEBUG_FS=y 2. Run simulate fail: cd /sys/kernel/debug/mmc1/fail_mmc_request echo 10 > probability echo 10 > times # repeat until hitting issues 3. It happened payload length exceeds max htc length. [ 199.935506] ath10k_sdio mmc1:0001:1: payload length 57005 exceeds max htc length: 4088 .... [ 264.990191] ath10k_sdio mmc1:0001:1: payload length 57005 exceeds max htc length: 4088 4. after some time, such as 60 seconds, it start recovery which triggered by wmi command timeout for periodic scan. [ 269.229232] ieee80211 phy0: Hardware restart was requested [ 269.734693] ath10k_sdio mmc1:0001:1: device successfully recovered The simulate fail of sdio is not a real sdio transter fail, it only set an error status in mmc_should_fail_request after the transfer end, actually the transfer is success, then sdio_io_rw_ext_helper will return error status and stop transfer the left data. For example, the really RX len is 286 bytes, then it will split to 2 blocks in sdio_io_rw_ext_helper, one is 256 bytes, left is 30 bytes, if the first 256 bytes get an error status by mmc_should_fail_request,then the left 30 bytes will not read in this RX operation. Then when the next RX arrive, the left 30 bytes will be considered as the header of the read, the top 4 bytes of the 30 bytes will be considered as lookaheads, but actually the 4 bytes is not the lookaheads, so the len from this lookaheads is not correct, it exceeds max htc length 4088 sometimes. When happened exceeds, the buffer chain is not matched between firmware and ath10k, then it need to start recovery ASAP. Recently then recovery will be started by wmi command timeout, but it will be long time later, for example, it is 60+ seconds later from the periodic scan, if it does not have periodic scan, it will be longer. Start recovery when it happened "payload length exceeds max htc length" will be reasonable. This patch only effect sdio chips. Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00029. Signed-off-by: Wen Gong Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20200108031957.22308-3-wgong@codeaurora.org Signed-off-by: Sasha Levin --- drivers/net/wireless/ath/ath10k/sdio.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/net/wireless/ath/ath10k/sdio.c b/drivers/net/wireless/ath/ath10k/sdio.c index 8fe626deadeb0..24b1927a07518 100644 --- a/drivers/net/wireless/ath/ath10k/sdio.c +++ b/drivers/net/wireless/ath/ath10k/sdio.c @@ -550,6 +550,10 @@ static int ath10k_sdio_mbox_rx_alloc(struct ath10k *ar, le16_to_cpu(htc_hdr->len), ATH10K_HTC_MBOX_MAX_PAYLOAD_LENGTH); ret = -ENOMEM; + + queue_work(ar->workqueue, &ar->restart_work); + ath10k_warn(ar, "exceeds length, start recovery\n"); + goto err; } -- 2.27.0