v4l2_device_disconnect() is called when the device is disconnected, so that the
v4l2-core rejects all ioctl calls.
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Acked-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The tuner type is set by the v4l2-core based on the device type.
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Acked-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

vidioc_s_fmt_vbi_cap() is a 100% duplicate of vidioc_g_fmt_vbi_cap() and
therefore can be removed.
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Acked-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The em28xx driver doesn't support the VIDIOC_G_CROP and VIDIOC_S_CROP ioctls,
so VIDIOC_CROPCAP is useless and has the potential to confuse applications,
because it can be interpreted as indicator for cropping support.
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Acked-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

With the current code V4L2_BUF_TYPE_VIDEO_CAPTURE is accepted only, but for VBI
devices only buffer type V4L2_BUF_TYPE_VBI_CAPTURE is used/valid.
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Acked-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

VIDIOC_S_PARM doesn't make sense for VBI device nodes, because we don't support
selecting the number of read buffers to use.
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Acked-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Instead of checking the device type and returning -ENOTTY inside the ioctl
function, use v4l2_disable_ioctl() to disable the ioctl VIDIOC_S_PARM if the
device is not a camera.
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Acked-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Instead of checking the device type and returning -EINVAL inside the ioctl
functions, use v4l2_disable_ioctl() to disable the ioctls VIDIOC_G_AUDIO and
VIDIOC_S_AUDIO if the device doesn't support audio.
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Acked-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Disable the ioctls VIDIOC_G_TUNER, VIDIOC_S_TUNER, VIDIOC_G_FREQUENCY and
VIDIOC_S_FREQUENCY for video and VBI devices without tuner.
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Acked-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Instead of checking the device type and returning -ENOTTY inside the ioctl
functions, use v4l2_disable_ioctl() to disable the ioctls VIDIOC_QUERYSTD,
VIDIOC_G_STD and VIDIOC_S_STD if the device is a camera.
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Acked-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

file argument is a struct file being passed to ->open() or
already opened; none of the checks in lirc_get_pdata()
can fail.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

As reported by Klaus Schmidinger:
 "In VDR I use an ioctl() call with FE_READ_UNCORRECTED_BLOCKS on a
  device (using stb0899).  After this call I check 'errno' for
  EOPNOTSUPP to determine whether this device supports this call.  This
  used to work just fine, until a few months ago I noticed that my
  devices using stb0899 didn't display their signal quality in VDR's OSD
  any more.  After further investigation I found that
  ioctl(FE_READ_UNCORRECTED_BLOCKS) no longer returns EOPNOTSUPP, but
  rather ENOTTY.  And since I stop getting the signal quality in case
  any unknown errno value appears, this broke my signal quality query
  function."

While the changes reflect what is there at:

  http://comments.gmane.org/gmane.linux.kernel/1235728

it does cause regression on userspace.  So, revert it to stop the
damage.

This reverts commit 177ffe50 ("[media] dvb_frontend: return -ENOTTY
for unimplement IOCTL").
Reported-by: NKlaus Schmidinger <Klaus.Schmidinger@tvdr.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

It is now possible to build the davinci vpss code
on multiplatform kernels, which causes a problem
since the driver tries to incude the davinci
platform specific mach/hardware.h file. Fortunately
that file is not required at all in the driver,
so we can simply remove the #include statement.

Without this patch, building allyesconfig results in:

drivers/media/platform/davinci/vpss.c:28:27: fatal error: mach/hardware.h: No such file or directory
compilation terminated.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: N"Lad, Prabhakar" <prabhakar.lad@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Cc: Mauro Carvalho Chehab <mchehab@redhat.com>

Texas Instruments WL1273 I2C FM Radio (RADIO_WL1273) selects
MFD_CORE, which itself depends on GENERIC_HARDIRQS.
So add the dependency to the TI driver as well.
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Acked-by: NMauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

The "Technisat SkyStar USB plus" is a TT-connect S-2400 clone, which the
V4L-DVB drivers already support. However, some of these devices (like
mine) come with a different USB PID 0x3009 instead of 0x3006.

There have already been patches simply overwriting the USB PID in
dvb-usb-ids.h. Of course these patches were rejected because they would
have disabled the 0x3006 PID.

This new patch adds the 0x3009 PID to dvb-usb-ids.h, and adds references
to it within the ttusb2.c driver. PID 0x3006 devices will continue to work.

The only difference between the two hardware models seems to be the
EEPROM chip. In fact, Windows BDA driver names the 0x3009 device with a
"(8 kB EEPROM)" suffix. In spite of that, the 0x3009 device works
absolutely flawlessly using the existing ttusb2 driver.
Signed-off-by: NChristoph Nuscheler <christoph.nuscheler@t-online.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NAlistair Buxton <a.j.buxton@gmail.com>
Acked-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Seems to work just the same as older revisions.
Signed-off-by: NRoland Scheidegger <rscheidegger_lists@hispeed.ch>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This patch adds device tree parsing for gpio_ir_recv platform_data and
the mandatory binding documentation. It basically follows what we already
have for e.g. gpio_keys. All required device tree properties are OS
independent but an optional property allows linux specific support for rc
maps.
Signed-off-by: NSebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Reviewed-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Smatch complains that "cmdbuf[cmdcount - length]" might go past the end
of the array.  It's an easy warning to silence by moving the limit
check earlier.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This prepares for the removal of vou_file.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Replace video_devdata() followed by video_get_drvdata() calls with
video_drvdata().
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This patch uses various devm_ functions for data that is allocated in the
probe function of a platform driver and is only freed in the remove
function.
This also fixes a checkpatch warning, removing a space before a \n in a
string.
Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The original commit, adding the mt9t112 driver said, that mt9t111 and
mt9t112 had identical register layouts. This however doesn't seem to be
the case. At least pixel format selection in the mt9t111 datasheet is
different from the driver implementation. So far only the default YUYV
format has been verified to work with mt9t111. Limit the driver to only
report one supported format with mt9t111 until more formats are
implemented.
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The V4L2_CID_SHARPNESS control in the sh-mobile-ceu-camera driver, if off,
turns the CEU low-pass filter on. This is the opposite to the hardware
default and can degrade image quality. Switch default to on to restore the
default unfiltered mode.
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This reverts commit a92591a7.

From: Michael Büsch <m@bues.ch>
To: linux-media@vger.kernel.org
Cc: mchehab@redhat.com
Subject: Re: [git:v4l-dvb/for_v3.9] [media] fc0011: Return early, if the frequency is already tuned
Date: Mon, 11 Feb 2013 21:59:19 +0100

Can you please revert this one again? It might cause issues if the dvb device
is reset/reinitialized.
Requested-by: NMichael Büsch <m@bues.ch>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Commits 5e6e81b2 (cx18) and
2aebbf67 (ivtv) added an __init
annotation to the cx18-alsa-load and ivtv-alsa-load functions. However,
these functions are called *after* initialization by the main cx18/ivtv
driver. By that time the memory containing those functions is already
freed and your machine goes BOOM.

Cc: stable@vger.kernel.org # for 3.8
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

With the conversion to videobuf2, some unnecessary calls of
em28xx_set_alternate() have been removed. It is now called at analog streaming
start only.
This has unveiled a bug that causes USB bulk transfers to fail with all urbs
having status -EVOERFLOW.
The reason is, that for bulk transfers usb_set_interface() needs to be called
even if the previous alt setting was the same (side note: bulk transfers seem
to work only with alt=0).
While it seems to be NOT necessary for isoc transfers, it's reasonable to just
call usb_set_interface() unconditionally in em28xx_set_alternate().
Also add a comment that explains the issue to prevent regressions in the future.

Cc: stable@vger.kernel.org # for 3.8
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The address of a variable is impossible to be null, so we remove the check.
Signed-off-by: NCong Ding <dinggnu@gmail.com>
Signed-off-by: NMichael Krufky <mkrufky@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Return early, if we already tuned to a frequency.
Signed-off-by: NMichael Buesch <m@bues.ch>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Add some sanity checks to the calculations and make the REG_16 register write consistent
with the other ones.
Signed-off-by: NMichael Buesch <m@bues.ch>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Fix the xin value clamping and use clamp_t().
Signed-off-by: NMichael Buesch <m@bues.ch>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This patch was applied by mistake. Michael thinks that it
it needs more work than simply moving the soft reset.

So, it should be held back for further review.

This reverts commit 0a323770.

Requested by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Assign the maximum instead of masking with the maximum on value overflow.
Signed-off-by: NMichael Buesch <m@bues.ch>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

tm6000_poll could use an uninitialized buf pointer. Move the buf-handling
code inside the 'if' that initializes the buf pointer.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This patch is driven by a static checker warning.
The ttusb_process_muxpack() function is only called from
ttusb_process_frame().  Before calling, it verifies that len >= 2.  The
problem is that len == 2 is not valid and would lead to an array
underflow.
Odd number values for len are also invalid and would lead to reading
past the end of the array.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Without this patch we get the following build error:
drivers/media/platform/s5p-tv/mixer_video.c:
In function ‘find_and_register_subdev’:
drivers/media/platform/s5p-tv/mixer_video.c:42:34: error:
‘platform_bus_type’ undeclared (first use in this function)
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Without this patch we get the following compilation errors:
drivers/media/platform/s5p-tv/mixer.h:345:13: error: Expected ; at end of declaration
drivers/media/platform/s5p-tv/mixer.h:345:13: error: got mxr_irq_handler
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The bytesperline calculation was incorrect: it used the old width instead of
the provided width. Fixed.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Acked-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

While running checkpatch.pl after the last patch, I noticed
lots of those:
	WARNING: please, no space before tabs
	#151: FILE: drivers/media/common/tveeprom.c:99:
	+^I{ TUNER_ABSENT,        ^I^I"None" },$

(together with other checkpatch.pl errors/warnings)

While I won't be fixing everything, as I have already an
script to fix the above, let's do it, in order to clean it
a little bit.

While here, also drop cmacs-specific format text at the end.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>