On Thu, May 05, 2022 at 11:32:07AM -0700, Jakub Kicinski wrote: > On Tue, 3 May 2022 15:15:05 +0200 Lukas Wunner wrote: > > @@ -608,11 +618,20 @@ static void smsc95xx_status(struct usbnet *dev, struct urb *urb) > > intdata = get_unaligned_le32(urb->transfer_buffer); > > netif_dbg(dev, link, dev->net, "intdata: 0x%08X\n", intdata); > > > > + /* USB interrupts are received in softirq (tasklet) context. > > + * Switch to hardirq context to make genirq code happy. > > + */ > > + local_irq_save(flags); > > + __irq_enter_raw(); > > + > > if (intdata & INT_ENP_PHY_INT_) > > - ; > > + generic_handle_domain_irq(pdata->irqdomain, PHY_HWIRQ); > > else > > netdev_warn(dev->net, "unexpected interrupt, intdata=0x%08X\n", > > intdata); > > + > > + __irq_exit_raw(); > > + local_irq_restore(flags); > > IRQ maintainers could you cast your eyes over this? > > Full patch: > > https://lore.kernel.org/all/c6b7f4e4a17913d2f2bc4fe722df0804c2d6fea7.1651574194.git.lukas@xxxxxxxxx/ This is basically identical to what drivers/net/usb/lan78xx.c does in lan78xx_status(), except I'm passing the hw irq instead of the linux irq to genirq code, thereby avoiding the overhead of a radix_tree_lookup(). generic_handle_domain_irq() warns unconditionally on !in_irq(), unlike handle_irq_desc(), which constrains the warning to handle_enforce_irqctx() (i.e. x86 APIC, arm GIC/GICv3). Perhaps that's an oversight in generic_handle_domain_irq(), unless __irq_resolve_mapping() becomes unsafe outside in_irq() for some reason... In any case the unconditional in_irq() necessitates __irq_enter_raw() here. And there's no _safe variant() of generic_handle_domain_irq() (unlike generic_handle_irq_safe() which was recently added by 509853f9e1e7), hence the necessity of an explicit local_irq_save(). Thanks, Lukas