linux-kernel - Re: [PATCH 1/2] usb/ehci-hub: Add workaround for EG20T/ML7213/ML7223/ML7831

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.44L0.1204101044490.1605-100000@iolanthe.rowland.org>
Date:	Tue, 10 Apr 2012 10:57:35 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Tomoya MORINAGA <tomoya.rohm@...il.com>
cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	<linux-usb@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<qi.wang@...el.com>, <yong.y.wang@...el.com>,
	<joel.clark@...el.com>, <kok.howg.ewe@...el.com>
Subject: Re: [PATCH 1/2] usb/ehci-hub: Add workaround for EG20T/ML7213/ML7223/ML7831

On Tue, 10 Apr 2012, Tomoya MORINAGA wrote:

> ISSUE: When a bit of EHCI status register (USBSTS) is set
> as 1, if the corresponded bit of EHCI interrupt enable
> register(USBINTR) is set as 1, an interrupt occurs.
> After that, even if the bit of USBINTR is set as 0, the
> interrupt continues occurring.
> Workaround: Clear the bit 3 of USBSTS before enabling the
> interrupt, at resume process.

These two patches do a lot more than is necessary.  At the same time, 
they also seem to do a lot less.

You don't have to check for the faulty product IDs; clearing the
STS_FLR bit (bit 3 of USBSTS) is always okay because the driver doesn't 
use it.

On the other hand, the STS_FLR bit will get set once every second (at
least) whenever the controller is running.  According to your
description above, this means the controller will cause an interrupt
storm as soon as its first interrupt occurs.  What you really need to
do is clear STS_FLR in ehci_irq().

Does the patch below fix your problem?

Alan Stern



 drivers/usb/host/ehci-hcd.c |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

Index: usb-3.4/drivers/usb/host/ehci-hcd.c
===================================================================
--- usb-3.4.orig/drivers/usb/host/ehci-hcd.c
+++ usb-3.4/drivers/usb/host/ehci-hcd.c
@@ -860,8 +860,13 @@ static irqreturn_t ehci_irq (struct usb_
 		goto dead;
 	}
 
+	/*
+	 * We don't use STS_FLR, but some controllers don't like it to
+	 * remain on, so mask it out along with the other status bits.
+	 */
+	masked_status = status & (INTR_MASK | STS_FLR);
+
 	/* Shared IRQ? */
-	masked_status = status & INTR_MASK;
 	if (!masked_status || unlikely(ehci->rh_state == EHCI_RH_HALTED)) {
 		spin_unlock(&ehci->lock);
 		return IRQ_NONE;

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/