Switch the info about the detected chip type from debug to info level
as it might be useful not only for debugging purposes.
Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Instead of explicitely checking debug use nvt_dbg like in other parts
of the driver thus simplifying the code.
Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Add support for the NCT6779D. It's found e.g. on the Zotac CI321 mini-pc
and I successfully tested it on this device.
Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

nvt_hw_detect always returns 0, therefore make it return void.
Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Make the chip detection code more similar to the one used for the
same chips in watchdog/w83627hf_wdt.c and hwmon/w83627ehf.c.

Apart from better maintainability we gain
- unified naming of chips (e.g. 677C -> NCT6776F)
- driver works with all revisions of the chips
  (least 4 bits of id are masked)
Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Switch to managed resource handling using the devm_ functions.
Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

chip_major / chip_minor are accessed sequentially in probe only.
Therefore no lock is needed.
Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Using IRQ_RETVAL is unneeded here. IRQ_NONE / IRQ_HANDLED can be
returned directly.
Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

This reverts commit da7ee60b.

The current code is not mature enough, the API should allow a single
protocol to be specified. Also, the current code contains heuristics
that will depend on module load order.
Signed-off-by: NDavid Härdeman <david@hardeman.nu>
Acked-by: NAntti Seppälä <a.seppala@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Nuvoton-cir utilizes the encoding capabilities of rc-core to convert
scancodes from user space to pulse/space format understood by the
underlying hardware.

Converted samples are then written to the wakeup fifo along with other
necessary configuration to enable wake up functionality.
Signed-off-by: NAntti Seppälä <a.seppala@gmail.com>
Signed-off-by: NJames Hogan <james@albanarts.com>
Cc: Jarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Removing some boilerplate by using module_pnp_driver instead of calling
register and unregister in the otherwise empty init/exit functions
Signed-off-by: NPeter Huewe <peterhuewe@gmx.de>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Instead of allocating a var to store 0 and just return it,
change the code to return 0 directly.
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Fix various sparse warnings under drivers/media/rc/*.c, mostly
by making functions static.
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>

The allowed and enabled protocol masks need to be expanded to be per
filter type in order to support wakeup filter protocol selection. To
ease that process abstract access to the rc_dev::allowed_protos and
rc_dev::enabled_protocols members with inline functions.
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>

On certain motherboards (mainly Intel NUC series) bios keeps the
Nuvoton CIR device disabled at boot.

This patch adds a call to kernel PNP layer to activate the device if it
is not already activated. This will improve the chances of the PNP probe
actually succeeding on Intel NUC platforms.
Signed-off-by: NAntti Seppälä <a.seppala@gmail.com>
Cc: Jarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

There are reports[1] that on some motherboards loading the nuvoton-cir
disables PS/2 keyboard input. This is caused by an erroneous write of
CIR_INTR_MOUSE_IRQ_BIT to ACPI control register.

According to datasheet the write enables mouse power management event
interrupts which will probably have ill effects if the motherboard has
only one PS/2 port with keyboard in it.

The cir hardware does not need mouse interrupts to function and should
not touch them. This patch removes the illegal writes and registry
definitions.

[1] http://ubuntuforums.org/showthread.php?t=2106277&p=12461912&mode=threaded#post12461912Reported-by: NBruno Maire <bruno.maire@besonet.ch>
Tested-by: NBruno Maire <bruno.maire@besonet.ch>
Signed-off-by: NAntti Seppälä <a.seppala@gmail.com>
Acked-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Since rc_unregister_device() frees its argument, the subsequently
call to rc_free_device() on the same variable will cause a double
free bug. Fix by set argument to NULL, thus when fall through to
rc_free_device(), nothing will be done there.
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

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>

This should fix a potential race condition, when the irq handler
triggers while rc_register_device is still setting up the rdev->raw
device.
This crash has not been observed in practice, but there should be a very
small window where it could occur. Since ir_raw_event_store_with_filter
checks if rdev->raw is not NULL before using it, this bug is not
triggered if the request_irq triggers a pending irq directly (since
rdev->raw will still be NULL then).
This commit was tested on nuvoton-cir only.

Cc: Jarod Wilson <jarod@redhat.com>
Cc: Maxim Levitsky <maximlevitsky@gmail.com>
Cc: David Härdeman <david@hardeman.nu>
Signed-off-by: NMatthijs Kooijman <matthijs@stdin.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This fixes a problem in fintek-cir and nuvoton-cir where the
irq handler would trigger during module load before the rdev member was
set, causing a NULL pointer crash.
It seems this crash is very reproducible (just bombard the receiver with
IR signals during module load), probably because when request_irq is
called, any pending intterupt is handled immediately, before
request_irq returns and rdev can be set.
This same crash was supposed to be fixed by commit
9ef449c6 ("[media] rc: Postpone ISR
registration"), but the crash was still observed on the nuvoton-cir
driver.
This commit was tested on nuvoton-cir only.

Cc: Jarod Wilson <jarod@redhat.com>
Signed-off-by: NMatthijs Kooijman <matthijs@stdin.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Before, labels were simply numbered. Now, the labels are named after the
cleanup action they'll perform (first), based on how the winbond-cir
driver does it. This makes the code a bit more clear and makes changes
in the ordering of labels easier to review.
This change is applied only to the rc drivers that do significant
cleanup in their probe functions: ati-remote, ene-ir, fintek-cir,
gpio-ir-recv, ite-cir, nuvoton-cir.
This commit should not change any code, it just renames goto labels.

[mchehab@redhat.com: removed changes at gpio-ir-recv.c, due to
 merge conflicts]
Signed-off-by: NMatthijs Kooijman <matthijs@stdin.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The carrier detect return value is never used on nuvoton driver:
drivers/media/rc/nuvoton-cir.c: In function 'nvt_process_rx_ir_data':
drivers/media/rc/nuvoton-cir.c:623:6: warning: variable 'carrier' set but not used [-Wunused-but-set-variable]
Also, this would be called only if a boolean variable is enabled,
but there's no condition that enables it inside the driver. So,
comment the carrier detection code, as it might be useful later,
and remove the unused glue code.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

drivers/media/rc/nuvoton-cir.c:1223:5: warning: no previous prototype for 'nvt_init' [-Wmissing-prototypes]
drivers/media/rc/nuvoton-cir.c:1228:6: warning: no previous prototype for 'nvt_exit' [-Wmissing-prototypes]
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>

"carrier" comes from a get_user() in ir_lirc_ioctl().  We need to test
that it's not zero before using it as a divisor.  It might have been
nice to test for this ir_lirc_ioctl() but the mceusb driver uses zero to
disable carrier modulation.
The bug in redrat3 is a little more subtle.  The ->carrier is passed to
mod_freq_to_val() which uses it as a divisor.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

No need to duplicate normal kernel logging capabilities.

Add pr_fmt and convert pr_reg to pr_info.
Remove pr_reg macros.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

fintek-cir, ite-cir and nuvoton-cir may try to free an I/O region
and/or IRQ handler that was never allocated after a failure in their
respective probe functions.  Add and use separate labels on the
failure path so they will do the right cleanup after each possible
point of failure.

Compile-tested only.
Signed-off-by: NBen Hutchings <ben@decadent.org.uk>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

An early registration of an ISR was causing a crash to several users (for
example, with the ite-cir driver: http://bugs.launchpad.net/bugs/972723).
The reason was that IRQs were being triggered before a driver
initialisation was completed.

This patch fixes this by moving the invocation to request_irq() and to
request_region() to a later stage on the driver probe function.

Cc: <stable@vger.kernel.org>
Signed-off-by: NLuis Henriques <luis.henriques@canonical.com>
Acked-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The nuvoton-cir driver was storing up consecutive pulse-pulse and
space-space samples internally, for no good reason, since
ir_raw_event_store_with_filter() already merges back to back like
samples types for us. This should also fix a regression introduced late
in 3.0 that related to a timeout change, which actually becomes correct
when coupled with this change. Tested with RC6 and RC5 on my own
nuvoton-cir hardware atop vanilla 3.0.0, after verifying quirky
behavior in 3.0 due to the timeout change.
Reported-by: NStephan Raue <sraue@openelec.tv>
CC: Stephan Raue <sraue@openelec.tv>
CC: stable@vger.kernel.org
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Durations can never be negative, so it makes sense to consistently use
unsigned int for LIRC transmission. Contrary to the initial impression,
this shouldn't actually change the userspace API.
Signed-off-by: NDavid Härdeman <david@hardeman.nu>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The nuvoton-cir inherited an insanely low idle timeout value from the
mceusb driver. We're fixing mceusb, should fix this driver too.
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

- Set a default timeout (matching mceusb.c) and use
  ir_raw_event_store_with_filter, which leads to better behavior when
  using lirc userspace decoding with this hardware
- Fill in rx_resolution with the value we're using here (50us)
- Wire up input phys and device parent pointer
- Use device_init_wakeup() instead of device_set_wakeup_*()
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Thanks to some excellent investigative work by Douglas Clowes, it was
uncovered that the older w83667hg Nuvoton chip functions with this
driver after actually enabling the CIR function via its multi-function
chip config register. The CIR and CIR wide-band sensor enable bits are
just in a different place on this hardware, so we only poke register
0x27 on 677 hardware now, and we poke register 0x2c on the 667 now.
Reported-by: NDouglas Clowes <dclowes1@optusnet.com.au>
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

There are additional chip IDs that report a PNP ID of NTN0530, which we
were refusing to load on. Instead, lets just warn if we encounter an
unknown chip, as there's a chance it will work just fine.

Also, expand the list of known hardware to include both an earlier and a
later generation chip that this driver should function with. Douglas has
an older w83667hg variant, that with a touch more work, will be
supported by this driver, and Lutz has a newer w83677hg variant that
works without any further modifications to the driver.
Reported-by: NDouglas Clowes <dclowes1@optusnet.com.au>
Reported-by: NLutz Sammer <johns98@gmx.net>
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The CIR Wake FIFO is 67 bytes long, but the stock remote appears to only
populate 65 of them. Limit comparison to 65 bytes, and wake from suspend
works a whole lot better (it wasn't working at all for most folks).

Fix based on comparison with the old lirc_wb677 driver from Nuvoton,
debugging and testing done by Dave Treacy by way of the lirc mailing
list.
Reported-by: NDave Treacy <davetreacy@gmail.com>
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Due to my own stupidity, some of the wrong time unit conversion macros
were being used inside some of the IR drivers I've been working on. Fix
that, and convert over some additional places to also use the macros.
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Make sure we have a matching chip id high and one or the other
of the chip id low values.
Print the values if the probe fails.
Signed-off-by: NNicolas Kaiser <nikai@nikai.net>
Acked-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

for i in `find drivers/staging -type f -name *.[ch]` `find include/media -type f -name *.[ch]` `find drivers/media -type f -name *.[ch]`; do sed s,IR_TYPE,RC_TYPE,g <$i >a && mv a $i; done
for i in `find drivers/staging -type f -name *.[ch]` `find include/media -type f -name *.[ch]` `find drivers/media -type f -name *.[ch]`; do sed s,ir_type,rc_type,g <$i >a && mv a $i; done
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>