LinuxQuestions.org - USB port nn disabled by hub (EMI?), re-enabling

Okay I did some digging myself:
In stable: 2.4.37.10 2010-09-06
in /drivers/usb/hub.c

/*
* EM interference sometimes causes bad shielded USB devices to
* be shutdown by the hub, this hack enables them again.
* Works at least with mouse driver.
*/
if (!(portstatus & USB_PORT_STAT_ENABLE) &&
(portstatus & USB_PORT_STAT_CONNECTION) && (dev->children[i])) {
err("already running port %i disabled by hub (EMI?), re-enabling...", i + 1);
usb_hub_port_connect_change(hub, i, portstatus, portchange);
}

-----

in /drivers/usb/hub.h

/*
* wPortStatus bit field
* See USB 2.0 spec Table 11-21
*/
#define USB_PORT_STAT_CONNECTION 0x0001
#define USB_PORT_STAT_ENABLE 0x0002
#define USB_PORT_STAT_SUSPEND 0x0004
#define USB_PORT_STAT_OVERCURRENT 0x0008
#define USB_PORT_STAT_RESET 0x0010
/* bits 5 for 7 are reserved */
#define USB_PORT_STAT_POWER 0x0100
#define USB_PORT_STAT_LOW_SPEED 0x0200
#define USB_PORT_STAT_HIGH_SPEED 0x0400
#define USB_PORT_STAT_TEST 0x0800
#define USB_PORT_STAT_INDICATOR 0x1000
/* bits 13 to 15 are reserved */

------

USB 2.0 spec says:

11.24.2.7.1.1 PORT_CONNECTION
When the Port Power bit is one, this bit indicates whether or not a device is attached. This field reads as one
when a device is attached; it reads as zero when no device is attached. This bit is reset to zero when the port
is in the Powered-off state or the Disconnected states. It is set to one when the port is in the Powered state,
a device attach is detected (see Section 7.1.7.3), and the port transitions from the Disconnected state to the
Disabled state.
SetPortFeature(PORT_CONNECTION) and ClearPortFeature(PORT_CONNECTION) requests shall not
be used by the USB System Software and must be treated as no-operation requests by hubs.

11.24.2.7.1.2 PORT_ENABLE
This bit is set when the port is allowed to send or receive packet data or resume signaling.
This bit may be set only as a result of a SetPortFeature(PORT_RESET) request. When the hub exits the
Resetting state or, if present, the Speed_eval state, this bit is set and bus traffic may be transmitted to the
port. This bit may be cleared as the result of any of the following:
• The port being in the Powered-off state
• Receipt of a ClearPortFeature(PORT_ENABLE) request
• Port_Error detection
• Disconnect detection
• When the port enters the Resetting state as a result of receiving the SetPortFeature(PORT_RESET)
request
The hub response to a SetPortFeature(PORT_ENABLE) request is not specified. The preferred behavior is
that the hub respond with a Request Error. This may not be used by the USB System Software. The
ClearPortFeature(PORT_ENABLE) request is supported as specified in Section 11.5.1.4.

------

So the message is triggered when a connected port is changed to disabled by the hardware, and the code in usb.c then reenables it.
It also isn't a disconnect detection or an overcurrent detection.

I assume, then, that the hardware is disabling the port due to Port_Error detection:

------

USB 2.0 spec:

Port_Error == Internal Error condition detected (see Section 11.8.1)

11.8.1 Port Error
A Port Error can occur on a downstream facing port that is in the Enabled state. A Port Error condition
exists when:
• The hub is in the WFEOP (Wait for End of Packet) state with connectivity established upstream from the port when the
(micro)frame timer reaches the EOF2 point.
• At the EOF2 point, the Hub Repeater is in the WFSOPFU (Wait for Start of Packet from Upstream Port) state, and there is other than Idle state on the port.

If upstream-directed connectivity is established when the (micro)frame timer reaches the EOF1 point, the
upstream Transmitter will (return to Inactive state) generate a full-speed EOP to prevent the hub from being
disabled by the upstream hub. The connected port is then disabled if it has not ended the packet and
returned to the Idle state before the (micro)frame timer reaches the EOF2 point.

------

It looks to me like the protocol is being disrupted. It's a shielded USB cable, and USB uses differential signaling, so I'm suspecting the USB controller in my end device (a touchscreen) is the victim of some EMI coupled either through a common 0V reference connection, or through the touch interface it is connected to. (it isn't static discharge in this case.)