user/sven/linux.git/drivers, branch v3.14.16

cpufreq: move policy kobj to policy->cpu at resume

2014-08-07T21:52:38Z

commit 92c14bd9477a20a83144f08c0ca25b0308bf0730 upstream. This is only relevant to implementations with multiple clusters, where clusters have separate clock lines but all CPUs within a cluster share it. Consider a dual cluster platform with 2 cores per cluster. During suspend we start hot unplugging CPUs in order 1 to 3. When CPU2 is removed, policy->kobj would be moved to CPU3 and when CPU3 goes down we wouldn't free policy or its kobj as we want to retain permissions/values/etc. Now on resume, we will get CPU2 before CPU3 and will call __cpufreq_add_dev(). We will recover the old policy and update policy->cpu from 3 to 2 from update_policy_cpu(). But the kobj is still tied to CPU3 and isn't moved to CPU2. We wouldn't create a link for CPU2, but would try that for CPU3 while bringing it online. Which will report errors as CPU3 already has kobj assigned to it. This bug got introduced with commit 42f921a, which overlooked this scenario. To fix this, lets move kobj to the new policy->cpu while bringing first CPU of a cluster back. Also do a WARN_ON() if kobject_move failed, as we would reach here only for the first CPU of a non-boot cluster. And we can't recover from this situation, if kobject_move() fails. Fixes: 42f921a6f10c (cpufreq: remove sysfs files for CPUs which failed to come back after resume) Cc: 3.13+ # 3.13+ Reported-and-tested-by: Bu Yitian Reported-by: Saravana Kannan Reviewed-by: Srivatsa S. Bhat Signed-off-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

staging: vt6655: Fix Warning on boot handle_irq_event_percpu.

2014-08-07T21:52:38Z

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-07T21:52:37Z

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-07T21:52:37Z

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-07T21:52:37Z

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-07T21:52:37Z

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-07T21:52:37Z

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-07T21:52:37Z

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-07T21:52:37Z

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-07T21:52:37Z

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