[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+ASDXN34u8mAVdhbfSK14pG_9qUcPvK4tFEywN4s2grqyu9=g@mail.gmail.com>
Date: Mon, 27 Sep 2021 13:30:03 -0700
From: Brian Norris <briannorris@...omium.org>
To: Jonas Dreßler <verdre@...d.nl>
Cc: Amitkumar Karwar <amitkarwar@...il.com>,
Ganapathi Bhat <ganapathi017@...il.com>,
Xinming Hu <huxinming820@...il.com>,
Kalle Valo <kvalo@...eaurora.org>,
"David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
Tsuchiya Yuto <kitakar@...il.com>,
linux-wireless <linux-wireless@...r.kernel.org>,
"<netdev@...r.kernel.org>" <netdev@...r.kernel.org>,
Linux Kernel <linux-kernel@...r.kernel.org>,
linux-pci <linux-pci@...r.kernel.org>,
Maximilian Luz <luzmaximilian@...il.com>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Bjorn Helgaas <bhelgaas@...gle.com>,
Pali Rohár <pali@...nel.org>,
Heiner Kallweit <hkallweit1@...il.com>,
Johannes Berg <johannes@...solutions.net>
Subject: Re: [PATCH v2 0/2] mwifiex: Work around firmware bugs on 88W8897 chip
On Tue, Sep 14, 2021 at 4:48 AM Jonas Dreßler <verdre@...d.nl> wrote:
>
> This is the second revision of the patch, the first one is here:
> https://lore.kernel.org/linux-wireless/20210830123704.221494-1-verdre@v0yd.nl/
>
> Changes between v1 and v2:
> - Only read-back the register write to the TX ring write pointer, not all writes
> - Mention firmware version in commit message+code comment for future reference
> - Use -EIO return value in second patch
> - Use definitions for waiting intervals in second patch
I tested this version, and it doesn't have the same issues v1 had
(regarding long-blocking reads, causing audio dropouts, etc.), so:
Tested-by: Brian Norris <briannorris@...omium.org>
As suggested elsewhere, this polling loop approach is a little slower
than just waiting for an interrupt instead (and that proves out; the
wakeup latency seems to increase by ~1 "short" polling interval; so
about half a millisecond). It seems like that could be optimized if
needed, because you *are* still waiting for an interrupt anyway. But I
haven't tried benchmarking anything that would really matter for this;
when we're already waiting 6+ ms, another 0.5ms isn't the end of the
world.
This doesn't really count as Reviewed-by. There are probably better
improvements to the poling loop (e.g., Andy's existing suggestions);
and frankly, I'd rather see if the dropped writes can be fixed
somehow. But I'm not holding my breath for the latter, and don't have
any good suggestions. So if this is the best we can do, so be it.
Regards,
Brian
Powered by blists - more mailing lists