[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250104100923.67tmfgiuyu2h7zzd@thinkpad>
Date: Sat, 4 Jan 2025 15:39:23 +0530
From: Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
To: Brian Norris <briannorris@...omium.org>
Cc: Bjorn Helgaas <helgaas@...nel.org>, Jingoo Han <jingoohan1@...il.com>,
Lorenzo Pieralisi <lpieralisi@...nel.org>,
Bjorn Helgaas <bhelgaas@...gle.com>, linux-kernel@...r.kernel.org,
linux-pci@...r.kernel.org, Rob Herring <robh@...nel.org>,
Krzysztof Wilczyński <kw@...ux.com>,
Marc Zyngier <maz@...nel.org>
Subject: Re: [PATCH] PCI: dwc: Use level-triggered handler for MSI IRQs
On Fri, Jan 03, 2025 at 02:47:09PM -0800, Brian Norris wrote:
[...]
> > Oh, and it would be awesome if we can motivate this patch by mentioning
> > an actual problem it can avoid.
> >
> > It sounds like there really *is* a problem at least in some
> > topologies, so I think we should describe that problem before
> > explaining why we haven't seen it yet.
>
> Yeah, that's probably a good idea ... I'm still working out the nature
> of a problem I'm dealing with here, but it has to do with when (due to
> HW bugs) I have to configure the parent interrupt (GIC) as
> edge-triggered. It turns out this change alone doesn't resolve all my
> problems, but:
>
> (a) I was hoping to get feedback on whether this change is sensible
> regardless of the adjacent HW bug I'm dealing with (I think it is);
> and
This patch alone (with your proposed commit message change) makes sense to me.
Since DWC MSI controller is a hierarchial interrupt controller and most of the
designs chose to use level triggered SPI to signal GIC, we never had to face an
issue. GIC would mask the interrupt first and then unmask it after handling. So
even if the DWC MSI is level/edge triggered, the behavior would mostly be the
same.
But we should model the interrupt as per the hardware design. So your patch is
doing the right thing.
> (b) I don't think I have a great publishable explanation of my HW bug(s)
> yet.
>
This is not a blocker for this patch IMO.
> I understand (b) is not really a great situation for public review and
> would understand if that delays/defers any action here. But I'm also not
> really an IRQ expert (though I have to dabble quite a lot) and am
> interested in (a) still.
>
> (If it helps, I can try to summarize the above in a commit message, even
> if it's still a bit vague.)
>
Your bug is not strictly relevant to this patch. Quoting the spec reference and
changing the commit message as per Bjorn's suggestion is enough.
- Mani
--
மணிவண்ணன் சதாசிவம்
Powered by blists - more mailing lists