On 2025-09-04 15:18:50 [+0200], Lukas Wunner wrote: > On Thu, Sep 04, 2025 at 02:48:21PM +0200, Lukas Wunner wrote: > > On Thu, Sep 04, 2025 at 09:30:24AM +0200, Sebastian Andrzej Siewior wrote: > > > On 2025-09-02 17:44:41 [-0500], Crystal Wood wrote: > > > > +++ b/drivers/pci/pcie/aer.c > > > > @@ -1671,7 +1671,8 @@ static int aer_probe(struct pcie_device *dev) > > > > set_service_data(dev, rpc); > > > > > > > > status = devm_request_threaded_irq(device, dev->irq, aer_irq, aer_isr, > > > > - IRQF_SHARED, "aerdrv", dev); > > > > + IRQF_NO_THREAD | IRQF_SHARED, > > > > + "aerdrv", dev); > > > > > > I'm not sure if this works with IRQF_SHARED. Your primary handler is > > > IRQF_SHARED + IRQF_NO_THREAD and another shared handler which is > > > forced-threaded will have IRQF_SHARED + IRQF_ONESHOT. > > > If the core does not complain, all good. Worst case might be the shared > > > ONESHOT lets your primary handler starve. It would be nice if you could > > > check if you have shared handler here (I have no aer I three boxes I > > > checked). > > > > Yes, interrupt sharing can happen if the Root Port uses legacy INTx > > interrupts. In that case other port services such as hotplug, > > bandwidth control, PME or DPC may use the same interrupt. > > I should add that none of these other port service drivers use > IRQF_ONESHOT. They're all IRQF_SHARED only. Yes. But. If they get forced-threaded then we have a primary handler irq_default_primary_handler() as the hardirq handler. This one would be marked IRQF_ONESHOT. The other primary handler would be aer_irq() in this case. As long as all (or none) are forced-threaded then it is fine. In this case it could be a miss match, I'm not sure. > Thanks, > > Lukas Sebastian
