All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Alexey Klimov" <alexey.klimov@linaro.org>
To: "Praveen Talari" <praveen.talari@oss.qualcomm.com>,
	"Praveen Talari" <quic_ptalari@quicinc.com>
Cc: "Jorge Ramirez" <jorge.ramirez@oss.qualcomm.com>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Jiri Slaby" <jirislaby@kernel.org>,
	"Bryan O'Donoghue" <bryan.odonoghue@linaro.org>,
	<linux-arm-msm@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<linux-serial@vger.kernel.org>, <psodagud@quicinc.com>,
	<djaggi@quicinc.com>, <quic_msavaliy@quicinc.com>,
	<quic_vtanuku@quicinc.com>, <quic_arandive@quicinc.com>,
	<quic_shazhuss@quicinc.com>, <krzk@kernel.org>
Subject: Re: [PATCH v1] serial: qcom-geni: Fix pinctrl deadlock on runtime resume
Date: Tue, 16 Sep 2025 18:12:41 +0100	[thread overview]
Message-ID: <DCUE5AXJ99BG.150SRQMY7EJG6@linaro.org> (raw)
In-Reply-To: <aMl9Fbuyq7hdXvQC@trex>

Hi Praveen,

On Tue Sep 16, 2025 at 4:07 PM BST, Jorge Ramirez wrote:
> On 16/09/25 16:39:00, Jorge Ramirez wrote:
>> On 16/09/25 12:20:25, Praveen Talari wrote:
>> > Hi Alexey
>> > 
>> > Thank you for your support.
>> > 
>> > On 9/15/2025 7:55 PM, Praveen Talari wrote:
>> > > Hi Alexey,
>> > > 
>> > > On 9/15/2025 3:09 PM, Alexey Klimov wrote:
>> > > > (removing <quic_mnaresh@quicinc.com> from c/c -- too many mail not
>> > > > delivered)
>> > > > 
>> > > > Hi Praveen,
>> > > > 
>> > > > On Mon Sep 15, 2025 at 7:58 AM BST, Praveen Talari wrote:
>> > > > > Hi Alexey,
>> > > > > 
>> > > > > Really appreciate you waiting!
>> > > > > 
>> > > > > On 9/11/2025 2:30 PM, Alexey Klimov wrote:
>> > > > > > Hi Praveen,
>> > > > > > 
>> > > > > > On Thu Sep 11, 2025 at 9:34 AM BST, Praveen Talari wrote:
>> > > > > > > Hi Alexy,
>> > > > > > > 
>> > > > > > > Thank you for update.
>> > > > > > > 
>> > > > > > > On 9/10/2025 1:35 AM, Alexey Klimov wrote:
>> > > > > > > > 
>> > > > > > > > (adding Krzysztof to c/c)
>> > > > > > > > 
>> > > > > > > > On Mon Sep 8, 2025 at 6:43 PM BST, Alexey Klimov wrote:
>> > > > > > > > > On Mon Sep 8, 2025 at 5:45 PM BST, Praveen Talari wrote:
>> > > > > > > > > > A deadlock is observed in the
>> > > > > > > > > > qcom_geni_serial driver during runtime
>> > > > > > > > > > resume. This occurs when the pinctrl
>> > > > > > > > > > subsystem reconfigures device pins
>> > > > > > > > > > via msm_pinmux_set_mux() while the serial device's interrupt is an
>> > > > > > > > > > active wakeup source. msm_pinmux_set_mux() calls disable_irq() or
>> > > > > > > > > > __synchronize_irq(), conflicting with the active wakeup state and
>> > > > > > > > > > causing the IRQ thread to enter an uninterruptible (D-state) sleep,
>> > > > > > > > > > leading to system instability.
>> > > > > > > > > > 
>> > > > > > > > > > The critical call trace leading to the deadlock is:
>> > > > > > > > > > 
>> > > > > > > > > >        Call trace:
>> > > > > > > > > >        __switch_to+0xe0/0x120
>> > > > > > > > > >        __schedule+0x39c/0x978
>> > > > > > > > > >        schedule+0x5c/0xf8
>> > > > > > > > > >        __synchronize_irq+0x88/0xb4
>> > > > > > > > > >        disable_irq+0x3c/0x4c
>> > > > > > > > > >        msm_pinmux_set_mux+0x508/0x644
>> > > > > > > > > >        pinmux_enable_setting+0x190/0x2dc
>> > > > > > > > > >        pinctrl_commit_state+0x13c/0x208
>> > > > > > > > > >        pinctrl_pm_select_default_state+0x4c/0xa4
>> > > > > > > > > >        geni_se_resources_on+0xe8/0x154
>> > > > > > > > > >        qcom_geni_serial_runtime_resume+0x4c/0x88
>> > > > > > > > > >        pm_generic_runtime_resume+0x2c/0x44
>> > > > > > > > > >        __genpd_runtime_resume+0x30/0x80
>> > > > > > > > > >        genpd_runtime_resume+0x114/0x29c
>> > > > > > > > > >        __rpm_callback+0x48/0x1d8
>> > > > > > > > > >        rpm_callback+0x6c/0x78
>> > > > > > > > > >        rpm_resume+0x530/0x750
>> > > > > > > > > >        __pm_runtime_resume+0x50/0x94
>> > > > > > > > > >        handle_threaded_wake_irq+0x30/0x94
>> > > > > > > > > >        irq_thread_fn+0x2c/xa8
>> > > > > > > > > >        irq_thread+0x160/x248
>> > > > > > > > > >        kthread+0x110/x114
>> > > > > > > > > >        ret_from_fork+0x10/x20
>> > > > > > > > > > 
>> > > > > > > > > > To resolve this, explicitly manage the wakeup IRQ state within the
>> > > > > > > > > > runtime suspend/resume callbacks. In the
>> > > > > > > > > > runtime resume callback, call
>> > > > > > > > > > disable_irq_wake() before enabling resources. This preemptively
>> > > > > > > > > > removes the "wakeup" capability from the IRQ, allowing subsequent
>> > > > > > > > > > interrupt management calls to proceed
>> > > > > > > > > > without conflict. An error path
>> > > > > > > > > > re-enables the wakeup IRQ if resource enablement fails.
>> > > > > > > > > > 
>> > > > > > > > > > Conversely, in runtime suspend, call
>> > > > > > > > > > enable_irq_wake() after resources
>> > > > > > > > > > are disabled. This ensures the interrupt is configured as a wakeup
>> > > > > > > > > > source only once the device has fully
>> > > > > > > > > > entered its low-power state. An
>> > > > > > > > > > error path handles disabling the wakeup IRQ
>> > > > > > > > > > if the suspend operation
>> > > > > > > > > > fails.
>> > > > > > > > > > 
>> > > > > > > > > > Fixes: 1afa70632c39 ("serial: qcom-geni:
>> > > > > > > > > > Enable PM runtime for serial driver")
>> > > > > > > > > > Signed-off-by: Praveen Talari <praveen.talari@oss.qualcomm.com>
>> > > > > > > > > 
>> > > > > > > > > You forgot:
>> > > > > > > > > 
>> > > > > > > > > Reported-by: Alexey Klimov <alexey.klimov@linaro.org>
>> > > > > > > > > 
>> > > > > > > > > Also, not sure where this change will go, via
>> > > > > > > > > Greg or Jiri, but ideally
>> > > > > > > > > this should be picked for current -rc cycle since regression is
>> > > > > > > > > introduced during latest merge window.
>> > > > > > > > > 
>> > > > > > > > > I also would like to test it on qrb2210 rb1 where this regression is
>> > > > > > > > > reproduciable.
>> > 
>> > Since I don't have this board, could you kindly validate the new change and
>> > run a quick test on your end?
>> > 
>> > diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c
>> > b/drivers/pinctrl/qcom/pinctrl-msm.c
>> > index 83eb075b6bfa..3d6601dc6fcc 100644
>> > --- a/drivers/pinctrl/qcom/pinctrl-msm.c
>> > +++ b/drivers/pinctrl/qcom/pinctrl-msm.c
>> > @@ -215,7 +215,7 @@ static int msm_pinmux_set_mux(struct pinctrl_dev
>> > *pctldev,
>> >          */
>> >         if (d && i != gpio_func &&
>> >             !test_and_set_bit(d->hwirq, pctrl->disabled_for_mux))
>> > -               disable_irq(irq);
>> > +               disable_irq_nosync(irq);
>> > 
>> >         raw_spin_lock_irqsave(&pctrl->lock, flags);
>> 
>> 
>> sorry Praveen, didnt see this proposal. testing on my end as well.
>> 
>
> just tested on my end and all modules load - deadlocked before this
> update so there is progress (now we can load the network driver)

Is it supposed to be orginal patch here plus disable_irq_nosync()?
Meaning changes for qcom_geni_serial_runtime_{suspend,resume}
+ disable_irq_nosync() in msm_pinmux_set_mux()?

It seems to work here but let me know few more runs.

Best regards,
Alexey




  reply	other threads:[~2025-09-16 17:12 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-08 16:45 [PATCH v1] serial: qcom-geni: Fix pinctrl deadlock on runtime resume Praveen Talari
2025-09-08 17:43 ` Alexey Klimov
2025-09-09 20:05   ` Alexey Klimov
2025-09-11  8:34     ` Praveen Talari
2025-09-11  9:00       ` Alexey Klimov
2025-09-15  6:58         ` Praveen Talari
2025-09-15  9:39           ` Alexey Klimov
2025-09-15 14:25             ` Praveen Talari
2025-09-16  6:50               ` Praveen Talari
2025-09-16 14:39                 ` Jorge Ramirez
2025-09-16 15:07                   ` Jorge Ramirez
2025-09-16 17:12                     ` Alexey Klimov [this message]
2025-09-17  0:05                       ` Krzysztof Kozlowski
2025-09-17  0:13                         ` Krzysztof Kozlowski
2025-09-17  4:02                           ` Praveen Talari
2025-09-17  3:26                       ` Praveen Talari
2025-09-16 14:34         ` Jorge Ramirez

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DCUE5AXJ99BG.150SRQMY7EJG6@linaro.org \
    --to=alexey.klimov@linaro.org \
    --cc=bryan.odonoghue@linaro.org \
    --cc=djaggi@quicinc.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jirislaby@kernel.org \
    --cc=jorge.ramirez@oss.qualcomm.com \
    --cc=krzk@kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=praveen.talari@oss.qualcomm.com \
    --cc=psodagud@quicinc.com \
    --cc=quic_arandive@quicinc.com \
    --cc=quic_msavaliy@quicinc.com \
    --cc=quic_ptalari@quicinc.com \
    --cc=quic_shazhuss@quicinc.com \
    --cc=quic_vtanuku@quicinc.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.