lwn.git/drivers, branch v3.15.9

drm/i915: Ignore VBT backlight presence check on HP Chromebook 14

2014-08-07T23:53:53+00:00

commit 724cb06fa9b1e1ffd98188275543fdb3b8eaca4f upstream. commit c675949ec58ca50d5a3ae3c757892f1560f6e896 drm/i915: do not setup backlight if not available according to VBT caused a regression on the HP Chromebook 14 (with Celeron 2955U CPU), which has a misconfigured VBT. Apply quirk to ignore the VBT backlight presence check during backlight setup. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79813 Signed-off-by: Scot Doyle Tested-by: Stefan Nagy Cc: Jani Nikula Cc: Daniel Vetter Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman

staging: vt6655: Fix Warning on boot handle_irq_event_percpu.

2014-08-07T23:53:53+00:00

commit 6cff1f6ad4c615319c1a146b2aa0af1043c5e9f5 upstream. WARNING: CPU: 0 PID: 929 at /home/apw/COD/linux/kernel/irq/handle.c:147 handle_irq_event_percpu+0x1d1/0x1e0() irq 17 handler device_intr+0x0/0xa80 [vt6655_stage] enabled interrupts Using spin_lock_irqsave appears to fix this. Signed-off-by: Malcolm Priestley Signed-off-by: Greg Kroah-Hartman

dm cache: fix race affecting dirty block count

2014-08-07T23:53:52+00:00

commit 44fa816bb778edbab6b6ddaaf24908dd6295937e upstream. nr_dirty is updated without locking, causing it to drift so that it is non-zero (either a small positive integer, or a very large one when an underflow occurs) even when there are no actual dirty blocks. This was due to a race between the workqueue and map function accessing nr_dirty in parallel without proper protection. People were seeing under runs due to a race on increment/decrement of nr_dirty, see: https://lkml.org/lkml/2014/6/3/648 Fix this by using an atomic_t for nr_dirty. Reported-by: roma1390@gmail.com Signed-off-by: Anssi Hannula Signed-off-by: Joe Thornber Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman

dm bufio: fully initialize shrinker

2014-08-07T23:53:52+00:00

commit d8c712ea471ce7a4fd1734ad2211adf8469ddddc upstream. 1d3d4437eae1 ("vmscan: per-node deferred work") added a flags field to struct shrinker assuming that all shrinkers were zero filled. The dm bufio shrinker is not zero filled, which leaves arbitrary kmalloc() data in flags. So far the only defined flags bit is SHRINKER_NUMA_AWARE. But there are proposed patches which add other bits to shrinker.flags (e.g. memcg awareness). Rather than simply initializing the shrinker, this patch uses kzalloc() when allocating the dm_bufio_client to ensure that the embedded shrinker and any other similar structures are zeroed. This fixes theoretical over aggressive shrinking of dm bufio objects. If the uninitialized dm_bufio_client.shrinker.flags contains SHRINKER_NUMA_AWARE then shrink_slab() would call the dm shrinker for each numa node rather than just once. This has been broken since 3.12. Signed-off-by: Greg Thelen Acked-by: Mikulas Patocka Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman

iio: buffer: Fix demux table creation

2014-08-07T23:53:52+00:00

commit 61bd55ce1667809f022be88da77db17add90ea4e upstream. When creating the demux table we need to iterate over the selected scan mask for the buffer to get the samples which should be copied to destination buffer. Right now the code uses the mask which contains all active channels, which means the demux table contains entries which causes it to copy all the samples from source to destination buffer one by one without doing any demuxing. Signed-off-by: Lars-Peter Clausen Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman

iio:bma180: Missing check for frequency fractional part

2014-08-07T23:53:52+00:00

commit 9b2a4d35a6ceaf217be61ed8eb3c16986244f640 upstream. val2 should be zero This will make no difference for correct inputs but will reject incorrect ones with a decimal part in the value written to the sysfs interface. Signed-off-by: Peter Meerwald Cc: Oleksandr Kravchenko Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman

iio:bma180: Fix scale factors to report correct acceleration units

2014-08-07T23:53:52+00:00

commit 381676d5e86596b11e22a62f196e192df6091373 upstream. The userspace interface for acceleration sensors is documented as using m/s^2 units [Documentation/ABI/testing/sysfs-bus-iio] The fullscale raw values for the BMA80 corresponds to -/+ 1, 1.5, 2, etc G depending on the selected mode. The scale table was converting to G rather than m/s^2. Change the scaling table to match the documented interface. See commit 71702e6e, iio: mma8452: Use correct acceleration units, for a related fix. Signed-off-by: Peter Meerwald Cc: Oleksandr Kravchenko Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman

ACPI / PNP: Fix acpi_pnp_match()

2014-08-07T23:53:52+00:00

commit b6328a07bd6b3d31b64f85864fe74f3b08c010ca upstream. The acpi_pnp_match() function is used for finding the ACPI device object that should be associated with the given PNP device. Unfortunately, the check used by that function is not strict enough and may cause success to be returned for a wrong ACPI device object. To fix that, use the observation that the pointer to the ACPI device object in question is already stored in the data field in struct pnp_dev, so acpi_pnp_match() can simply use that field to do its job. This problem was uncovered in 3.14 by commit 202317a573b2 (ACPI / scan: Add acpi_device objects for all device nodes in the namespace). Fixes: 202317a573b2 (ACPI / scan: Add acpi_device objects for all device nodes in the namespace) Reported-and-tested-by: Vinson Lee Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

staging: vt6655: Fix disassociated messages every 10 seconds

2014-08-07T23:53:52+00:00

commit 4aa0abed3a2a11b7d71ad560c1a3e7631c5a31cd upstream. byReAssocCount is incremented every second resulting in disassociated message being send every 10 seconds whether connection or not. byReAssocCount should only advance while eCommandState is in WLAN_ASSOCIATE_WAIT Change existing scope to if condition. Signed-off-by: Malcolm Priestley Signed-off-by: Greg Kroah-Hartman

scsi: handle flush errors properly

2014-08-07T23:53:51+00:00

commit 89fb4cd1f717a871ef79fa7debbe840e3225cd54 upstream. Flush commands don't transfer data and thus need to be special cased in the I/O completion handler so that we can propagate errors to the block layer and filesystem. Signed-off-by: James Bottomley Reported-by: Steven Haber Tested-by: Steven Haber Reviewed-by: Martin K. Petersen Signed-off-by: Christoph Hellwig Signed-off-by: Greg Kroah-Hartman