>-----Original Message----- >From: Ulf Hansson <ulf.hans...@linaro.org> >Sent: Thursday, December 17, 2020 10:42 PM >To: Bhaskara Budiredla <bbudire...@marvell.com> >Cc: Kees Cook <keesc...@chromium.org>; Colin Cross ><ccr...@android.com>; Tony Luck <tony.l...@intel.com>; Sunil Kovvuri >Goutham <sgout...@marvell.com>; linux-...@vger.kernel.org; Linux >Kernel Mailing List <linux-kernel@vger.kernel.org>; Christoph Hellwig ><h...@lst.de> >Subject: Re: [EXT] Re: [PATCH 1/2] mmc: Support kmsg dumper based on >pstore/blk > >On Thu, 17 Dec 2020 at 12:36, Bhaskara Budiredla <bbudire...@marvell.com> >wrote: >> >> >> [...] >> >> >> >> An extra check can be added to see if host was runtime suspended >> >> >> ahead of panic write attempt. >> >> > >> >> >What if that is the case, should we just return an error? >> >> > >> >> Yes. >> >> >> >> >Moreover, even the device belonging to the mmc card can be runtime >> >> >suspended too. So if that is the case, we should return an error too? >> >> > >> >> >> >> Yes, same here. >> >> >> >> Please comment if returning error is sufficient here or can there be >> an attempt to wake the device through either of the atomic activation calls: >> pm_runtime_get(), pm_request_resume()? > >Hmm, I would start with playing with the below. mmc_claim_host supports >also nested claims. > >mmc_claim_host(host) - this will call pm_runtime_get_sync(host) >mmc_get_card(card, NULL) - this will call can >pm_runtime_get_sync(card)) and also try to claim the host >
As you suggested I am creating a parallel path that avoids wait queue to claim the host. The *_sync()* routines could sleep, I can't use them as part of panic write. >Kind regards >Uffe Thanks, Bhaskara
