All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: "Jonas Dreßler" <verdre@v0yd.nl>
Cc: "Amitkumar Karwar" <amitkarwar@gmail.com>,
	"Ganapathi Bhat" <ganapathi017@gmail.com>,
	"Xinming Hu" <huxinming820@gmail.com>,
	"Kalle Valo" <kvalo@codeaurora.org>,
	"David S. Miller" <davem@davemloft.net>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Tsuchiya Yuto" <kitakar@gmail.com>,
	linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
	"Maximilian Luz" <luzmaximilian@gmail.com>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Pali Rohár" <pali@kernel.org>,
	"Heiner Kallweit" <hkallweit1@gmail.com>,
	"Johannes Berg" <johannes@sipsolutions.net>,
	"Brian Norris" <briannorris@chromium.org>,
	stable@vger.kernel.org
Subject: Re: [PATCH v2 2/2] mwifiex: Try waking the firmware until we get an interrupt
Date: Wed, 22 Sep 2021 14:19:43 +0300	[thread overview]
Message-ID: <YUsRT1rmtITJiJRh@smile.fi.intel.com> (raw)
In-Reply-To: <20210914114813.15404-3-verdre@v0yd.nl>

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?

> +	mwifiex_dbg(adapter, EVENT,
> +		    "event: Tried %d times until firmware woke up\n", n_tries);

-- 
With Best Regards,
Andy Shevchenko



  reply	other threads:[~2021-09-22 11:19 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-14 11:48 [PATCH v2 0/2] mwifiex: Work around firmware bugs on 88W8897 chip Jonas Dreßler
2021-09-14 11:48 ` [PATCH v2 1/2] mwifiex: Use non-posted PCI write when setting TX ring write pointer Jonas Dreßler
2021-09-22 11:17   ` Andy Shevchenko
2021-09-22 12:08     ` Jonas Dreßler
2021-09-22 13:22       ` Andy Shevchenko
2021-09-22 14:03   ` David Laight
2021-09-22 14:27     ` Pali Rohár
2021-09-22 15:54       ` David Laight
2021-09-30 14:27         ` Jonas Dreßler
2021-10-06 16:01           ` Jonas Dreßler
2021-09-14 11:48 ` [PATCH v2 2/2] mwifiex: Try waking the firmware until we get an interrupt Jonas Dreßler
2021-09-22 11:19   ` Andy Shevchenko [this message]
2021-09-30 18:04     ` Jonas Dreßler
2021-09-30 20:58       ` Andy Shevchenko
2021-09-30 21:07         ` Jonas Dreßler
2021-09-30 21:16           ` Andy Shevchenko
2021-10-03  9:18   ` Jonas Dreßler
2021-10-04 17:52     ` Brian Norris
2021-09-27 20:30 ` [PATCH v2 0/2] mwifiex: Work around firmware bugs on 88W8897 chip Brian Norris

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YUsRT1rmtITJiJRh@smile.fi.intel.com \
    --to=andriy.shevchenko@linux.intel.com \
    --cc=amitkarwar@gmail.com \
    --cc=bhelgaas@google.com \
    --cc=briannorris@chromium.org \
    --cc=davem@davemloft.net \
    --cc=ganapathi017@gmail.com \
    --cc=hkallweit1@gmail.com \
    --cc=huxinming820@gmail.com \
    --cc=johannes@sipsolutions.net \
    --cc=kitakar@gmail.com \
    --cc=kuba@kernel.org \
    --cc=kvalo@codeaurora.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=luzmaximilian@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=pali@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=verdre@v0yd.nl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.