On Mon, 16 Jul 2012, Ming Lei wrote:
> On Wed, Jul 11, 2012 at 11:22 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
> > This patch (as1578) adds an hrtimer event to handle the death of an
> > EHCI controller. When a controller dies, it doesn't necessarily stop
> > running right away. The new event polls at 1-ms intervals to see when
> > all activity has safely stopped. This replaces a busy-wait polling
> > loop in the current code.
> > --- usb-3.4.orig/drivers/usb/host/ehci-timer.c
> > +++ usb-3.4/drivers/usb/host/ehci-timer.c
> > @@ -69,6 +69,7 @@ static void ehci_clear_command_bit(struc
> > static unsigned event_delays_ns[] = {
> > 1 * NSEC_PER_MSEC, /* EHCI_HRTIMER_POLL_ASS */
> > 1 * NSEC_PER_MSEC, /* EHCI_HRTIMER_POLL_PSS */
> > + 1 * NSEC_PER_MSEC, /* EHCI_HRTIMER_POLL_DEAD */
> > 1125 * NSEC_PER_USEC, /* EHCI_HRTIMER_UNLINK_INTR */
> > 10 * NSEC_PER_MSEC, /* EHCI_HRTIMER_DISABLE_PERIODIC */
> > 15 * NSEC_PER_MSEC, /* EHCI_HRTIMER_DISABLE_ASYNC */
> > @@ -193,6 +194,30 @@ static void ehci_disable_PSE(struct ehci
> > }
> >
> >
> > +/* Poll the STS_HALT status bit; see when a dead controller stops */
> > +static void ehci_handle_controller_death(struct ehci_hcd *ehci)
> > +{
> > + if (!(ehci_readl(ehci, &ehci->regs->status) & STS_HALT)) {
>
> If ehci_stop is runing when the EHCI_HRTIMER_POLL_DEAD event
> is pending, there may be one race since ehci->enabled_hrtimer_events
> is cleared in ehci_stop.
That's right. A later patch in the series takes care of these races.
However this particular race doesn't really matter. If the controller
dies while the driver is being unloaded, who cares? ehci_stop will
reset the controller anyway.
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
