Re: [PATCH 2/2] usb: xhci: add interrupter type

["Neronin, Niklas" <niklas.neronin@linux.intel.com>]

On 04/02/2026 3.17, Wesley Cheng wrote:
> 
> 
> On 1/28/2026 5:15 AM, Niklas Neronin wrote:
>> xhci-sideband creates a secondary interrupter without an associated IRQ.
>> Such interrupters are non-operational and cannot enabled or disabled.
>>
> 
> Is the wording here correct?  Every interrupter should have a physical interrupt line, however, it may not be owned by the processor running Linux. (ie offloaded to another DSP)
> 

In this case, the xhci driver allocates an xhci-sideband interrupter
structure but does not bind it to an IRQ or register an interrupt handler.
Event processing for this interrupter is performed by the sideband code via
polling of the event ring rather than through an interrupt.

From the xhci core driver's perspective, the interrupter structure exists,
but it requires no interrupt management. Beyond allocation and teardown,
the xhci core driver does not interact with it, which is why it is treated
as a "noop" interrupter.

>> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
>> index fcf8b486b0e0..c4e0c1cfb94e 100644
>> --- a/drivers/usb/host/xhci.c
>> +++ b/drivers/usb/host/xhci.c
>> @@ -314,6 +314,9 @@ int xhci_enable_interrupter(struct xhci_interrupter *ir)
>>   {
>>       u32 iman;
>>   +    if (ir->type == INTR_NOOP)
>> +        return 0;
>> +
>>       if (!ir || !ir->ir_set)
>>           return -EINVAL;
>>   @@ -331,6 +334,9 @@ int xhci_disable_interrupter(struct xhci_hcd *xhci, struct xhci_interrupter *ir)
>>   {
>>       u32 iman;
>>   +    if (ir->type == INTR_NOOP)
>> +        return 0;
>> +
> 
> In some of my previous discussions with Mathias, I think he mentioned there was a use case where Linux would handle interrupts for both the primary and secondary interrupters.  I didn't get much more info, but maybe it was for segmenting events occurring on different EPs.  However, I'm not sure where that control/trigger comes from, ie from the class driver level, or within xHCI.

In such a scenario, secondary interrupters would be associated with an IRQ
and handled similarly to the primary interrupter, using the same interrupt
handling paths in the xhci driver.

> 
> Just wondering if this is going to lay out the groundwork for that to be added, as in xhci_sideband_create_interrupter() we're just assuming that its a INTR_NOOP versus allowing it to be configured by the caller.
> 

All interrupters are stored in the 'xhci->interrupter[]' array, and this
change introduces a way to distinguish interrupters that are handled by
the xhci core from those that are not.

Thanks,
Niklas