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>

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>

It's better to give platform code a chance to specify the allowed
protocols to use.

[mchehab@redhat.com: fix merge conflict with a patch that made
 half of this change]
Signed-off-by: NDu, Changbin <changbin.du@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Cc: Ravi Kumar V <kumarrav@codeaurora.org>
Signed-off-by: NBenoît Thébaudeau <benoit.thebaudeau@advansee.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Make it possible for gpio-ir-recv users to choose a map name.

Cc: Ravi Kumar V <kumarrav@codeaurora.org>
Signed-off-by: NBenoît Thébaudeau <benoit.thebaudeau@advansee.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Add missing information so that udev can create an entry for gpio-ir-recv under
/dev/input/by-path/ .

Cc: Ravi Kumar V <kumarrav@codeaurora.org>
Signed-off-by: NBenoît Thébaudeau <benoit.thebaudeau@advansee.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

There are couple places where we check unsigned values for negative.  I
changed ->gpin_nr to signed because in gpio_ir_recv_probe() we do:
        if (pdata->gpio_nr < 0)
                return -EINVAL;
I also change gval to a signed int in gpio_ir_recv_irq() because that's
the type that gpio_get_value_cansleep() returns and we test for negative
returns.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: NTrilok Soni <tsoni@codeaurora.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Adds GPIO based IR Receiver driver. It decodes signals using decoders
available in rc framework.
Signed-off-by: NRavi Kumar V <kumarrav@codeaurora.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>