1. 12 3月, 2014 1 次提交
  2. 04 1月, 2013 1 次提交
    • G
      Drivers: media: remove __dev* attributes. · 4c62e976
      Greg Kroah-Hartman 提交于
      CONFIG_HOTPLUG is going away as an option.  As a result, the __dev*
      markings need to be removed.
      
      This change removes the use of __devinit, __devexit_p, __devinitdata,
      __devinitconst, and __devexit from these drivers.
      
      Based on patches originally written by Bill Pemberton, but redone by me
      in order to handle some of the coding style issues better, by hand.
      
      Cc: Bill Pemberton <wfp5p@virginia.edu>
      Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4c62e976
  3. 22 12月, 2012 2 次提交
    • M
      [media] rc: Set rdev before irq setup · d62b6818
      Matthijs Kooijman 提交于
      This fixes a problem in fintek-cir and nuvoton-cir where the
      irq handler would trigger during module load before the rdev member was
      set, causing a NULL pointer crash.
      It seems this crash is very reproducible (just bombard the receiver with
      IR signals during module load), probably because when request_irq is
      called, any pending intterupt is handled immediately, before
      request_irq returns and rdev can be set.
      This same crash was supposed to be fixed by commit
      9ef449c6 ("[media] rc: Postpone ISR
      registration"), but the crash was still observed on the nuvoton-cir
      driver.
      This commit was tested on nuvoton-cir only.
      
      Cc: Jarod Wilson <jarod@redhat.com>
      Signed-off-by: NMatthijs Kooijman <matthijs@stdin.nl>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      d62b6818
    • M
      [media] rc: Make probe cleanup goto labels more verbose · 70ef6991
      Matthijs Kooijman 提交于
      Before, labels were simply numbered. Now, the labels are named after the
      cleanup action they'll perform (first), based on how the winbond-cir
      driver does it. This makes the code a bit more clear and makes changes
      in the ordering of labels easier to review.
      This change is applied only to the rc drivers that do significant
      cleanup in their probe functions: ati-remote, ene-ir, fintek-cir,
      gpio-ir-recv, ite-cir, nuvoton-cir.
      This commit should not change any code, it just renames goto labels.
      
      [mchehab@redhat.com: removed changes at gpio-ir-recv.c, due to
       merge conflicts]
      Signed-off-by: NMatthijs Kooijman <matthijs@stdin.nl>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      70ef6991
  4. 28 10月, 2012 1 次提交
  5. 27 10月, 2012 1 次提交
    • D
      [media] rc-core: add separate defines for protocol bitmaps and numbers · c003ab1b
      David Härdeman 提交于
      The RC_TYPE_* defines are currently used both where a single protocol is
      expected and where a bitmap of protocols is expected.
      
      Functions like rc_keydown() and functions which add/remove entries to the
      keytable want a single protocol. Future userspace APIs would also
      benefit from numeric protocols (rather than bitmap ones). Keytables are
      smaller if they can use a small(ish) integer rather than a bitmap.
      
      Other functions or struct members (e.g. allowed_protos,
      enabled_protocols, etc) accept multiple protocols and need a bitmap.
      
      Using different types reduces the risk of programmer error. Using a
      protocol enum whereever possible also makes for a more future-proof
      user-space API as we don't need to worry about a sufficient number of
      bits being available (e.g. in structs used for ioctl() calls).
      
      The use of both a number and a corresponding bit is dalso one in e.g.
      the input subsystem as well (see all the references to set/clear bit when
      changing keytables for example).
      
      This patch separate the different usages in preparation for
      upcoming patches.
      
      Where a single protocol is expected, enum rc_type is used; where one or more
      protocol(s) are expected, something like u64 is used.
      
      The patch has been rewritten so that the format of the sysfs "protocols"
      file is no longer altered (at the loss of some detail). The file itself
      should probably be deprecated in the future though.
      Signed-off-by: NDavid Härdeman <david@hardeman.nu>
      Cc: Andy Walls <awalls@md.metrocast.net>
      Cc: Maxim Levitsky <maximlevitsky@gmail.com>
      Cc: Antti Palosaari <crope@iki.fi>
      Cc: Mike Isely <isely@pobox.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      c003ab1b
  6. 14 8月, 2012 1 次提交
  7. 07 7月, 2012 1 次提交
  8. 20 5月, 2012 1 次提交
  9. 27 4月, 2012 2 次提交
  10. 15 2月, 2012 1 次提交
  11. 11 6月, 2011 1 次提交
  12. 26 5月, 2011 1 次提交
    • J
      [media] fintek-cir: new driver for Fintek LPC SuperIO CIR function · 9bdc79ea
      Jarod Wilson 提交于
      This is a new driver for the Fintek LPC SuperIO CIR function, in the
      Fintek F71809 chip. Hardware and datasheets were provided by Fintek, so
      thanks go to them for supporting this effort.
      
      This driver started out as a copy of the nuvoton-cir driver, and was
      then modified as needed for the Fintek chip. The two share many
      similaries, though the buffer handling for the Fintek chip is actually
      nearly identical to the mceusb buffer handling, so the parser routine is
      almost a drop-in copy of the mceusb buffer parser (a candidate for being
      abstracted out into shared code at some point).
      
      This initial code drop *only* supports receive, but the hardware does
      support transmit as well. I really haven't even started to look at
      what's required, but my guess is that its also pretty similar to mceusb.
      Most people are probably only really interested in RX anyway though, so
      I think its good to get this out there even with only RX.
      
      (Nb: there are also Fintek-made mceusb receivers, which presumably, this
      chip shares CIR hardware with).
      
      This hardware can be found on at least Jetway NC98 boards and derivative
      systems, and likely others as well. Functionality was tested with an
      NC98 development board, in-kernel decode of RC6 (mce), RC5 (hauppauge)
      and NEC-ish (tivo) remotes all successful, as was lirc userspace decode
      of the RC6 remote.
      
      CC: Aaron Huang <aaron_huang@fintek.com.tw>
      CC: Tom Tsai <tom_tsai@fintek.com.tw>
      Signed-off-by: NJarod Wilson <jarod@redhat.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      9bdc79ea