On Wed, 14 Mar 2018, Fredrik Noring wrote:
> Hi Alan Stern,
>
> > > > What happened to the changes to ohci_run() and ohci_irq() that were in
> > > > v2 of this RFC? Did you decide they weren't needed?
> > >
> > > In v3 Jürgen Urban folded those changes into the driver functions
> > >
> > > ohci_ps2_enable(),
> > > ohci_ps2_disable(),
> > > ohci_ps2_start_hc() and
> > > ohci_ps2_stop_hc()
> > >
> > > in drivers/usb/host/ohci-ps2.c.
> >
> > Good, I was going to suggest doing that.
>
> There is one quirk with the ISR that perhaps could be clarified: For some
> reason we have to intercept ohci_irq to disable interrupts, as shown in the
> function below, otherwise the whole USB subsystem eventually will freeze up.
>
> Is this a known OHCI problem? Is some part of its USB core ISR not reentrant?
The USB interrupt handlers in general are not reentrant. Or if they
are, it's more by accident than by design.
> static irqreturn_t ohci_ps2_irq(struct usb_hcd *hcd)
> {
> struct ohci_hcd *ohci = hcd_to_ohci(hcd);
> struct ohci_regs __iomem *regs = ohci->regs;
>
> /*
> * FIXME: For some reason OHCI_INTR_MIE is required in the
> * IRQ handler. Without it, reading a large amount of data
> * (> 1 GB) from a mass storage device results in a freeze.
> */
> ohci_writel(ohci, OHCI_INTR_MIE, ®s->intrdisable);
>
> return ohci_irq(hcd); /* Call normal IRQ handler. */
> }
This should not be needed; it indicates that something is wrong with
the way interrupt requests are handled on this platform.
Are you using threaded interrupts at all? If you are, you have to
change the spin_lock() call in ohci_irq() to spin_lock_irqsave(). You
could try making this change in any case, to see if it prevents the
freezes.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
