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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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: David 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: Mauro Carvalho Chehab <mchehab@redhat.com>
Note that the firmware already disables the receiver before transmit,
there is no need to do this from the driver.
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Since commit "[media] rc-core: move timeout and checks to lirc", the
incoming buffer is used after the driver transmits.
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The TechnoTrend USB IR Receiver sends 125 ISO URBs per second, even when
there is no IR activity. Reduce the number of wake ups from the other
drivers too.
This saves about 0.25ms/s on a 2.4GHz Core 2 according to powertop.
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The Pioneer CU-700 remote causes receiver overflows if you hold down any
button. The remote does not send NEC IR repeats, it repeats the entire
NEC code after 20ms.
The iguanair hardware advertises an interval of 10 which just not enough;
with 100 URBs per second and at most 7 edges per URB, we handle at most
700 edges per second. The remote generates about 900.
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
With the timeout supplied the interface can go idle. The keymap is
the same one as other drivers which do not come with a remote.
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Firmware versions lower than 0x0205 use a different interface which is not
supported. Also report the firmware version in the standard format.
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Rather than using usb_interrupt_msg() to receive responses, reuse the
urb callback we already have in place.
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
