Re: [PATCH v10 3/3] firmware: qcom_scm: Use TASK_IDLE state in wait_for_wq_completion()

From: Mukesh Ojha

Date: Thu Dec 04 2025 - 02:36:09 EST


On Wed, Dec 03, 2025 at 04:27:25PM +0530, Shivendra Pratap wrote:
>
>
> On 12/3/2025 2:01 PM, Mukesh Ojha wrote:
> > On Sun, Nov 30, 2025 at 08:11:04PM +0530, Shivendra Pratap wrote:
> >> From: Unnathi Chalicheemala <unnathi.chalicheemala@xxxxxxxxxxxxxxxx>
> >>
> >> When the kernel issues an SMC (Secure Monitor Call) and the firmware
> >> requests the kernel to wait, the waiting thread enters an
> >> uninterruptible (D) state. In case of an extended wait request by the
> >> firmware, any device suspend request, cannot proceed because of the
> >> thread stuck in D state. This blocks the device suspend.
> >
> > Not only that, it is stuck in D state after holding a mutex, which is
> > more severe because none of the SMC calls can go through. However, this
> > has been the case since the day the firmware started supporting waitq
> > with a single context, which is somewhat acceptable as the firmware does
> > not allow otherwise. Since, you are adding the multiple waitq context
> > supported by firmware with your other patches,
> >
> > Do you plan to support multiple waitq contexts i.e parallel SCM calls,
> > in SCM driver as well ?
>
> Yes. Parallel SCM can be enabled once this waitq enablement support is
> in place.

Thanks.

Reviewed-by: Mukesh Ojha <mukesh.ojha@xxxxxxxxxxxxxxxx>

>
> thanks,
> Shivendra

--
-Mukesh Ojha