[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BN6PR1801MB2068B9F13F0E21BF726562E5DEC40@BN6PR1801MB2068.namprd18.prod.outlook.com>
Date: Thu, 17 Dec 2020 11:36:34 +0000
From: Bhaskara Budiredla <bbudiredla@...vell.com>
To: Ulf Hansson <ulf.hansson@...aro.org>
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
[...]
>> >> 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()?
Thanks,
Bhaskara
Powered by blists - more mailing lists