Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 15 1月, 2010 1 次提交
  3. 13 1月, 2010 3 次提交
  5. 12 1月, 2010 1 次提交
    • M
      HID: make USB device id constant · d67dec5b
      由 Márton Németh 提交于 
      The id_table field of the struct usb_device_id is constant in <linux/usb.h>
so it is worth to make the initialization data also constant.

The semantic match that finds this kind of pattern is as follows:
(http://coccinelle.lip6.fr/)

// <smpl>
@r@
disable decl_init,const_decl_init;
identifier I1, I2, x;
@@
	struct I1 {
	  ...
	  const struct I2 *x;
	  ...
	};
@s@
identifier r.I1, y;
identifier r.x, E;
@@
	struct I1 y = {
	  .x = E,
	};
@c@
identifier r.I2;
identifier s.E;
@@
	const struct I2 E[] = ... ;
@depends on !c@
identifier r.I2;
identifier s.E;
@@
+	const
	struct I2 E[] = ...;
// </smpl>
Signed-off-by: NMárton Németh <nm127@freemail.hu>
Cc: Julia Lawall <julia@diku.dk>
Cc: cocci@diku.dk
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      d67dec5b
  7. 06 1月, 2010 1 次提交
  9. 05 1月, 2010 1 次提交
  11. 04 1月, 2010 3 次提交
  13. 23 12月, 2009 2 次提交
  15. 03 12月, 2009 2 次提交
  17. 25 11月, 2009 1 次提交
  19. 24 11月, 2009 1 次提交
  21. 13 11月, 2009 1 次提交
  23. 06 11月, 2009 1 次提交
  25. 05 11月, 2009 1 次提交
    • J
      HID: fixup quirk for NCR devices · 5b915d9e
      由 Jiri Kosina 提交于 
      NCR devices are terminally broken by design -- they claim themselves to contain
proper input applications in their HID report descriptor, but behave very badly
if treated in standard way.

According to NCR developers, the devices get confused when queried for reports
in a standard way, rendering them unusable.

NCR is shipping application called "RPSL" that can be used to drive these
devices through hiddev, under the assumption that in-kernel driver doesn't
perform initial report query.
If it does, neither in-kernel nor hiddev-based driver can operate with these
devices any more.

Introduce a quirk that skips the report query for all NCR devices. The previous
NOGET quirk was wrong and had been introduced because I misunderstood the nature
of brokenness of these devices.
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      5b915d9e
  27. 04 11月, 2009 1 次提交
  29. 20 10月, 2009 1 次提交
  31. 14 10月, 2009 3 次提交
  33. 12 10月, 2009 1 次提交
  35. 05 10月, 2009 1 次提交
  37. 01 10月, 2009 1 次提交
    • J
      HID: fix kerneldoc comment for hid_input_report() · ff9b00a2
      由 Jiri Kosina 提交于 
      The kerneldoc comment for 'interrupt' has already confused a lot
of people, as it is simply wrong. It doesn't carry the information
about the context, but is used to distinguish between two fundamental
types of low-level transport transfers -- interrupt vs. control.

Make this clear in the comment.
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      ff9b00a2
  39. 29 9月, 2009 1 次提交
  41. 20 9月, 2009 1 次提交
  43. 17 9月, 2009 2 次提交
  45. 15 9月, 2009 1 次提交
  47. 26 8月, 2009 1 次提交
  49. 20 8月, 2009 1 次提交
    • J
      HID: support larger reports than 64 bytes in hiddev · affbb8c6
      由 Jiri Kosina 提交于 
      hiddev userspace driver uses a rignbuffer to store the parsed usages
that should be returned through read(). This buffer is 64 bytes long,
which is sufficient for queueing single USB 1.0 low-speed report, which
is of maximum size 48 bytes.

There are however USB HID devices which are full-speed USB devices, and
therefore they are free to produce reports 64 bytes long. This is correctly
handled by HID core, but read() on hiddev node gets stuck forever, because
the ring buffer loops infinitely (as it is exactly 64 bytes long as well),
never advancing the buffer pointer.

Plus, the core driver is ready to handle highspeed devices, so we should be
able to handle reports from such devices in the hiddev driver as well, which
means we need larger ringbuffer.
Reported-by: NMichael Zeisel <michael.zeisel@philips.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      affbb8c6
  51. 18 8月, 2009 1 次提交
  53. 08 8月, 2009 4 次提交
  55. 23 7月, 2009 1 次提交