> Ugh, this is a giant patch. It's too big for stable, and it adds new
> host controller driver APIs. We can't do that for stable.
Yes, agree!
> > + return 1;
> > + } else if (!(hcd->driver->flags & HCD_MSI_FIRST))
> > + return 1;
>
> You don't need the else statement here, since you always return in the
> previous if block.
Correct! remove 'else' here make code more clear.
> > +/* msi irq handler should be here, if driver has */
> > +irqreturn_t hcd_msi_irq(int irq, struct usb_hcd *hcd)
> > +{
> > + return hcd->driver->irq(hcd);
> > +}
>
> This works for now, but it isn't going to work in the future. We need
> the USB core to provide us with the irq number so we can map the MSI-X
> interrupt to the event ring that generated the interrupt, whenever we
> get around to adding multiple event rings.
>
> I think you need to add a new USB hcd callback for MSI/MSI-X vectors. The
> xHCI usb_hcd can provide both pointers.
>
Do you mean to add 2 new vectors for MSI/MSIX in hc_driver?
---
@@ -205,11 +212,14 @@ struct hc_driver {
/* irq handler */
irqreturn_t (*irq) (struct usb_hcd *hcd);
+ irqreturn_t (*msi_irq) (struct usb_hcd *hcd);
+ irqreturn_t (*msix_irq) (struct usb_hcd *hcd);
int flags;
---
It is reasonable. When I written the code, I thought it may need
different MSI/MSIX irq handlers later for different driver. :)
Actually, There is 2 ways to implement this vectors for detail.
a, let driver's self code to do request_irq() for each of vectors for
MSI/MSIX, and hc_driver just has a simple hook for them.
b, do detailed request_irq() work in usb-core(in hcd-pci.c).
Consider all pci MSI/MSIX interface is similar, we may prefer the second
way to save some code.
What's opinions for above 2 ways?
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
