From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail.candelatech.com ([208.74.158.172] helo=ns3.lanforge.com) by merlin.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1Ve6Kq-00061F-BT for ath10k@lists.infradead.org; Wed, 06 Nov 2013 16:52:05 +0000 Message-ID: <527A739C.4060807@candelatech.com> Date: Wed, 06 Nov 2013 08:51:40 -0800 From: Ben Greear MIME-Version: 1.0 Subject: Re: What to do about hung firmware? References: <52793E4B.20302@candelatech.com> <87ob5yt1kp.fsf@kamboji.qca.qualcomm.com> In-Reply-To: <87ob5yt1kp.fsf@kamboji.qca.qualcomm.com> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "ath10k" Errors-To: ath10k-bounces+kvalo=adurom.com@lists.infradead.org To: Kalle Valo Cc: Michal Kazior , ath10k@lists.infradead.org On 11/05/2013 11:46 PM, Kalle Valo wrote: > Michal Kazior writes: > >> You probably could try WMI_ECHO_CMDID to implement a keep alive when >> idling (i.e. not sending WMI commands for a few seconds at least). > > Sending something periodically would be bad from power consumption point > of view. We would need to either disable it by default, only send it if > there's a problem or something like that. Ok, how about this: If we hit the 3*HZ timeout, then we send a ping to the firmware even if we are out of tickets. If we get no response to that in 3*HZ or so, then consider firmware hung and reset it. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k