drivers/nutdrv_qx.c, drivers/blazer_usb.c: cypress_command()/phoenix_command(): clear endpoint halt and retry on LIBUSB_ERROR_OVERFLOW [#598]

Some firmware in the 0665:5161 Cypress USB-Serial bridge family
(Salicru SPS ONE, Ippon, Belkin F6C1200-UNV, ViewPower, various
Voltronic Power UPSes) occasionally emits an interrupt-IN frame
larger than the declared wMaxPacketSize=8, mid-reply. The kernel
xHCI driver flags this as LIBUSB_ERROR_OVERFLOW and discards the
data; from that point on, every subsequent read on the endpoint
also returns OVERFLOW until a USB-level reset is performed, which
results in "Data stale" from upsd until the driver is restarted.

Issue an immediate CLEAR_FEATURE(HALT) on EP 0x81 and retry the
read once. CLEAR_FEATURE(HALT) unsticks the kernel-side endpoint
state, and in the observed cases the firmware's TX FIFO state as
well, so the next read returns a clean frame. If the retry also
overflows, the existing error path is taken unchanged.

Captured at byte level on a Salicru SPS 1500 ONE BL (Voltronic-QS
H-protocol over 0665:5161, host xHCI on Linux 6.14): firmware
emits chunks 3..6 of the QS reply collapsed into a single frame
that exceeds wMaxPacketSize, kernel reports LIBUSB_ERROR_OVERFLOW,
and all subsequent reads on EP 0x81 return OVERFLOW until a port
reset.

The same fix is applied to cypress_command() and phoenix_command()
in both drivers because the read loops are byte-identical and the
bug is at the USB transport layer, below either subdriver's
protocol logic.

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

Author: Pyker

drivers/blazer_usb.c

@@ -128,6 +128,26 @@ static int cypress_command(const char *cmd, char *buf, size_t buflen)
 			0x81,
 			(usb_ctrl_charbuf)&buf[i], 8, 1000);
 
+		/* Some firmware in the 0665:5161 Cypress USB-Serial bridge family
+		 * (Salicru SPS ONE, Ippon, Belkin F6C1200-UNV, ViewPower, various
+		 * Voltronic Power UPSes) occasionally emits an interrupt-IN frame
+		 * larger than the declared wMaxPacketSize=8, mid-reply. The kernel
+		 * xHCI driver flags this as LIBUSB_ERROR_OVERFLOW and discards the
+		 * data; from that point on, every subsequent read on the endpoint
+		 * also returns OVERFLOW until a USB-level reset is performed.
+		 * Clear the endpoint halt and retry once: this issues CLEAR_FEATURE
+		 * (HALT) which unsticks the kernel-side endpoint state and in most
+		 * observed cases the firmware's TX-FIFO state as well. If the retry
+		 * also overflows, fall through to the normal error path below.
+		 * See NUT issue #598. */
+		if (ret == LIBUSB_ERROR_OVERFLOW) {
+			upsdebugx(2, "%s: LIBUSB_ERROR_OVERFLOW on EP 0x81, clearing halt and retrying", __func__);
+			usb_clear_halt(udev, 0x81);
+			ret = usb_interrupt_read(udev,
+				0x81,
+				(usb_ctrl_charbuf)&buf[i], 8, 1000);
+		}
+
 		/*
 		 * Any errors here mean that we are unable to read a reply (which
 		 * will happen after successfully writing a command to the UPS)
@@ -212,6 +232,26 @@ static int phoenix_command(const char *cmd, char *buf, size_t buflen)
 			0x81,
 			(usb_ctrl_charbuf)&buf[i], 8, 1000);
 
+		/* Some firmware in the 0665:5161 Cypress USB-Serial bridge family
+		 * (Salicru SPS ONE, Ippon, Belkin F6C1200-UNV, ViewPower, various
+		 * Voltronic Power UPSes) occasionally emits an interrupt-IN frame
+		 * larger than the declared wMaxPacketSize=8, mid-reply. The kernel
+		 * xHCI driver flags this as LIBUSB_ERROR_OVERFLOW and discards the
+		 * data; from that point on, every subsequent read on the endpoint
+		 * also returns OVERFLOW until a USB-level reset is performed.
+		 * Clear the endpoint halt and retry once: this issues CLEAR_FEATURE
+		 * (HALT) which unsticks the kernel-side endpoint state and in most
+		 * observed cases the firmware's TX-FIFO state as well. If the retry
+		 * also overflows, fall through to the normal error path below.
+		 * See NUT issue #598. */
+		if (ret == LIBUSB_ERROR_OVERFLOW) {
+			upsdebugx(2, "%s: LIBUSB_ERROR_OVERFLOW on EP 0x81, clearing halt and retrying", __func__);
+			usb_clear_halt(udev, 0x81);
+			ret = usb_interrupt_read(udev,
+				0x81,
+				(usb_ctrl_charbuf)&buf[i], 8, 1000);
+		}
+
 		/*
 		 * Any errors here mean that we are unable to read a reply (which
 		 * will happen after successfully writing a command to the UPS)

drivers/nutdrv_qx.c

@@ -778,6 +778,26 @@ static int	cypress_command(const char *cmd, size_t cmdlen, char *buf, size_t buf
 			0x81,
 			(usb_ctrl_charbuf)&buf[i], 8, 1000);
 
+		/* Some firmware in the 0665:5161 Cypress USB-Serial bridge family
+		 * (Salicru SPS ONE, Ippon, Belkin F6C1200-UNV, ViewPower, various
+		 * Voltronic Power UPSes) occasionally emits an interrupt-IN frame
+		 * larger than the declared wMaxPacketSize=8, mid-reply. The kernel
+		 * xHCI driver flags this as LIBUSB_ERROR_OVERFLOW and discards the
+		 * data; from that point on, every subsequent read on the endpoint
+		 * also returns OVERFLOW until a USB-level reset is performed.
+		 * Clear the endpoint halt and retry once: this issues CLEAR_FEATURE
+		 * (HALT) which unsticks the kernel-side endpoint state and in most
+		 * observed cases the firmware's TX-FIFO state as well. If the retry
+		 * also overflows, fall through to the normal error path below.
+		 * See NUT issue #598. */
+		if (ret == LIBUSB_ERROR_OVERFLOW) {
+			upsdebugx(2, "%s: LIBUSB_ERROR_OVERFLOW on EP 0x81, clearing halt and retrying", __func__);
+			usb_clear_halt(udev, 0x81);
+			ret = usb_interrupt_read(udev,
+				0x81,
+				(usb_ctrl_charbuf)&buf[i], 8, 1000);
+		}
+
 		/* Any errors here mean that we are unable to read a reply
 		 * (which will happen after successfully writing a command
 		 * to the UPS) */
@@ -989,6 +1009,26 @@ static int	phoenix_command(const char *cmd, size_t cmdlen, char *buf, size_t buf
 			0x81,
 			(usb_ctrl_charbuf)&buf[i], 8, 1000);
 
+		/* Some firmware in the 0665:5161 Cypress USB-Serial bridge family
+		 * (Salicru SPS ONE, Ippon, Belkin F6C1200-UNV, ViewPower, various
+		 * Voltronic Power UPSes) occasionally emits an interrupt-IN frame
+		 * larger than the declared wMaxPacketSize=8, mid-reply. The kernel
+		 * xHCI driver flags this as LIBUSB_ERROR_OVERFLOW and discards the
+		 * data; from that point on, every subsequent read on the endpoint
+		 * also returns OVERFLOW until a USB-level reset is performed.
+		 * Clear the endpoint halt and retry once: this issues CLEAR_FEATURE
+		 * (HALT) which unsticks the kernel-side endpoint state and in most
+		 * observed cases the firmware's TX-FIFO state as well. If the retry
+		 * also overflows, fall through to the normal error path below.
+		 * See NUT issue #598. */
+		if (ret == LIBUSB_ERROR_OVERFLOW) {
+			upsdebugx(2, "%s: LIBUSB_ERROR_OVERFLOW on EP 0x81, clearing halt and retrying", __func__);
+			usb_clear_halt(udev, 0x81);
+			ret = usb_interrupt_read(udev,
+				0x81,
+				(usb_ctrl_charbuf)&buf[i], 8, 1000);
+		}
+
 		/* Any errors here mean that we are unable to read a reply
 		 * (which will happen after successfully writing a command
 		 * to the UPS) */