linux-stable.git/drivers, branch v3.12.22

media: V4L2: fix VIDIOC_CREATE_BUFS in 64- / 32-bit compatibility mode

2014-06-09T13:54:00+00:00

commit 97d9d23dda6f37d90aefeec4ed619d52df525382 upstream.

If a struct contains 64-bit fields, it is aligned on 64-bit boundaries
within containing structs in 64-bit compilations. This is the case with
struct v4l2_window, which contains pointers and is embedded into struct
v4l2_format, and that one is embedded into struct v4l2_create_buffers.
Unlike some other structs, used as a part of the kernel ABI as ioctl()
arguments, that are packed, these structs aren't packed. This isn't a
problem per se, but the ioctl-compat code for VIDIOC_CREATE_BUFS contains
a bug, that triggers in such 64-bit builds. That code wrongly assumes,
that in struct v4l2_create_buffers, struct v4l2_format immediately follows
the __u32 memory field, which in fact isn't the case. This bug wasn't
visible until now, because until recently hardly any applications used
this ioctl() and mostly embedded 32-bit only drivers implemented it. This
is changing now with addition of this ioctl() to some USB drivers, e.g.
UVC. This patch fixes the bug by copying parts of struct
v4l2_create_buffers separately.

Signed-off-by: Guennadi Liakhovetski 
Acked-by: Laurent Pinchart 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Jiri Slaby

media: V4L2: ov7670: fix a wrong index, potentially Oopsing the kernel from user-space

2014-06-09T13:54:00+00:00

commit cfece5857ca51d1dcdb157017aba226f594e9dcf upstream.

Commit 75e2bdad8901a0b599e01a96229be922eef1e488 "ov7670: allow
configuration of image size, clock speed, and I/O method" uses a wrong
index to iterate an array. Apart from being wrong, it also uses an
unchecked value from user-space, which can cause access to unmapped
memory in the kernel, triggered by a normal desktop user with rights to
use V4L2 devices.

Signed-off-by: Guennadi Liakhovetski 
Acked-by: Jonathan Corbet 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Jiri Slaby

media: fc2580: fix tuning failure on 32-bit arch

2014-06-09T13:53:59+00:00

commit 8845cc6415ec28ef8d57b3fb81c75ef9bce69c5f upstream.

There was some frequency calculation overflows which caused tuning
failure on 32-bit architecture. Use 64-bit numbers where needed in
order to avoid calculation overflows.

Thanks for the Finnish person, who asked remain anonymous, reporting,
testing and suggesting the fix.

Signed-off-by: Antti Palosaari 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Jiri Slaby

iommu/amd: Fix interrupt remapping for aliased devices

2014-06-09T13:53:59+00:00

commit e028a9e6b8a637af09ac4114083280df4a7045f1 upstream.

An apparent cut and paste error prevents the correct flags from being
set on the alias device resulting in MSI on conventional PCI devices
failing to work.  This also produces error events from the IOMMU like:

AMD-Vi: Event logged [INVALID_DEVICE_REQUEST device=00:14.4 address=0x000000fdf8000000 flags=0x0a00]

Where 14.4 is a PCIe-to-PCI bridge with a device behind it trying to
use MSI interrupts.

Signed-off-by: Alex Williamson 
Signed-off-by: Joerg Roedel 
Signed-off-by: Jiri Slaby

spi: core: Ignore unsupported Dual/Quad Transfer Mode bits

2014-06-09T13:53:57+00:00

commit 83596fbeb5d28e8cb8878786133945d4dc7c0090 upstream.

The availability of SPI Dual or Quad Transfer Mode as indicated by the
"spi-tx-bus-width" and "spi-rx-bus-width" properties in the device tree is
a hardware property of the SPI master, SPI slave, and board wiring.  Hence
the SPI core should not reject an SPI slave because an SPI master driver
doesn't (yet) support Dual or Quad Transfer Mode.

Change the lack of Dual or Quad Transfer Mode support in the SPI master
driver from an error condition to a warning condition, and ignore the
unsupported mode bits, falling back to Single Transfer Mode, to avoid
breakages when running old kernels with new device trees.

Fixes: f477b7fb13df (spi: DUAL and QUAD support)
Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Mark Brown 
Signed-off-by: Jiri Slaby

crypto: caam - add allocation failure handling in SPRINTFCAT macro

2014-06-09T13:53:55+00:00

commit 27c5fb7a84242b66bf1e0b2fe6bf40d19bcc5c04 upstream.

GFP_ATOMIC memory allocation could fail.
In this case, avoid NULL pointer dereference and notify user.

Cc: Kim Phillips 
Signed-off-by: Horia Geanta 
Signed-off-by: Herbert Xu 
Signed-off-by: Jiri Slaby

i2c: s3c2410: resume race fix

2014-06-09T13:53:54+00:00

commit ce78cc071f5f541480e381cc0241d37590041a9d upstream.

Don't unmark the device as suspended until after it's been re-setup.

The main race would be w.r.t. an i2c driver that gets resumed at the same
time (asyncronously), that is allowed to do a transfer since suspended
is set to 0 before reinit, but really should have seen the -EIO return
instead.

Signed-off-by: Olof Johansson 
Signed-off-by: Doug Anderson 
Acked-by: Kukjin Kim 
Signed-off-by: Wolfram Sang 
Signed-off-by: Jiri Slaby

i2c: designware: Mask all interrupts during i2c controller enable

2014-06-09T13:53:54+00:00

commit 47bb27e78867997040a228328f2a631c3c7f2c82 upstream.

There have been "i2c_designware 80860F41:00: controller timed out" errors
on a number of Baytrail platforms. The issue is caused by incorrect value in
Interrupt Mask Register (DW_IC_INTR_MASK)  when i2c core is being enabled.
This causes call to __i2c_dw_enable() to immediately start the transfer which
leads to timeout. There are 3 failure modes observed:

1. Failure in S0 to S3 resume path

The default value after reset for DW_IC_INTR_MASK is 0x8ff. When we start
the first transaction after resuming from system sleep, TX_EMPTY interrupt
is already unmasked because of the hardware default.

2. Failure in normal operational path

This failure happens rarely and is hard to reproduce. Debug trace showed that
DW_IC_INTR_MASK had value of 0x254 when failure occurred, which meant
TX_EMPTY was unmasked.

3. Failure in S3 to S0 suspend path

This failure also happens rarely and is hard to reproduce. Adding debug trace
that read DW_IC_INTR_MASK made this failure not reproducible. But from ISR
call trace we could conclude TX_EMPTY was unmasked when problem occurred.

The patch masks all interrupts before the controller is enabled to resolve the
faulty DW_IC_INTR_MASK conditions.

Signed-off-by: Wenkai Du 
Acked-by: Mika Westerberg 
[wsa: improved the comment and removed typo in commit msg]
Signed-off-by: Wolfram Sang 
Signed-off-by: Jiri Slaby

i2c: rcar: bail out on zero length transfers

2014-06-09T13:53:53+00:00

commit d7653964c590ba846aa11a8f6edf409773cbc492 upstream.

This hardware does not support zero length transfers. Instead, the
driver does one (random) byte transfers currently with undefined results
for the slaves. We now bail out.

Signed-off-by: Wolfram Sang 
Signed-off-by: Wolfram Sang 
Signed-off-by: Jiri Slaby

ACPI: blacklist win8 OSI for Dell Inspiron 7737

2014-06-09T13:53:52+00:00

commit b753631b3576bf343151a82513c5d56fcda1e24f upstream.

With win8 capabiltiy, the machine will boot itself immediately after
shutdown command has executed.

Work around this issue by disabling win8 capcability.  This workaround
also makes wireless hotkey work.

Signed-off-by: Edward Lin 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Jiri Slaby