[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPDyKFoSr72bKd3qzYi9QZT5L3DewjEYjRExE+V4XmdiqHLkXw@mail.gmail.com>
Date: Thu, 17 Dec 2020 18:11:54 +0100
From: Ulf Hansson <ulf.hansson@...aro.org>
To: Bhaskara Budiredla <bbudiredla@...vell.com>
Cc: Kees Cook <keescook@...omium.org>,
Colin Cross <ccross@...roid.com>,
Tony Luck <tony.luck@...el.com>,
Sunil Kovvuri Goutham <sgoutham@...vell.com>,
"linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Christoph Hellwig <hch@....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 <bbudiredla@...vell.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
Kind regards
Uffe
Powered by blists - more mailing lists