1. 10 3月, 2009 2 次提交
  2. 09 3月, 2009 4 次提交
  3. 01 3月, 2009 1 次提交
  4. 30 1月, 2009 1 次提交
  5. 13 1月, 2009 1 次提交
    • U
      Input: corgi_ts - mark probe function as __devinit · 840207ed
      Uwe Kleine-König 提交于
      A pointer to corgits_probe is passed to the core via
      platform_driver_register and so the function must not disappear when the
      .init sections are discarded.  Otherwise (if also having HOTPLUG=y)
      unbinding and binding a device to the driver via sysfs will result in an
      oops as does a device being registered late.
      
      An alternative to this patch is using platform_driver_probe instead of
      platform_driver_register plus removing the pointer to the probe function
      from the struct platform_driver.
      
      [dtor@mail.ru: fixed some more section markups]
      Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
      Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
      840207ed
  6. 11 1月, 2009 1 次提交
  7. 08 1月, 2009 1 次提交
  8. 23 12月, 2008 2 次提交
  9. 20 12月, 2008 1 次提交
  10. 02 12月, 2008 1 次提交
  11. 25 11月, 2008 2 次提交
    • P
      hrtimer: removing all ur callback modes · ca109491
      Peter Zijlstra 提交于
      Impact: cleanup, move all hrtimer processing into hardirq context
      
      This is an attempt at removing some of the hrtimer complexity by
      reducing the number of callback modes to 1.
      
      This means that all hrtimer callback functions will be ran from HARD-irq
      context.
      
      I went through all the 30 odd hrtimer callback functions in the kernel
      and saw only one that I'm not quite sure of, which is the one in
      net/can/bcm.c - hence I'm CC-ing the folks responsible for that code.
      
      Furthermore, the hrtimer core now calls callbacks directly with IRQs
      disabled in case you try to enqueue an expired timer. If this timer is a
      periodic timer (which should use hrtimer_forward() to advance its time)
      then it might be possible to end up in an inf. recursive loop due to the
      fact that hrtimer_forward() doesn't round up to the next timer
      granularity, and therefore keeps on calling the callback - obviously
      this needs a fix.
      
      Aside from that, this seems to compile and actually boot on my dual core
      test box - although I'm sure there are some bugs in, me not hitting any
      makes me certain :-)
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      ca109491
    • J
      Input: add support for Wacom W8001 penabled serial touchscreen · 3eb1aa43
      Jaya Kumar 提交于
      The Wacom W8001 sensor is a sensor device (uses electromagnetic
      resonance) and it is interfaced via its serial microcontroller
      to the host.
      Signed-off-by: NJaya Kumar <jayakumar.lkml@gmail.com>
      Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
      3eb1aa43
  12. 20 11月, 2008 1 次提交
    • N
      Input: usbtouchscreen - fix TSC-10 DM USB controllers without EEPROM · 2ec6f246
      Nuno Lucas 提交于
      The usbtouchscreen module implements a driver for the TSC-10 DM USB
      touchscreen controllers, but assumes a 2-byte response for the
      CMD_RESET and CMD_RATE commands, when they can be only a single byte
      when no EEPROM is connected.
      
      The driver worked with an earlier controller revision, but new
      revisions of the controller fail.
      
      It seems the problem is that the early controller had the
      SEL4/EEPROM-CS pin high, but the new controller has it down, making
      the response different.
      
      Without the fix, the controller would answer the single byte 0x06
      (ACK), making the init fail with -ENODEV because buf[1] is 0xFF (as
      initialized before).
      
      As the single byte is the only thing we need to check it was ok, there
      is no need to verify the second byte.
      
      The [0x15 0x01] case is the NAK [0x15] response for when there is no
      data in the EEPROM [bit-0 of second byte set], so I let that be, as I
      don't have any controller with an EEPROM.
      
      With this patch, both the earlier and latest controller work the same.
      
      Note: This was previously submited as BUG #11961 [1] on the bugzilla
      tracker, but rebased to version 2.6.27.4 and with unnecessary comments
      and printk's removed.
      
      [1] http://bugzilla.kernel.org/show_bug.cgi?id=11961Signed-off-by: NNuno Lucas <ntlucas@gmail.com>
      Acked-by: NDaniel Ritz <daniel.ritz@gmx.ch>
      Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
      2ec6f246
  13. 30 10月, 2008 2 次提交
  14. 21 10月, 2008 1 次提交
  15. 20 10月, 2008 2 次提交
  16. 14 10月, 2008 1 次提交
  17. 09 10月, 2008 1 次提交
  18. 18 9月, 2008 1 次提交
  19. 17 9月, 2008 1 次提交
  20. 11 9月, 2008 3 次提交
  21. 24 8月, 2008 1 次提交
  22. 21 8月, 2008 1 次提交
  23. 18 8月, 2008 1 次提交
  24. 11 8月, 2008 1 次提交
  25. 07 8月, 2008 2 次提交
  26. 29 7月, 2008 1 次提交
  27. 27 7月, 2008 1 次提交
  28. 24 7月, 2008 2 次提交