CONFIG_FB_OMAP2_FORCE_AUTO_UPDATE doesn't exist in Kconfig and is never defined anywhere
else, therefore removing all references for it from the source code.
Signed-off-by: Christian Dietrich <qy03fugy@stud.informatik.uni-erlangen.de>
Acked-by: Vaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch fixes possible race conditions in queue management with SMP:
when a frame was completed, the irq function tried to use the next frame
buffer. At this time, it was possible that the application on an other
processor updated the frame pointer, making the image to point to a bad
buffer.
The patch contains two main changes:
- the image transfer uses the queue indexes which are protected against
simultaneous memory access,
- the image pointer which is used for image concatenation is only set at
interrupt level.
Some subdrivers which used the image pointer have been updated.
Reported-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The problem may occur with SMP:
- a frame is completed at interrupt level (in gspca_frame_add with
packet_type == LAST_PACKET,
- just after clearing the bit V4L2_BUF_FLAG_QUEUED and before setting
the bit V4L2_BUF_FLAG_DONE, on the other processor, the application
tries to requeue the same frame buffer,
- then, the qbuf function succeeds because ALL_FLAGS are not set.
The fix sets and resets the two flags in one instruction.
Reported-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
As pointed by Christoph Egger <siccegge@stud.informatik.uni-erlangen.de>,
The config Option DVB_DIBCOM_DEBUG was dropped while removing the dibusb
driver in favor of dvb-usb in 2005. However it remaind existant at some
places of the kernel config.
Instead of just removing the debug capability, the better is to just remove
the bad dependency, making the modprobe function always visible.
Thanks-to: Christoph Egger <siccegge@stud.informatik.uni-erlangen.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The recently added support for lgs8g75 included some 8051 machine code
without accompanying source code. Replace this with use of the
firmware loader.
Compile-tested only.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch to the si470x_vidioc_s_tuner function was developed in
cooperation with Roel Kluin <roel.kluin@gmail.com>. It sets the default
retval to 0 instead of -EINVAL, identical to what is done in all other
set/get functions of v4l2_ioctl_ops. This is just as cosmetic change, as
retval is directly overwritten by the si470x_disconnect_check() anyway.
Signed-off-by: Tobias Lorenz <tobias.lorenz@gmx.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Spent a while last night getting device initialization packet captures
under Windows for all generations of devices. There are a few places
where we were doing things differently, and few things we were doing
that we don't need to do, particularly on gen3 hardware, and I *think*
one of those things is what was locking up my pinnacle hw from time to
time -- at least, its been perfectly well behaved every time its been
plugged in since making this change.
First up, we're adding a bit more to the gen1 init routine here. Its
not absolutely necessary, the hardware works the same both with and
without it, but I'd like to be consistent w/Windows here.
Second, DEVICE_RESET is never called when initializing either of my
gen3 devices, its only called for gen1 and gen2. The bits in the gen3
init after removing that, are safe (and interesting) to run on all
hardware, so there's no more gen3-specific init done, there's instead
a generic mceusb_get_parameters() that is run for all hardware.
Third, the gen3 flag isn't needed. We only care if hardware is gen3
during probe, so I've dropped that from the device flags struct.
Successfully tested on all three generations of mceusb hardware.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Prior init unification/simplification patch made these unused, forgot
to remove them, so this silences:
drivers/media/IR/mceusb.c: In function ‘mceusb_gen1_init’:
drivers/media/IR/mceusb.c:769: warning: unused variable ‘partial’
drivers/media/IR/mceusb.c:768: warning: unused variable ‘i’
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
New code should not rely on the big kernel lock,
so use the unlocked_ioctl file operation in lirc.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Tested-by: Jarod Wilson <jarod@redhat.com>
Acked-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
ir-jvc-decoder uses bitreverse interfaces, so it should select
BITREVERSE.
ir-jvc-decoder.c:(.text+0x550bc): undefined reference to `byte_rev_table'
ir-jvc-decoder.c:(.text+0x550c6): undefined reference to `byte_rev_table'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
On Wed, Jul 07, 2010 at 02:52:58PM +0200, Jiri Slaby wrote:
> Hi,
>
> stanse found a locking error in lirc_dev_fop_read:
> if (mutex_lock_interruptible(&ir->irctl_lock))
> return -ERESTARTSYS;
> ...
> while (written < length && ret == 0) {
> if (mutex_lock_interruptible(&ir->irctl_lock)) { #1
> ret = -ERESTARTSYS;
> break;
> }
> ...
> }
>
> remove_wait_queue(&ir->buf->wait_poll, &wait);
> set_current_state(TASK_RUNNING);
> mutex_unlock(&ir->irctl_lock); #2
>
> If lock at #1 fails, it beaks out of the loop, with the lock unlocked,
> but there is another "unlock" at #2.
This should do the trick. Completely untested beyond compiling, but its
not exactly a complicated fix, and in practice, I'm not aware of anyone
ever actually tripping that locking bug, so there's zero functional change
in typical use here.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Since commit b402843787
the 'driver_data' field resides in device's struct device_private
which may be allocated by dev_set_drvdata() if device_private
struct was not allocated previously.
dev_set_drvdata() is used in video_set_drvdata() to set
the driver's private data pointer in v4l2 drivers. Setting
the private data _before_ registering the v4l2 device results
in a memory leak since __video_register_device() also calls
video_set_drvdata(), but after zeroing the device structure.
Thus, the reference to the previously allocated device_private
struct goes lost and a new device_private will be allocated.
All v4l drivers which call video_set_drvdata() _before_
calling video_register_device() are affected. The patch fixes
__video_register_device() to preserve previously allocated
device_private reference.
Caught by kmemleak.
Signed-off-by: Anatolij Gustschin <agust@denx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Use the register CLUNC to reset the CPTU registers (LSB & MSB) when they
saturate at 0xFFFF. Fixes as well a few register typos.
Signed-off-by: Guillaume Audirac <guillaume.audirac@webag.fr>
Signed-off-by: Steven Toth <stoth@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Add a missing bit for reading the transmission mode (2K/8K) in
tda10048_get_tps
Signed-off-by: Guillaume Audirac <guillaume.audirac@webag.fr>
Signed-off-by: Steven Toth <stoth@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Completes the bit-error-rate read function with the CBER register (before
Viterbi decoder). The returned value is 1e8*actual_ber to be positive.
Also includes some typo mistakes.
Signed-off-by: Guillaume Audirac <guillaume.audirac@webag.fr>
Signed-off-by: Steven Toth <stoth@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Started out as an effort to try to tackle the last remaining issue I'm
having with this damned pinnacle device getting wedged the first time
its plugged in after an indeterminate length of not being plugged in.
Didn't get that solved yet, but did streamline the init code a bit more
and remove some superfluous gunk. Nukes a completely unneeded call to
usb_device_init() and several lines of overly complex crap in the gen1
device init path.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Adds support for Video-In (VIU) unit of Freescale
MPC5121e. The driver supports RGB888/RGB565 formats,
capture and overlay on MPC5121e DIU frame buffer.
Signed-off-by: Hongjun Chen <hong-jun.chen@freescale.com>
Signed-off-by: Anatolij Gustschin <agust@denx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The camera requires the PROBE_MINMAX quirk. Add a corresponding entry
in the device IDs list
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Data buffers on the stack are not allowed for USB I/O. Use dynamically
allocated buffers instead when querying control length and control
capabilities.
The control capabilities are now also stored in the uvc_control
structure.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Use the macros instead of hardcoding numerical constants for the
controls information bitfield.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The UVCIOC_CTRL_MAP ioctl doesn't support menu entries for menu
controls. As the uvc_xu_control_mapping structure has no reserved
fields, this can't be fixed while keeping ABI compatibility.
Modify the UVCIOC_CTRL_MAP ioctl to add menu entries support, and define
UVCIOC_CTRL_MAP_OLD that supports the old ABI without any ability to add
menu controls.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
According to the v4l2 spec, writing any value to a button control should
result in the action belonging to the button control being triggered.
UVC cams however want to see a 1 written, this patch fixes this by
overriding whatever value user space passed in with -1 (0xffffffff) when
the control is a button control.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Per Pieter Hoekstra:
I have a Antec Fusion with a iMON Lcd and I get the following error:
imon 6-1:1.0: Unknown 0xffdc device, defaulting to VFD and iMON IR (id
0x9e)
The driver is functional if I load it like this: (I do not use a remote for it)
modprobe imon display_type=1 (On Mythbuntu 10.04/2.6.32)
This device is a lcd-type with support for a MCE remote. Looking at
the source code, this device (0x9e) is the same as id 0x9f.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
It might be useful to be able to disable the IR support, either for
debugging purposes, or just for users who know they won't use the IR
remote control anyway. On many cards, IR support requires expensive
polling/sampling which is better avoided if never needed.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Move I2C IR initialization from just after I2C bus setup to right
before non-I2C IR initialization. This is the same as was done for
the bttv driver several months ago. Might solve bugs which have not yet
been reported for some cards. It makes both drivers consistent, and
makes it easier to disable IR support (coming soon.)
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
drivers/media/common/tuners/xc5000.c: In function ‘xc_write_reg’:
drivers/media/common/tuners/xc5000.c:298: warning: passing argument 3 of ‘xc5000_readreg’ from incompatible pointer type
drivers/media/common/tuners/xc5000.c:235: note: expected ‘u16 *’ but argument is of type ‘u8 *’
drivers/media/common/tuners/xc5000.c: At top level:
drivers/media/common/tuners/xc5000.c:223: warning: ‘xc_read_i2c_data’ defined but not used
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Convert the cx23885 driver to use the new in kernel IR pulse
decoders for the integrated CX2388[578] IR controllers. Rip out a lot
of RC-5 decoding related code in the process and rename some variables
for clarity or to more accurately describe their usage.
Signed-off-by: Andy Walls <awalls@md.metrocast.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Move from the generic, shared card_ir state structure to a cx23885 driver
specific IR state structure in anticipation of moving to the new IR pulse
decoders in the IR core.
Fix up the card name truncation in the dmesg log while we're at it,
by avoiding using fixed length string storage in our new IR state
structure.
Signed-off-by: Andy Walls <awalls@md.metrocast.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The image pointer and its length are now in the main structure instead
of in the frame buffer. They are updated on application vidioc_qbuf and
in the URB interrupt function when ending an image.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The Kconfig variables are moved to video/davinci/Kconfig through another
patch and these are to be therefore removed
Signed-off-by: Muralidharan Karicheri <mkaricheri@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Currently VPFE Capture driver and DM6446 CCDC driver is being
reused for AM3517. So this patch is preparing the Kconfig/makefile
for re-use of such IP's.
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: Muralidharan Karicheri <mkaricheri@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Resend due to a whitespace issue I created by mistake.
The below patch fixes a warning message create by gcc 4.6.0
CC [M] drivers/media/common/tuners/tuner-simple.o
drivers/media/common/tuners/tuner-simple.c: In function 'simple_set_tv_freq':
drivers/media/common/tuners/tuner-simple.c:548:20: warning: variable 'tun' set but not used
Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The read_status field is initialized twice to the same value.
The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@r@
identifier I, s, fld;
position p0,p;
expression E;
@@
struct I s =@p0 { ... .fld@p = E, ...};
@s@
identifier I, s, r.fld;
position r.p0,p;
expression E;
@@
struct I s =@p0 { ... .fld@p = E, ...};
@script:python@
p0 << r.p0;
fld << r.fld;
ps << s.p;
pr << r.p;
@@
if int(ps[0].line)<int(pr[0].line) or int(ps[0].column)<int(pr[0].column):
cocci.print_main(fld,p0)
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Rework xc_write_reg function for correct read register of the xc5000.
It is very useful for tm6000.
Tested for tm6000 and for saa7134 works well.
Signed-off-by: Beholder Intl. Ltd. Dmitry Belimov <d.belimov@gmail.com>
Acked-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
copy_to_user() returns the number of bytes remaining to be copied which
isn't the right thing to return here. The comments say that these
functions in dvb_ca_en50221.c should return the number of bytes copied or
an error return. I've changed it to return -EFAULT.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
copy_to/from_user() returns the number of bytes remaining to be copied
but the code here was testing for negative returns. I modified it to
return -EFAULT. These functions are called from si4713_s_ext_ctrls() and
that only tests for negative error codes.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Update the Kconfig selections to match the code.
Add the usual condition of !DVB_FE_CUSTOMISE.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
In the hdpvr_probe () function, when an error occurs while probing the device,
the workqueue created by the create_single_thread () call is not properly
destroyed.
Signed-off-by: Perceval Anichini <perceval@trilogic.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
s2255drv: cleanup of device structure
cleanup of device structure.
single channel array instead of multiple arrays in device for
each channel property.
simplifies open callback by removing search for channel index.
Signed-off-by: Dean Anderson <linux-dev@sensoray.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This is just a cleanup patch. We never use the "udev" variable so I
have removed it.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Smatch complained because "d" is dereferenced first and then checked for
null later . The only code path where "d" could be a invalid pointer is
if this is a cold device in dvb_usb_device_init(). I consulted Antti
Palosaari and he explained that anysee is always a warm device.
I have added a comment and removed the unneeded null check.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
On 05/29/10 01:30, Jean-Francois Moine wrote:
> On Fri, 28 May 2010 13:03:28 -0400
> Amerigo Wang<amwang@redhat.com> wrote:
>
>> Subject: [PATCH 6/6] Remove obsolete zc0301 v4l driver
>>
>> Duplicate functionality with the gspca_zc3xx driver, zc0301 only
>> supports 2 USB-ID's (because it only supports a limited set of
>> sensors) wich are also supported by the gspca_zc3xx driver
>> (which supports 53 USB-ID's in total).
>
> You forgot to remove the conditionnal compilation in the gspca_zc3xx
> driver (USB_DEVICE(0x046d, 0x08ae) in gspca/zc3xx.c)
>
Right, thanks for pointing this out!
Attached is the updated patch, please use this one instead.
Thanks!
Duplicate functionality with the gspca_zc3xx driver, zc0301 only
supports 2 USB-ID's (because it only supports a limited set of
sensors) wich are also supported by the gspca_zc3xx driver
(which supports 53 USB-ID's in total).
Signed-off-by: Amerigo Wang <amwang@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The videobuf_dmabuf and videobuf_vmalloc_memory fields have a vmalloc
field to store the kernel virtual address of vmalloc'ed buffers. Rename
the field to vaddr.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The fields are assigned but never used, remove them.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Those functions are only called inside videobuf-dma-sg.c, make them
static.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The cx88 and cx25821 drivers abuse videobuf_buffer to handle audio data.
Remove the abuse by creating private audio buffer structures with a
videobuf_dmabuf field.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of creating dirty wrappers around videobuf_dma_map/unmap that
create a dummy videobuf_queue structure, modify videobuf_dma_map/unmap
to take a device pointer argument and use it directly. The
videobuf_sg_dma_map/unmap then become unused and can be removed.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This function is not specific to mmap, hence the rename.
Add a check whether we are not streaming or reading (for read mode that
uses the stream queue) before freeing anything.
Signed-off-by: Pawel Osciak <p.osciak@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
These functions allocate videobuf_buffer structures only. Renaming in order
to prevent confusion with functions allocating actual video buffer memory.
Rename the functions in videobuf-core.h videobuf-dma-sg.c as well.
Signed-off-by: Pawel Osciak <p.osciak@samsung.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Use memdup_user when user data is immediately copied into the
allocated region.
The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@@
expression from,to,size,flag;
position p;
identifier l1,l2;
@@
- to = \(kmalloc@p\|kzalloc@p\)(size,flag);
+ to = memdup_user(from,size);
if (
- to==NULL
+ IS_ERR(to)
|| ...) {
<+... when != goto l1;
- -ENOMEM
+ PTR_ERR(to)
...+>
}
- if (copy_from_user(to, from, size) != 0) {
- <+... when != goto l2;
- -EFAULT
- ...+>
- }
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
v2: copy of buffer data from userspace done inside this plugin/driver,
keeping the actual drivers minimal, and more flexible in what we can
deliver to them later on (they may be fed from within kernelspace later
on, by an in-kernel IR encoder).
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
v2: currently unused ioctls are included, but #if 0'd out
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Use kmemdup when some other buffer is immediately copied into the
allocated region.
A simplified version of the semantic patch that makes this change is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@@
expression from,to,size,flag;
statement S;
@@
- to = \(kmalloc\|kzalloc\)(size,flag);
+ to = kmemdup(from,size,flag);
if (to==NULL || ...) S
- memcpy(to, from, size);
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
Signed-off-by: Douglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
I started fixing one or two lines, but after a while I got into a groove
and started changing everything. I left the lines longer than 80
characters because that seemed to be the style in this file.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Douglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Use kmemdup when some other buffer is immediately copied into the
allocated region.
A simplified version of the semantic patch that makes this change is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@@
expression from,to,size,flag;
statement S;
@@
- to = \(kmalloc\|kzalloc\)(size,flag);
+ to = kmemdup(from,size,flag);
if (to==NULL || ...) S
- memcpy(to, from, size);
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
Signed-off-by: Douglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Some (North American) providers use a non-standard mode called
"8psk turbo fec". Since there is no flag in the driver that
would allow an application to determine whether a particular
device can handle "turbo fec", the attached patch introduces
FE_CAN_TURBO_FEC.
Since there is no flag in the SI data that would indicate
that a transponder uses "turbo fec", VDR will assume that
all 8psk transponders on DVB-S use "turbo fec".
Tested-by: Derek Kelly <user.vdr@gmail.com>
Signed-off-by: Klaus Schmidinger <Klaus.Schmidinger@tvdr.de>
Signed-off-by: Douglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Use kmemdup when some other buffer is immediately copied into the
allocated region.
A simplified version of the semantic patch that makes this change is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@@
expression from,to,size,flag;
statement S;
@@
- to = \(kmalloc\|kzalloc\)(size,flag);
+ to = kmemdup(from,size,flag);
if (to==NULL || ...) S
- memcpy(to, from, size);
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
Signed-off-by: Douglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Use kmemdup when some other buffer is immediately copied into the
allocated region.
A simplified version of the semantic patch that makes this change is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@@
expression from,to,size,flag;
statement S;
@@
- to = \(kmalloc\|kzalloc\)(size,flag);
+ to = kmemdup(from,size,flag);
if (to==NULL || ...) S
- memcpy(to, from, size);
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
Signed-off-by: Douglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Propagte correct error values instead of returning -1 which just means
-EPERM ("Permission denied")
Signed-off-by: Daniel Mack <daniel@caiaq.de>
Signed-off-by: Douglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Add a mutex_unlock missing on the error path. In the other functions in
the same file the locks and unlocks of this mutex appear to be balanced,
so it would seem that the same should hold in this case.
The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@@
expression E1;
@@
* mutex_lock(E1,...);
<+... when != E1
if (...) {
... when != E1
* return ...;
}
...+>
* mutex_unlock(E1,...);
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
Signed-off-by: Douglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
My previous patch to depend on FONTS was not sufficient since
FONTS is boolean. VIDEO_VIVI needs to depend on a tristate so that
it won't be enabled as =y when framebuffer is built as modular, so
modify it to depend on the same symbols that FONTS depends on, which
are FRAMEBUFFER_CONSOLE || STI_CONSOLE.
Fixes this build error when VIDEO_VIVI=y and FRAMEBUFFER_CONSOLE=m:
vivi.c:(.init.text+0x7205): undefined reference to `find_font'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Douglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
mchehab: merged with IR/mceusb: userspace buffer copy moved out of driver
Userspace buffer copy moved out of driver and into lirc bridge driver
[mchehab@redhat.com: merged the patch to avoid compilation errors with allyesconfig ]
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
I have pinnacle hardware now. None of this pinnacle-specific crap is at
all necessary (in fact, some of it needed to be removed to actually make
it work). The only thing unique about this device is that it often
transfers inbound data w/a header of 0x90, meaning 16 bytes of IR data
following it, so I had to make adjustments for that, and now its working
perfectly fine.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The first-gen mceusb device init code, while mostly functional, had a few
issues in it. This patch does the following:
1) removes use of magic numbers
2) eliminates mapping of memory from stack
3) makes debug spew translator functional
Additionally, this clean-up revealed that we cannot read the proper default
tx blaster bitmask from the device, we do actually have to initialize it
ourselves, which requires use of a somewhat gross list-based mask inversion
check.
This patch also removes the entirely unnecessary use of struct ir_input_state.
Also supersedes two earlier patches that also touched on first-gen
cleanup, but were partially botched. This one actually compiles, works,
etc., I swear. ;)
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Was using input_unregister_device directly, instead of using
ir_input_unregister, which tears down a bunch of other things in
addition to eventually calling input_unregister_device.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Was using input_unregister_device directly, instead of using
ir_input_unregister, which tears down a bunch of other things in
addition to eventually calling input_unregister_device.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Fix ir-nec-decoder build: it uses bitrev library code, so
select BITREVERSE in its Kconfig.
ir-nec-decoder.c:(.text+0x1a2517): undefined reference to `byte_rev_table'
ir-nec-decoder.c:(.text+0x1a2526): undefined reference to `byte_rev_table'
ir-nec-decoder.c:(.text+0x1a2530): undefined reference to `byte_rev_table'
ir-nec-decoder.c:(.text+0x1a2539): undefined reference to `byte_rev_table'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch moves the state from each raw decoder into the
ir_raw_event_ctrl struct.
This allows the removal of code like this:
spin_lock(&decoder_lock);
list_for_each_entry(data, &decoder_list, list) {
if (data->ir_dev == ir_dev)
break;
}
spin_unlock(&decoder_lock);
return data;
which is currently run for each decoder on each event in order
to get the client-specific decoding state data.
In addition, ir decoding modules and ir driver module load
order is now independent. Centralizing the data also allows
for a nice code reduction of about 30% per raw decoder as
client lists and client registration callbacks are no longer
necessary (but still kept around for the benefit of the lirc
decoder).
Out-of-tree modules can still use a similar trick to what
the raw decoders did before this patch until they are merged.
Signed-off-by: David Härdeman <david@hardeman.nu>
Acked-by: Jarod Wilson <jarod@redhat.com>
Tested-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
With this change, it is now possible to do something like:
su -c 'echo "none +rc-5 +nec" > /sys/class/rc/rc1/protocols'
This prevents the need of multiple opens, one for each protocol change,
and makes userspace application easier.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Writing "none" to /dev/class/rc/rc*/protocols will disable all protocols.
This allows an easier setup, from userspace, as userspace applications don't
need to disable protocol per protocol, before enabling a different set of
protocols.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
While rc-5 and rc-6 protocols are generally abreviated as "rc5" and "rc6",
previous sysfs nodes uses rc-5 and rc-6 for the Philips protocols. This is
consistent with the protocol nomenclature given by the original Philips
spec: "Remote control system RC-5" (doc. Nr. 9398 706 23011).
Also, rc5 is the name of a widely known cryptography protocol.
So, the better is to keep referring to those protocols as "rc-5" and "rc-6".
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using "magic" sizes for protocol names, replace them by an
array, and use strlen().
No functional changes.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
With the current logic, each raw decoder needs to add a copy of the exact
same sysfs code. This is both unnecessary and also means that (re)loading
an IR driver after raw decoder modules have been loaded won't work as
expected.
This patch moves that logic into ir-raw-event and adds a single sysfs
file per device.
Reading that file returns something like:
"rc5 [rc6] nec jvc [sony]"
(with enabled protocols in [] brackets)
Writing either "+protocol" or "-protocol" to that file will
enable or disable the according protocol decoder.
An additional benefit is that the disabling of a decoder will be
remembered across module removal/insertion so a previously
disabled decoder won't suddenly be activated again. The default
setting is to enable all decoders.
This is also necessary for the next patch which moves even more decoder
state into the central raw decoding structs.
Signed-off-by: David Härdeman <david@hardeman.nu>
Acked-by: Jarod Wilson <jarod@redhat.com>
Tested-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Partially convert drivers/media/video/ir-kbd-i2c.c to
not use ir-functions.c
Signed-off-by: David Härdeman <david@hardeman.nu>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Partially convert drivers/media/video/cx88/cx88-input.c to not use
ir-functions.c
Signed-off-by: David Härdeman <david@hardeman.nu>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of generating one printk for every IR read, prints it only when
count is different from the last count.
While here, as this code is called on every 100ms during the runtime
lifetime, do some performance optimization, assuming that, under normal
circumstances, it is unlikely that the driver would get a new key/key
repeat on every poll.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Convert drivers/media/video/em28xx/em28xx-input.c to not use ir-functions.c
Signed-off-by: David Härdeman <david@hardeman.nu>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Convert drivers/media/dvb/mantis/mantis_input.c to not use ir-functions.c
Signed-off-by: David Härdeman <david@hardeman.nu>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Add Genius iSlim 310 webcam to the supported list of the PAC7302 driver.
For more information see http://linuxtv.org/wiki/index.php/PixArt_PAC7301/PAC7302 .
Signed-off-by: Márton Németh <nm127@freemail.hu>
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
- Extra spaces to align some variable names and a defined value
Signed-off-by: Olivier Lorin <o.lorin@laposte.net>
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
- Change of rounded image resolutions to the real ones for MI2020 sensor
in order to discard 2 random lines in the bottom of images
Signed-off-by: Olivier Lorin <o.lorin@laposte.net>
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
- Setting changes applied after an end of image marker reception
This is the way MI2020 sensor works.
It seems to be logical to wait for a complete image before
to change a setting.
Signed-off-by: Olivier Lorin <o.lorin@laposte.net>
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
- 1 ms "msleep" applied to each sensor after USB control data exchange
This was done for two sensors because these exchanges were known to
be too quick depending on laptop model.
It is fairly logical to apply this delay to each sensor
in order to prevent from having errors with untested hardwares.
Signed-off-by: Olivier Lorin <o.lorin@laposte.net>
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
- new MI2020 driver version made from a webcam gift
- all previous flavors of this driver removed
Signed-off-by: Olivier Lorin <o.lorin@laposte.net>
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch address an arithmetic error for the case where the only remaining
content in the USB packet was the "225Axxxx" start of active video. In cases
where that happened to be at the end of the frame, we would inject it into the
videobuf (which is incorrect). This caused fields to be intermittently
rendered off by two pixels.
Thanks to Eugeniy Meshcheryakov for bringing this issue to my attention
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Add NTSC closed captioning support for au0828 based products. Note that this
also required reworking the locking to support streaming on both the video and
VBI devices (the logic for which I copied from my changes made to the em28xx
several months ago).
This work was sponsored by GetWellNetwork Inc.
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Fix error detection of failures during initialization of first instance:
Dont pass a function into the tda_fail macro. Instead, save the function
return value and pass that into the tda_fail macro.
This prevents the function from being called twice in cases of failure,
for example:
[19026.074070] tuner 4-0060: chip found @ 0xc0 (device #0)
[19026.087755] tda18271 4-0060: creating new instance
[19026.089965] Unknown device detected @ 4-0060, device not supported.
[19026.092233] Unknown device detected @ 4-0060, device not supported.
[19026.092241] tda18271_attach: [4-0060|M] error -22 on line 1275
[19026.092327] tda18271 4-0060: destroying instance
Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
If the firmware has failed, this patch will automatically reload &
restart the card. The previous card state will be restored on a
successful restart. Firmware reload will only happen if neither the
encoder or decoder is active. If the card is busy then behaviour is as
before, returning -EIO on device access until the reload can occur. On
cards that support video output, coloured bars will be displayed during
the reload.
Andy Walls (ivtv maintainer and patch committer) made minor tweaks to
comments and the logged messages, but nothing substantial otherwise.
Signed-off-by: Ian Armstrong <ian@iarmst.demon.co.uk>
Signed-off-by: Andy Walls <awalls@md.metrocast.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
>From Ian's e-mail:
When a device is opened the firmware state will be checked. If it isn't
responding then the open will fail with -EIO. Due to the nature of the
hardware, a single failed check will block everything since we don't know
exactly what has failed. A side effect of this is the blocking of debug
access, so an additional debug level has been created which allows the block
to be bypassed.
Andy Walls' modifications:
I modified Ian's patch to add a separate fw_debug module parameter to change
the driver's behavior, as opposed to using the normal debug module parameter.
The fw_debug module parameter is only available when CONFIG_VIDEO_ADV_DEBUG
is set.
I also made some minor whitespace adjustments and changed some warning
messages to be a bit more specific. s/happy/glad/g
Signed-off-by: Ian Armstrong <ian@iarmst.demon.co.uk>
Signed-off-by: Andy Walls <awalls@md.metrocast.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The signal bit is unreliable on the DT3304 in QAM mode, so
set FE_HAS_SIGNAL based on 'cr_lock'
Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
There's a currently-unused lgdt3304 demod driver, which leaves a lot to
be desired as far as functionality. The 3304 is unsurprisingly quite
similar to the 3305, and empirical testing yeilds far better results
and more complete functionality by merging 3304 support into the 3305
driver. (For example, the current lgdt3304 driver lacks support for
signal strength, snr, ucblocks, etc., which we get w/the lgdt3305).
For the moment, not dropping the lgdt3304 driver, and its still up to
a given device's config setup to choose which demod driver to use, but
I'd suggest dropping the 3304 driver entirely.
As a follow-up to this patch, I've got another patch that adds support
for the KWorld PlusTV 340U (ATSC) em2870-based tuner stick, driving
its lgdt3304 demod via this lgdt3305 driver, which is what I used to
successfully test this patch with both VSB_8 and QAM_256 signals.
A few pieces are still a touch crude, but I think its a solid start,
as well as much cleaner and more feature-complete than the existing
lgdt3304 driver.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This function is used when the USB video interface is checked by
the subdriver.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
- variable / function rename
- set the gains in one exchange
- don't alter the register 80 which contains the AWB flag
and other sensor specific values
- the global gain is now the average of the R, G and B gains.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch also renames the last polling message from the closer one
of the ms-windows driver.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The new table is sorted and extracted from a clear part of the MS-Windows
driver.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch also changes a bit the contrast control.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
These registers seem to act on the JPEG compression whose control
is not implemented in the current driver.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The JPEG header is now included in the subdriver structure instead
of being allocated and freed at capture start and stop.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
setcolors(0 is a no-op for 7670 sensors, so we should not report a
saturation control for 7670 sensors.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
What we've called brightness so far actually is an exposure control,
rename it and fixup the maximum and default values.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
There is a problem with certain tv8532 cams, where sometimes there
hsync/vsync locks one pixel of where it normally locks. While trying to
fix this (which I failed to do). I noticed there are lots if duplicate
register writes and unnecessary register reads in the tv8532 driver. This
patch cleanes these ups (which has no negative effects, but unfortunately
also does not help).
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
With the ovfx2 bridge sometimes the first few frames in a stream
would be no good, as the bridge and sensor are not in complete hsync /
vsync yet. This can easily be detected by checking the framesize. So if the
framesize is short and it is one of the 1ste 3 frames after an sd_start,
drop it.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This is a new driver for the Windows Media Center Edition/eHome
Infrared Remote transceiver devices. Its a port of the current
lirc_mceusb driver to ir-core, and currently lacks transmit support,
but will grow it back soon enough... This driver also differs from
lirc_mceusb in that it borrows heavily from a simplified IR buffer
decode routine found in Jon Smirl's earlier ir-mceusb port.
This driver has been tested on the original first-generation MCE IR
device with the MS vendor ID, as well as a current-generation device
with a Topseed vendor ID. Every receiver supported by lirc_mceusb
should work equally well. Testing was done primarily with RC6 MCE
remotes, but also briefly with a Hauppauge RC5 remote, and all works
as expected.
v2: fix call to ir_raw_event_handle so repeats work as they should.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This is the RC6 keymap for the Windows Media Center Edition remotes
that come bundled with MCE/eHome Infrared Remote transceivers. Tested
with 3 different variants of the remote, but its possible there are
still some additional keys missing, but its simple enough to add them
in later...
This patch also adds an IR_TYPE_ALL convenience macro to make life
easier for receivers that support all IR protocols.
v2: fix an erroneous comment that referred to imon devices
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Rather than registering all IR protocol decoders as enabled when bringing
up a new device, only enable the IR protocol decoder that matches the
keymap being loaded. Additional decoders can be enabled on the fly by
those that need to, either by twiddling sysfs bits or by using the
ir-keytable util from v4l-utils.
Functional testing done with the mceusb driver, and it behaves as expected,
only the rc6 decoder is enabled, keys are all handled properly, etc.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
On Fri, May 28, 2010 at 3:59 PM, Jarod Wilson <jarod@redhat.com> wrote:
> The mceusb driver I'm about to submit handles just about any raw IR you
> can throw at it. The ir-core loads up all protocol decoders, starting
> with NEC, then RC5, then RC6. RUN_DECODER() was trying them in the same
> order, and exiting if any of the decoders didn't like the data. The
> default mceusb remote talks RC6(6A). Well, the RC6 decoder never gets a
> chance to run unless you move the RC6 decoder to the front of the list.
>
> What I believe to be correct is to have RUN_DECODER keep trying all of
> the decoders, even when one triggers an error. I don't think the errors
> matter so much as it matters that at least one was successful -- i.e.,
> that _sumrc is > 0. The following works for me w/my mceusb driver and
> the default decoder ordering -- NEC and RC5 still fail, but RC6 still
> gets a crack at it, and successfully does its job.
>
> Signed-off-by: Jarod Wilson <jarod@redhat.com>
>
> ---
> drivers/media/IR/ir-raw-event.c | 7 ++++---
>
> diff --git a/drivers/media/IR/ir-raw-event.c b/drivers/media/IR/ir-raw-event.c
> index ea68a3f..44162db 100644
> --- a/drivers/media/IR/ir-raw-event.c
> +++ b/drivers/media/IR/ir-raw-event.c
> @@ -36,14 +36,15 @@ static DEFINE_SPINLOCK(ir_raw_handler_lock);
> */
> #define RUN_DECODER(ops, ...) ({ \
> struct ir_raw_handler *_ir_raw_handler; \
> - int _sumrc = 0, _rc; \
> + int _sumrc = 0, _rc, _fail; \
> spin_lock(&ir_raw_handler_lock); \
> list_for_each_entry(_ir_raw_handler, &ir_raw_handler_list, list) { \
> if (_ir_raw_handler->ops) { \
> _rc = _ir_raw_handler->ops(__VA_ARGS__); \
> if (_rc < 0) \
> - break; \
> - _sumrc += _rc; \
> + _fail++; \
> + else \
> + _sumrc += _rc; \
Self-NAK. The only place we actually *care* about the retval from a
RUN_DECODER() call is in __ir_input_register(), and currently, its
looking for retval < 0, which is currently never possible. When we're
running the decoders, either they fail and return -EINVAL or they
succeed and return 0, and in the register case, we get either a
negative error (ex: -ENOMEM from rc6) or 0, so with the above, _sumrc
will *always* be 0 in the two cases I'm looking at. The third place
where RUN_DECODER gets called (decoder unregister) doesn't care about
the retval either. New patch below, including updated comments about
the macro.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Christian Dietrich