HID: logitech: don't use stack based dj_report structures

On a system with a logitech wireless keyboard/mouse and DMA-API debugging
enabled, this warning appears at boot:

kernel: WARNING: at lib/dma-debug.c:929 check_for_stack.part.12+0x70/0xa7()
kernel: Hardware name: MS-7593
kernel: uhci_hcd 0000:00:1d.1: DMA-API: device driver maps memory fromstack [addr=ffff8801b0079c29]

Make logi_dj_recv_query_paired_devices and logi_dj_recv_switch_to_dj_mode
use a structure allocated with kzalloc rather than a stack based one.

Signed-off-by: Marc Dionne <marc.c.dionne@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
[media] v4l: Correct create_bufs documentation

Patch id 6016af82eafcb6e086a8f2a2197b46029a843d68 ("[media] v4l2: use __u32
rather than enums in ioctl() structs") unintentionally changes the type of
the format field in struct v4l2_create_buffers from struct v4l2_format to
__u32. Revert that change.

Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
[media] Fix vivi regression

This patch fixes a regression introduced by commit
5126f2590bee412e3053de851cb07f531e4be36a:

[media] v4l2-dev: add flag to have the core lock all file operations

I forgot to add the locks to the vivi read operation.

Regards,

	Hans

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
[media] Fix regression in ioctl numbering

Yuck. The VIDIOC_(TRY_)DECODER_CMD ioctls already had ioctl numbers 96 and 97,
and after merging the timings API I forgot to continue numbering from 98. So
now we have two ioctls with number 96 and two with 97.

With the new table-driver ioctl handling in v4l2-ioctl.c it is essential that
each ioctl has its own unique number, so let's fix this quickly for 3.5.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
[media] Fix query/enum_dv_timings regression

Now query/enum_dv_timings finally work again.

The timings API patches and the core ioctl changes clearly sailed right past
each other without realizing that both needed to adapt to the other.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
[media] V4L2 spec fix

Two small docbook fixes:

- prepare-buf was not positioned in alphabetical order, moved to the right place.
- the format field in create_bufs had the wrong type in the documentation

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Reviewed-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
[media] lg2160: fix off-by-one error in lg216x_write_regs

Fix an off-by-one error in lg216x_write_regs, causing the last element
of the lg216x init block to be ignored.  Spotted by Dan Carpenter.

Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
[media] radio/si470x: Add support for the Axentia ALERT FM USB Receiver

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
[media] snd_tea575x: Report correct frequency range for EU/US versus JA models

My EU/US 5757 cannot tune below approx 86 Mhz, that is below that it
does not even generate the standard not tuned to anything radio noise anymore,
so clearly the 5757 cannot tune to the Japanese frequencies. This patch
assumes that likewise the 5759 cannot tune to the EU/US frequencies.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
CC: Ondrej Zary <linux@rainbow-software.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
[media] snd_tea575x: Make the module using snd_tea575x the fops owner

Before this patch the owner field of the /dev/radio# device fops was set to
the snd-tea575x-tuner module itself. Meaning that the module which was using
it could be rmmod-ed while the device is open, and then BAD things happen.

I know, as I found out the hard way :)

Note that there is no need to also somehow increase the refcount of the
snd-tea575x-tuner module itself, since any drivers using it will have
symbolic references to it.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
CC: Ondrej Zary <linux@rainbow-software.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
[media] snd_tea575x: set_freq: update cached freq to the actual achieved frequency

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
CC: Ondrej Zary <linux@rainbow-software.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
[media] bttv: Use btv->has_radio rather then the card info when registering the tuner

bttv_init_card2() sets btv->has_audio to a *default* value from the tvcards
array and then may update it by reading a card specific eeprom or gpio
detection.

After bttv_init_card2(), bttv_init_tuner() gets called, and it should clearly
use the updated, dynamic has_radio value from btv->has_radio, rather then
the const value in the tvcards array.

This fixes the radio not working on my Hauppauge WinTV.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
[media] bttv: Remove unused needs_tvaudio card variable

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
[media] bttv: The Hauppauge 61334 needs the msp3410 to do radio demodulation

The (radio) audio out from the tuner (which can also demod FM radio) does not
seem to be hooked up to the msp3410 on this board in any way, so the only way
to get sound from the radio part is to make the msp3410 do the FM radio demod.

The msp3410 can handle this fine, but it is a bit weird compared to how it
is handled on other boards.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
[media] gspca_pac7311: Correct number of controls

This avoids the need for a re-alloc during init.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
[media] gscpa_sn9c20x: Move clustering of controls to after error checking

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
[media] gspca_ov534: make AGC and AWB controls independent

Even if the best results are indeed achieved with both AGC and AWB
enabled, the webcam is capable of setting these independently, and the
user can see the difference of any of the 4 combinations of these two
boolean controls.

Removing the dependency from one another simplifies the code and gives
more control to the user.

Signed-off-by: Antonio Ospite <ospite@studenti.unina.it>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
[media] gspca-core: Fix buffers staying in queued state after a stream_off

This fixes a regression introduced by commit f7059ea and should be
backported to all supported stable kernels which have this commit.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: Antonio Ospite <ospite@studenti.unina.it>
CC: stable@vger.kernel.org
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
[media] gspca - ov534/ov534_9: Fix sccd_read/write errors

The ov534 bridge is too slow to handle the sensor accesses
requested by fast hosts giving 'sccb_reg_write failed'.
A small delay fixes the problem.

Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
[media] gspca - sonixj: Fix bad values of webcam 0458:7025

The webcam 0458:7025 (Eye911Q) has:
- an inverted power pin,
- a sensor mi0360b which cannot be probed.

Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>