drivers/media/rc/rc-main.c:749 rc_close() warn: inconsistent indenting

There's an extra space there.
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Since commit da6e162d ("[media] rc-core: simplify sysfs code"), when
the IR protocol is set using the sysfs interface to the same set of
protocols that are already set, store_protocols() does not refresh the
scancode filter with the new protocol, even if it has already called the
change_protocol() callback successfully. This results in the filter
being disabled in the hardware and not re-enabled until the filter is
set again using sysfs.

Fix in store_protocols() by still re-applying the filter whenever the
change_protocol() driver callback succeeded.

The problem can be reproduced with the img-ir driver by setting a
filter, and then setting the protocol to the same protocol that is
already set:
$ echo nec > protocols
$ echo 0xffff > filter_mask
$ echo nec > protocols

After this, messages which don't match the filter were still being
received.

Fixes: da6e162d ("[media] rc-core: simplify sysfs code")
Reported-by: NSifan Naeem <sifan.naeem@imgtec.com>
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Cc: David Härdeman <david@hardeman.nu>
Cc: <stable@vger.kernel.org> # v3.17+
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

The functions input_free_device() and rc_close() test whether their argument
is NULL and then return immediately. Thus the test around the call
is not needed.

This issue was detected by using the Coccinelle software.
Signed-off-by: NMarkus Elfring <elfring@users.sourceforge.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

As reported by smatch:
	drivers/media/rc/rc-main.c:1426 rc_register_device() warn: should '1 << rc_map->rc_type' be a 64 bit type?
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

lockdep reports a potential circular dependecy deadlock when registering input device.

Unlock mutex rc_dev->lock prior to calling ir_raw_event_register to avoid the circular
dependency since that function also calls input_register_device and rc_open.

 ======================================================
 [ INFO: possible circular locking dependency detected ]
 3.17.0-rc7+ #24 Not tainted
 -------------------------------------------------------
 modprobe/647 is trying to acquire lock:
  (input_mutex){+.+.+.}, at: [<ffffffff812ed81c>] input_register_device+0x2ba/0x381

 but task is already holding lock:
  (ir_raw_handler_lock){+.+.+.}, at: [<ffffffff813186ed>] ir_raw_event_register+0x102/0x190

 which lock already depends on the new lock.

[cut text]

 other info that might help us debug this:

 Chain exists of:
   input_mutex --> &dev->lock --> ir_raw_handler_lock

  Possible unsafe locking scenario:

        CPU0                    CPU1
        ----                    ----
   lock(ir_raw_handler_lock);
                                lock(&dev->lock);
                                lock(ir_raw_handler_lock);
   lock(input_mutex);

  *** DEADLOCK ***

 4 locks held by modprobe/647:
  #0:  (&dev->mutex){......}, at: [<ffffffff812d19f3>] device_lock+0xf/0x11
  #1:  (&dev->mutex){......}, at: [<ffffffff812d19f3>] device_lock+0xf/0x11
  #2:  (&dev->lock){+.+.+.}, at: [<ffffffff81317fff>] rc_register_device+0x55d/0x58a
  #3:  (ir_raw_handler_lock){+.+.+.}, at: [<ffffffff813186ed>] ir_raw_event_register+0x102/0x190

 stack backtrace:
 CPU: 0 PID: 647 Comm: modprobe Not tainted 3.17.0-rc7+ #24

 Call Trace:
  [<ffffffff81489d6a>] dump_stack+0x46/0x58
  [<ffffffff81487699>] print_circular_bug+0x1f8/0x209
  [<ffffffff81074353>] __lock_acquire+0xb54/0xeda
  [<ffffffff81080f17>] ? console_unlock+0x34d/0x399
  [<ffffffff81074c01>] lock_acquire+0xd9/0x111
  [<ffffffff812ed81c>] ? input_register_device+0x2ba/0x381
  [<ffffffff8148e650>] mutex_lock_interruptible_nested+0x57/0x381
  [<ffffffff812ed81c>] ? input_register_device+0x2ba/0x381
  [<ffffffff81124e03>] ? kfree+0x7c/0x96
  [<ffffffff812ed81c>] ? input_register_device+0x2ba/0x381
  [<ffffffff81072531>] ? trace_hardirqs_on+0xd/0xf
  [<ffffffff812ed81c>] input_register_device+0x2ba/0x381
  [<ffffffff8131a537>] ir_mce_kbd_register+0x109/0x139
  [<ffffffff81318728>] ir_raw_event_register+0x13d/0x190
  [<ffffffff81317e40>] rc_register_device+0x39e/0x58a
  [<ffffffff81072531>] ? trace_hardirqs_on+0xd/0xf
  [<ffffffffa00cf2e3>] nvt_probe+0x5ad/0xd52 [nuvoton_cir]
  [<ffffffffa00ced36>] ? nvt_resume+0x80/0x80 [nuvoton_cir]
  [<ffffffff81296003>] pnp_device_probe+0x8c/0xa9
  [<ffffffff812d1b94>] ? driver_sysfs_add+0x6e/0x93
  [<ffffffff812d203a>] driver_probe_device+0xa1/0x1e3
  [<ffffffff812d217c>] ? driver_probe_device+0x1e3/0x1e3
  [<ffffffff812d21ca>] __driver_attach+0x4e/0x6f
  [<ffffffff812d075b>] bus_for_each_dev+0x5a/0x8c
  [<ffffffff812d1b24>] driver_attach+0x19/0x1b
  [<ffffffff812d1879>] bus_add_driver+0xf1/0x1d6
  [<ffffffff812d2817>] driver_register+0x87/0xbe
  [<ffffffffa0120000>] ? 0xffffffffa0120000
  [<ffffffff81295da4>] pnp_register_driver+0x1c/0x1e
  [<ffffffffa0120010>] nvt_init+0x10/0x1000 [nuvoton_cir]
  [<ffffffff8100030e>] do_one_initcall+0xea/0x18c
  [<ffffffff8111497f>] ? __vunmap+0x9d/0xc7
  [<ffffffff810a3ca1>] load_module+0x1c21/0x1f2c
  [<ffffffff810a0bce>] ? show_initstate+0x44/0x44
  [<ffffffff810a404e>] SyS_init_module+0xa2/0xb1
  [<ffffffff81490ed2>] system_call_fastpath+0x16/0x1b
Signed-off-by: NTomas Melin <tomas.melin@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

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>