IR receiver using nuvoton-cir and lirc required additional configuration
steps after upgrade from kernel 3.16 to 3.17-rcX. Bisected regression to
commit da6e162d ("[media] rc-core:
simplify sysfs code").

The regression comes from adding function change_protocol in ir-raw.c.
It changes behaviour so that only the protocol enabled by driver's
map_name will be active after registration. This breaks user space
behaviour, lirc does not get key press signals anymore.

Enable lirc protocol by default for ir raw decoders to restore original
behaviour.

Cc: stable@vger.kernel.org # for v3.17
Signed-off-by: NTomas Melin <tomas.melin@iki.fi>
Acked-by: NDavid Härdeman <david@hardeman.nu>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

On some hardware (au0828/au8522), the hardware is broken with
regards to the initial pulse detection. So, the driver needs to
produce a fake start pulse. That limits the acceptable protocols,
as it is not possible to produce a fake pulse that would cover
all supported protocols.

So, allow the driver to explicitly set the allowed protocols.

If the driver doesn't specify, keep the old behavior.
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

This protocol is found on Dreambox remotes

[m.chehab@samsung.com: CodingStyle fixes and conflict fix]
Signed-off-by: NMarcel Mol <marcel@mesa.nl>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

We already have dev->scancode_filter and dev->scancode_wakeup_filter
so rename dev->scanmask to dev->scancode_mask for consistency.
Signed-off-by: NDavid Härdeman <david@hardeman.nu>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

The basic API of rc-core used to be:

	dev = rc_allocate_device();
	dev->x = a;
	dev->y = b;
	dev->z = c;
	rc_register_device();

which is a pretty common pattern in the kernel, after the introduction of
protocol arrays the API looks something like:

	dev = rc_allocate_device();
	dev->x = a;
	rc_set_allowed_protocols(dev, RC_BIT_X);
	dev->z = c;
	rc_register_device();

There's no real need for the protocols to be an array, so change it
back to be consistent (and in preparation for the following patches).

[m.chehab@samsung.com: added missing changes at some files]
Signed-off-by: NDavid Härdeman <david@hardeman.nu>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Simplify and cleanup the sysfs code a bit.

[m.chehab@samsung.com: rebased and fixed a CodingStyle issue]
Signed-off-by: NDavid Härdeman <david@hardeman.nu>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

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>

The generic scancode filtering has questionable value and makes it
impossible to determine from userspace if there is an actual
scancode hw filter present or not.

So revert the generic parts.

Based on a patch from James Hogan <james.hogan@imgtec.com>, but this
version also makes sure that only the valid sysfs files are created
in the first place.
Signed-off-by: NDavid Härdeman <david@hardeman.nu>
Acked-by: NJames Hogan <james.hogan@imgtec.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Overloading dev->s_filter to do two different functions (set wakeup filters
and generic hardware filters) makes it impossible to tell what the
hardware actually supports, so create a separate dev->s_wakeup_filter and
make the distinction explicit.
Signed-off-by: NDavid Härdeman <david@hardeman.nu>
Acked-by: NJames Hogan <james.hogan@imgtec.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

rc_map_get() takes a single string literal for the module to load,
so make sure it cannot be used as a format string in the call to
request_module().
Signed-off-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

While playing with make coccicheck I noticed this message:
drivers/media/rc/rc-main.c:1245:3-9: preceding lock on line 1238

It was introduced by commit 587d1b06 ([media] rc-core: reuse device
numbers) which returns -ENOMEM after a mutex_lock without first
unlocking it when there are no more device numbers left. The added code
doesn't depend on the device lock, so move it before the lock is taken.
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

When either of the normal or wakeup filter protocols are changed,
refresh the corresponding scancode filter, i.e. try and set the same
scancode filter with the new protocol. If that fails clear the filter
instead.

If no protocol was selected the filter is just cleared, and if no
s_filter callback exists the filter is left unmodified.

Similarly clear the filter mask when the filter is set if no protocol is
currently selected.

This simplifies driver code which no longer has to explicitly worry
about modifying the filter on a protocol change. This also allows the
change_wakeup_protocol callback to be omitted entirely if there is only
a single available wakeup protocol at a time, since selecting no
protocol will automatically clear the wakeup filter, disabling wakeup.
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Reviewed-by: NAntti Seppälä <a.seppala@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Add a wakeup_protocols sysfs file which controls the new
rc_dev::enabled_protocols[RC_FILTER_WAKEUP], which is the mask of
protocols that are used for the wakeup filter.

A new RC driver callback change_wakeup_protocol() is called to change
the wakeup protocol mask.
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Reviewed-by: NAntti Seppälä <a.seppala@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Only a single allowed and enabled protocol mask currently exists in
struct rc_dev, however to support a separate wakeup filter protocol two
of each are needed, ideally as an array.

Therefore make both rc_dev::allowed_protos and rc_dev::enabled_protocols
arrays, update all users to reference the first element
(RC_FILTER_NORMAL), and add a couple more helper functions for drivers
to use for setting the allowed and enabled wakeup protocols.

We also rename allowed_protos to allowed_protocols while we're at it,
which is more consistent with enabled_protocols.
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Reviewed-by: NAntti Seppälä <a.seppala@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Add generic scancode filtering of RC input events, and fall back to
permitting any RC_FILTER_NORMAL scancode filter to be set if no s_filter
callback exists. This allows raw IR decoder events to be filtered, and
potentially allows hardware decoders to set looser filters and rely on
generic code to filter out the corner cases.
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Reviewed-by: NAntti Seppälä <a.seppala@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Propagate errors returned by drivers from the s_filter callback back to
userland when updating scancode filters. This allows userland to see
when the filter couldn't be updated, usually because it's not a valid
filter for the hardware.

Previously the filter was being updated conditionally on success of
s_filter, but the write always reported success back to userland.
Reported-by: NAntti Seppälä <a.seppala@gmail.com>
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

There are several left overs with my old email address.
Remove their occurrences and add myself at CREDITS, to
allow people to be able to reach me on my new addresses.
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Add and document a generic sysfs based scancode filtering interface for
making use of IR data matching hardware to filter out uninteresting
scancodes. Two filters exist, one for normal operation and one for
filtering scancodes which are permitted to wake the system from suspend.

The following files are added to /sys/class/rc/rc?/:
 - filter: normal scancode filter value
 - filter_mask: normal scancode filter mask
 - wakeup_filter: wakeup scancode filter value
 - wakeup_filter_mask: wakeup scancode filter mask

A new s_filter() driver callback is added which must arrange for the
specified filter to be applied at the right time. Drivers can convert
the scancode filter into a raw IR data filter, which can be applied
immediately or later (for wake up filters).
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Cc: Mauro Carvalho Chehab <m.chehab@samsung.com>
Cc: linux-media@vger.kernel.org
Cc: Rob Landley <rob@landley.net>
Cc: linux-doc@vger.kernel.org
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Add Sharp infrared protocol constants RC_TYPE_SHARP and RC_BIT_SHARP.
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Since v3.12, specifically 153a60bb ([media] rc: add feedback led
trigger for rc keypresses), an LED trigger is activated on IR keydown
whether or not a keypress is generated (i.e. even if there's no matching
keycode). However the repeat and keyup logic isn't used unless there is
a keypress, which results in non-keypress keydown events turning on the
LED and not turning it off again.

On the assumption that the intent was for the LED only to light up on
valid key presses (you probably don't want it lighting up for the wrong
remote control for example), move the led_trigger_event() call inside
the keycode check.
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Acked-by: NSean Young <sean@mess.org>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Fix sparse warning:
	drivers/media/rc/rc-main.c:27:1: sparse: symbol 'ir_core_dev_number' was not declared. Should it be static?
Signed-off-by: NFengguang Wu <fengguang.wu@intel.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Before changeset d8b4b582, the remote controller device numbers
were released when the device were unregistered. That helped to maintain
some sanity, as, when USB devices are replugged, the remote controller
would get the same number.

Restore the same behaviour.
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

At least technisat-usb2.c doesn't set these...
Signed-off-by: NJuergen Lock <nox@jelal.kn-bremen.de>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Many devices with an ir receiver also have a feedback led. Add the
led trigger to support this.
Signed-off-by: NSean Young <sean@mess.org>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

This patch adds user count to rc_dev structure, the reason to add this
new member is to allow other code like lirc to open rc device directly.
In the existing code, rc device is only opened by input subsystem which
works ok if we have any input drivers to match. But in case like lirc
where there will be no input driver, rc device will be never opened.
Having this user count variable will be usefull to allow rc device to be
opened from code other than rc-main.
This patch also adds rc_open and rc_close functions for other drivers
like lirc to open and close rc devices. This functions safely increment
and decrement the user count. Other driver wanting to open rc device
should call rc_open and rc_close, rather than directly modifying the
rc_dev structure.
Signed-off-by: NSrinivas Kandagatla <srinivas.kandagatla@st.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

store_protocols() treats dev->rc_map.rc_type as a bitmap which is wrong for
two reasons. First of all, it is pretty bogus to change the protocol type of
the keymap just because the hardware has been asked to decode a different
protocol.
Second, dev->rc_map.rc_type is an enum (i.e. a single protocol) as pointed
out by James Hogan <james.hogan@imgtec.com>.
Fix both issues by introducing a separate enabled_protocols member to
struct rc_dev.
Signed-off-by: NDavid Härdeman <david@hardeman.nu>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The name is already misleading and will be more so in the future as the
connection to the input subsystem is obscured away further.
Signed-off-by: NDavid Härdeman <david@hardeman.nu>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

rc-core is a subsystem so it should be registered earlier if built into the
kernel.
Signed-off-by: NDavid Härdeman <david@hardeman.nu>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This error path is missing the unlock.

[mchehab@redhat.com: Merged two equal patches into one]
Signed-off-by: NSasha Levin <sasha.levin@oracle.com>
Acked-by: NDavid Härdeman <david@hardeman.nu>
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

We recently introduced a new return -ENODEV in this function but we need
to unlock before returning.

[mchehab@redhat.com: found two patches with the same fix. Merged SOB's/acks into one patch]
Acked-by: NHerton R. Krzesinski <herton.krzesinski@canonical.com>
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Cc: stable@vger.kernel.org
Signed-off-by: NDouglas Bagnall <douglas@paradise.net.nz>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

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>

For some reason, when the lirc daemon learns that a usb remote control
has been unplugged, it wants to read the sysfs attributes of the
disappearing device. This is useful for uncovering transient
inconsistencies, but less so for keeping the system running when such
inconsistencies exist.

Under some circumstances (like every time I unplug my dvb stick from
my laptop), lirc catches an rc_dev whose raw event handler has been
removed (presumably by ir_raw_event_unregister), and proceeds to
interrogate the raw protocols supported by the NULL pointer.

This patch avoids the NULL dereference, and ignores the issue of how
this state of affairs came about in the first place.

Version 2 incorporates changes recommended by Mauro Carvalho Chehab
(-ENODEV instead of -EINVAL, and a signed-off-by).
Signed-off-by: NDouglas Bagnall <douglas@paradise.net.nz>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This changes rc_core to not load the IR decoders at load time,
postponing it to load only if a RC_DRIVER_IR_RAW device is
registered via rc_register_device.
We use a static boolean variable, to ensure decoders modules
are only loaded once.
Tested with rc-loopback device only.
Signed-off-by: NEzequiel Garcia <elezegarcia@gmail.com>
Acked-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

both callers of device_get_devnode() are only interested in lower 16bits
and nobody tries to return anything wider than 16bit anyway.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

This protocol is found on Sanyo/Aiwa remotes.

Tested with an Aiwa RC-7AS06 remote control.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

A pending cleanup will mean that module.h won't be implicitly
everywhere anymore.  Make sure the modular drivers in clocksource
are actually calling out for <module.h> explicitly in advance.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>

rc unregister logic were deadly broken, preventing some drivers to
be removed. Among the broken things, rc_dev_uevent() is being called
during device_del(), causing a data filling on an area that it is
not ready anymore.

Also, some drivers have a stop callback defined, that needs to be called
before data removal, as it stops data polling.
Acked-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This is a custom IR protocol decoder, for the RC-6-ish protocol used by
the Microsoft Remote Keyboard, apparently developed internally at
Microsoft, and officially dubbed MCIR-2, per their March 2011 remote and
transceiver requirements and specifications document, which also touches
on this IR keyboard/mouse device.

Its a standard keyboard with embedded thumb stick mouse pointer and
mouse buttons, along with a number of media keys. The media keys are
standard RC-6, identical to the signals from the stock MCE remotes, and
will be handled as such. The keyboard and mouse signals will be decoded
and delivered to the system by an input device registered specifically
by this driver.

Successfully tested with multiple mceusb-driven transceivers, as well as
with fintek-cir and redrat3 hardware. Essentially, any raw IR hardware
with enough sampling resolution should be able to use this decoder,
nothing about it is at all receiver-hardware-specific.

This work is inspired by lirc_mod_mce:

The documentation there and code aided in understanding and decoding the
protocol, but the bulk of the code is actually borrowed more from the
existing in-kernel decoders than anything. I did recycle the keyboard
keycode table, a few defines, and some of the keyboard and mouse data
parsing bits from lirc_mod_mce though.

Special thanks to James Meyer for providing the hardware, and being
patient with me as I took forever to get around to writing this.

callback routine to ensure we don't get any stuck keys, and used
symbolic names for the keytable. Also cc'ing Florian this time, who I
believe is the original mod-mce author...

CC: Florian Demski <fdemski@users.sourceforge.net>
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

If change_protocol() fails and we goto out_raw, then it calls unlock
twice.  I noticed that the other time we called change_protocol() we
held the &dev->lock, so I changed it to hold it here too.
Reviewed-by: NJarod Wilson <jarod@redhat.com>
Acked-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Due to commit cdda911c, evdev only
becomes readable when the buffer contains an EV_SYN/SYN_REPORT event. If
we get a repeat or a scancode we don't have a mapping for, we never call
input_sync, and thus those events don't get reported in a timely
fashion.

For example, take an mceusb transceiver with a default rc6 keymap. Press
buttons on an rc5 remote while monitoring with ir-keytable, and you'll
see nothing. Now press a button on the rc6 remote matching the keymap.
You'll suddenly get the rc5 key scancodes, the rc6 scancode and the rc6
key spit out all at the same time.

Pressing and holding a button on a remote we do have a keymap for also
works rather unreliably right now, due to repeat events also happening
without a call to input_sync (we bail from ir_do_keydown before getting
to the point where it calls input_sync).

Easy fix though, just add two strategically placed input_sync calls
right after our input_event calls for EV_MSC, and all is well again.
Technically, we probably should have been doing this all along, its just
that it never caused any functional difference until the referenced
change went into the input layer.

input_sync once per IR signal. There was another hidden bug in the code
where we were calling input_report_key using last_keycode instead of our
just discovered keycode, which manifested with the reordering of calling
input_report_key and setting last_keycode.
Reported-by: NStephan Raue <sraue@openelec.tv>
CC: Stephan Raue <sraue@openelec.tv>
CC: Mauro Carvalho Chehab <mchehab@redhat.com>
CC: Jeff Brown <jeffbrown@android.com>
Acked-by: NDmitry Torokhov <dtor@mail.ru>
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>