Cause of EHCI bogus "fatal" IRQs?

Hi,

I apologize if this has already been reported, I didn't find anything
with a quick search in the archives. I have been looking at the EHCI
code in 2.6.18 and found this:

In 2.6.18 ehci_irq() [1], starting at line 619 the code looks like this:
         /* remote wakeup [4.3.1] */
619         if (status & STS_PCD) {
620                 unsigned        i = HCS_N_PORTS (ehci->hcs_params);
621
622                 /* resume root hub? */
623                 status = readl (&ehci->regs->command);
624                 if (!(status & CMD_RUN))
625                         writel (status | CMD_RUN, &ehci->regs->command);
626
<snip, no assignments to status>
644         }
645
646         /* PCI errors [4.15.2.4] */
647         if (unlikely ((status & STS_FATAL) != 0)) {
648                 /* bogus "fatal" IRQs appear on some chips... why?  */
649                 status = readl (&ehci->regs->status);
650                 dbg_cmd (ehci, "fatal", readl (&ehci->regs->command));
651                 dbg_status (ehci, "fatal", status);
652                 if (status & STS_HALT) {
653                         ehci_err (ehci, "fatal error\n");
654 dead:
655                         ehci_reset (ehci);
656                         writel (0, &ehci->regs->configured_flag);
657                         /* generic layer kills/unlinks all urbs, then
658                          * uses ehci_stop to clean up the rest
659                          */
660                         bh = 1;
661                 }
662         }

Now, STS_FATAL (Host System Error) is bit 4 in the USBSTS register. If
STS_PCD is set line 623 assigns the status variable with the value of
USBCMD. Which will, sometimes, trigger the status & STS_FATAL
condition since bit 4 in USBCMD is Periodic Schedule Enable.

The problem above was fixed by a patch from Alan Stern [2] "Fix
root-hub and port suspend/resume problems" but I did not find any
comments about the problem above being identified. The code in 2.6.21
still contains:

/* PCI errors [4.15.2.4] */
	if (unlikely ((status & STS_FATAL) != 0)) {
		/* bogus "fatal" IRQs appear on some chips... why?  */
		status = ehci_readl(ehci, &ehci->regs->status);

So, if the bogus IRQs were triggered by the assignment of USBCMD to
status above, the comment and the re-reading of USBSTS could perhaps
be removed?

Best regards,
  Jan


[1] http://lxr.linux.no/source/drivers/usb/host/ehci-hcd.c?v=2.6.18#L618
[2] http://surl.se/auaz

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel