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

media: vb2: fix VBI/poll regression

2014-10-09T19:23:49+00:00

commit 58d75f4b1ce26324b4d809b18f94819843a98731 upstream.

The recent conversion of saa7134 to vb2 unconvered a poll() bug that
broke the teletext applications alevt and mtt. These applications
expect that calling poll() without having called VIDIOC_STREAMON will
cause poll() to return POLLERR. That did not happen in vb2.

This patch fixes that behavior. It also fixes what should happen when
poll() is called when STREAMON is called but no buffers have been
queued. In that case poll() will also return POLLERR, but only for
capture queues since output queues will always return POLLOUT
anyway in that situation.

This brings the vb2 behavior in line with the old videobuf behavior.

Signed-off-by: Hans Verkuil 
Acked-by: Laurent Pinchart 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman

vgaarb: Don't default exclusively to first video device with mem+io

2014-10-09T19:23:49+00:00

commit 86fd887b7fe350819dae5b55e7fef05b511c8656 upstream.

Commit 20cde694027e ("x86, ia64: Move EFI_FB vga_default_device()
initialization to pci_vga_fixup()") moved boot video device detection from
efifb to x86 and ia64 pci/fixup.c.

For dual-GPU Apple computers above change represents a regression as code
in efifb did forcefully override vga_default_device while the merge did not
(vgaarb happens prior to PCI fixup).

To improve on initial device selection by vgaarb (it cannot know if PCI
device not behind bridges see/decode legacy VGA I/O or not), move the
screen_info based check from pci_video_fixup() to vgaarb's init function and
use it to refine/override decision taken while adding the individual PCI
VGA devices.  This way PCI fixup has no reason to adjust vga_default_device
anymore but can depend on its value for flagging shadowed VBIOS.

This has the nice benefit of removing duplicated code but does introduce a
#if defined() block in vgaarb.  Not all architectures have screen_info and
would cause compile to fail without it.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=84461
Reported-and-Tested-By: Andreas Noever 
Signed-off-by: Bruno Prémont 
Signed-off-by: Bjorn Helgaas 
CC: Matthew Garrett 
Signed-off-by: Greg Kroah-Hartman

x86, ia64: Move EFI_FB vga_default_device() initialization to pci_vga_fixup()

2014-10-09T19:23:49+00:00

commit 20cde694027e7477cc532833e38ab9fcaa83fb64 upstream.

Commit b4aa0163056b ("efifb: Implement vga_default_device() (v2)") added
efifb vga_default_device() so EFI systems that do not load shadow VBIOS or
setup VGA get proper value for boot_vga PCI sysfs attribute on the
corresponding PCI device.

Xorg doesn't detect devices when boot_vga=0, e.g., on some EFI systems such
as MacBookAir2,1.  Xorg detects the GPU and finds the DRI device but then
bails out with "no devices detected".

Note: When vga_default_device() is set boot_vga PCI sysfs attribute
reflects its state.  When unset this attribute is 1 whenever
IORESOURCE_ROM_SHADOW flag is set.

With introduction of sysfb/simplefb/simpledrm efifb is getting obsolete
while having native drivers for the GPU also makes selecting sysfb/efifb
optional.

Remove the efifb implementation of vga_default_device() and initialize
vgaarb's vga_default_device() with the PCI GPU that matches boot
screen_info in pci_fixup_video().

[bhelgaas: remove unused "dev" in efifb_setup()]
Fixes: b4aa0163056b ("efifb: Implement vga_default_device() (v2)")
Tested-by: Anibal Francisco Martinez Cortina 
Signed-off-by: Bruno Prémont 
Signed-off-by: Bjorn Helgaas 
Acked-by: Matthew Garrett 
Signed-off-by: Greg Kroah-Hartman

uas: Add missing le16_to_cpu calls to asm1051 / asm1053 usb-id check

2014-10-09T19:23:49+00:00

commit a79e5bc53a9519202dfad7d916761601fcbf8db1 upstream.

Reported-by: kbuild test robot 
Signed-off-by: Hans de Goede 
Signed-off-by: Greg Kroah-Hartman

uas: Disable uas on ASM1051 devices

2014-10-09T19:23:49+00:00

commit a9c54caa456dccba938005f6479892b589975e6a upstream.

There are a large numbers of issues with ASM1051 devices in uas mode:

1) They do not support REPORT SUPPORTED OPERATION CODES

2) They use out of spec 8 byte status iu-s when they have no sense data,
   switching to normal 16 byte status iu-s when they do have sense data.

3) They hang / crash when combined with some disks, e.g. a Crucial M500 ssd.

4) They hang / crash when stressed (through e.g. sg_reset --bus) with disks
   with which then normally do work (once 1 & 2 are worked around).

Where as in BOT mode they appear to work fine, so the best way forward with
these devices is to just blacklist them for uas usage.

Unfortunately this is easier said then done. as older versions of the ASM1053
(which works fine) use the same usb-id as the ASM1051.

When connected over USB-3 the 2 can be told apart by the number of streams
they support. So this patch adds some less then pretty code to disable uas for
the ASM1051. When connected over USB-2, simply disable uas alltogether for
devices with the shared usb-id.

Cc: stable@vger.kernel.org # 3.16
Signed-off-by: Hans de Goede 
Signed-off-by: Greg Kroah-Hartman

uas: Log a warning when we cannot use uas because the hcd lacks streams

2014-10-09T19:23:49+00:00

commit 43508be512661c905d0320ee73e0b65ef36d2459 upstream.

So that an user who wants to use uas can see why he is not getting uas.

Also move the check down so that we don't warn if there are other reasons
why uas cannot work.

Signed-off-by: Hans de Goede 
Signed-off-by: Greg Kroah-Hartman

uas: Only complain about missing sg if all other checks succeed

2014-10-09T19:23:49+00:00

commit cc4deafc86f75f4e716b37fb4ea3572eb1e49e50 upstream.

Don't complain about controllers without sg support if there are other
reasons why uas cannot be used anyways.

Signed-off-by: Hans de Goede 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Flush the PTEs after updating them before suspend

2014-10-09T19:23:48+00:00

commit 91e56499304f3d612053a9cf17f350868182c7d8 upstream.

As we use WC updates of the PTE, we are responsible for notifying the
hardware when to flush its TLBs. Do so after we zap all the PTEs before
suspend (and the BIOS tries to read our GTT).

Fixes a regression from

commit 828c79087cec61eaf4c76bb32c222fbe35ac3930
Author: Ben Widawsky 
Date:   Wed Oct 16 09:21:30 2013 -0700

    drm/i915: Disable GGTT PTEs on GEN6+ suspend

that survived and continue to cause harm even after

commit e568af1c626031925465a5caaab7cca1303d55c7
Author: Daniel Vetter 
Date:   Wed Mar 26 20:08:20 2014 +0100

    drm/i915: Undo gtt scratch pte unmapping again

v2: Trivial rebase.
v3: Fixes requires pointer dances.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82340
Tested-by: ming.yao@intel.com
Signed-off-by: Chris Wilson 
Cc: Takashi Iwai 
Cc: Paulo Zanoni 
Cc: Todd Previte 
Cc: Daniel Vetter 
Reviewed-by: Daniel Vetter 
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

md/raid5: disable 'DISCARD' by default due to safety concerns.

2014-10-09T19:23:48+00:00

commit 8e0e99ba64c7ba46133a7c8a3e3f7de01f23bd93 upstream.

It has come to my attention (thanks Martin) that 'discard_zeroes_data'
is only a hint.  Some devices in some cases don't do what it
says on the label.

The use of DISCARD in RAID5 depends on reads from discarded regions
being predictably zero.  If a write to a previously discarded region
performs a read-modify-write cycle it assumes that the parity block
was consistent with the data blocks.  If all were zero, this would
be the case.  If some are and some aren't this would not be the case.
This could lead to data corruption after a device failure when
data needs to be reconstructed from the parity.

As we cannot trust 'discard_zeroes_data', ignore it by default
and so disallow DISCARD on all raid4/5/6 arrays.

As many devices are trustworthy, and as there are benefits to using
DISCARD, add a module parameter to over-ride this caution and cause
DISCARD to work if discard_zeroes_data is set.

If a site want to enable DISCARD on some arrays but not on others they
should select DISCARD support at the filesystem level, and set the
raid456 module parameter.
    raid456.devices_handle_discard_safely=Y

As this is a data-safety issue, I believe this patch is suitable for
-stable.
DISCARD support for RAID456 was added in 3.7

Cc: Shaohua Li 
Cc: "Martin K. Petersen" 
Cc: Mike Snitzer 
Cc: Heinz Mauelshagen 
Acked-by: Martin K. Petersen 
Acked-by: Mike Snitzer 
Fixes: 620125f2bf8ff0c4969b79653b54d7bcc9d40637
Signed-off-by: NeilBrown 
Signed-off-by: Greg Kroah-Hartman

cpufreq: pcc-cpufreq: Fix wait_event() under spinlock

2014-10-09T19:23:48+00:00

commit e65b5ddba84634f31d42dfd86013f4c6be5e9e32 upstream.

Fix the following bug introduced by commit 8fec051eea73 (cpufreq:
Convert existing drivers to use cpufreq_freq_transition_{begin|end})
that forgot to move the spin_lock() in pcc_cpufreq_target() past
cpufreq_freq_transition_begin() which calls wait_event():

BUG: sleeping function called from invalid context at drivers/cpufreq/cpufreq.c:370
in_atomic(): 1, irqs_disabled(): 0, pid: 2636, name: modprobe
Preemption disabled at:[] pcc_cpufreq_target+0x27/0x200 [pcc_cpufreq]
[   51.025044]
CPU: 57 PID: 2636 Comm: modprobe Tainted: G            E  3.17.0-default #7
Hardware name: Hewlett-Packard ProLiant DL980 G7, BIOS P66 07/07/2010
 00000000ffffffff ffff88026c46b828 ffffffff81589dbd 0000000000000000
 ffff880037978090 ffff88026c46b848 ffffffff8108e1df ffff880037978090
 0000000000000000 ffff88026c46b878 ffffffff8108e298 ffff88026d73ec00
Call Trace:
 [] dump_stack+0x4d/0x90
 [] ___might_sleep+0x10f/0x180
 [] __might_sleep+0x48/0xd0
 [] cpufreq_freq_transition_begin+0x75/0x140 drivers/cpufreq/cpufreq.c:370 wait_event(policy->transition_wait, !policy->transition_ongoing);
 [] ? preempt_count_add+0xb9/0xc0
 [] pcc_cpufreq_target+0x63/0x200 [pcc_cpufreq] drivers/cpufreq/pcc-cpufreq.c:207 spin_lock(&pcc_lock);
 [] ? update_ts_time_stats+0x7f/0xb0
 [] __cpufreq_driver_target+0x85/0x170
 [] od_check_cpu+0xa8/0xb0
 [] dbs_check_cpu+0x180/0x1d0
 [] cpufreq_governor_dbs+0x3b0/0x720
 [] od_cpufreq_governor_dbs+0x33/0xe0
 [] __cpufreq_governor+0xa9/0x210
 [] cpufreq_set_policy+0x1e2/0x2e0
 [] cpufreq_init_policy+0x8c/0x110
 [] ? cpufreq_update_policy+0x1b0/0x1b0
 [] ? preempt_count_sub+0xb9/0x100
 [] __cpufreq_add_dev+0x596/0x6b0
 [] ? pcc_cpufreq_probe+0x4b4/0x4b4 [pcc_cpufreq]
 [] cpufreq_add_dev+0xe/0x10
 [] subsys_interface_register+0xc1/0xf0
 [] ? preempt_count_sub+0xb9/0x100
 [] cpufreq_register_driver+0x117/0x2a0
 [] pcc_cpufreq_init+0x55/0x9f8 [pcc_cpufreq]
 [] ? pcc_cpufreq_probe+0x4b4/0x4b4 [pcc_cpufreq]
 [] do_one_initcall+0xc8/0x1f0
 [] ? __vunmap+0x9d/0x100
 [] do_init_module+0x30/0x1b0
 [] load_module+0x686/0x710
 [] ? do_init_module+0x1b0/0x1b0
 [] SyS_init_module+0x9b/0xc0
 [] system_call_fastpath+0x16/0x1b

Fixes: 8fec051eea73 (cpufreq: Convert existing drivers to use cpufreq_freq_transition_{begin|end})
Reported-and-tested-by: Mike Galbraith 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman