linux-toradex.git/drivers, branch v3.2.60

dma: mv_xor: Flush descriptors before activating a channel

2014-06-09T12:29:15+00:00

commit 5a9a55bf9157d3490b0c8c4c81d4708602c26e07 upstream.

We need to use writel() instead of writel_relaxed() when starting
a channel, to ensure all the descriptors have been flushed before
the activation.

While at it, remove the unneeded read-modify-write and make the
code simpler.

Signed-off-by: Lior Amsalem 
Signed-off-by: Ezequiel Garcia 
Signed-off-by: Dan Williams 
[bwh: Backported to 3.2: it was using __raw_readl() and __raw_writel()
 which are just as wrong]
Signed-off-by: Ben Hutchings

can: peak_pci: prevent use after free at netdev removal

2014-06-09T12:29:14+00:00

commit 0b5a958cf4df3a5cd578b861471e62138f55c85e upstream.

As remarked by Christopher R. Baker in his post at

http://marc.info/?l=linux-can&m=139707295706465&w=2

there's a possibility for an use after free condition at device removal.

This simplified patch introduces an additional variable to prevent the issue.
Thanks for catching this.

Reported-by: Christopher R. Baker 
Signed-off-by: Stephane Grosjean 
Signed-off-by: Marc Kleine-Budde 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

can: peak_pci: Fix the way channels are linked together

2014-06-09T12:29:14+00:00

commit 29830406415c227a54af429d7b300aabd4754237 upstream.

Change the way channels objects are linked together by peak_pci_probe()
avoiding any kernel oops when driver is removed. Side effect is that
the list is now browsed from last to first channel.

Signed-off-by: Stephane Grosjean 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Ben Hutchings

drm/radeon: handle non-VGA class pci devices with ATRM

2014-06-09T12:29:14+00:00

commit d8ade3526b2aa0505132c404c05a38b73ea15490 upstream.

Newer PX systems have non-VGA pci class dGPUs.  Update
the ATRM fetch method to handle those cases.

bug:
https://bugzilla.kernel.org/show_bug.cgi?id=75401

Signed-off-by: Alex Deucher 
Signed-off-by: Christian König 
[bwh: Backported to 3.2: s/ACPI_HANDLE()/DEVICE_ACPI_HANDLE()/]
Signed-off-by: Ben Hutchings

drm/radeon: also try GART for CPU accessed buffers

2014-06-09T12:29:13+00:00

commit 544092596e8ac269f70e70961b5e9381909c9b1e upstream.

Placing them exclusively into VRAM might not work all the time.

Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=78297

Signed-off-by: Christian König 
Reviewed-by: Alex Deucher 
[bwh: Backported to 3.2: ttm_bo_validate() takes an extra no_wait_reserve
 parameter; keep passing true]
Signed-off-by: Ben Hutchings

PCI: shpchp: Check bridge's secondary (not primary) bus speed

2014-06-09T12:29:12+00:00

commit 93fa9d32670f5592c8e56abc9928fc194e1e72fc upstream.

When a new device is added below a hotplug bridge, the bridge's secondary
bus speed and the device's bus speed must match.  The shpchp driver
previously checked the bridge's *primary* bus speed, not the secondary bus
speed.

This caused hot-add errors like:

  shpchp 0000:00:03.0: Speed of bus ff and adapter 0 mismatch

Check the secondary bus speed instead.

[bhelgaas: changelog]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=75251
Fixes: 3749c51ac6c1 ("PCI: Make current and maximum bus speeds part of the PCI core")
Signed-off-by: Marcel Apfelbaum 
Signed-off-by: Bjorn Helgaas 
Acked-by: Michael S. Tsirkin 
Signed-off-by: Ben Hutchings

i2c: s3c2410: resume race fix

2014-06-09T12:29:12+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 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

i2c: designware: Mask all interrupts during i2c controller enable

2014-06-09T12:29:12+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: Ben Hutchings

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

2014-06-09T12:29:11+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 
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings

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

2014-06-09T12:29:11+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 
[bwh: Backported to 3.2:
 - Adjust filename
 - win_sizes array is static, not per-device]
Signed-off-by: Ben Hutchings