[PATCH 1/2] input: usb: hid: Bump maximum global item tag report size to 128 bytes

The Freescale i.MX28 BootROM USB recovery mode implements the USB HID
protocol, yet the global item tag report size is 128. Linux checks if
this is 96 as of now, see [1]. This causes Linux to refuse to communicate
with this device, making it impossible to use the recovery mode.

This is not a standard HID device per se, but rather a software emulation
implemented within the BootROM code and realized through USB OTG-capable
port switched to device mode present on the device.

Previous attempt to discuss this issue dates back to 2011, see [2]. There
has been not much response. Also noteworthy is the [3], where there seems
to be a pointing device that has issue similar to this one.

The tool making use of the USB recovery mode is available at [4].

[1] http://comments.gmane.org/gmane.linux.kernel.input/22328
[2] http://www.spinics.net/lists/linux-usb/msg43463.html
[3] https://bbs.archlinux.org/viewtopic.php?pid=1141340
[4] http://git.bfuser.eu/?p=marex/mxsldr.git;a=summary

Signed-off-by: Marek Vasut <redacted>
Cc: Chen Peter <redacted>
Cc: Greg KH <redacted>
Cc: Jiri Kosina <redacted>
---
 drivers/hid/hid-core.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 60ea284..2b9dd76 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c

@@ -374,7 +374,7 @@ static int hid_parser_global(struct hid_parser *parser, struct hid_item *item)
 
 	case HID_GLOBAL_ITEM_TAG_REPORT_SIZE:
 		parser->global.report_size = item_udata(item);
-		if (parser->global.report_size > 96) {
+		if (parser->global.report_size > 128) {
 			hid_err(parser->device, "invalid report_size %d\n",
 					parser->global.report_size);
 			return -1;

-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

The USB recovery mode present in i.MX28 ROM emulates USB HID.
It needs this quirk to behave properly.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Chen Peter <redacted>
Cc: Greg KH <redacted>
Cc: Jiri Kosina <redacted>
---
 drivers/hid/hid-ids.h           |    3 +++
 drivers/hid/usbhid/hid-quirks.c |    1 +
 2 files changed, 4 insertions(+)

diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 1dcb76f..ab8ce9f 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h

@@ -296,6 +296,9 @@
 #define USB_VENDOR_ID_EZKEY		0x0518
 #define USB_DEVICE_ID_BTC_8193		0x0002
 
+#define USB_VENDOR_ID_FREESCALE		0x15A2
+#define USB_DEVICE_ID_FREESCALE_MX28	0x004F
+
 #define USB_VENDOR_ID_FRUCTEL	0x25B6
 #define USB_DEVICE_ID_GAMETEL_MT_MODE	0x0002
 

diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index 903eef3..6a09570 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c

@@ -101,6 +101,7 @@ static const struct hid_blacklist {
 	{ USB_VENDOR_ID_SIGMA_MICRO, USB_DEVICE_ID_SIGMA_MICRO_KEYBOARD, HID_QUIRK_NO_INIT_REPORTS },
 	{ USB_VENDOR_ID_KYE, USB_DEVICE_ID_KYE_MOUSEPEN_I608X, HID_QUIRK_MULTI_INPUT },
 	{ USB_VENDOR_ID_KYE, USB_DEVICE_ID_KYE_EASYPEN_M610X, HID_QUIRK_MULTI_INPUT },
+	{ USB_VENDOR_ID_FREESCALE, USB_DEVICE_ID_FREESCALE_MX28, HID_QUIRK_NOGET },
 	{ 0, 0 }
 };
 

-- 
1.7.10.4

On Sun, 5 Aug 2012, Marek Vasut wrote:

The Freescale i.MX28 BootROM USB recovery mode implements the USB HID
protocol, yet the global item tag report size is 128. Linux checks if
this is 96 as of now, see [1]. This causes Linux to refuse to communicate
with this device, making it impossible to use the recovery mode.

This is not a standard HID device per se, but rather a software emulation
implemented within the BootROM code and realized through USB OTG-capable
port switched to device mode present on the device.

Previous attempt to discuss this issue dates back to 2011, see [2]. There
has been not much response. Also noteworthy is the [3], where there seems
to be a pointing device that has issue similar to this one.

The tool making use of the USB recovery mode is available at [4].

[1] http://comments.gmane.org/gmane.linux.kernel.input/22328
[2] http://www.spinics.net/lists/linux-usb/msg43463.html
[3] https://bbs.archlinux.org/viewtopic.php?pid=1141340
[4] http://git.bfuser.eu/?p=marex/mxsldr.git;a=summary

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Chen Peter <redacted>
Cc: Greg KH <redacted>
Cc: Jiri Kosina <redacted>

I have not admit I don't remember where the original limit came from -- 
the spec doesn't mandate it as far as I can tell.

I am queueing this patch now for next merge window. Thanks.

-- 
Jiri Kosina
SUSE Labs

Dear Jiri Kosina,

On Sun, 5 Aug 2012, Marek Vasut wrote:

quoted

The Freescale i.MX28 BootROM USB recovery mode implements the USB HID
protocol, yet the global item tag report size is 128. Linux checks if
this is 96 as of now, see [1]. This causes Linux to refuse to communicate
with this device, making it impossible to use the recovery mode.

This is not a standard HID device per se, but rather a software emulation
implemented within the BootROM code and realized through USB OTG-capable
port switched to device mode present on the device.

Previous attempt to discuss this issue dates back to 2011, see [2]. There
has been not much response. Also noteworthy is the [3], where there seems
to be a pointing device that has issue similar to this one.

The tool making use of the USB recovery mode is available at [4].

[1] http://comments.gmane.org/gmane.linux.kernel.input/22328
[2] http://www.spinics.net/lists/linux-usb/msg43463.html
[3] https://bbs.archlinux.org/viewtopic.php?pid=1141340
[4] http://git.bfuser.eu/?p=marex/mxsldr.git;a=summary

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Chen Peter <redacted>
Cc: Greg KH <redacted>
Cc: Jiri Kosina <redacted>

I have not admit I don't remember where the original limit came from --
the spec doesn't mandate it as far as I can tell.

I am queueing this patch now for next merge window. Thanks.

[...]

Thanks!

Best regards,
Marek Vasut