Re: [PATCH] Input: xpad - add support for Azeron devices

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [Low] The patch inadvertently introduces duplicate device entries and breaks the documented sorting order of the `xpad_device` array.

Pre-existing issues:
- [High] The newly supported devices permanently wedge the driver's OUT endpoint upon connection due to an unhandled -EPIPE stall on the LED packet.
--

commit 82abb48f58f1b666ded31cf35205e5974880b177
Author: Roberts Kursitis <roberts.kursitis@azeron.eu>

Input: xpad - add support for Azeron devices

Add USB Vendor and Product IDs for the Azeron devices (Cyro, Cyborg,
Classic/Compact, Cyro Lefty, Cyborg II and Keyzen).

> diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
> index feb8f368f834e..82019cbe2a9c7 100644
> --- a/drivers/input/joystick/xpad.c
> +++ b/drivers/input/joystick/xpad.c
> @@ -292,6 +292,14 @@ static const struct xpad_device {
>  	{ 0x1689, 0xfd00, "Razer Onza Tournament Edition", 0, XTYPE_XBOX360 },
>  	{ 0x1689, 0xfd01, "Razer Onza Classic Edition", 0, XTYPE_XBOX360 },
>  	{ 0x1689, 0xfe00, "Razer Sabertooth", 0, XTYPE_XBOX360 },
> +	{ 0x162e, 0xbeef, "Joytech Neo-Se Take2", 0, XTYPE_XBOX360 },
> +	{ 0x16d0, 0x1103, "Azeron Cyro", 0, XTYPE_XBOX360 },
> +	{ 0x16d0, 0x113c, "Azeron Cyborg", 0, XTYPE_XBOX360 },
> +	{ 0x16d0, 0x1192, "Azeron Classic/Compact", 0, XTYPE_XBOX360 },
> +	{ 0x16d0, 0x1212, "Azeron Cyro Lefty", 0, XTYPE_XBOX360 },
> +	{ 0x16d0, 0x12f7, "Azeron Cyborg II", 0, XTYPE_XBOX360 },
> +	{ 0x16d0, 0x13ea, "Azeron Keyzen", 0, XTYPE_XBOX360 },
> +	{ 0x1689, 0xfd00, "Razer Onza Tournament Edition", 0, XTYPE_XBOX360 },
[Severity: Low]
It looks like this might be a copy-paste error, and it also breaks the
documented vendor/product ID sorting order of the xpad_device array.

Was it intended to duplicate the "Joytech Neo-Se Take2" and "Razer Onza
Tournament Edition" entries here?

[Severity: High]
This isn't a bug introduced by this patch, but adding these new devices here
unconditionally triggers it since they are mapped generically as XTYPE_XBOX360
without any quirks.

The commit message notes that these devices reject the LED magic-packet with
a stall (-EPIPE). Because they are mapped as XTYPE_XBOX360, xpad_led_probe()
unconditionally queues an LED initialization command during probe.

When the device stalls the endpoint, the xpad_irq_out() handler receives
-EPIPE but fails to clear the hardware halt via usb_clear_halt(). It leaves
the endpoint permanently halted at the hardware level:

drivers/input/joystick/xpad.c:xpad_irq_out() {
	...
	switch (status) {
	case 0:
		/* success */
		xpad->irq_out_active = xpad_prepare_next_out_packet(xpad);
		break;
	...
	default:
		dev_dbg(dev, "%s - nonzero urb status received: %d\n",
			__func__, status);
		break;
	}
	...
}

The host controller will ignore further submissions to a halted endpoint,
causing all subsequent output commands (like force-feedback) to silently
fail or hang.

Should a quirk be implemented and applied to these devices to avoid sending
LED packets to devices that stall on them?

>  	{ 0x17ef, 0x6182, "Lenovo Legion Controller for Windows", 0, XTYPE_XBOX360 },
>  	{ 0x1949, 0x041a, "Amazon Game Controller", 0, XTYPE_XBOX360 },
>  	{ 0x1a86, 0xe310, "Legion Go S", 0, XTYPE_XBOX360 },

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260619121901.17926-1-roberts.kursitis@azeron.eu?part=1