linux-toradex.git, branch v3.11.9

Linux 3.11.9

2013-11-20T20:31:48+00:00

media: sh_vou: almost forever loop in sh_vou_try_fmt_vid_out()

2013-11-20T20:31:40+00:00

commit 47c32ec9392a1fc7dec9d7cfde084e1432fcee82 upstream.

The "i < " part of the "i < ARRAY_SIZE()" condition was missing.

Signed-off-by: Dan Carpenter 
[g.liakhovetski@gmx.de: remove unrelated superfluous braces]
Signed-off-by: Guennadi Liakhovetski 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman

usbcore: set lpm_capable field for LPM capable root hubs

2013-11-20T20:31:40+00:00

commit 9df89d85b407690afa46ddfbccc80bec6869971d upstream.

This patch sets the lpm_capable field for root hubs with LPM capabilities.

Signed-off-by: Xenia Ragiadakou 
Reported-by: Martin MOKREJS 
Suggested-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman

usb: fail on usb_hub_create_port_device() errors

2013-11-20T20:31:40+00:00

commit e58547eb9561a8a72d46e2d411090a614d33ac0e upstream.

Ignoring usb_hub_create_port_device() errors cause later NULL pointer
deference when uninitialized hub->ports[i] entries are dereferenced
after port memory allocation error.

Signed-off-by: Krzysztof Mazur 
Acked-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman

usb: fix cleanup after failure in hub_configure()

2013-11-20T20:31:40+00:00

commit d0308d4b6b02597f39fc31a9bddf7bb3faad5622 upstream.

If the hub_configure() fails after setting the hdev->maxchild
the hub->ports might be NULL or point to uninitialized kzallocated
memory causing NULL pointer dereference in hub_quiesce() during cleanup.

Now after such error the hdev->maxchild is set to 0 to avoid cleanup
of uninitialized ports.

Signed-off-by: Krzysztof Mazur 
Acked-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman

backlight: atmel-pwm-bl: fix deferred probe from __init

2013-11-20T20:31:40+00:00

commit 9d3fde86b15303decea632c929fbf1f3ae4501f2 upstream.

Move probe out of __init section and don't use platform_driver_probe
which cannot be used with deferred probing.

Since commit e9354576 ("gpiolib: Defer failed gpio requests by default")
this driver might return -EPROBE_DEFER if a gpio_request fails.

Cc: Richard Purdie 
Cc: Jingoo Han 
Cc: Jean-Christophe Plagniol-Villard 
Signed-off-by: Johan Hovold 
Signed-off-by: Greg Kroah-Hartman

misc: atmel_pwm: add deferred-probing support

2013-11-20T20:31:40+00:00

commit 5c6d6fd1564138ad048564e48639f842714a90c6 upstream.

Two drivers (atmel-pwm-bl and leds-atmel-pwm) currently depend on the
atmel_pwm driver to have bound to any pwm-device before their devices
are probed.

Support deferred probing of such devices by making sure to return
-EPROBE_DEFER from pwm_channel_alloc when no pwm-device has yet been
bound.

Signed-off-by: Johan Hovold 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: pcie: add new SKUs for 7000 & 3160 NIC series

2013-11-20T20:31:39+00:00

commit b49926629fb5c324bb1ed3960fb0d7905a4a8562 upstream.

Add some new PCI IDs to the table for 7000 & 3160 series

Cc: stable@vger.kernel.org
Signed-off-by: Matti Gottlieb 
Reviewed-by: Emmanuel Grumbach 
Signed-off-by: Johannes Berg 
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Greg Kroah-Hartman

perf: Fix perf ring buffer memory ordering

2013-11-20T20:31:39+00:00

commit bf378d341e4873ed928dc3c636252e6895a21f50 upstream.

The PPC64 people noticed a missing memory barrier and crufty old
comments in the perf ring buffer code. So update all the comments and
add the missing barrier.

When the architecture implements local_t using atomic_long_t there
will be double barriers issued; but short of introducing more
conditional barrier primitives this is the best we can do.

Reported-by: Victor Kaplansky 
Tested-by: Victor Kaplansky 
Signed-off-by: Peter Zijlstra 
Cc: Mathieu Desnoyers 
Cc: michael@ellerman.id.au
Cc: Paul McKenney 
Cc: Michael Neuling 
Cc: Frederic Weisbecker 
Cc: anton@samba.org
Cc: benh@kernel.crashing.org
Link: http://lkml.kernel.org/r/20131025173749.GG19466@laptop.lan
Signed-off-by: Ingo Molnar 
Cc: Michael Neuling 
Signed-off-by: Greg Kroah-Hartman

drm/i915/dp: workaround BIOS eDP bpp clamping issue

2013-11-20T20:31:39+00:00

commit c6cd2ee2d59111a07cd9199564c9bdcb2d11e5cf upstream.

This isn't a real fix to the problem, but rather a stopgap measure while
trying to find a proper solution.

There are several laptops out there that fail to light up the eDP panel
in UEFI boot mode. They seem to be mostly IVB machines, including but
apparently not limited to Dell XPS 13, Asus TX300, Asus UX31A, Asus
UX32VD, Acer Aspire S7. They seem to work in CSM or legacy boot.

The difference between UEFI and CSM is that the BIOS provides a
different VBT to the kernel. The UEFI VBT typically specifies 18 bpp and
1.62 GHz link for eDP, while CSM VBT has 24 bpp and 2.7 GHz link. We end
up clamping to 18 bpp in UEFI mode, which we can fit in the 1.62 Ghz
link, and for reasons yet unknown fail to light up the panel.

Dithering from 24 to 18 bpp itself seems to work; if we use 18 bpp with
2.7 GHz link, the eDP panel lights up. So essentially this is a link
speed issue, and *not* a bpp clamping issue.

The bug raised its head since
commit 657445fe8660100ad174600ebfa61536392b7624
Author: Daniel Vetter 
Date:   Sat May 4 10:09:18 2013 +0200

    Revert "drm/i915: revert eDP bpp clamping code changes"

which started clamping bpp *before* computing the link requirements, and
thus affecting the required bandwidth. Clamping after the computations
kept the link at 2.7 GHz.

Even though the BIOS tells us to use 18 bpp through the VBT, it happily
boots up at 24 bpp and 2.7 GHz itself! Use this information to
selectively ignore the VBT provided value.

We can't ignore the VBT eDP bpp altogether, as there are other laptops
that do require the clamping to be used due to EDID reporting higher bpp
than the panel can support.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=59841
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67950
Tested-by: Ulf Winkelvos 
Tested-by: jkp 
Signed-off-by: Jani Nikula 
Signed-off-by: Daniel Vetter 
[Jani: stable 3.11 backport]
Signed-off-by: Greg Kroah-Hartman