All of lore.kernel.org
 help / color / mirror / Atom feed
From: Manivannan Sadhasivam <mani@kernel.org>
To: Kalle Valo <kvalo@kernel.org>
Cc: Qiang Yu <quic_qianyu@quicinc.com>,
	quic_hemantk@quicinc.com, loic.poulain@linaro.org,
	quic_jhugo@quicinc.com, mhi@lists.linux.dev,
	linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
	quic_cang@quicinc.com, ath11k@lists.infradead.org
Subject: Re: [PATCH v4 1/1] bus: mhi: host: Move IRQ allocation to controller registration phase
Date: Tue, 26 Jul 2022 13:39:13 +0530	[thread overview]
Message-ID: <20220726080913.GF5522@workstation> (raw)
In-Reply-To: <87wnc1qdhz.fsf@kernel.org>

On Mon, Jul 25, 2022 at 09:00:08PM +0300, Kalle Valo wrote:
> Manivannan Sadhasivam <mani@kernel.org> writes:
> 
> > On Wed, Jul 20, 2022 at 05:47:37PM +0800, Qiang Yu wrote:
> >
> >> 
> >> On 7/20/2022 5:39 PM, Manivannan Sadhasivam wrote:
> >> > On Mon, Jul 18, 2022 at 02:15:23PM +0300, Kalle Valo wrote:
> >> > > + ath11k list
> >> > > 
> >> > > Manivannan Sadhasivam <mani@kernel.org> writes:
> >> > > 
> >> > > > On Thu, Jun 23, 2022 at 10:43:03AM +0800, Qiang Yu wrote:
> >> > > > > During runtime, the MHI endpoint may be powered up/down several times.
> >> > > > > So instead of allocating and destroying the IRQs all the time, let's just
> >> > > > > enable/disable IRQs during power up/down.
> >> > > > > 
> >> > > > > The IRQs will be allocated during mhi_register_controller() and freed
> >> > > > > during mhi_unregister_controller(). This works well for things like PCI
> >> > > > > hotplug also as once the PCI device gets removed, the controller will
> >> > > > > get unregistered. And once it comes back, it will get registered back
> >> > > > > and even if the IRQ configuration changes (MSI), that will get accounted.
> >> > > > > 
> >> > > > > Signed-off-by: Qiang Yu <quic_qianyu@quicinc.com>
> >> > > > Applied to mhi-next!
> >> > > I did a bisect and this patch breaks ath11k during rmmod. I'm on
> >> > > vacation right now so I can't investigate in detail but more info below.
> >> > > 
> >> > I just tested linux-next/master next-20220718 on my NUC with QCA6390, but I'm
> >> > not able to reproduce the issue during rmmod! Instead I couldn't connect to AP.
> >> 
> >> I suspect that in __free_irq(), if CONFIG_DEBUG_SHIRQ is enabled, irq
> >> handler for a shared IRQ will be invoked and null pointer access happen.
> >> 
> >> #ifdef CONFIG_DEBUG_SHIRQ
> >>     /*
> >>      * It's a shared IRQ -- the driver ought to be prepared for an IRQ
> >>      * event to happen even now it's being freed, so let's make sure that
> >>      * is so by doing an extra call to the handler ....
> >>      *
> >>      * ( We do this after actually deregistering it, to make sure that a
> >>      *   'real' IRQ doesn't run in parallel with our fake. )
> >>      */
> >>     if (action->flags & IRQF_SHARED) {
> >>         local_irq_save(flags);
> >>         action->handler(irq, dev_id);
> >>         local_irq_restore(flags);
> >>     }
> >> #endif
> >> 
> >
> > Ah yes, after enabling CONFIG_DEBUG_SHIRQ I could reproduce the issue.
> 
> So how to fix this regression? (If there's already a fix I might have
> missed it as I came back only today)
> 

Copied you on the fix patch. Please test and let us know!

Thanks,
Mani

> -- 
> https://patchwork.kernel.org/project/linux-wireless/list/
> 
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

-- 
ath11k mailing list
ath11k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath11k

WARNING: multiple messages have this Message-ID (diff)
From: Manivannan Sadhasivam <mani@kernel.org>
To: Kalle Valo <kvalo@kernel.org>
Cc: Qiang Yu <quic_qianyu@quicinc.com>,
	quic_hemantk@quicinc.com, loic.poulain@linaro.org,
	quic_jhugo@quicinc.com, mhi@lists.linux.dev,
	linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
	quic_cang@quicinc.com, ath11k@lists.infradead.org
Subject: Re: [PATCH v4 1/1] bus: mhi: host: Move IRQ allocation to controller registration phase
Date: Tue, 26 Jul 2022 13:39:13 +0530	[thread overview]
Message-ID: <20220726080913.GF5522@workstation> (raw)
In-Reply-To: <87wnc1qdhz.fsf@kernel.org>

On Mon, Jul 25, 2022 at 09:00:08PM +0300, Kalle Valo wrote:
> Manivannan Sadhasivam <mani@kernel.org> writes:
> 
> > On Wed, Jul 20, 2022 at 05:47:37PM +0800, Qiang Yu wrote:
> >
> >> 
> >> On 7/20/2022 5:39 PM, Manivannan Sadhasivam wrote:
> >> > On Mon, Jul 18, 2022 at 02:15:23PM +0300, Kalle Valo wrote:
> >> > > + ath11k list
> >> > > 
> >> > > Manivannan Sadhasivam <mani@kernel.org> writes:
> >> > > 
> >> > > > On Thu, Jun 23, 2022 at 10:43:03AM +0800, Qiang Yu wrote:
> >> > > > > During runtime, the MHI endpoint may be powered up/down several times.
> >> > > > > So instead of allocating and destroying the IRQs all the time, let's just
> >> > > > > enable/disable IRQs during power up/down.
> >> > > > > 
> >> > > > > The IRQs will be allocated during mhi_register_controller() and freed
> >> > > > > during mhi_unregister_controller(). This works well for things like PCI
> >> > > > > hotplug also as once the PCI device gets removed, the controller will
> >> > > > > get unregistered. And once it comes back, it will get registered back
> >> > > > > and even if the IRQ configuration changes (MSI), that will get accounted.
> >> > > > > 
> >> > > > > Signed-off-by: Qiang Yu <quic_qianyu@quicinc.com>
> >> > > > Applied to mhi-next!
> >> > > I did a bisect and this patch breaks ath11k during rmmod. I'm on
> >> > > vacation right now so I can't investigate in detail but more info below.
> >> > > 
> >> > I just tested linux-next/master next-20220718 on my NUC with QCA6390, but I'm
> >> > not able to reproduce the issue during rmmod! Instead I couldn't connect to AP.
> >> 
> >> I suspect that in __free_irq(), if CONFIG_DEBUG_SHIRQ is enabled, irq
> >> handler for a shared IRQ will be invoked and null pointer access happen.
> >> 
> >> #ifdef CONFIG_DEBUG_SHIRQ
> >>     /*
> >>      * It's a shared IRQ -- the driver ought to be prepared for an IRQ
> >>      * event to happen even now it's being freed, so let's make sure that
> >>      * is so by doing an extra call to the handler ....
> >>      *
> >>      * ( We do this after actually deregistering it, to make sure that a
> >>      *   'real' IRQ doesn't run in parallel with our fake. )
> >>      */
> >>     if (action->flags & IRQF_SHARED) {
> >>         local_irq_save(flags);
> >>         action->handler(irq, dev_id);
> >>         local_irq_restore(flags);
> >>     }
> >> #endif
> >> 
> >
> > Ah yes, after enabling CONFIG_DEBUG_SHIRQ I could reproduce the issue.
> 
> So how to fix this regression? (If there's already a fix I might have
> missed it as I came back only today)
> 

Copied you on the fix patch. Please test and let us know!

Thanks,
Mani

> -- 
> https://patchwork.kernel.org/project/linux-wireless/list/
> 
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

  reply	other threads:[~2022-07-26  8:11 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-23  2:43 [PATCH v4 1/1] bus: mhi: host: Move IRQ allocation to controller registration phase Qiang Yu
2022-06-23 11:54 ` Manivannan Sadhasivam
2022-06-23 12:49   ` Qiang Yu
2022-06-23 17:00   ` Jeffrey Hugo
2022-06-24  7:27 ` Manivannan Sadhasivam
2022-07-18 11:15   ` Kalle Valo
2022-07-18 11:15     ` Kalle Valo
2022-07-20  9:39     ` Manivannan Sadhasivam
2022-07-20  9:39       ` Manivannan Sadhasivam
2022-07-20  9:47       ` Qiang Yu
2022-07-20  9:47         ` Qiang Yu
2022-07-21 10:19         ` Manivannan Sadhasivam
2022-07-21 10:19           ` Manivannan Sadhasivam
2022-07-25 18:00           ` Kalle Valo
2022-07-25 18:00             ` Kalle Valo
2022-07-26  8:09             ` Manivannan Sadhasivam [this message]
2022-07-26  8:09               ` Manivannan Sadhasivam
2022-07-26 17:48               ` Kalle Valo
2022-07-26 17:48                 ` Kalle Valo
2022-07-25 17:57       ` Kalle Valo
2022-07-25 17:57         ` Kalle Valo

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=20220726080913.GF5522@workstation \
    --to=mani@kernel.org \
    --cc=ath11k@lists.infradead.org \
    --cc=kvalo@kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=loic.poulain@linaro.org \
    --cc=mhi@lists.linux.dev \
    --cc=quic_cang@quicinc.com \
    --cc=quic_hemantk@quicinc.com \
    --cc=quic_jhugo@quicinc.com \
    --cc=quic_qianyu@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.