linux/drivers/base, branch v4.3

mm: cma: fix incorrect type conversion for size during dma allocation

2015-10-23T08:55:10Z

This was found during userspace fuzzing test when a large size dma cma allocation is made by driver(like ion) through userspace. show_stack+0x10/0x1c dump_stack+0x74/0xc8 kasan_report_error+0x2b0/0x408 kasan_report+0x34/0x40 __asan_storeN+0x15c/0x168 memset+0x20/0x44 __dma_alloc_coherent+0x114/0x18c Signed-off-by: Rohit Vaswani Acked-by: Greg Kroah-Hartman Cc: Marek Szyprowski Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

PM / Domains: Fix validation of latency constraints in genpd governor

2015-10-14T00:34:43Z

Commit ba2bbfbf6307 (PM / Domains: Remove intermediate states from the power off sequence) changed the power off sequence in genpd. That also required some updates regarding the validation of latency constraints in the genpd governor. Unfortunate that wasn't covered, so let's fix this. From a runtime PM and latency point of view, we need to consider the worst case scenario while validating latency constraints. That's typically when a call to pm_runtime_get_sync() needs to wait for a ongoing runtime suspend operation to be carried out, as it then also needs to wait for the device to be runtime resumed again. The above mentioned commit made the genpd governor's ->stop_ok() callback responsible of validating genpd's device's runtime suspend/resume latency. In other words, the constraint needs to be validated towards the relevant latencies present in genpd's ->runtime_suspend|resume() callbacks. Earlier, that included latencies from the ->stop|start() callbacks, but as ->save|restore_state() are now also being invoked from genpd's ->runtime_suspend|resume() and to comply with the worst case scenario, let's take also those latencies into account. Fixes: ba2bbfbf6307 (PM / Domains: Remove intermediate states from the power off sequence) Signed-off-by: Ulf Hansson Signed-off-by: Rafael J. Wysocki

Merge tag 'regmap-fix-v4.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap

2015-10-07T13:15:49Z

Pull regmap fixes from Mark Brown: "A couple of fixes for the debugfs information on the register map, fixing issues with very small reads potentially causing underflows and wraparounds" * tag 'regmap-fix-v4.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap: regmap: debugfs: Don't bother actually printing when calculating max length regmap: debugfs: Ensure we don't underflow when printing access masks

Merge branches 'pm-cpuidle', 'pm-opp' and 'pm-tools'

2015-10-01T20:30:47Z

* pm-cpuidle: intel_idle: Skylake Client Support - updated * pm-opp: PM / OPP: Fix typo modifcation -> modification PM / OPP: of_property_count_u32_elems() can return errors * pm-tools: tools/power turbosat: update version number tools/power turbostat: SKL: Adjust for TSC difference from base frequency tools/power turbostat: KNL workaround for %Busy and Avg_MHz tools/power turbostat: IVB Xeon: fix --debug regression

Merge tag 'driver-core-4.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core

2015-09-27T00:54:53Z

Pull driver core fix from Greg KH: "Here is one driver core fix for 4.3-rc3 that resolves a reported oops" * tag 'driver-core-4.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: cpu/cacheinfo: Fix teardown path

PM / OPP: Fix typo modifcation -> modification

2015-09-25T21:09:57Z

Reported-by: Viresh Kumar Signed-off-by: Stephen Boyd Acked-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki

PM / OPP: of_property_count_u32_elems() can return errors

2015-09-25T00:35:54Z

of_property_count_u32_elems() will never return 0, but a -ve error value of a positive count. And so the current !count check is wrong. Also, a missing "opp-microvolt" property isn't a problem and so we need to do of_find_property() separately to confirm that. Fixes: 274659029c9d (PM / OPP: Add support to parse "operating-points-v2" bindings) Signed-off-by: Viresh Kumar Reviewed-by: Stephen Boyd Signed-off-by: Rafael J. Wysocki

regmap: debugfs: Don't bother actually printing when calculating max length

2015-09-19T14:38:12Z

The in kernel snprintf() will conveniently return the actual length of the printed string even if not given an output beffer at all so just do that rather than relying on the user to pass in a suitable buffer, ensuring that we don't need to worry if the buffer was truncated due to the size of the buffer passed in. Reported-by: Rasmus Villemoes Signed-off-by: Mark Brown Cc: stable@vger.kernel.org

regmap: debugfs: Ensure we don't underflow when printing access masks

2015-09-19T14:38:11Z

If a read is attempted which is smaller than the line length then we may underflow the subtraction we're doing with the unsigned size_t type so move some of the calculation to be additions on the right hand side instead in order to avoid this. Reported-by: Rasmus Villemoes Signed-off-by: Mark Brown Cc: stable@vger.kernel.org

cpu/cacheinfo: Fix teardown path

2015-09-17T13:06:54Z

Philip Müller reported a hang when booting 32-bit 4.1 kernel on an AMD box. A fragment of the splat was enough to pinpoint the issue: task: f58e0000 ti: f58e8000 task.ti: f58e800 EIP: 0060:[] EFLAGS: 00010206 CPU: 0 EIP is at free_cache_attributes+0x83/0xd0 EAX: 00000001 EBX: f589d46c ECX: 00000090 EDX: 360c2000 ESI: 00000000 EDI: c1724a80 EBP: f58e9ec0 ESP: f58e9ea0 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 CR0: 8005003b CR2: 000000ac CR3: 01731000 CR4: 000006d0 cache_shared_cpu_map_setup() did check sibling CPUs cacheinfo descriptor while the respective teardown path cache_shared_cpu_map_remove() didn't. Fix that. >From tglx's version: to be on the safe side, move the cacheinfo descriptor check to free_cache_attributes(), thus cleaning up the hotplug path a little and making this even more robust. Reported-and-tested-by: Philip Müller Reviewed-by: Thomas Gleixner Acked-by: Sudeep Holla Cc: # 4.1 Cc: Andre Przywara Cc: Guenter Roeck Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: linux-kernel@vger.kernel.org Cc: manjaro-dev@manjaro.org Cc: Philip Müller Link: https://lkml.kernel.org/r/55B47BB8.6080202@manjaro.org Signed-off-by: Borislav Petkov Signed-off-by: Greg Kroah-Hartman