Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp353875pxb; Wed, 3 Nov 2021 05:26:29 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzvoW++wlo8i+CYxv3fX4TzNI2A8BQacAvr1MyB76Ndh3f+WtRfqhQSu7ARPEMXi8v9o6op X-Received: by 2002:a6b:6603:: with SMTP id a3mr31365275ioc.218.1635942389459; Wed, 03 Nov 2021 05:26:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1635942389; cv=none; d=google.com; s=arc-20160816; b=UqfcKx82mvfJq2gr46Jui8AN4g1C6W9hOdy+7i7y64X8/DaveFmitAQ603huW7Se7f 7DaX+SrLa0PBqCYEPTSwzdiypJxyGdjiJDu3NnQ20e/kCK+F/T6IfIxTYVx3BZ5vfd11 t/fkdUQf/CcH+aKoKRJIqiTb+syv3l6x7zxuB/V6D1PvOMUh7i28WTz5JLUCs20U3KG6 hiJfvSEhdC3FYvgpWZtdTtnxTqHuK5ek2RESzbQHN7+lOkw/jvwvQTx3y5/KLxSbT0lo kEDWstYWLTGyO8x/ZaiqxFKQz+MScyWc8RVe0YAXpfFQRuHx41s4IMa40E7++nz5JRmz +ecQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:mime-version:date :message-id; bh=A7D1mKx1JYg09kR3Bx8+t0lSkhRHlmbxztgQq+xr/K8=; b=j0URg5H41WPIKCui7cx6vU+M2/CHR9hLCjWewtugjMhLA5zmPICcYxbbfmrQJi2ew8 3MlzhmfKygmd2y7AbQPEb1eeDaCmkNMw4htN9mjiqavbzpW7S/B/GoPvp9E6P/SYiv5k MLykw58Jy3hU2uS0fcoupxGx+XONicmGG4rfUy1do248i8Ucgq4PJqgA4Zgu6QCSAiYX 6KmRfOBIAXXdXRgVczcQQgyewgp8AI3wnF+w/S2OxzhM6r2lTHouh/1BQoM/USfFq0K5 Xum1uD13RtqNckKk5mHZ4JwPH/xtZOY21XBVaMhJe1lfSM2DWqwkmDMYPVv30z44Gb/m wc+g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y15si3963775ilu.148.2021.11.03.05.25.59; Wed, 03 Nov 2021 05:26:29 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231705AbhKCM23 (ORCPT + 66 others); Wed, 3 Nov 2021 08:28:29 -0400 Received: from mout-p-102.mailbox.org ([80.241.56.152]:52762 "EHLO mout-p-102.mailbox.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229816AbhKCM22 (ORCPT ); Wed, 3 Nov 2021 08:28:28 -0400 Received: from smtp202.mailbox.org (smtp202.mailbox.org [IPv6:2001:67c:2050:105:465:1:4:0]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-102.mailbox.org (Postfix) with ESMTPS id 4HkmFp4rVxzQjXt; Wed, 3 Nov 2021 13:25:50 +0100 (CET) X-Virus-Scanned: amavisd-new at heinlein-support.de Message-ID: Date: Wed, 3 Nov 2021 13:25:44 +0100 MIME-Version: 1.0 Subject: Re: [PATCH] mwifiex: Add quirk to disable deep sleep with certain hardware revision Content-Language: en-US To: Brian Norris Cc: Amitkumar Karwar , Ganapathi Bhat , Xinming Hu , Kalle Valo , "David S. Miller" , Jakub Kicinski , Tsuchiya Yuto , linux-wireless@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Maximilian Luz , Andy Shevchenko , Bjorn Helgaas , =?UTF-8?Q?Pali_Roh=c3=a1r?= References: <20211028073729.24408-1-verdre@v0yd.nl> From: =?UTF-8?Q?Jonas_Dre=c3=9fler?= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 80FB026B Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org On 10/28/21 23:27, Brian Norris wrote: > On Thu, Oct 28, 2021 at 12:37 AM Jonas Dreßler 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 >