1. 14 12月, 2016 1 次提交
  2. 22 9月, 2016 1 次提交
  3. 29 5月, 2016 1 次提交
    • G
      Eliminate bad hash multipliers from hash_32() and hash_64() · ef703f49
      George Spelvin 提交于
      The "simplified" prime multipliers made very bad hash functions, so get rid
      of them.  This completes the work of 689de1d6.
      
      To avoid the inefficiency which was the motivation for the "simplified"
      multipliers, hash_64() on 32-bit systems is changed to use a different
      algorithm.  It makes two calls to hash_32() instead.
      
      drivers/media/usb/dvb-usb-v2/af9015.c uses the old GOLDEN_RATIO_PRIME_32
      for some horrible reason, so it inherits a copy of the old definition.
      Signed-off-by: NGeorge Spelvin <linux@sciencehorizons.net>
      Cc: Antti Palosaari <crope@iki.fi>
      Cc: Mauro Carvalho Chehab <m.chehab@samsung.com>
      ef703f49
  4. 10 6月, 2015 1 次提交
    • M
      [media] dvb: Get rid of typedev usage for enums · 0df289a2
      Mauro Carvalho Chehab 提交于
      The DVB API was originally defined using typedefs. This is against
      Kernel CodingStyle, and there's no good usage here. While we can't
      remove its usage on userspace, we can avoid its usage in Kernelspace.
      
      So, let's do it.
      
      This patch was generated by this shell script:
      
      	for j in $(grep typedef include/uapi/linux/dvb/frontend.h |cut -d' ' -f 3); do for i in $(find drivers/media -name '*.[ch]' -type f) $(find drivers/staging/media -name '*.[ch]' -type f); do sed "s,${j}_t,enum $j," <$i >a && mv a $i; done; done
      
      While here, make CodingStyle fixes on the affected lines.
      Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>
      Acked-by: Stefan Richter <stefanr@s5r6.in-berlin.de> # for drivers/media/firewire/*
      0df289a2
  5. 03 9月, 2014 1 次提交
  6. 24 7月, 2014 1 次提交
    • D
      [media] rc-core: document the protocol type · 120703f9
      David Härdeman 提交于
      Right now the protocol information is not preserved, rc-core gets handed a
      scancode but has no idea which protocol it corresponds to.
      
      This patch (which required reading through the source/keymap for all drivers,
      not fun) makes the protocol information explicit which is important
      documentation and makes it easier to e.g. support multiple protocols with one
      decoder (think rc5 and rc-streamzap). The information isn't used yet so there
      should be no functional changes.
      
      [m.chehab@samsung.com: rebased, added cxusb and removed bad whitespacing]
      Signed-off-by: NDavid Härdeman <david@hardeman.nu>
      Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
      120703f9
  7. 08 11月, 2013 1 次提交
  8. 22 3月, 2013 1 次提交
  9. 19 3月, 2013 1 次提交
  10. 06 1月, 2013 2 次提交
  11. 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
  12. 07 10月, 2012 1 次提交
  13. 24 9月, 2012 4 次提交
  14. 16 8月, 2012 1 次提交
  15. 14 8月, 2012 2 次提交
  16. 04 8月, 2012 12 次提交
  17. 15 5月, 2012 1 次提交
  18. 20 3月, 2012 2 次提交
  19. 11 1月, 2012 1 次提交
  20. 31 12月, 2011 3 次提交
  21. 13 12月, 2011 1 次提交