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

samsung-laptop: Add use_native_backlight quirk, and enable it on some models

2015-03-06T22:53:05+00:00

commit 4690555e13c48fef07f2762f6b0cd6b181e326d0 upstream.

Since kernel 3.14 the backlight control has been broken on various Samsung
Atom based netbooks. This has been bisected and this problem happens since
commit b35684b8fa94 ("drm/i915: do full backlight setup at enable time")

This has been reported and discussed in detail here:
http://lists.freedesktop.org/archives/intel-gfx/2014-July/049395.html

Unfortunately no-one has been able to fix this. This only affects Samsung
Atom netbooks, and the Linux kernel and the BIOS of those laptops have never
worked well together. All affected laptops already have a quirk to avoid using
the standard acpi-video interface and instead use the samsung specific SABI
interface which samsung-laptop uses. It seems that recent fixes to the i915
driver have also broken backlight control through the SABI interface.

The intel_backlight driver OTOH works fine, and also allows for finer grained
backlight control. So add a new use_native_backlight quirk, and replace the
broken_acpi_video quirk with this quirk for affected models. This new quirk
disables acpi-video as before and also stops samsung-laptop from registering
the SABI based samsung_laptop backlight interface, leaving only the working
intel_backlight interface.

This commit enables this new quirk for 3 models which are known to be affected,
chances are that it needs to be used on other models too.

BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1094948 # N145P
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1115713 # N250P
Reported-by: Bertrik Sikken  # N150P
Cc: stable@vger.kernel.org # 3.16
Signed-off-by: Hans de Goede 
Signed-off-by: Darren Hart 
Signed-off-by: Greg Kroah-Hartman

EDAC, amd64_edac: Prevent OOPS with >16 memory controllers

2015-03-06T22:53:05+00:00

commit 0c510cc83bdbaac8406f4f7caef34f4da0ba35ea upstream.

When DRAM errors occur on memory controllers after EDAC_MAX_MCS (16),
the kernel fatally dereferences unallocated structures, see splat below;
this occurs on at least NumaConnect systems.

Fix by checking if a memory controller info structure was found.

BUG: unable to handle kernel NULL pointer dereference at 0000000000000320
IP: [] decode_bus_error+0x2f/0x2b0
PGD 2f8b5a3067 PUD 2f8b5a2067 PMD 0
Oops: 0000 [#2] SMP
Modules linked in:
CPU: 224 PID: 11930 Comm: stream_c.exe.gn Tainted: G   D    3.19.0 #1
Hardware name: Supermicro H8QGL/H8QGL, BIOS 3.5b    01/28/2015
task: ffff8807dbfb8c00 ti: ffff8807dd16c000 task.ti: ffff8807dd16c000
RIP: 0010:[] [] decode_bus_error+0x2f/0x2b0
RSP: 0000:ffff8907dfc03c48 EFLAGS: 00010297
RAX: 0000000000000001 RBX: 9c67400010080a13 RCX: 0000000000001dc6
RDX: 000000001dc61dc6 RSI: ffff8907dfc03df0 RDI: 000000000000001c
RBP: ffff8907dfc03ce8 R08: 0000000000000000 R09: 0000000000000022
R10: ffff891fffa30380 R11: 00000000001cfc90 R12: 0000000000000008
R13: 0000000000000000 R14: 000000000000001c R15: 00009c6740001000
FS: 00007fa97ee18700(0000) GS:ffff8907dfc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000320 CR3: 0000003f889b8000 CR4: 00000000000407e0
Stack:
 0000000000000000 ffff8907dfc03df0 0000000000000008 9c67400010080a13
 000000000000001c 00009c6740001000 ffff8907dfc03c88 ffffffff810e4f9a
 ffff8907dfc03ce8 ffffffff81b375b9 0000000000000000 0000000000000010
Call Trace:
 
 ? vprintk_default
 ? printk
 amd_decode_mce
 notifier_call_chain
 atomic_notifier_call_chain
 mce_log
 machine_check_poll
 mce_timer_fn
 ? mce_cpu_restart
 call_timer_fn.isra.29
 run_timer_softirq
 __do_softirq
 irq_exit
 smp_apic_timer_interrupt
 apic_timer_interrupt
 
 ? down_read_trylock
 __do_page_fault
 ? __schedule
 do_page_fault
 page_fault

Signed-off-by: Daniel J Blueman 
Link: http://lkml.kernel.org/r/1424144078-24589-1-git-send-email-daniel@numascale.com
[ Boris: massage commit message ]
Signed-off-by: Borislav Petkov 
Signed-off-by: Greg Kroah-Hartman

sb_edac: Fix detection on SNB machines

2015-03-06T22:53:05+00:00

commit 11249e73992981e31fd50e7231da24fad68e3320 upstream.

d0585cd815fa ("sb_edac: Claim a different PCI device") changed the
probing of sb_edac to look for PCI device 0x3ca0:

3f:0e.0 System peripheral: Intel Corporation Xeon E5/Core i7 Processor Home Agent (rev 07)
00: 86 80 a0 3c 00 00 00 00 07 00 80 08 00 00 80 00
...

but we're matching for 0x3ca8, i.e. PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_TA
in sbridge_probe() therefore the probing fails.

Changing it to probe for 0x3ca0 (PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_HA0),
.i.e., the 14.0 device, fixes the issue and driver loads successfully
again:

[ 2449.013120] EDAC DEBUG: sbridge_init:
[ 2449.017029] EDAC sbridge: Seeking for: PCI ID 8086:3ca0
[ 2449.022368] EDAC DEBUG: sbridge_get_onedevice: Detected 8086:3ca0
[ 2449.028498] EDAC sbridge: Seeking for: PCI ID 8086:3ca0
[ 2449.033768] EDAC sbridge: Seeking for: PCI ID 8086:3ca8
[ 2449.039028] EDAC DEBUG: sbridge_get_onedevice: Detected 8086:3ca8
[ 2449.045155] EDAC sbridge: Seeking for: PCI ID 8086:3ca8
...

Add a debug printk while at it to be able to catch the failure in the
future and dump driver version on successful load.

Fixes: d0585cd815fa ("sb_edac: Claim a different PCI device")
Acked-by: Aristeu Rozanski 
Cc: Tony Luck 
Acked-by: Andy Lutomirski 
Acked-by: Mauro Carvalho Chehab 
Signed-off-by: Borislav Petkov 
Signed-off-by: Greg Kroah-Hartman

md/raid1: fix read balance when a drive is write-mostly.

2015-03-06T22:53:05+00:00

commit d1901ef099c38afd11add4cfb3312c02ef21ec4a upstream.

When a drive is marked write-mostly it should only be the
target of reads if there is no other option.

This behaviour was broken by

commit 9dedf60313fa4dddfd5b9b226a0ef12a512bf9dc
    md/raid1: read balance chooses idlest disk for SSD

which causes a write-mostly device to be *preferred* is some cases.

Restore correct behaviour by checking and setting
best_dist_disk and best_pending_disk rather than best_disk.

We only need to test one of these as they are both changed
from -1 or >=0 at the same time.

As we leave min_pending and best_dist unchanged, any non-write-mostly
device will appear better than the write-mostly device.

Reported-by: Tomáš Hodek 
Reported-by: Dark Penguin 
Signed-off-by: NeilBrown 
Link: http://marc.info/?l=linux-raid&m=135982797322422
Fixes: 9dedf60313fa4dddfd5b9b226a0ef12a512bf9dc
Signed-off-by: Greg Kroah-Hartman

md/raid5: Fix livelock when array is both resyncing and degraded.

2015-03-06T22:53:04+00:00

commit 26ac107378c4742978216be1005b7291b799c7b2 upstream.

Commit a7854487cd7128a30a7f4f5259de9f67d5efb95f:
  md: When RAID5 is dirty, force reconstruct-write instead of read-modify-write.

Causes an RCW cycle to be forced even when the array is degraded.
A degraded array cannot support RCW as that requires reading all data
blocks, and one may be missing.

Forcing an RCW when it is not possible causes a live-lock and the code
spins, repeatedly deciding to do something that cannot succeed.

So change the condition to only force RCW on non-degraded arrays.

Reported-by: Manibalan P 
Bisected-by: Jes Sorensen 
Tested-by: Jes Sorensen 
Signed-off-by: NeilBrown 
Fixes: a7854487cd7128a30a7f4f5259de9f67d5efb95f
Signed-off-by: Greg Kroah-Hartman

clocksource: mtk: Fix race conditions in probe code

2015-03-06T22:53:04+00:00

commit d4a19eb3b15a4ba98f627182f48d5bc0cffae670 upstream.

We have two race conditions in the probe code which could lead to a null
pointer dereference in the interrupt handler.

The interrupt handler accesses the clockevent device, which may not yet be
registered.

First race condition happens when the interrupt handler gets registered before
the interrupts get disabled. The second race condition happens when the
interrupts get enabled, but the clockevent device is not yet registered.

Fix that by disabling the interrupts before we register the interrupt and enable
the interrupts after the clockevent device got registered.

Reported-by: Gongbae Park 
Signed-off-by: Matthias Brugger 
Signed-off-by: Daniel Lezcano 
Signed-off-by: Greg Kroah-Hartman

gpio: tps65912: fix wrong container_of arguments

2015-03-06T22:53:03+00:00

commit 2f97c20e5f7c3582c7310f65a04465bfb0fd0e85 upstream.

The gpio_chip operations receive a pointer the gpio_chip struct which is
contained in the driver's private struct, yet the container_of call in those
functions point to the mfd struct defined in include/linux/mfd/tps65912.h.

Signed-off-by: Nicolas Saenz Julienne 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman

gpiolib: of: allow of_gpiochip_find_and_xlate to find more than one chip per node

2015-03-06T22:53:03+00:00

commit 9cf75e9e4ddd587ac12e88e8751c358b7b27e95f upstream.

The change:

7b8792bbdffdff3abda704f89c6a45ea97afdc62
gpiolib: of: Correct error handling in of_get_named_gpiod_flags

assumed that only one gpio-chip is registred per of-node.
Some drivers register more than one chip per of-node, so
adjust the matching function of_gpiochip_find_and_xlate to
not stop looking for chips if a node-match is found and
the translation fails.

Fixes: 7b8792bbdffd ("gpiolib: of: Correct error handling in of_get_named_gpiod_flags")
Signed-off-by: Hans Holmberg 
Acked-by: Alexandre Courbot 
Tested-by: Robert Jarzmik 
Tested-by: Tyler Hall 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman

serial: fsl_lpuart: avoid new transfer while DMA is running

2015-03-06T22:53:01+00:00

commit 5f1437f61a0b351d25b528c159360da3d5e8c77b upstream.

When the UART is in DMA receive mode (RDMAS set) and one character
just arrived while another interrupt is handled (e.g. TX), the RDRF
(receiver data register full flag) is set due to the water level of
1. But since the DMA will take care of this character, there is no
need to handle it by calling lpuart_prepare_rx. Handling it leads to
adding the RX timeout timer twice:

[   74.336698] Kernel BUG at 80053070 [verbose debug info unavailable]
[   74.342999] Internal error: Oops - BUG: 0 [#1] ARM0:00.00 khungtaskd
[   74.347817] Modules linked in:    0 S  0.0  0.0   0:00.00 writeback
[   74.350926] CPU: 0 PID: 0 Comm: swapper Not tainted 3.19.0-rc3-00001-g39d78e2 #1788
[   74.358617] Hardware name: Freescale Vybrid VF610 (Device Tree)t
[   74.364563] task: 807a7678 ti: 8079c000 task.ti: 8079c000 kblockd
[   74.370002] PC is at add_timer+0x24/0x28.0  0.0   0:00.09 kworker/u2:1
[   74.373960] LR is at lpuart_int+0x15c/0x3d8
[   74.378171] pc : [<80053070>]    lr : [<802e0d88>]    psr: a0010193
[   74.378171] sp : 8079de10  ip : 8079de20  fp : 8079de1c
[   74.389694] r10: 807d44c0  r9 : 8688c300  r8 : 00000013
[   74.394943] r7 : 20010193  r6 : 00000000  r5 : 000000a0  r4 : 86997210
[   74.401498] r3 : ffffa7da  r2 : 80817868  r1 : 86997210  r0 : 86997344
[   74.408052] Flags: NzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
[   74.415489] Control: 10c5387d  Table: 8611c059  DAC: 00000015
[   74.421265] Process swapper (pid: 0, stack limit = 0x8079c230)
...

Solve this by only execute the receiver path (lpuart_prepare_rx) if
the DMA receive mode (RDMAS) is not set. Also, make sure the flag is
cleared on initialization, in case it has been left set.

This can be best reproduced using UART as a serial console, then
running top while dd'ing data into the terminal.

Signed-off-by: Stefan Agner 
Signed-off-by: Greg Kroah-Hartman

serial: fsl_lpuart: delete timer on shutdown

2015-03-06T22:53:01+00:00

commit 4a8588a1cf867333187d9ff071e6fbdab587d194 upstream.

If the serial port gets closed while a RX transfer is in progress,
the timer might fire after the serial port shutdown finished. This
leads in a NULL pointer dereference:

[    7.508324] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[    7.516590] pgd = 86348000
[    7.519445] [00000000] *pgd=86179831, *pte=00000000, *ppte=00000000
[    7.526145] Internal error: Oops: 17 [#1] ARM
[    7.530611] Modules linked in:
[    7.533876] CPU: 0 PID: 123 Comm: systemd Not tainted 3.19.0-rc3-00004-g5b11ea7 #1778
[    7.541827] Hardware name: Freescale Vybrid VF610 (Device Tree)
[    7.547862] task: 861c3400 ti: 86ac8000 task.ti: 86ac8000
[    7.553392] PC is at lpuart_timer_func+0x24/0xf8
[    7.558127] LR is at lpuart_timer_func+0x20/0xf8
[    7.562857] pc : [<802df99c>]    lr : [<802df998>]    psr: 600b0113
[    7.562857] sp : 86ac9b90  ip : 86ac9b90  fp : 86ac9bbc
[    7.574467] r10: 80817180  r9 : 80817b98  r8 : 80817998
[    7.579803] r7 : 807acee0  r6 : 86989000  r5 : 00000100  r4 : 86997210
[    7.586444] r3 : 86ac8000  r2 : 86ac9bc0  r1 : 86997210  r0 : 00000000
[    7.593085] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
[    7.600341] Control: 10c5387d  Table: 86348059  DAC: 00000015
[    7.606203] Process systemd (pid: 123, stack limit = 0x86ac8230)

Setup the timer on UART startup which allows to delete the timer
unconditionally on shutdown. This also saves the initialization
on each transfer.

Signed-off-by: Stefan Agner 
Signed-off-by: Greg Kroah-Hartman