From: "Jonas Dreßler" <verdre@v0yd.nl>
To: "Pali Rohár" <pali@kernel.org>,
"Andy Shevchenko" <andy.shevchenko@gmail.com>
Cc: Brian Norris <briannorris@chromium.org>,
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 <linux-wireless@vger.kernel.org>,
netdev@vger.kernel.org,
Linux Kernel <linux-kernel@vger.kernel.org>,
linux-pci <linux-pci@vger.kernel.org>,
Maximilian Luz <luzmaximilian@gmail.com>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Bjorn Helgaas <bhelgaas@google.com>
Subject: Re: [PATCH 1/2] mwifiex: Use non-posted PCI register writes
Date: Thu, 30 Sep 2021 17:38:43 +0200 [thread overview]
Message-ID: <db583b3c-6bfc-d765-a588-eb47c76cea31@v0yd.nl> (raw)
In-Reply-To: <20210923202231.t2zjoejpxrbbe5hc@pali>
On 9/23/21 10:22 PM, Pali Rohár wrote:
> On Thursday 23 September 2021 22:41:30 Andy Shevchenko wrote:
>> On Thu, Sep 23, 2021 at 6:28 PM Jonas Dreßler <verdre@v0yd.nl> wrote:
>>> On 9/22/21 2:50 PM, Jonas Dreßler wrote:
>>
>> ...
>>
>>> - Just calling mwifiex_write_reg() once and then blocking until the card
>>> wakes up using my delay-loop doesn't fix the issue, it's actually
>>> writing multiple times that fixes the issue
>>>
>>> These observations sound a lot like writes (and even reads) are actually
>>> being dropped, don't they?
>>
>> It sounds like you're writing into a not ready (fully powered on) device.
>
> This reminds me a discussion with Bjorn about CRS response returned
> after firmware crash / reset when device is not ready yet:
> https://lore.kernel.org/linux-pci/20210922164803.GA203171@bhelgaas/
>
> Could not be this similar issue? You could check it via reading
> PCI_VENDOR_ID register from config space. And if it is not valid value
> then card is not really ready yet.
>
>> To check this, try to put a busy loop for reading and check the value
>> till it gets 0.
>>
>> Something like
>>
>> unsigned int count = 1000;
>>
>> do {
>> if (mwifiex_read_reg(...) == 0)
>> break;
>> } while (--count);
>>
>>
>> --
>> With Best Regards,
>> Andy Shevchenko
I've tried both reading PCI_VENDOR_ID and the firmware status using a
busy loop now, but sadly none of them worked. It looks like the card
always replies with the correct values even though it sometimes won't
wake up after that.
I do have one new observation though, although I've no clue what could
be happening here: When reading PCI_VENDOR_ID 1000 times to wakeup we
can "predict" the wakeup failure because exactly one (usually around the
20th) of those 1000 reads will fail. Maybe the firmware actually tries
to wake up, encounters an error somewhere in its wakeup routines and
then goes down a special failure code path. That code path keeps the
cards CPU so busy that at some point a PCI_VENDOR_ID request times out?
Or well, maybe the card actually wakes up fine, but we don't receive the
interrupt on our end, so many possibilities...
next prev parent reply other threads:[~2021-09-30 15:38 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-30 12:37 [PATCH 0/2] mwifiex: Work around firmware bugs on 88W8897 chip Jonas Dreßler
2021-08-30 12:37 ` [PATCH 1/2] mwifiex: Use non-posted PCI register writes Jonas Dreßler
2021-08-30 12:49 ` Andy Shevchenko
2021-09-01 14:01 ` Jonas Dreßler
2021-09-01 15:47 ` Andy Shevchenko
2021-09-01 15:51 ` Pali Rohár
2021-09-01 16:51 ` Heiner Kallweit
2021-09-01 17:07 ` Johannes Berg
2021-09-01 19:07 ` Heiner Kallweit
2021-09-01 22:41 ` Bjorn Helgaas
2021-09-02 14:05 ` Bjorn Helgaas
2021-09-01 19:40 ` Brian Norris
2021-09-01 20:40 ` Andy Shevchenko
2021-09-01 21:04 ` Brian Norris
2021-09-01 21:07 ` Brian Norris
2021-09-18 7:37 ` Jonas Dreßler
2021-09-20 17:48 ` Brian Norris
2021-09-22 12:50 ` Jonas Dreßler
2021-09-23 15:28 ` Jonas Dreßler
2021-09-23 19:37 ` Andy Shevchenko
2021-09-23 19:41 ` Andy Shevchenko
2021-09-23 20:22 ` Pali Rohár
2021-09-30 15:38 ` Jonas Dreßler [this message]
2021-09-30 15:42 ` Pali Rohár
2021-09-30 16:14 ` Jonas Dreßler
2021-09-30 16:19 ` Pali Rohár
2021-09-30 16:22 ` Jonas Dreßler
2021-09-30 16:39 ` Pali Rohár
2021-08-30 12:37 ` [PATCH 2/2] mwifiex: Try waking the firmware until we get an interrupt Jonas Dreßler
2021-08-30 12:51 ` Andy Shevchenko
2021-08-30 12:55 ` Andy Shevchenko
2021-09-25 17:32 ` [PATCH 0/2] mwifiex: Work around firmware bugs on 88W8897 chip Pali Rohár
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=db583b3c-6bfc-d765-a588-eb47c76cea31@v0yd.nl \
--to=verdre@v0yd.nl \
--cc=amitkarwar@gmail.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=andy.shevchenko@gmail.com \
--cc=bhelgaas@google.com \
--cc=briannorris@chromium.org \
--cc=davem@davemloft.net \
--cc=ganapathi017@gmail.com \
--cc=huxinming820@gmail.com \
--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 \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).