From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id ED325C433F5 for ; Wed, 15 Sep 2021 10:06:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CD85860F51 for ; Wed, 15 Sep 2021 10:06:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232243AbhIOKIQ (ORCPT ); Wed, 15 Sep 2021 06:08:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55698 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232071AbhIOKIP (ORCPT ); Wed, 15 Sep 2021 06:08:15 -0400 Received: from mout-p-201.mailbox.org (mout-p-201.mailbox.org [IPv6:2001:67c:2050::465:201]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 95508C061574 for ; Wed, 15 Sep 2021 03:06:56 -0700 (PDT) Received: from smtp2.mailbox.org (smtp2.mailbox.org [80.241.60.241]) (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-201.mailbox.org (Postfix) with ESMTPS id 4H8bV51YszzQkSX; Wed, 15 Sep 2021 12:06:53 +0200 (CEST) X-Virus-Scanned: amavisd-new at heinlein-support.de Subject: Re: [EXT] Re: mwifiex cmd timeout on one pci variant To: Dominique MARTINET Cc: Sharvari Harisangam , "linux-wireless@vger.kernel.org" , Amitkumar Karwar , Takashi Iwai , Tsuchiya Yuto , Geert Uytterhoeven , Arnd Bergmann , Lee Jones , Kalle Valo , Xinming Hu , Ganapathi Bhat References: From: =?UTF-8?Q?Jonas_Dre=c3=9fler?= Message-ID: <9337f5b5-71e4-ce35-b7ce-872fdf3d91a0@v0yd.nl> Date: Wed, 15 Sep 2021 12:06:46 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 04FBD183C Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org On 9/15/21 3:43 AM, Dominique MARTINET wrote: > Hi Jonas, > > Jonas Dreßler wrote on Tue, Sep 14, 2021 at 12:11:46PM +0200: >> regarding the firmware version, as you can see in the commit updating the >> firmware binaries (https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/mrvl/pcie8897_uapsta.bin?id=1a5773c0c89ee44cee51a285d5c7c1063cdb0891), >> indeed the version numbering differs between the different versions of the >> card (usb/usb, pcie/usb, pcie/uart(?)). > > Right. The update frequency is also quite different, so I'm assuming the > pcie/uart version I'm using has a lot of vulnerabilities left open as > well... > > >> Anyway, if you manage to find newer firmware for any of those versions, I'd >> be happy if you could point me to that, apparently they just fixed a >> critical vulnerability in the Windows firmware again (see https://support.microsoft.com/en-us/surface/surface-pro-5th-gen-update-history-5203144a-90c1-63df-ce0b-7ec7ff32ff10), >> I wouldn't be surprised if our firmware is also affected by that. > > That sounds like a safe bet.. > I assume the firmwares are not compatible and we can't just load these? Yeah, they're quite similar and seem to descend from the same codebase, but the APIs between the kernel driver and the firmware are very different. > > >> About the command timeout, I have no idea why the fix isn't working for you, >> but well, my analysis of the issue is also just a (not exactly educated) >> guess, so it might as well be a completely different problem and my fix is >> just a lucky hack. > > Right, it really depends on why the firmware crashed, but we have no way > of investigating that at the moment. One more thing that comes to mind after reading this discussion https://lore.kernel.org/linux-wireless/eb555433-ade1-e89e-30e4-f4c1c24c25e7@gmail.com/ is that maybe the read-back is really only serving the purpose of a udelay(), so if you want you can try playing around with that a bit instead of the read-back. > >> I'd kinda hope though that my proposed patches finally wake up some people >> at NXP and motivate them to take a look at that firmware repo again. > > If it works well enough it could be a reason not to bother :D > Alternatively if they can't spend time on it maybe open the firmware > code (under NDA? my company probably already has one with NXP..), but > my problem will need more time to reach them through regular channels. >