- 23 Sep, 2014 31 commits
-
-
Shuah Khan authored
xc5000 releases firmware right after loading it. Change it to save the firmware and release it from xc5000_release(). This helps avoid fecthing firmware when forced firmware load requests come in to change analog tv frequence and when firmware needs to be reloaded after suspend and resume. Signed-off-by:
Shuah Khan <shuahkh@osg.samsung.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@osg.samsung.com>
-
Mauro Carvalho Chehab authored
drivers/media/pci/saa7134/saa7134-go7007.c: In function ‘saa7134_go7007_interface_reset’: drivers/media/pci/saa7134/saa7134-go7007.c:147:6: warning: variable ‘status’ set but not used [-Wunused-but-set-variable] Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com>
-
Mauro Carvalho Chehab authored
drivers/media/pci/saa7134/saa7134-go7007.c:247:17: warning: incorrect type in argument 1 (different base types) drivers/media/pci/saa7134/saa7134-go7007.c:247:17: expected unsigned int [unsigned] val drivers/media/pci/saa7134/saa7134-go7007.c:247:17: got restricted __le32 [usertype] <noident> drivers/media/pci/saa7134/saa7134-go7007.c:252:17: warning: incorrect type in argument 1 (different base types) drivers/media/pci/saa7134/saa7134-go7007.c:252:17: expected unsigned int [unsigned] val drivers/media/pci/saa7134/saa7134-go7007.c:252:17: got restricted __le32 [usertype] <noident> drivers/media/pci/saa7134/saa7134-go7007.c:299:9: warning: incorrect type in argument 1 (different base types) drivers/media/pci/saa7134/saa7134-go7007.c:299:9: expected unsigned int [unsigned] val drivers/media/pci/saa7134/saa7134-go7007.c:299:9: got restricted __le32 [usertype] <noident> drivers/media/pci/saa7134/saa7134-go7007.c:300:9: warning: incorrect type in argument 1 (different base types) drivers/media/pci/saa7134/saa7134-go7007.c:300:9: expected unsigned int [unsigned] val drivers/media/pci/saa7134/saa7134-go7007.c:300:9: got restricted __le32 [usertype] <noident> Signed-off-by: -
Mauro Carvalho Chehab authored
All error/warnings: drivers/built-in.o: In function `saa7134_go7007_fini': >> saa7134-go7007.c:(.text+0x3b628b): undefined reference to `go7007_snd_remove' drivers/built-in.o: In function `saa7134_go7007_interface_reset': >> saa7134-go7007.c:(.text+0x3b659a): undefined reference to `go7007_read_interrupt' drivers/built-in.o: In function `saa7134_go7007_init': >> saa7134-go7007.c:(.text+0x3b65fa): undefined reference to `go7007_alloc' >> saa7134-go7007.c:(.text+0x3b66ed): undefined reference to `go7007_boot_encoder' >> saa7134-go7007.c:(.text+0x3b66fe): undefined reference to `go7007_register_encoder' drivers/built-in.o: In function `saa7134_go7007_irq_ts_done': >> saa7134-go7007.c:(.text+0x3b6c2a): undefined reference to `go7007_parse_video_stream' >> saa7134-go7007.c:(.text+0x3b6c86): undefined reference to `go7007_parse_video_stream' This happens when: - VIDEO_SAA7134 is either 'm' or 'y' - VIDEO_GO7007 is not selected. Reported-by:
kbuild test robot <fengguang.wu@intel.com> Signed-off-by:
-
Hans Verkuil authored
This patch adds support to saa7134 for 'WIS Voyager or compatible' PCI boards such as the Sensoray model 614 with which this patch was tested. It is a saa7134-based PCI board with a go7007 MPEG encoder. This was a patch when the go7007 was still in staging and was not applied when go7007 was moved to drivers/media since it needed more work. That work is now done and this last piece of go7007 support can now go in. Signed-off-by:
-
Hans Verkuil authored
The saa7134 driver missed capturing line 23 of the VBI area for the 50 Hz formats. Include that line in the VBI capture. Signed-off-by:
-
Hans Verkuil authored
v4l_print_ext_controls() would print the 'size' if it was 0 and 'value' if size was non-zero, but it should have been the other way around. Signed-off-by:
-
Dan Carpenter authored
We don't need to check "ret", we know it's zero. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Dan Carpenter authored
We know "ret" is zero so we don't need to test for it. It upsets the static checkers when we test stuff but we know the answer. drivers/media/usb/as102/as102_usb_drv.c:164 as102_send_ep1() warn: we tested 'ret' before and it was 'false' drivers/media/usb/as102/as102_usb_drv.c:189 as102_read_ep2() warn: we tested 'ret' before and it was 'false' Also, we don't need to initialize "ret". Signed-off-by:
-
Amber Thrall authored
Fixed various coding styles, ignoring coding style error on line 5 for all files containing a link that is longer than 80 characters long. Signed-off-by:
Amber Thrall <amber.rose.thrall@gmail.com> Signed-off-by:
-
Alexey Khoroshilov authored
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:
Alexey Khoroshilov <khoroshilov@ispras.ru> Signed-off-by:
-
Maciej Matraszek authored
Fix clamp_align() used in v4l_bound_align_image() to prevent overflow when passed large value like UINT32_MAX. In the current implementation: clamp_align(UINT32_MAX, 8, 8192, 3) returns 8, because in line: x = (x + (1 << (align - 1))) & mask; x overflows to (-1 + 4) & 0x7 = 3, while expected value is 8192. v4l_bound_align_image() is heavily used in VIDIOC_S_FMT and VIDIOC_SUBDEV_S_FMT ioctls handlers, and documentation of the latter explicitly states that: "The modified format should be as close as possible to the original request." -- http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-subdev-g-fmt.html Thus one would expect, that passing UINT32_MAX as format width and height will result in setting maximum possible resolution for the device. Particularly, when the driver doesn't support VIDIOC_ENUM_FRAMESIZES ioctl, which is common in the codebase. Fixes changeset: b0d3159bSigned-off-by:Maciej Matraszek <m.matraszek@samsung.com> Acked-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Frank Schaefer authored
Setting the value of the chip config register to EM28XX_CHIPCFG_AC97 in case of a read error is a leftover from the past which is no longer needed. Signed-off-by:
Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by:
-
Frank Schaefer authored
Field has_audio in struct em28xx_audio_mode is used together with value EM28XX_NO_AC97 of field ac97 to determine the internal type of audio (none/i2s/ac97). This makes the code difficult to understand: !audio_mode.has_audio && audio_mode.ac97 == EM28XX_NO_AC97 => no audio !audio_mode.has_audio && audio_mode.ac97 != EM28XX_NO_AC97 => BUG audio_mode.has_audio && audio_mode.ac97 == EM28XX_NO_AC97 => AC97 audio audio_mode.has_audio && audio_mode.ac97 != EM28XX_NO_AC97 => I2S audio Simplify the whole thing by introducing an enum em28xx_int_audio_type which describes the internal audio type (none, ac97, i2s) and is hooked directly to the device struct. Then get rid of field has_audio in struct em28xx_audio_mode. A follow-up patch will then remove struct em28xx_ac97_mode and finally the whole struct em28xx_audio_mode. Signed-off-by:
-
Frank Schaefer authored
As far as we know devices can either have audio class or vendor class usb interfaces but not both at the same time. Even if both interface types could be provided by devices at the same time, the current code is totally broken for that case. So clean up and simplify the usb audio class handling by replacing fields "has_audio_class" (device has usb audio class compliant interface) and "has_alsa_audio" (device has vendor audio interface) in struct em28xx with a single enum em28xx_usb_audio_type. Signed-off-by:
-
Frank Schaefer authored
Fields "ac97_feat", "ac97_vendor_id" and "i2s_samplerates" of struct em28xx_audio_mode are used nowhere, except in function em28xx_audio_setup(). So get rid of them and use local variables instead. Signed-off-by:
-
Laurent Pinchart authored
The buffer flags are incorrectly referred to as V4L2_BUF_FLAGS_* instead of V4L2_BUF_FLAG_* in comments. Fix it. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by:
Marek Szyprowski <m.szyprowski@samsung.com> Acked-by:
-
Olli Salonen authored
This patch adds support for Si2147-A30 tuner. Fairly trivial, no firmware needed for this tuner. However, command 14 00 02 07 01 00 seems to be mandatory. On Si2157 and Si2158 the value 0x0100 is the default value, so this patch does not impact the existing tuners/devices. On Si2147 the default is 0x0000 and I can't get a lock with that value. While here, fix the return length of the previous set command to 4 bytes. Signed-off-by:
Olli Salonen <olli.salonen@iki.fi> Acked-by:
Antti Palosaari <crope@iki.fi> Reviewed-by:
-
Dan Carpenter authored
"program_info_length" is user controlled and can go up to 4095. The operand[] array has 509 bytes so we need to add a limit here to prevent buffer overflows. The " - 4" in the limit check is because we have 4 bytes more data to add after the memcpy(). [mchehab@osg.samsung.com: as I merged the version 1 of the patch, I needed to rebase to apply just the differences between v1 and v2] Signed-off-by:
-
Dan Carpenter authored
"len" is user controlled and can be up to 255. Anything more than 59 will cause a buffer overflow so we need to add a test for that. Signed-off-by:
-
Alexey Khoroshilov authored
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:
-
Dan Carpenter authored
"program_info_length" is user controlled and can go up to 4095. The operand[] array has 509 bytes so we need to add a limit here to prevent buffer overflows. Signed-off-by:
Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by:
-
Dan Carpenter authored
We need to add a limit check here so we don't overflow the buffer. Signed-off-by:
-
Andy Shevchenko authored
There is no need to use hex_dump_to_buffer() since we have a kernel helper to dump up to 64 bytes just via printk(). Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Dan Carpenter authored
We call kfree(data_buf) in the error handling and that will oops if this is an error pointer. Signed-off-by:
-
Frank Schaefer authored
GIT_AUTHOR_DATE=1409603039 This reverts commit b99f0aad Author: Mauro Carvalho Chehab <m.chehab@samsung.com> [media] em28xx: check if a device has audio earlier Better to split chipset detection from the audio setup. So, move the detection code to em28xx_init_dev(). It broke analog audio of the Hauppauge winTV HVR 900 and very likely many other em28xx devices. Background: The local variable has_audio in em28xx_usb_probe() describes if the currently probed _usb_interface_ has an audio endpoint, while dev->audio_mode.has_audio means that the _device_ as a whole provides analog audio. Hence it is wrong to set dev->audio_mode.has_audio = has_audio in em28xx_usb_probe(). As result, audio support is no longer detected and configured on devices which have the audio endpoint on a separate interface, because em28xx_audio_setup() bails out immediately at the beginning. Revert the faulty commit to restore the old audio detection procedure, which checks the chip configuration register to determine if the device has analog audio. Cc: <stable@vger.kernel.org> # 3.14 to 3.16 Reported-by:
Oravecz Csaba <oravecz@nytud.mta.hu> Tested-by:
-
Matthias Schwarzott authored
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:
Matthias Schwarzott <zzam@gentoo.org> Signed-off-by:
-
Matthias Schwarzott authored
Add support for: [2040:b139] Hauppauge WinTV HVR-901H (1114xx) According to the inf file, the hardware is similar to [2040:b131] Hauppauge WinTV 930C-HD (model 1114xx) The only difference is the demod Si2161 instead of Si2165 (but both are supported by the si2165 driver). Signed-off-by:
-
Matthias Schwarzott authored
Add support for: [2040:b138] Hauppauge WinTV HVR-900H (111xxx) The hardware is similar to [2040:b130] Hauppauge WinTV 930C-HD (model 1113xx) The only difference is the demod Si2161 instead of Si2165 (but both are supported by the si2165 driver). Signed-off-by:
-
Matthias Schwarzott authored
Additionally print chip name with revision symbolically. This is a preparation for supporting new Hauppauge WinTV-HVR-900-H based on cx231xx. Signed-off-by:
-
Matthias Schwarzott authored
Current firmware is only for revision D. Signed-off-by:
-
- 22 Sep, 2014 9 commits
-
-
Jingoo Han authored
Casting the return value which is a void pointer is redundant. The conversion from void pointer to any other pointer type is guaranteed by the C programming language. Signed-off-by:
Jingoo Han <jg1.han@samsung.com> Signed-off-by:
-
Fengguang Wu authored
make vpfe_standards[] static. Signed-off-by:
-
Olli Salonen authored
Add a maintainer for the new CIMaX SP2 driver. Signed-off-by:
-
Mauro Carvalho Chehab authored
A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @decl@ identifier i1,fld; type T; field list[n] fs; @@ struct i1 { fs T fld; ...}; @bad@ identifier decl.i1,i2; expression e; initializer list[decl.n] is; @@ struct i1 i2 = { is, + .fld = e - e ,...}; // </smpl> Not sure why, but some tables are still using the old way, but at least several of them got fixed. Signed-off-by:
-
Julia Lawall authored
Use c99 initializers for structures. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @decl@ identifier i1,fld; type T; field list[n] fs; @@ struct i1 { fs T fld; ...}; @bad@ identifier decl.i1,i2; expression e; initializer list[decl.n] is; @@ struct i1 i2 = { is, + .fld = e - e ,...}; // </smpl> Signed-off-by:
Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by:
-
Mauro Carvalho Chehab authored
This is used by the I2C code in order to slow down the speed to 20 kHz on devices with xc5000 or xc5000c. So, it needs to be filled for all devices that use either xc5000 or xc5000c. Signed-off-by: -
Mauro Carvalho Chehab authored
Right now, the au0828 driver uses .tuner to detect if analog tv is being used or not. By not filling .tuner fields at the board struct, the I2C core can't do decisions based on it. So, add a field to explicitly tell when analog TV is supported. No functional changes. Signed-off-by: -
Mauro Carvalho Chehab authored
This comment is already at the au0828-i2c where it belongs. So, remove it from a board's entry. It doesn't make any sense there, as we're setting the clock to 250kHz there, slowing it down only at the au0828-i2c. Signed-off-by: -
Mauro Carvalho Chehab authored
cab_state->modulation is initialized with a wrong value: drivers/media/dvb-frontends/stv0367.c:3000:42: warning: mixing different enum types drivers/media/dvb-frontends/stv0367.c:3000:42: int enum fe_modulation versus drivers/media/dvb-frontends/stv0367.c:3000:42: int enum stv0367cab_mod as it was declared as "enum stv0367cab_mod". While it could be fixed, there's no value on it, as this is never used. So, just remove the modulation from cab_state structure. Signed-off-by:
-
