From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from sabertooth01.qualcomm.com ([65.197.215.72]) by merlin.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1WNHoZ-0003Kz-Kb for ath10k@lists.infradead.org; Tue, 11 Mar 2014 08:13:32 +0000 From: Kalle Valo Subject: Re: ath10k driver crashes whenever firmware crashes on ARM SoC References: <871tzq210z.fsf@kamboji.qca.qualcomm.com> <871ty9jijp.fsf@kamboji.qca.qualcomm.com> Date: Tue, 11 Mar 2014 10:13:01 +0200 In-Reply-To: (Adrian Chadd's message of "Tue, 11 Mar 2014 00:52:54 -0700") Message-ID: <87siqpi25u.fsf@kamboji.qca.qualcomm.com> MIME-Version: 1.0 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: Adrian Chadd Cc: "ath10k@lists.infradead.org" , Avery Pennarun (Fixing top posting) Adrian Chadd writes: > On 11 March 2014 00:40, Avery Pennarun wrote: > >> We do have a separate reset line controlled by a GPIO. Using that >> crashes the SoC's PCIe host implementation (whee!). But I got help >> from the SoC manufacturer and was able to get some instructions for >> resetting their PCIe host controller. When I do all the magic >> incantations in the right order, the system can recover, albeit with a >> fully reset ath10k chip. This workaround is unfortunately specific to >> the host device platform so it won't do you much good. > > ... it's not a complete loss! > > This to me says "we need a hook from the driver to call the host > "reset the bus" thing". > > We also kinda need it for ath9k/ath5k (if it's not there) so AHB > attached things can be reset by actually poking an SoC reset register. Yeah, that kind of hook would be good to have. -- Kalle Valo _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k