Closed kitakar5525 closed 4 years ago
I feel that we don't need the patch mwifiex: pcie: disable bridge_d3 for Surface gen4+
anymore. When I tried on Arch's v5.8 kernel, it survived several suspend. And the bridge_d3 was already set to false
. But I'm not so sure. For now, let's keep the patch and investigate it later.
I feel that we don't need the patch
mwifiex: pcie: disable bridge_d3 for Surface gen4+
anymore. When I tried on Arch's v5.8 kernel, it survived several suspend. And the bridge_d3 was already set tofalse
. But I'm not so sure. For now, let's keep the patch and investigate it later.
Interesting. You could try to add a sysfs file to override the quirks from user-space. That should allow us to test if different things are still needed without having to re-compile things, at least if they're implemented as quirks.
Hi, I slightly cleaned up mwifiex patches.
mwifiex: pcie: disable bridge_d3 for Surface gen4+
Changes from the previous patch:mwifiex: add allow_ps_mode module parameter
Changes from the previous patch:-EPERM
instead of-1
for return value when enabling ps_mode is disallowed by modparamallow_ps_mode
modparam permission from0444
to0644
because it can be changed after probe as wellmwifiex: mwifiex: print message when changing ps_mode
Changes from the previous patch:mwifiex: disable ps_mode explicitly by default instead
Changes from previous patch:mwifiex: sta_cmd: add comment for not enabling ps_mode by default
andmwifiex: sta_cmd: do not enable ps_mode by default
Removing the code that enables ps_mode might be enough, but there's also no reason not to explicitly disable it. So, let's disable it explicitly.