[...]
>> >> 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
On Thu, 17 Dec 2020 at 12:36, Bhaskara Budiredla <[email protected]> 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
>-----Original Message-----
>From: Ulf Hansson <[email protected]>
>Sent: Thursday, December 17, 2020 10:42 PM
>To: Bhaskara Budiredla <[email protected]>
>Cc: Kees Cook <[email protected]>; Colin Cross
><[email protected]>; Tony Luck <[email protected]>; Sunil Kovvuri
>Goutham <[email protected]>; [email protected]; Linux
>Kernel Mailing List <[email protected]>; Christoph Hellwig
><[email protected]>
>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 <[email protected]>
>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