Gitweb:     
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=5f8364b7d63acdc2216ca0f7d0a8557c318479ea
Commit:     5f8364b7d63acdc2216ca0f7d0a8557c318479ea
Parent:     fe1ec341df1b510e5e614ccdad4a89273d6f6fe8
Author:     Alan Stern <[EMAIL PROTECTED]>
AuthorDate: Tue Dec 5 16:29:55 2006 -0500
Committer:  Greg Kroah-Hartman <[EMAIL PROTECTED]>
CommitDate: Wed Dec 20 10:14:26 2006 -0800

    UHCI: module parameter to ignore overcurrent changes
    
    Certain boards seem to like to issue false overcurrent notifications,
    for example on ports that don't have anything connected to them.  This
    looks like a hardware error, at the level of noise to those ports'
    overcurrent input signals (or non-debounced VBUS comparators).  This
    surfaces to users as truly massive amounts of syslog spam from khubd
    (which is appropriate for real hardware problems, except for the
    volume from multiple ports).
    
    Using this new "ignore_oc" flag helps such systems work more sanely,
    by preventing such indications from getting to khubd (and spamming
    syslog).  The downside is of course that true overcurrent errors will
    be masked; they'll appear as spontaneous disconnects, without the
    diagnostics that will let users troubleshoot issues like
    short-circuited cables.  In addition, controllers with no devices
    attached will be forced to poll for new devices rather than relying on
    interrupts, since each overcurrent event would generate a new
    interrupt.
    
    This patch (as826) is essentially a copy of David Brownell's ignore_oc
    patch for ehci-hcd, ported to uhci-hcd.
    
    Signed-off-by: Alan Stern <[EMAIL PROTECTED]>
    Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
 Documentation/kernel-parameters.txt |    8 ++++++++
 drivers/usb/host/uhci-hcd.c         |   13 ++++++++++++-
 drivers/usb/host/uhci-hub.c         |   14 ++++++++++++--
 3 files changed, 32 insertions(+), 3 deletions(-)

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index ef69c75..25d2985 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1714,6 +1714,14 @@ and is between 256 and 4096 characters. It is defined in 
the file
        uart6850=       [HW,OSS]
                        Format: <io>,<irq>
 
+       uhci-hcd.ignore_oc=
+                       [USB] Ignore overcurrent events (default N).
+                       Some badly-designed motherboards generate lots of
+                       bogus events, for ports that aren't wired to
+                       anything.  Set this parameter to avoid log spamming.
+                       Note that genuine overcurrent events won't be
+                       reported either.
+
        usbhid.mousepoll=
                        [USBHID] The interval which mice are to be polled at.
 
diff --git a/drivers/usb/host/uhci-hcd.c b/drivers/usb/host/uhci-hcd.c
index e87692c..acd101c 100644
--- a/drivers/usb/host/uhci-hcd.c
+++ b/drivers/usb/host/uhci-hcd.c
@@ -60,6 +60,11 @@ Randy Dunlap, Georg Acher, Deti Fliegl, Thomas Sailer, Roman 
Weissgaerber, \
 Alan Stern"
 #define DRIVER_DESC "USB Universal Host Controller Interface driver"
 
+/* for flakey hardware, ignore overcurrent indicators */
+static int ignore_oc;
+module_param(ignore_oc, bool, S_IRUGO);
+MODULE_PARM_DESC(ignore_oc, "ignore hardware overcurrent indications");
+
 /*
  * debug = 0, no debugging messages
  * debug = 1, dump failed URBs except for stalls
@@ -169,6 +174,11 @@ static int resume_detect_interrupts_are_broken(struct 
uhci_hcd *uhci)
 {
        int port;
 
+       /* If we have to ignore overcurrent events then almost by definition
+        * we can't depend on resume-detect interrupts. */
+       if (ignore_oc)
+               return 1;
+
        switch (to_pci_dev(uhci_dev(uhci))->vendor) {
            default:
                break;
@@ -921,7 +931,8 @@ static int __init uhci_hcd_init(void)
 {
        int retval = -ENOMEM;
 
-       printk(KERN_INFO DRIVER_DESC " " DRIVER_VERSION "\n");
+       printk(KERN_INFO DRIVER_DESC " " DRIVER_VERSION "%s\n",
+                       ignore_oc ? ", overcurrent ignored" : "");
 
        if (usb_disabled())
                return -ENODEV;
diff --git a/drivers/usb/host/uhci-hub.c b/drivers/usb/host/uhci-hub.c
index f8347f1..bacc25c 100644
--- a/drivers/usb/host/uhci-hub.c
+++ b/drivers/usb/host/uhci-hub.c
@@ -52,10 +52,20 @@ static int any_ports_active(struct uhci_hcd *uhci)
 static inline int get_hub_status_data(struct uhci_hcd *uhci, char *buf)
 {
        int port;
+       int mask = RWC_BITS;
+
+       /* Some boards (both VIA and Intel apparently) report bogus
+        * overcurrent indications, causing massive log spam unless
+        * we completely ignore them.  This doesn't seem to be a problem
+        * with the chipset so much as with the way it is connected on
+        * the motherboard; if the overcurrent input is left to float
+        * then it may constantly register false positives. */
+       if (ignore_oc)
+               mask &= ~USBPORTSC_OCC;
 
        *buf = 0;
        for (port = 0; port < uhci->rh_numports; ++port) {
-               if ((inw(uhci->io_addr + USBPORTSC1 + port * 2) & RWC_BITS) ||
+               if ((inw(uhci->io_addr + USBPORTSC1 + port * 2) & mask) ||
                                test_bit(port, &uhci->port_c_suspend))
                        *buf |= (1 << (port + 1));
        }
@@ -263,7 +273,7 @@ static int uhci_hub_control(struct usb_hcd *hcd, u16 
typeReq, u16 wValue,
                        wPortChange |= USB_PORT_STAT_C_CONNECTION;
                if (status & USBPORTSC_PEC)
                        wPortChange |= USB_PORT_STAT_C_ENABLE;
-               if (status & USBPORTSC_OCC)
+               if ((status & USBPORTSC_OCC) && !ignore_oc)
                        wPortChange |= USB_PORT_STAT_C_OVERCURRENT;
 
                if (test_bit(port, &uhci->port_c_suspend)) {
-
To unsubscribe from this list: send the line "unsubscribe git-commits-head" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to