- 12 3月, 2014 1 次提交
-
-
由 James Hogan 提交于
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>
-
- 04 1月, 2013 1 次提交
-
-
由 Greg Kroah-Hartman 提交于
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>
-
- 22 12月, 2012 2 次提交
-
-
由 Matthijs Kooijman 提交于
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>
-
由 Matthijs Kooijman 提交于
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>
-
- 28 10月, 2012 1 次提交
-
-
由 Mauro Carvalho Chehab 提交于
Cc: Linux Media Mailing List <linux-media@vger.kernel.org> drivers/media/rc/fintek-cir.c:687:5: warning: no previous prototype for 'fintek_init' [-Wmissing-prototypes] drivers/media/rc/fintek-cir.c:692:6: warning: no previous prototype for 'fintek_exit' [-Wmissing-prototypes] Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 27 10月, 2012 1 次提交
-
-
由 David Härdeman 提交于
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>
-
- 14 8月, 2012 1 次提交
-
-
由 Sean Young 提交于
The TechnoTrend USB IR Receiver sends 125 ISO URBs per second, even when there is no IR activity. Reduce the number of wake ups from the other drivers too. This saves about 0.25ms/s on a 2.4GHz Core 2 according to powertop. Signed-off-by: NSean Young <sean@mess.org> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 07 7月, 2012 1 次提交
-
-
由 Joe Perches 提交于
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>
-
- 20 5月, 2012 1 次提交
-
-
由 Ben Hutchings 提交于
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>
-
- 27 4月, 2012 2 次提交
-
-
由 Dan Carpenter 提交于
The current condition is always true, so everything uses LOGICAL_DEV_CIR_REV2 (8). It should be that Fintek products 0x0408(F71809) and 0x0804(F71855) use logical device LOGICAL_DEV_CIR_REV1 (5) and other chip ids use logical device 8. In other words, this fixes hardware detection for 0x0408 and 0x0804. Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Acked-by: NJarod Wilson <jarod@redhat.com> Cc: stable@kernel.org Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Luis Henriques 提交于
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>
-
- 15 2月, 2012 1 次提交
-
-
由 Mauro Carvalho Chehab 提交于
Acked-by: NJarod Wilson <jarod@redhat.com> Reviewed-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 11 6月, 2011 1 次提交
-
-
由 Jarod Wilson 提交于
There was a missing lock in fintek_suspend. Without the lock, its possible the system will be in the middle of receiving IR (draining the RX buffer) when we try to disable CIR interrupts. Signed-off-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 26 5月, 2011 1 次提交
-
-
由 Jarod Wilson 提交于
This is a new driver for the Fintek LPC SuperIO CIR function, in the Fintek F71809 chip. Hardware and datasheets were provided by Fintek, so thanks go to them for supporting this effort. This driver started out as a copy of the nuvoton-cir driver, and was then modified as needed for the Fintek chip. The two share many similaries, though the buffer handling for the Fintek chip is actually nearly identical to the mceusb buffer handling, so the parser routine is almost a drop-in copy of the mceusb buffer parser (a candidate for being abstracted out into shared code at some point). This initial code drop *only* supports receive, but the hardware does support transmit as well. I really haven't even started to look at what's required, but my guess is that its also pretty similar to mceusb. Most people are probably only really interested in RX anyway though, so I think its good to get this out there even with only RX. (Nb: there are also Fintek-made mceusb receivers, which presumably, this chip shares CIR hardware with). This hardware can be found on at least Jetway NC98 boards and derivative systems, and likely others as well. Functionality was tested with an NC98 development board, in-kernel decode of RC6 (mce), RC5 (hauppauge) and NEC-ish (tivo) remotes all successful, as was lirc userspace decode of the RC6 remote. CC: Aaron Huang <aaron_huang@fintek.com.tw> CC: Tom Tsai <tom_tsai@fintek.com.tw> Signed-off-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-