lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cc7432f4-824a-abe2-e304-5ba019ac8c89@v0yd.nl>
Date:   Wed, 3 Nov 2021 13:25:44 +0100
From:   Jonas Dreßler <verdre@...d.nl>
To:     Brian Norris <briannorris@...omium.org>
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@...r.kernel.org, netdev@...r.kernel.org,
        linux-kernel@...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>
Subject: Re: [PATCH] mwifiex: Add quirk to disable deep sleep with certain
 hardware revision

On 10/28/21 23:27, Brian Norris wrote:
> On Thu, Oct 28, 2021 at 12:37 AM Jonas Dreßler <verdre@...d.nl> wrote:
>>
>> The 88W8897 PCIe+USB card in the hardware revision 20 apparently has a
>> hardware issue where the card wakes up from deep sleep randomly and very
>> often, somewhat depending on the card activity, maybe the hardware has a
>> floating wakeup pin or something.
> 
> What makes you think it's associated with the particular "hardware
> revision 20"? Have you used multiple revisions on the same platform
> and found that only certain ones fail in this way? Otherwise, your
> theory in the last part of your sentence sounds like a platform issue,
> where you might do a DMI match instead.

The issue only appeared for some community members using Surface devices,
happening on the Surface Book 2 of one person, but not on the Surface Book
2 of another person. When investigating we were poking around in the dark
for a long time and almost gave up until we found that those two devices
had different hardware revisions of the same wifi card installed (ChipRev
20 vs 21).

So it seems pretty clear that with revision 21 they fixed some hardware
bug that causes those spurious wakeups.

FWIW, obviously a proper workaround for this would have to be implemented
in the firmware.

> 
>> --- a/drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c
>> +++ b/drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c
>> @@ -708,6 +708,22 @@ static int mwifiex_ret_ver_ext(struct mwifiex_private *priv,
>>   {
>>          struct host_cmd_ds_version_ext *ver_ext = &resp->params.verext;
>>
>> +       if (test_and_clear_bit(MWIFIEX_IS_REQUESTING_FW_VEREXT, &priv->adapter->work_flags)) {
>> +               if (strncmp(ver_ext->version_str, "ChipRev:20, BB:9b(10.00), RF:40(21)", 128) == 0) {
> 
> Rather than memorize the 128-size array here, maybe use
> sizeof(ver_ext->version_str) ?

Sounds like a good idea, yeah.

> 
> Brian
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ