From: Tsuchiya Yuto <kitakar@gmail.com>
To: Brian Norris <briannorris@chromium.org>
Cc: Amitkumar Karwar <amitkarwar@gmail.com>,
Ganapathi Bhat <ganapathi.bhat@nxp.com>,
Xinming Hu <huxinming820@gmail.com>,
Kalle Valo <kvalo@codeaurora.org>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
linux-wireless <linux-wireless@vger.kernel.org>,
"<netdev@vger.kernel.org>" <netdev@vger.kernel.org>,
Linux Kernel <linux-kernel@vger.kernel.org>,
Maximilian Luz <luzmaximilian@gmail.com>,
Andy Shevchenko <andriy.shevchenko@intel.com>,
verdre@v0yd.nl
Subject: Re: [PATCH 1/3] mwifiex: disable ps_mode explicitly by default instead
Date: Fri, 30 Oct 2020 17:04:34 +0900 [thread overview]
Message-ID: <8fa12bfff1cc30b655934e303cad78ae75b0fcde.camel@gmail.com> (raw)
In-Reply-To: <CA+ASDXMfuqy=kCECktP_mYm9cAapXukeLhe=1i3uPbTu9wS2Qw@mail.gmail.com>
On Thu, 2020-10-29 at 11:25 -0700, Brian Norris wrote:
> On Wed, Oct 28, 2020 at 7:04 PM Tsuchiya Yuto <kitakar@gmail.com> wrote:
> >
> > On Microsoft Surface devices (PCIe-88W8897), the ps_mode causes
> > connection unstable, especially with 5GHz APs. Then, it eventually causes
> > fw crash.
> >
> > This commit disables ps_mode by default instead of enabling it.
> >
> > Required code is extracted from mwifiex_drv_set_power().
> >
> > Signed-off-by: Tsuchiya Yuto <kitakar@gmail.com>
>
> You should read up on WIPHY_FLAG_PS_ON_BY_DEFAULT and
> CONFIG_CFG80211_DEFAULT_PS, and set/respect those appropriately (hint:
> mwifiex sets WIPHY_FLAG_PS_ON_BY_DEFAULT, and your patch makes this a
> lie). Also, this seems like a quirk that you haven't properly worked
> out -- if you're working on a quirk framework in your other series,
> you should just key into that.
Thanks for the review! I didn't know about the flag, much appreciated.
By setting the flag to false explicitly, indeed userspace doesn't try
to enable power_save now at least for this short amount of time. I wonder
if I can drop the second patch (adding module parameter) now. But I still
want to make sure that power_save won't be enabled by userspace tools by
default.
Regarding quirks, I also don't want to break existing users. So, of course
I can try to use the quirk framework if we really can't fix the firmware.
> For the record, Chrome OS supports plenty of mwifiex systems with 8897
> (SDIO only) and 8997 (PCIe), with PS enabled, and you're hurting
> those. Your problem sounds to be exclusively a problem with the PCIe
> 8897 firmware.
Actually, I already know that some Chromebooks use these mwifiex cards
(but not out PCIe-88W8897) because I personally like chromiumos. I'm
always wondering what is the difference. If the difference is firmware,
our PCIe-88W8897 firmware should really be fixed instead of this stupid
series.
Yes, I'm sorry that I know this series is just a stupid one but I have to
send this anyway because this stability issue has not been fixed for a
long time. I should have added this buglink to every commit as well:
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=109681
If the firmware can't be fixed, I'm afraid I have to go this way. It makes
no sense to keep enabling power_save for the affected devices if we know
it's broken.
> As-is, NAK.
>
> Brian
next prev parent reply other threads:[~2020-10-30 8:04 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-28 14:24 [PATCH 0/3] mwifiex: disable ps_mode by default for stability Tsuchiya Yuto
2020-10-28 14:24 ` [PATCH 1/3] mwifiex: disable ps_mode explicitly by default instead Tsuchiya Yuto
2020-10-29 18:25 ` Brian Norris
2020-10-29 18:36 ` Andy Shevchenko
2020-10-29 18:56 ` Brian Norris
2020-10-30 8:04 ` Tsuchiya Yuto [this message]
2020-11-20 21:04 ` Brian Norris
2020-11-26 19:44 ` Tsuchiya Yuto
2020-10-28 14:24 ` [PATCH 2/3] mwifiex: add allow_ps_mode module parameter Tsuchiya Yuto
2020-10-28 22:04 ` Brian Norris
2020-10-29 17:04 ` Willem de Bruijn
2020-10-30 8:02 ` Tsuchiya Yuto
2020-10-30 7:58 ` Tsuchiya Yuto
2020-10-30 11:02 ` Andy Shevchenko
2020-11-02 9:18 ` Tsuchiya Yuto
2020-10-28 14:24 ` [PATCH 3/3] mwifiex: print message when changing ps_mode Tsuchiya Yuto
[not found] ` <20201028152115.GT4077@smile.fi.intel.com>
2020-10-30 8:26 ` [PATCH 0/3] mwifiex: disable ps_mode by default for stability Tsuchiya Yuto
2020-12-20 21:43 ` 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=8fa12bfff1cc30b655934e303cad78ae75b0fcde.camel@gmail.com \
--to=kitakar@gmail.com \
--cc=amitkarwar@gmail.com \
--cc=andriy.shevchenko@intel.com \
--cc=briannorris@chromium.org \
--cc=davem@davemloft.net \
--cc=ganapathi.bhat@nxp.com \
--cc=huxinming820@gmail.com \
--cc=kuba@kernel.org \
--cc=kvalo@codeaurora.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=luzmaximilian@gmail.com \
--cc=netdev@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 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).