Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp570902pxb; Thu, 30 Sep 2021 12:05:50 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw94QFaXsMQaQYUltT3e24ZSzYl08R4XFYLiO0nziZFO5vz8gdURIuy1n2d+5ywlSawyrKc X-Received: by 2002:a62:1d8a:0:b0:44b:9660:41f6 with SMTP id d132-20020a621d8a000000b0044b966041f6mr6962781pfd.7.1633028749983; Thu, 30 Sep 2021 12:05:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633028749; cv=none; d=google.com; s=arc-20160816; b=N8suaXE9fTUtfkH7e5a56wl6o60GW09+Q3b95+nOi61sxis2zSA43Ww+EfAzO4UVdD PdtBnAJgncOC+jiqurnd0M++53EcKcXVn+nboefpW70XoVDJRY4jKP2L1/pxyW1xoUyo isv8tUFDMUyoPM7f46ThbIkG41XTGNmScTy7YsJphv6/bMTfORW0nKFEoHf2+V2hUFpD yFjfHlFzfxe0tiBMpG9UNfIg0r6dJRAFIt+Zf9X14yLx6W1286A3g93pomA1rHfY5oeD VT8FmWy0uTmhDC1eVCj3QLfxrIMcLIT/GCC7JabFEaLFBD8KQrBRSkoaiVYfYo6QNOJr TcRA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:date:message-id:from:references:cc:to :subject; bh=rHyTWO+/twmDj7NWHg9iHTWv3cZKUp0FCTJdPRwUfAY=; b=gPam1zKo+1sxVHolHHoN521QAo652CuWC0uDagC8Fuq/KNSitRllUxSlVdtINDCTtK vXYCItPy1KTuDzeksWo7WzzuOaTMxSQZDXZEXAd8dMRkvch5RMJUVDNMcv0JYVdYF/XJ kjwvCCqDZb7P7lOlkqP1eOnw+HCNmQ/F3URkODd2M9XzCDlLetqWV8bz5W0yd9Jlzgy2 V+doLEvIPw051wUk907zUL3EymNrYaxiFHFcmy1IbrUnPlEAizzquU+tICpjWVkM4YQI LnFykOOLyNuoeGp5R7rrw7Ny0GkO6+TQHf53de0GKKDzVcXc/keqjkYm8jTA+3iazVea S02Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c17si4494687pfb.223.2021.09.30.12.05.36; Thu, 30 Sep 2021 12:05:49 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1352986AbhI3SFw (ORCPT + 78 others); Thu, 30 Sep 2021 14:05:52 -0400 Received: from mout-p-101.mailbox.org ([80.241.56.151]:36742 "EHLO mout-p-101.mailbox.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229699AbhI3SFw (ORCPT ); Thu, 30 Sep 2021 14:05:52 -0400 Received: from smtp1.mailbox.org (smtp1.mailbox.org [IPv6:2001:67c:2050:105:465:1:1:0]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-101.mailbox.org (Postfix) with ESMTPS id 4HL1Mq0ttGzQkBY; Thu, 30 Sep 2021 20:04:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at heinlein-support.de Subject: Re: [PATCH v2 2/2] mwifiex: Try waking the firmware until we get an interrupt To: Andy Shevchenko Cc: Amitkumar Karwar , Ganapathi Bhat , Xinming Hu , Kalle Valo , "David S. Miller" , Jakub Kicinski , Tsuchiya Yuto , linux-wireless@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org, Maximilian Luz , Bjorn Helgaas , =?UTF-8?Q?Pali_Roh=c3=a1r?= , Heiner Kallweit , Johannes Berg , Brian Norris , stable@vger.kernel.org References: <20210914114813.15404-1-verdre@v0yd.nl> <20210914114813.15404-3-verdre@v0yd.nl> From: =?UTF-8?Q?Jonas_Dre=c3=9fler?= Message-ID: Date: Thu, 30 Sep 2021 20:04:00 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 839D1188F Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org On 9/22/21 1:19 PM, Andy Shevchenko wrote: > On Tue, Sep 14, 2021 at 01:48:13PM +0200, Jonas Dreßler wrote: >> It seems that the firmware of the 88W8897 card sometimes ignores or >> misses when we try to wake it up by writing to the firmware status >> register. This leads to the firmware wakeup timeout expiring and the >> driver resetting the card because we assume the firmware has hung up or >> crashed (unfortunately that's not unlikely with this card). >> >> Turns out that most of the time the firmware actually didn't hang up, >> but simply "missed" our wakeup request and didn't send us an AWAKE >> event. >> >> Trying again to read the firmware status register after a short timeout >> usually makes the firmware wake up as expected, so add a small retry >> loop to mwifiex_pm_wakeup_card() that looks at the interrupt status to >> check whether the card woke up. >> >> The number of tries and timeout lengths for this were determined >> experimentally: The firmware usually takes about 500 us to wake up >> after we attempt to read the status register. In some cases where the >> firmware is very busy (for example while doing a bluetooth scan) it >> might even miss our requests for multiple milliseconds, which is why >> after 15 tries the waiting time gets increased to 10 ms. The maximum >> number of tries it took to wake the firmware when testing this was >> around 20, so a maximum number of 50 tries should give us plenty of >> safety margin. >> >> A good reproducer for this issue is letting the firmware sleep and wake >> up in very short intervals, for example by pinging a device on the >> network every 0.1 seconds. > > ... > >> + do { >> + if (mwifiex_write_reg(adapter, reg->fw_status, FIRMWARE_READY_PCIE)) { >> + mwifiex_dbg(adapter, ERROR, >> + "Writing fw_status register failed\n"); >> + return -EIO; >> + } >> + >> + n_tries++; >> + >> + if (n_tries <= N_WAKEUP_TRIES_SHORT_INTERVAL) >> + usleep_range(400, 700); >> + else >> + msleep(10); >> + } while (n_tries <= N_WAKEUP_TRIES_SHORT_INTERVAL + N_WAKEUP_TRIES_LONG_INTERVAL && >> + READ_ONCE(adapter->int_status) == 0); > > Can't you use read_poll_timeout() twice instead of this custom approach? > I've tried this now, but read_poll_timeout() is not ideal for our use-case. What we'd need would be read->sleep->poll->repeat instead of read->poll->sleep->repeat. With read_poll_timeout() we always end up doing one more (unnecessary) write. >> + mwifiex_dbg(adapter, EVENT, >> + "event: Tried %d times until firmware woke up\n", n_tries); >