On sun6i the cir block is attached to the reset controller, add support
for de-asserting the reset if a reset controller is specified in dt.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>
Acked-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
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>

Add img-ir module for decoding Philips rc6 protocol.
Signed-off-by: NSifan Naeem <sifan.naeem@imgtec.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Add img-ir module for decoding Philips rc5 protocol.
Signed-off-by: NSifan Naeem <sifan.naeem@imgtec.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Biphase decoding in the current img-ir has got a quirk, where multiple
Interrupts are generated when an incomplete IR code is received by the
decoder.

Patch adds a work around for the quirk and enables biphase decoding.
Signed-off-by: NSifan Naeem <sifan.naeem@imgtec.com>
Acked-by: NJames Hogan <james.hogan@imgtec.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Add toggle bit to struct img_ir_scancode_req so that protocols can
provide it to img_ir_handle_data(), and pass that toggle bit up to
rc_keydown instead of 0.

This is needed for the upcoming rc-5 and rc-6 patches.
Signed-off-by: NSifan Naeem <sifan.naeem@imgtec.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

The information being requested of hardware decode callbacks through
the img-ir-hw scancode API is mounting up, so combine it into a struct
which can be passed in with a single pointer rather than multiple
pointer arguments. This allows it to be extended more easily without
touching all the hardware decode callbacks.
Signed-off-by: NSifan Naeem <sifan.naeem@imgtec.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Don't bother setting .owner = THIS_MODULE, since it's already handled by
the platform_driver_register macro.
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

The ImgTec Infrared decoder block which img-ir drives is only used in
IMGWorks SoCs so far, such as the TZ1090 (Meta based) and the upcoming
Pistachio (MIPS based). Therefore make the driver depend on METAG (for
TZ1090) or MIPS (for Pistachio) or COMPILE_TEST (so that it is included
in x86 allmodconfig builds), to avoid cluttering the Kconfig menu with
drivers for hardware that isn't yet available on other platforms.
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

The img_ir_register_decoder() and img_ir_unregister_decoder() functions
were dropped prior to the img-ir driver being applied to simplify the
protocol decoder setup. However the declarations of these functions in
img-ir-hw.h were still included. Delete them since they're completely
unused.
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

The end timer is used for switching back from repeat code timings when
no repeat codes have been received for a certain amount of time. When
the protocol is changed, the end timer is deleted synchronously with
del_timer_sync(), however this takes place while holding the main spin
lock, and the timer handler also needs to acquire the spin lock.

This opens the possibility of a deadlock on an SMP system if the
protocol is changed just as the repeat timer is expiring. One CPU could
end up in img_ir_set_decoder() holding the lock and waiting for the end
timer to complete, while the other CPU is stuck in the timer handler
spinning on the lock held by the first CPU.

Lockdep also spots a possible lock inversion in the same code, since
img_ir_set_decoder() acquires the img-ir lock before the timer lock, but
the timer handler will try and acquire them the other way around:

=========================================================
[ INFO: possible irq lock inversion dependency detected ]
3.18.0-rc5+ #957 Not tainted
---------------------------------------------------------
swapper/0/0 just changed the state of lock:
 (((&hw->end_timer))){+.-...}, at: [<4006ae5c>] _call_timer_fn+0x0/0xfc
but this lock was taken by another, HARDIRQ-safe lock in the past:
 (&(&priv->lock)->rlock#2){-.....}

and interrupts could create inverse lock ordering between them.

other info that might help us debug this:
 Possible interrupt unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(((&hw->end_timer)));
                               local_irq_disable();
                               lock(&(&priv->lock)->rlock#2);
                               lock(((&hw->end_timer)));
  <Interrupt>
    lock(&(&priv->lock)->rlock#2);

 *** DEADLOCK ***

This is fixed by releasing the main spin lock while performing the
del_timer_sync() call. The timer is prevented from restarting before the
lock is reacquired by a new "stopping" flag which img_ir_handle_data()
checks before updating the timer.

---------------------------------------------------------
swapper/0/0 just changed the state of lock:
 (((&hw->end_timer))){+.-...}, at: [<4006ae5c>] _call_timer_fn+0x0/0xfc
but this lock was taken by another, HARDIRQ-safe lock in the past:
 (&(&priv->lock)->rlock#2){-.....}
and interrupts could create inverse lock ordering between them.
other info that might help us debug this:
 Possible interrupt unsafe locking scenario:
       CPU0                    CPU1
       ----                    ----
  lock(((&hw->end_timer)));
                               local_irq_disable();
                               lock(&(&priv->lock)->rlock#2);
                               lock(((&hw->end_timer)));
  <Interrupt>
    lock(&(&priv->lock)->rlock#2);
 *** DEADLOCK ***
This is fixed by releasing the main spin lock while performing the
del_timer_sync() call. The timer is prevented from restarting before the
lock is reacquired by a new "stopping" flag which img_ir_handle_data()
checks before updating the timer.
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Cc: Sifan Naeem <sifan.naeem@imgtec.com>
Cc: <stable@vger.kernel.org> # v3.15+
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

A problem was found on Polaris where if the unit it booted via the power
button on the infrared remote then the next button press on the remote
would return the key code used to power on the unit.

The sequence is:
 - The polaris powered off but with the powerdown controller (PDC) block
   still powered.
 - Press power key on remote, IR block receives the key.
 - Kernel starts, IR code is in IMG_IR_DATA_x but neither IMG_IR_RXDVAL
   or IMG_IR_RXDVALD2 are set.
 - Wait any amount of time.
 - Press any key.
 - IMG_IR_RXDVAL or IMG_IR_RXDVALD2 is set but IMG_IR_DATA_x is
   unchanged since the powerup key data was never read.

This is worked around by always reading the IMG_IR_DATA_x in
img_ir_set_decoder(), rather than only when the IMG_IR_RXDVAL or
IMG_IR_RXDVALD2 bit is set.
Signed-off-by: NDylan Rajaratnam <dylan.rajaratnam@imgtec.com>
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Cc: <stable@vger.kernel.org> # v3.15+
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

This fixes the driver on arm.
Reported-by: NSteven Guitton <keltiek@gmail.com>
Tested-by: NSteven Guitton <keltiek@gmail.com>
Signed-off-by: NSean Young <sean@mess.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Amlogic Meson SoCs include a infrared remote control receiver that can
operate in two modes: "NEC" mode in which the hardware decodes frames
using the NEC IR protocol, and "general" mode in which the receiver
simply reports the duration of pulses and spaces for software
decoding.

This is a driver for the IR receiver that implements software decoding
of received frames.
Signed-off-by: NBeniamino Galvani <b.galvani@gmail.com>
Acked-by: NCarlo Caione <carlo@caione.org>
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>

The toggle bit shouldn't be cleared before the toggle value is calculated.

This should probably go into 3.17.x as well.

Fixes: 120703f9 ([media] rc-core: document the protocol type)

Cc: stable@vger.kernel.org # For v3.17
Tested-by: NStephan Raue <mailinglists@openelec.tv>
Signed-off-by: NDavid Härdeman <david@hardeman.nu>
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>

Userspace expects to see a long space before the first pulse is sent on
the lirc device.  Currently, if a long time has passed and a new packet
is started, the lirc codec just returns and doesn't send anything.  This
makes lircd ignore many perfectly valid signals unless they are sent in
quick sucession.  When a reset event is delivered, we cannot know
anything about the duration of the space.  But it should be safe to
assume it has been a long time and we just set the duration to maximum.
Signed-off-by: NAustin Lund <austin.lund@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

This is a complete re-write inspired by the original lirc driver.
Signed-off-by: NSean Young <sean@mess.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

With kernel 3.17 the imon remote control for device 15c2:0034 does not
work anymore, which uses the OTHER protocol. Only the front panel
buttons which uses the RC6 protocol are working.

Adds the missing comparison for the RC_BIT_OTHER.

Cc: stable@vger.kernel.org # for Kernel 3.17
Signed-off-by: NUlrich Eckhardt <uli@uli-eckhardt.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Change CONFIG_PM to CONFIG_PM_SLEEP to solve
warning: 'hix5hd2_ir_suspend' & 'hix5hd2_ir_resume' defined but not used
Signed-off-by: NZhangfei Gao <zhangfei.gao@linaro.org>
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>

Changeset e87b540b broke RC5-SZ decoding, as it forgot to add
the extra bit check for the enabled protocols at the beginning of
the logic.
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>
Acked-by: NDavid Härdeman <david@hardeman.nu>
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>

A platform_driver does not need to set an owner, it will be populated by the
driver core.
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

A platform_driver does not need to set an owner, it will be populated by the
driver core.
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

While not all archs have readl_relaxed, we need to add a hack at the
driver to allow it to COMPILE_TEST on all archs:

	drivers/media/rc/ir-hix5hd2.c: In function ‘hix5hd2_ir_config’:
	drivers/media/rc/ir-hix5hd2.c:100:2: error: implicit declaration of function ‘readl_relaxed’ [-Werror=implicit-function-declaration]
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

This replaces http://git.linuxtv.org/v4l-utils/ (broken link)
by http://git.linuxtv.org/cgit.cgi/v4l-utils.git/Signed-off-by: NMichael Opdenacker <michael.opdenacker@free-electrons.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

drivers/media/rc/st_rc.c:107:38: warning: incorrect type in argument 1 (different address spaces)
drivers/media/rc/st_rc.c:107:38:    expected void const volatile [noderef] <asn:2>*addr
drivers/media/rc/st_rc.c:107:38:    got void *
drivers/media/rc/st_rc.c:110:53: warning: incorrect type in argument 1 (different address spaces)
drivers/media/rc/st_rc.c:110:53:    expected void const volatile [noderef] <asn:2>*addr
drivers/media/rc/st_rc.c:110:53:    got void *
drivers/media/rc/st_rc.c:116:54: warning: incorrect type in argument 2 (different address spaces)
drivers/media/rc/st_rc.c:116:54:    expected void volatile [noderef] <asn:2>*addr
drivers/media/rc/st_rc.c:116:54:    got void *
drivers/media/rc/st_rc.c:120:45: warning: incorrect type in argument 1 (different address spaces)
drivers/media/rc/st_rc.c:120:45:    expected void const volatile [noderef] <asn:2>*addr
drivers/media/rc/st_rc.c:120:45:    got void *
drivers/media/rc/st_rc.c:121:43: warning: incorrect type in argument 1 (different address spaces)
drivers/media/rc/st_rc.c:121:43:    expected void const volatile [noderef] <asn:2>*addr
drivers/media/rc/st_rc.c:121:43:    got void *
drivers/media/rc/st_rc.c:150:46: warning: incorrect type in argument 1 (different address spaces)
drivers/media/rc/st_rc.c:150:46:    expected void const volatile [noderef] <asn:2>*addr
drivers/media/rc/st_rc.c:150:46:    got void *
drivers/media/rc/st_rc.c:153:42: warning: incorrect type in argument 2 (different address spaces)
drivers/media/rc/st_rc.c:153:42:    expected void volatile [noderef] <asn:2>*addr
drivers/media/rc/st_rc.c:153:42:    got void *
drivers/media/rc/st_rc.c:174:32: warning: incorrect type in argument 2 (different address spaces)
drivers/media/rc/st_rc.c:174:32:    expected void volatile [noderef] <asn:2>*addr
drivers/media/rc/st_rc.c:174:32:    got void *
drivers/media/rc/st_rc.c:177:48: warning: incorrect type in argument 2 (different address spaces)
drivers/media/rc/st_rc.c:177:48:    expected void volatile [noderef] <asn:2>*addr
drivers/media/rc/st_rc.c:177:48:    got void *
drivers/media/rc/st_rc.c:187:48: warning: incorrect type in argument 2 (different address spaces)
drivers/media/rc/st_rc.c:187:48:    expected void volatile [noderef] <asn:2>*addr
drivers/media/rc/st_rc.c:187:48:    got void *
drivers/media/rc/st_rc.c:204:42: warning: incorrect type in argument 2 (different address spaces)
drivers/media/rc/st_rc.c:204:42:    expected void volatile [noderef] <asn:2>*addr
drivers/media/rc/st_rc.c:204:42:    got void *
drivers/media/rc/st_rc.c:205:35: warning: incorrect type in argument 2 (different address spaces)
drivers/media/rc/st_rc.c:205:35:    expected void volatile [noderef] <asn:2>*addr
drivers/media/rc/st_rc.c:205:35:    got void *
drivers/media/rc/st_rc.c:215:35: warning: incorrect type in argument 2 (different address spaces)
drivers/media/rc/st_rc.c:215:35:    expected void volatile [noderef] <asn:2>*addr
drivers/media/rc/st_rc.c:215:35:    got void *
drivers/media/rc/st_rc.c:216:35: warning: incorrect type in argument 2 (different address spaces)
drivers/media/rc/st_rc.c:216:35:    expected void volatile [noderef] <asn:2>*addr
drivers/media/rc/st_rc.c:216:35:    got void *
drivers/media/rc/st_rc.c:269:22: warning: incorrect type in assignment (different address spaces)
drivers/media/rc/st_rc.c:269:22:    expected void *base
drivers/media/rc/st_rc.c:269:22:    got void [noderef] <asn:2>*
drivers/media/rc/st_rc.c:349:46: warning: incorrect type in argument 2 (different address spaces)
drivers/media/rc/st_rc.c:349:46:    expected void volatile [noderef] <asn:2>*addr
drivers/media/rc/st_rc.c:349:46:    got void *
drivers/media/rc/st_rc.c:350:46: warning: incorrect type in argument 2 (different address spaces)
drivers/media/rc/st_rc.c:350:46:    expected void volatile [noderef] <asn:2>*addr
drivers/media/rc/st_rc.c:350:46:    got void *
drivers/media/rc/st_rc.c:371:61: warning: incorrect type in argument 2 (different address spaces)
drivers/media/rc/st_rc.c:371:61:    expected void volatile [noderef] <asn:2>*addr
drivers/media/rc/st_rc.c:371:61:    got void *
drivers/media/rc/st_rc.c:372:54: warning: incorrect type in argument 2 (different address spaces)
drivers/media/rc/st_rc.c:372:54:    expected void volatile [noderef] <asn:2>*addr
drivers/media/rc/st_rc.c:372:54:    got void *
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

drivers/media/rc/ir-hix5hd2.c:99:41: warning: incorrect type in argument 2 (different address spaces)
drivers/media/rc/ir-hix5hd2.c:99:41:    expected void volatile [noderef] <asn:2>*addr
drivers/media/rc/ir-hix5hd2.c:99:41:    got void *
drivers/media/rc/ir-hix5hd2.c:100:16: warning: incorrect type in argument 1 (different address spaces)
drivers/media/rc/ir-hix5hd2.c:100:16:    expected void const volatile [noderef] <asn:2>*addr
drivers/media/rc/ir-hix5hd2.c:100:16:    got void *
drivers/media/rc/ir-hix5hd2.c:117:40: warning: incorrect type in argument 2 (different address spaces)
drivers/media/rc/ir-hix5hd2.c:117:40:    expected void volatile [noderef] <asn:2>*addr
drivers/media/rc/ir-hix5hd2.c:117:40:    got void *
drivers/media/rc/ir-hix5hd2.c:119:41: warning: incorrect type in argument 2 (different address spaces)
drivers/media/rc/ir-hix5hd2.c:119:41:    expected void volatile [noderef] <asn:2>*addr
drivers/media/rc/ir-hix5hd2.c:119:41:    got void *
drivers/media/rc/ir-hix5hd2.c:121:41: warning: incorrect type in argument 2 (different address spaces)
drivers/media/rc/ir-hix5hd2.c:121:41:    expected void volatile [noderef] <asn:2>*addr
drivers/media/rc/ir-hix5hd2.c:121:41:    got void *
drivers/media/rc/ir-hix5hd2.c:147:18: warning: incorrect type in argument 1 (different address spaces)
drivers/media/rc/ir-hix5hd2.c:147:18:    expected void const volatile [noderef] <asn:2>*addr
drivers/media/rc/ir-hix5hd2.c:147:18:    got void *
drivers/media/rc/ir-hix5hd2.c:155:28: warning: incorrect type in argument 1 (different address spaces)
drivers/media/rc/ir-hix5hd2.c:155:28:    expected void const volatile [noderef] <asn:2>*addr
drivers/media/rc/ir-hix5hd2.c:155:28:    got void *
drivers/media/rc/ir-hix5hd2.c:157:25: warning: incorrect type in argument 1 (different address spaces)
drivers/media/rc/ir-hix5hd2.c:157:25:    expected void const volatile [noderef] <asn:2>*addr
drivers/media/rc/ir-hix5hd2.c:157:25:    got void *
drivers/media/rc/ir-hix5hd2.c:159:61: warning: incorrect type in argument 2 (different address spaces)
drivers/media/rc/ir-hix5hd2.c:159:61:    expected void volatile [noderef] <asn:2>*addr
drivers/media/rc/ir-hix5hd2.c:159:61:    got void *
drivers/media/rc/ir-hix5hd2.c:167:28: warning: incorrect type in argument 1 (different address spaces)
drivers/media/rc/ir-hix5hd2.c:167:28:    expected void const volatile [noderef] <asn:2>*addr
drivers/media/rc/ir-hix5hd2.c:167:28:    got void *
drivers/media/rc/ir-hix5hd2.c:169:36: warning: incorrect type in argument 1 (different address spaces)
drivers/media/rc/ir-hix5hd2.c:169:36:    expected void const volatile [noderef] <asn:2>*addr
drivers/media/rc/ir-hix5hd2.c:169:36:    got void *
drivers/media/rc/ir-hix5hd2.c:188:64: warning: incorrect type in argument 2 (different address spaces)
drivers/media/rc/ir-hix5hd2.c:188:64:    expected void volatile [noderef] <asn:2>*addr
drivers/media/rc/ir-hix5hd2.c:188:64:    got void *
drivers/media/rc/ir-hix5hd2.c:190:68: warning: incorrect type in argument 2 (different address spaces)
drivers/media/rc/ir-hix5hd2.c:190:68:    expected void volatile [noderef] <asn:2>*addr
drivers/media/rc/ir-hix5hd2.c:190:68:    got void *
drivers/media/rc/ir-hix5hd2.c:220:20: warning: incorrect type in assignment (different address spaces)
drivers/media/rc/ir-hix5hd2.c:220:20:    expected void *base
drivers/media/rc/ir-hix5hd2.c:220:20:    got void [noderef] <asn:2>*
drivers/media/rc/ir-hix5hd2.c:315:41: warning: incorrect type in argument 2 (different address spaces)
drivers/media/rc/ir-hix5hd2.c:315:41:    expected void volatile [noderef] <asn:2>*addr
drivers/media/rc/ir-hix5hd2.c:315:41:    got void *
drivers/media/rc/ir-hix5hd2.c:316:41: warning: incorrect type in argument 2 (different address spaces)
drivers/media/rc/ir-hix5hd2.c:316:41:    expected void volatile [noderef] <asn:2>*addr
drivers/media/rc/ir-hix5hd2.c:316:41:    got void *
drivers/media/rc/ir-hix5hd2.c:317:41: warning: incorrect type in argument 2 (different address spaces)
drivers/media/rc/ir-hix5hd2.c:317:41:    expected void volatile [noderef] <asn:2>*addr
drivers/media/rc/ir-hix5hd2.c:317:41:    got void *
drivers/media/rc/ir-hix5hd2.c:318:41: warning: incorrect type in argument 2 (different address spaces)
drivers/media/rc/ir-hix5hd2.c:318:41:    expected void volatile [noderef] <asn:2>*addr
drivers/media/rc/ir-hix5hd2.c:318:41:    got void *
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

There is no need to init .owner field.

Based on the patch from Peter Griffin <peter.griffin@linaro.org>
"mmc: remove .owner field for drivers using module_platform_driver"

This patch removes the superflous .owner field for drivers which
use the module_platform_driver API, as this is overriden in
platform_driver_register anyway."
Signed-off-by: NSrinivas Kandagatla <srinivas.kandagatla@linaro.org>
Acked-by: NMaxime Coquelin <maxime.coquelin@st.com>
Acked-by: NPeter Griffin <peter.griffin@linaro.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

This patch moves setting of pm_ops out of the CONFIG_PM_SLEEP condition.
Setting pm ops under CONFIG_PM_SLEEP does not make any sense.
This patch also remove unnecessary also remove CONFIG_PM condition for pm
member in st_rc_driver structure.
Signed-off-by: NSrinivas Kandagatla <srinivas.kandagatla@linaro.org>
Acked-by: NMaxime Coquelin <maxime.coquelin@st.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

This patch fixes a compilation error while building with the
random kernel configuration.

drivers/media/rc/st_rc.c: In function 'st_rc_probe':
drivers/media/rc/st_rc.c:281:2: error: implicit declaration of
function 'reset_control_get' [-Werror=implicit-function-declaration]
  rc_dev->rstc = reset_control_get(dev, NULL);

drivers/media/rc/st_rc.c:281:15: warning: assignment makes pointer
from integer without a cast [enabled by default]
  rc_dev->rstc = reset_control_get(dev, NULL);
Reported-by: NJim Davis <jim.epost@gmail.com>
Signed-off-by: NSrinivas Kandagatla <srinivas.kandagatla@linaro.org>
Acked-by: NMaxime Coquelin <maxime.coquelin@st.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

IR transmitter driver for Hisilicon hix5hd2 soc

By default all protocols are disabled.
For example nec decoder can be enabled by either
1. ir-keytable -p nec
2. echo nec > /sys/class/rc/rc0/protocols
See see Documentation/ABI/testing/sysfs-class-rc

[mchehab@osg.samsung.com: Add a fixup for the driver to compile on
 archs that don't provide writel_relaxed() macro]
Signed-off-by: NGuoxiong Yan <yanguoxiong@huawei.com>
Signed-off-by: NZhangfei Gao <zhangfei.gao@linaro.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

This is a RC5 remote controller map for DVBSky S860/960 devices.
Signed-off-by: NNibble Max <nibble.max@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

imon_probe() does three usb_get_dev(), but there is no any
usb_put_dev() in the driver.

The patch adds usb_put_dev() to error paths, to imon_disconnect()
and to imon_probe() as far as usbdev is not saved anywhere.

Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: NAlexey Khoroshilov <khoroshilov@ispras.ru>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

mceusb_init_rc_dev() does usb_get_dev(), but there is no any
usb_put_dev() in the driver.

The patch tries to straighten logic. It moves usb_get_dev()
directly to mceusb_dev_probe() and adds usb_put_dev() to an error path
and to mceusb_dev_disconnect().

Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: NAlexey Khoroshilov <khoroshilov@ispras.ru>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Add support for the si2161-based cx231xx devices:
	[2040:b138] Hauppauge WinTV HVR-900-H (model 111xxx)
	[2040:b139] Hauppauge WinTV HVR-901-H (model 1114xx)

They're similar to the already supported:
	[2040:b130] Hauppauge WinTV 930C-HD (model 1113xx)
Signed-off-by: NMatthias Schwarzott <zzam@gentoo.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

This patch introduces the use of !usb_endpoint_dir_in(epd) and
!usb_endpoint_xfer_int(epd).

The Coccinelle semantic patch that makes these changes is as follows:

- ((epd->bEndpointAddress & \(USB_ENDPOINT_DIR_MASK\|0x80\)) !=
-  \(USB_DIR_IN\|0x80\))
+ !usb_endpoint_dir_in(epd)

@@ struct usb_endpoint_descriptor *epd; @@

- ((epd->bmAttributes & \(USB_ENDPOINT_XFERTYPE_MASK\|3\)) !=
- \(USB_ENDPOINT_XFER_INT\|3\))
+ !usb_endpoint_xfer_int(epd)
Signed-off-by: NHimangi Saraogi <himangi774@gmail.com>
Acked-by: NJulia Lawall <julia.lawall@lip6.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

This patch introduces the use of the function usb_endpoint_type.

The Coccinelle semantic patch that makes these changes is as follows:

@@ struct usb_endpoint_descriptor *epd; @@

- (epd->bmAttributes & \(USB_ENDPOINT_XFERTYPE_MASK\|3\))
+ usb_endpoint_type(epd)
Signed-off-by: NHimangi Saraogi <himangi774@gmail.com>
Acked-by: NJulia Lawall <julia.lawall@lip6.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>