linux-toradex.git/drivers, branch v4.1.26

Input: pwm-beeper - fix - scheduling while atomic

2016-06-06T23:12:35+00:00

[ Upstream commit f49cf3b8b4c841457244c461c66186a719e13bcc ]

Pwm config may sleep so defer it using a worker.

On a Freescale i.MX53 based board we ran into "BUG: scheduling while
atomic" because input_inject_event locks interrupts, but
imx_pwm_config_v2 sleeps.

Tested on Freescale i.MX53 SoC with 4.6.0.

Signed-off-by: Manfred Schlaegl 
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Sasha Levin

UBI: Fix static volume checks when Fastmap is used

2016-06-06T23:12:34+00:00

[ Upstream commit 1900149c835ab5b48bea31a823ea5e5a401fb560 ]

Ezequiel reported that he's facing UBI going into read-only
mode after power cut. It turned out that this behavior happens
only when updating a static volume is interrupted and Fastmap is
used.

A possible trace can look like:
ubi0 warning: ubi_io_read_vid_hdr [ubi]: no VID header found at PEB 2323, only 0xFF bytes
ubi0 warning: ubi_eba_read_leb [ubi]: switch to read-only mode
CPU: 0 PID: 833 Comm: ubiupdatevol Not tainted 4.6.0-rc2-ARCH #4
Hardware name: SAMSUNG ELECTRONICS CO., LTD. 300E4C/300E5C/300E7C/NP300E5C-AD8AR, BIOS P04RAP 10/15/2012
0000000000000286 00000000eba949bd ffff8800c45a7b38 ffffffff8140d841
ffff8801964be000 ffff88018eaa4800 ffff8800c45a7bb8 ffffffffa003abf6
ffffffff850e2ac0 8000000000000163 ffff8801850e2ac0 ffff8801850e2ac0
Call Trace:
[] dump_stack+0x63/0x82
[] ubi_eba_read_leb+0x486/0x4a0 [ubi]
[] ubi_check_volume+0x83/0xf0 [ubi]
[] ubi_open_volume+0x177/0x350 [ubi]
[] vol_cdev_open+0x58/0xb0 [ubi]
[] chrdev_open+0xae/0x1d0
[] do_dentry_open+0x1ff/0x300
[] ? cdev_put+0x30/0x30
[] vfs_open+0x56/0x60
[] path_openat+0x4f4/0x1190
[] do_filp_open+0x91/0x100
[] ? __alloc_fd+0xc7/0x190
[] do_sys_open+0x13f/0x210
[] SyS_open+0x1e/0x20
[] entry_SYSCALL_64_fastpath+0x1a/0xa4

UBI checks static volumes for data consistency and reads the
whole volume upon first open. If the volume is found erroneous
users of UBI cannot read from it, but another volume update is
possible to fix it. The check is performed by running
ubi_eba_read_leb() on every allocated LEB of the volume.
For static volumes ubi_eba_read_leb() computes the checksum of all
data stored in a LEB. To verify the computed checksum it has to read
the LEB's volume header which stores the original checksum.
If the volume header is not found UBI treats this as fatal internal
error and switches to RO mode. If the UBI device was attached via a
full scan the assumption is correct, the volume header has to be
present as it had to be there while scanning to get known as mapped.
If the attach operation happened via Fastmap the assumption is no
longer correct. When attaching via Fastmap UBI learns the mapping
table from Fastmap's snapshot of the system state and not via a full
scan. It can happen that a LEB got unmapped after a Fastmap was
written to the flash. Then UBI can learn the LEB still as mapped and
accessing it returns only 0xFF bytes. As UBI is not a FTL it is
allowed to have mappings to empty PEBs, it assumes that the layer
above takes care of LEB accounting and referencing.
UBIFS does so using the LEB property tree (LPT).
For static volumes UBI blindly assumes that all LEBs are present and
therefore special actions have to be taken.

The described situation can happen when updating a static volume is
interrupted, either by a user or a power cut.
The volume update code first unmaps all LEBs of a volume and then
writes LEB by LEB. If the sequence of operations is interrupted UBI
detects this either by the absence of LEBs, no volume header present
at scan time, or corrupted payload, detected via checksum.
In the Fastmap case the former method won't trigger as no scan
happened and UBI automatically thinks all LEBs are present.
Only by reading data from a LEB it detects that the volume header is
missing and incorrectly treats this as fatal error.
To deal with the situation ubi_eba_read_leb() from now on checks
whether we attached via Fastmap and handles the absence of a
volume header like a data corruption error.
This way interrupted static volume updates will correctly get detected
also when Fastmap is used.

Cc: 
Reported-by: Ezequiel Garcia 
Tested-by: Ezequiel Garcia 
Signed-off-by: Richard Weinberger 
Signed-off-by: Sasha Levin

xen/events: Don't move disabled irqs

2016-06-06T23:12:34+00:00

[ Upstream commit f0f393877c71ad227d36705d61d1e4062bc29cf5 ]

Commit ff1e22e7a638 ("xen/events: Mask a moving irq") open-coded
irq_move_irq() but left out checking if the IRQ is disabled. This broke
resuming from suspend since it tries to move a (disabled) irq without
holding the IRQ's desc->lock. Fix it by adding in a check for disabled
IRQs.

The resulting stacktrace was:
kernel BUG at /build/linux-UbQGH5/linux-4.4.0/kernel/irq/migration.c:31!
invalid opcode: 0000 [#1] SMP
Modules linked in: xenfs xen_privcmd ...
CPU: 0 PID: 9 Comm: migration/0 Not tainted 4.4.0-22-generic #39-Ubuntu
Hardware name: Xen HVM domU, BIOS 4.6.1-xs125180 05/04/2016
task: ffff88003d75ee00 ti: ffff88003d7bc000 task.ti: ffff88003d7bc000
RIP: 0010:[]  [] irq_move_masked_irq+0xd2/0xe0
RSP: 0018:ffff88003d7bfc50  EFLAGS: 00010046
RAX: 0000000000000000 RBX: ffff88003d40ba00 RCX: 0000000000000001
RDX: 0000000000000001 RSI: 0000000000000100 RDI: ffff88003d40bad8
RBP: ffff88003d7bfc68 R08: 0000000000000000 R09: ffff88003d000000
R10: 0000000000000000 R11: 000000000000023c R12: ffff88003d40bad0
R13: ffffffff81f3a4a0 R14: 0000000000000010 R15: 00000000ffffffff
FS:  0000000000000000(0000) GS:ffff88003da00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fd4264de624 CR3: 0000000037922000 CR4: 00000000003406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Stack:
 ffff88003d40ba38 0000000000000024 0000000000000000 ffff88003d7bfca0
 ffffffff814c8d92 00000010813ef89d 00000000805ea732 0000000000000009
 0000000000000024 ffff88003cc39b80 ffff88003d7bfce0 ffffffff814c8f66
Call Trace:
 [] eoi_pirq+0xb2/0xf0
 [] __startup_pirq+0xe6/0x150
 [] xen_irq_resume+0x319/0x360
 [] xen_suspend+0xb5/0x180
 [] multi_cpu_stop+0xb5/0xe0
 [] ? cpu_stop_queue_work+0x80/0x80
 [] cpu_stopper_thread+0xb0/0x140
 [] ? finish_task_switch+0x76/0x220
 [] ? __raw_callee_save___pv_queued_spin_unlock+0x11/0x20
 [] smpboot_thread_fn+0x105/0x160
 [] ? sort_range+0x30/0x30
 [] kthread+0xd8/0xf0
 [] ? kthread_create_on_node+0x1e0/0x1e0
 [] ret_from_fork+0x3f/0x70
 [] ? kthread_create_on_node+0x1e0/0x1e0

Signed-off-by: Ross Lagerwall 
Reviewed-by: Boris Ostrovsky 
Cc: 
Signed-off-by: David Vrabel 
Signed-off-by: Sasha Levin

mmc: sdhci-acpi: Remove MMC_CAP_BUS_WIDTH_TEST for Intel controllers

2016-06-06T23:12:33+00:00

[ Upstream commit 265984b36ce82fec67957d452dd2b22e010611e4 ]

The CMD19/CMD14 bus width test has been found to be unreliable in
some cases.  It is not essential, so simply remove it.

Signed-off-by: Adrian Hunter 
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson 
Signed-off-by: Sasha Levin

mmc: longer timeout for long read time quirk

2016-06-06T23:12:33+00:00

[ Upstream commit 32ecd320db39bcb007679ed42f283740641b81ea ]

008GE0 Toshiba mmc in some Intel Baytrail tablets responds to
MMC_SEND_EXT_CSD in 450-600ms.

This patch will...

() Increase the long read time quirk timeout from 300ms to 600ms. Original
   author of that quirk says 300ms was only a guess and that the number
   may need to be raised in the future.

() Add this specific MMC to the quirk

Signed-off-by: Matt Gumbel 
Signed-off-by: Adrian Hunter 
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson 
Signed-off-by: Sasha Levin

drm/i915: Don't leave old junk in ilk active watermarks on readout

2016-06-06T23:12:33+00:00

[ Upstream commit 7045c3689f148a0c95f42bae8ef3eb2829ac7de9 ]

When we read out the watermark state from the hardware we're supposed to
transfer that into the active watermarks, but currently we fail to any
part of the active watermarks that isn't explicitly written. Let's clear
it all upfront.

Looks like this has been like this since the beginning, when I added the
readout. No idea why I didn't clear it up.

Cc: Matt Roper 
Fixes: 243e6a44b9ca ("drm/i915: Init HSW watermark tracking in intel_modeset_setup_hw_state()")
Cc: stable@vger.kernel.org
Signed-off-by: Ville Syrjälä 
Reviewed-by: Matt Roper 
Signed-off-by: Matt Roper 
Link: http://patchwork.freedesktop.org/patch/msgid/1463151318-14719-2-git-send-email-ville.syrjala@linux.intel.com
(cherry picked from commit 15606534bf0a65d8a74a90fd57b8712d147dbca6)
Signed-off-by: Jani Nikula 
Signed-off-by: Sasha Levin

PM / sleep: Handle failures in device_suspend_late() consistently

2016-06-06T23:12:32+00:00

[ Upstream commit 3a17fb329da68cb00558721aff876a80bba2fdb9 ]

Grygorii Strashko reports:

 The PM runtime will be left disabled for the device if its
 .suspend_late() callback fails and async suspend is not allowed
 for this device. In this case device will not be added in
 dpm_late_early_list and dpm_resume_early() will ignore this
 device, as result PM runtime will be disabled for it forever
 (side effect: after 8 subsequent failures for the same device
 the PM runtime will be reenabled due to disable_depth overflow).

To fix this problem, add devices to dpm_late_early_list regardless
of whether or not device_suspend_late() returns errors for them.

That will ensure failures in there to be handled consistently for
all devices regardless of their async suspend/resume status.

Reported-by: Grygorii Strashko 
Tested-by: Grygorii Strashko 
Signed-off-by: Rafael J. Wysocki 
Cc: All applicable 
Signed-off-by: Sasha Levin

Input: uinput - handle compat ioctl for UI_SET_PHYS

2016-06-06T23:12:32+00:00

[ Upstream commit affa80bd97f7ca282d1faa91667b3ee9e4c590e6 ]

When running a 32-bit userspace on a 64-bit kernel, the UI_SET_PHYS
ioctl needs to be treated with special care, as it has the pointer
size encoded in the command.

Signed-off-by: Ricky Liang 
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Sasha Levin

cpuidle: Fix cpuidle_state_is_coupled() argument in cpuidle_enter()

2016-06-06T23:12:25+00:00

[ Upstream commit e7387da52028b072489c45efeb7a916c0205ebd2 ]

Commit 0b89e9aa2856 (cpuidle: delay enabling interrupts until all
coupled CPUs leave idle) rightfully fixed a regression by letting
the coupled idle state framework to handle local interrupt enabling
when the CPU is exiting an idle state.

The current code checks if the idle state is coupled and, if so, it
will let the coupled code to enable interrupts. This way, it can
decrement the ready-count before handling the interrupt. This
mechanism prevents the other CPUs from waiting for a CPU which is
handling interrupts.

But the check is done against the state index returned by the back
end driver's ->enter functions which could be different from the
initial index passed as parameter to the cpuidle_enter_state()
function.

 entered_state = target_state->enter(dev, drv, index);

 [ ... ]

 if (!cpuidle_state_is_coupled(drv, entered_state))
	local_irq_enable();

 [ ... ]

If the 'index' is referring to a coupled idle state but the
'entered_state' is *not* coupled, then the interrupts are enabled
again. All CPUs blocked on the sync barrier may busy loop longer
if the CPU has interrupts to handle before decrementing the
ready-count. That's consuming more energy than saving.

Fixes: 0b89e9aa2856 (cpuidle: delay enabling interrupts until all coupled CPUs leave idle)
Signed-off-by: Daniel Lezcano 
Cc: 3.15+  # 3.15+
[ rjw: Subject & changelog ]
Signed-off-by: Rafael J. Wysocki 

Signed-off-by: Sasha Levin

cpuidle/coupled: Remove redundant 'dev' argument of cpuidle_state_is_coupled()

2016-06-06T23:12:25+00:00

[ Upstream commit 4c1ed5a6079078699128064664913ae7b079648f ]

For cpuidle_state_is_coupled(), 'dev' is not used, so remove it.

Signed-off-by: Xunlei Pang 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Sasha Levin