Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758019AbcK2P3D (ORCPT ); Tue, 29 Nov 2016 10:29:03 -0500 Received: from smtp.codeaurora.org ([198.145.29.96]:45232 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757116AbcK2P25 (ORCPT ); Tue, 29 Nov 2016 10:28:57 -0500 DMARC-Filter: OpenDMARC Filter v1.3.1 smtp.codeaurora.org CB2E9611A5 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=pass smtp.mailfrom=kvalo@codeaurora.org Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: mwifiex: pcie: implement timeout loop for FW programming doorbell From: Kalle Valo In-Reply-To: <1479868785-16263-1-git-send-email-briannorris@chromium.org> References: <1479868785-16263-1-git-send-email-briannorris@chromium.org> To: Brian Norris Cc: Amitkumar Karwar , Nishant Sarmukadam , , linux-wireless@vger.kernel.org, Cathy Luo , Dmitry Torokhov , Brian Norris User-Agent: pwcli/0.0.0-git (https://github.com/kvalo/pwcli/) Python/2.7.3 Message-Id: <20161129152856.ECB9A612BA@smtp.codeaurora.org> Date: Tue, 29 Nov 2016 15:28:56 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1345 Lines: 31 Brian Norris wrote: > Marvell Wifi PCIe modules don't always behave nicely for PCIe power > management when their firmware hasn't been loaded, particularly after > suspending the PCIe link one or more times. When this happens, we might > end up spinning forever in this status-polling tight loop. Let's make > this less tight by adding a timeout and by sleeping a bit in between > reads, as we do with the other similar loops. > > This prevents us from hogging a CPU even in such pathological cases, and > allows the FW initialization to just fail gracefully instead. > > I chose the same polling parameters as the earlier loop in this > function, and empirically, I found that this loop never makes it more > than about 12 cycles in a sane FW init sequence. I had no official > information on the actual intended latency for this portion of the > download. > > Signed-off-by: Brian Norris > Acked-by: Amitkumar Karwar Patch applied to wireless-drivers-next.git, thanks. 22dde1ed5a48 mwifiex: pcie: implement timeout loop for FW programming doorbell -- https://patchwork.kernel.org/patch/9442499/ Documentation about submitting wireless patches and checking status from patchwork: https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches