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=-9.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 7BECFC433F5 for ; Thu, 23 Sep 2021 20:22:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6588761029 for ; Thu, 23 Sep 2021 20:22:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243217AbhIWUYN (ORCPT ); Thu, 23 Sep 2021 16:24:13 -0400 Received: from mail.kernel.org ([198.145.29.99]:60872 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243173AbhIWUYG (ORCPT ); Thu, 23 Sep 2021 16:24:06 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 152C361019; Thu, 23 Sep 2021 20:22:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1632428554; bh=k3zPwqpim6rXUSX3FUMtpizfa7s/LUqUrCFSwGLVMl4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=jl6LFI7LsmrIxAq+IbA9wLE6geSN0xdYvqr1ECzUp3i/VipRQiqfiG6iy9AnfEh0s x5hjdUPf9VR1aTDUBkA/D3XPMoRvlJTX6DVGx8A7SXVg1a6WXzCzWQCsSnA54IVwWB JR2OWHtAAIXnqkUOHOmDZBEEJBoHqQHiQuubeS7FPy8BL6s1gl8AHkc/3rekzE7sBA 8VfIP3T/mMhkSgz6EiySNZTHCgzQ9yv7zo0CiKNgc3P7NYFpPTMwVLmsolCU2325Tc gdaZF7GfIKYvo8+1YarkNKpNyj9JXoIdGEwa3OLXsKi9VSfZnvgZuIkYb+pZZyqUiC 8ALyo4H4zrbqQ== Received: by pali.im (Postfix) id 971AC7D5; Thu, 23 Sep 2021 22:22:31 +0200 (CEST) Date: Thu, 23 Sep 2021 22:22:31 +0200 From: Pali =?utf-8?B?Um9ow6Fy?= To: Andy Shevchenko Cc: Jonas =?utf-8?Q?Dre=C3=9Fler?= , Brian Norris , Amitkumar Karwar , Ganapathi Bhat , Xinming Hu , Kalle Valo , "David S. Miller" , Jakub Kicinski , Tsuchiya Yuto , linux-wireless , netdev@vger.kernel.org, Linux Kernel , linux-pci , Maximilian Luz , Andy Shevchenko , Bjorn Helgaas Subject: Re: [PATCH 1/2] mwifiex: Use non-posted PCI register writes Message-ID: <20210923202231.t2zjoejpxrbbe5hc@pali> References: <20210830123704.221494-2-verdre@v0yd.nl> <0ce93e7c-b041-d322-90cd-40ff5e0e8ef0@v0yd.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20180716 Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org On Thursday 23 September 2021 22:41:30 Andy Shevchenko wrote: > On Thu, Sep 23, 2021 at 6:28 PM Jonas Dreßler wrote: > > On 9/22/21 2:50 PM, Jonas Dreßler wrote: > > ... > > > - Just calling mwifiex_write_reg() once and then blocking until the card > > wakes up using my delay-loop doesn't fix the issue, it's actually > > writing multiple times that fixes the issue > > > > These observations sound a lot like writes (and even reads) are actually > > being dropped, don't they? > > It sounds like you're writing into a not ready (fully powered on) device. This reminds me a discussion with Bjorn about CRS response returned after firmware crash / reset when device is not ready yet: https://lore.kernel.org/linux-pci/20210922164803.GA203171@bhelgaas/ Could not be this similar issue? You could check it via reading PCI_VENDOR_ID register from config space. And if it is not valid value then card is not really ready yet. > To check this, try to put a busy loop for reading and check the value > till it gets 0. > > Something like > > unsigned int count = 1000; > > do { > if (mwifiex_read_reg(...) == 0) > break; > } while (--count); > > > -- > With Best Regards, > Andy Shevchenko