drivers/nutdrv_qx.c: qx_command(): reset USB device after persistent LIBUSB_ERROR_OVERFLOW [#598]

LIBUSB_ERROR_OVERFLOW has been handled as a benign, retry-on-next-poll
condition (grouped with LIBUSB_ERROR_TIMEOUT and the default case) ever
since the original blazer import. For most devices a one-off oversized
interrupt-IN frame is indeed transient. But some Cypress USB-serial
bridge firmware (VID:PID 0665:5161; Salicru SPS, Ippon, ViewPower and
various Voltronic Power UPSes) wedges the endpoint once it overruns:
every subsequent interrupt read returns OVERFLOW and the driver spins in
the stale-data loop until an external USB-level reset. This is the
chronic hang reported in issue #598.

Distinguish the two cases with a small consecutive-overflow counter: the
first QX_USB_OVERFLOW_RESET_TRIES-1 overflows are retried on the next
poll (so genuine transients cost nothing but a skipped cycle), and a
sustained run escalates to usb_reset() + reconnect, reusing the recovery
path already used for PIPE/ETIME/IO errors. Any clean read resets the
counter.

Captured on a Salicru SPS 1500 ONE BL: an isolated overflow recovers on
the next poll, while a sustained lockup (dozens of consecutive overflows
within seconds) is cleared only by the device reset, matching the
behaviour of an external `usb_resetter --reset-device`.

Signed-off-by: Pedro Cunha <pedroagracio+nut@gmail.com>

Author: Pyker

drivers/nutdrv_qx.c

@@ -3881,10 +3881,23 @@ void	upsdrv_cleanup(void)
 
 /* Generic command processing function: send a command and read a reply.
  * Returns < 0 on error, 0 on timeout and the number of bytes read on success. */
+/* Consecutive LIBUSB_ERROR_OVERFLOW results on the interrupt-IN endpoint
+ * tolerated before escalating from "retry on the next poll" to a USB-level
+ * device reset. A one-off oversized frame is transient; a sustained run means
+ * the bridge firmware has wedged the endpoint and only re-enumeration clears
+ * it (e.g. the 0665:5161 Cypress USB-serial family: Salicru SPS, Ippon,
+ * ViewPower, various Voltronic Power). See NUT issue #598. */
+#define QX_USB_OVERFLOW_RESET_TRIES	3
+
 static ssize_t	qx_command(const char *cmd, size_t cmdlen, char *buf, size_t buflen)
 {
 #ifndef TESTING
 	ssize_t	ret = -1;
+# ifdef QX_USB
+	/* Persists across calls; only consecutive overflows accumulate (any clean
+	 * read zeroes it, see the switch on `ret` below). */
+	static int	overflow_tries = 0;
+# endif
 #endif
 
 /* NOTE: Could not find in which ifdef-ed codepath, but clang complained
@@ -3918,6 +3931,7 @@ static ssize_t	qx_command(const char *cmd, size_t cmdlen, char *buf, size_t bufl
 		ret = (*subdriver_command)(cmd, cmdlen, buf, buflen);
 
 		if (ret >= 0) {
+			overflow_tries = 0;	/* clean read: forget any overflow streak */
 			return ret;
 		}
 
@@ -3979,8 +3993,26 @@ static ssize_t	qx_command(const char *cmd, size_t cmdlen, char *buf, size_t bufl
 			udev = NULL;
 			break;
 
+		case LIBUSB_ERROR_OVERFLOW:	/* Value too large for defined data type:
+						 * an oversized interrupt-IN frame. A one-off is
+						 * transient (retry on the next poll); a sustained
+						 * run means the bridge firmware has wedged the
+						 * endpoint and only a USB-level reset recovers it.
+						 * See NUT issue #598. */
+			if (++overflow_tries < QX_USB_OVERFLOW_RESET_TRIES) {
+				upsdebugx(2, "Got OVERFLOW on EP 0x81 (%d/%d), retrying on next poll",
+					overflow_tries, QX_USB_OVERFLOW_RESET_TRIES);
+				break;
+			}
+			upsdebugx(1, "OVERFLOW on EP 0x81 persisted for %d polls; resetting device",
+				overflow_tries);
+			overflow_tries = 0;
+			if (usb_reset(udev) == 0) {
+				upsdebugx(1, "Device reset handled");
+			}
+			goto fallthrough_case_reconnect;
+
 		case LIBUSB_ERROR_TIMEOUT:	/* Connection timed out */
-		case LIBUSB_ERROR_OVERFLOW:	/* Value too large for defined data type */
 #if EPROTO && WITH_LIBUSB_0_1		/* limit to libusb 0.1 implementation */
 		case -EPROTO:		/* Protocol error */
 #endif