- 20 Oct, 2016 1 commit
-
-
Sergey Senozhatsky authored
'best' is always less or equals to 'pos', so `best - pos' returns a negative value which is then getting casted to `unsigned int' and passed to __cpufreq_driver_target()->acpi_cpufreq_target() for policy->freq_table selection. This results in BUG: unable to handle kernel paging request at ffff881019b469f8 IP: [<ffffffffa00356c1>] acpi_cpufreq_target+0x4f/0x190 [acpi_cpufreq] PGD 267f067 PUD 0 Oops: 0000 [#1] PREEMPT SMP CPU: 6 PID: 70 Comm: kworker/6:1 Not tainted 4.9.0-rc1-next-20161017-dbg-dirty Workqueue: events dbs_work_handler task: ffff88041b808000 task.stack: ffff88041b810000 RIP: 0010:[<ffffffffa00356c1>] [<ffffffffa00356c1>] acpi_cpufreq_target+0x4f/0x190 [acpi_cpufreq] RSP: 0018:ffff88041b813c60 EFLAGS: 00010282 RAX: ffff880419b46a00 RBX: ffff88041b848400 RCX: ffff880419b20f80 RDX: 00000000001dff38 RSI: 00000000ffffffff RDI: ffff88041b848400 RBP: ffff88041b813cb0 R08: 0000000000000006 R09: 0000000000000040 R10: ffffffff8207f9e0 R11: ffffffff8173595b R12: 0000000000000000 R13: ffff88041f1dff38 R14: 0000000000262900 R15: 0000000bfffffff4 FS: 0000000000000000(0000) GS:ffff88041f000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff881019b469f8 CR3: 000000041a2d3000 CR4: 00000000001406e0 Stack: ffff88041b813cb0 ffffffff813347f9 ffff88041b813ca0 ffffffff81334663 ffff88041f1d4bc0 ffff88041b848400 0000000000000000 0000000000000000 0000000000262900 0000000000000000 ffff88041b813d00 ffffffff813355dc Call Trace: [<ffffffff813347f9>] ? cpufreq_freq_transition_begin+0xf1/0xfc [<ffffffff81334663>] ? get_cpu_idle_time+0x97/0xa6 [<ffffffff813355dc>] __cpufreq_driver_target+0x3b6/0x44e [<ffffffff81336ca3>] cs_dbs_timer+0x11a/0x135 [<ffffffff81336fda>] dbs_work_handler+0x39/0x62 [<ffffffff81057823>] process_one_work+0x280/0x4a5 [<ffffffff81058719>] worker_thread+0x24f/0x397 [<ffffffff810584ca>] ? rescuer_thread+0x30b/0x30b [<ffffffff81418380>] ? nl80211_get_key+0x29/0x36a [<ffffffff8105d2b7>] kthread+0xfc/0x104 [<ffffffff8107ceea>] ? put_lock_stats.isra.9+0xe/0x20 [<ffffffff8105d1bb>] ? kthread_create_on_node+0x3f/0x3f [<ffffffff814b2092>] ret_from_fork+0x22/0x30 Code: 56 4d 6b ff 0c 41 55 41 54 53 48 83 ec 28 48 8b 15 ad 1e 00 00 44 8b 41 08 48 8b 87 c8 00 00 00 49 89 d5 4e 03 2c c5 80 b2 78 81 <46> 8b 74 38 04 45 3b 75 00 75 11 31 c0 83 39 00 0f 84 1c 01 00 RIP [<ffffffffa00356c1>] acpi_cpufreq_target+0x4f/0x190 [acpi_cpufreq] RSP <ffff88041b813c60> CR2: ffff881019b469f8 ---[ end trace 16d9fc7a17897d37 ]--- [ rjw: In some cases this bug may also cause incorrect frequencies to be selected by cpufreq governors. ] Fixes: 899bb664 (cpufreq: skip invalid entries when searching the frequency) Link: http://marc.info/?l=linux-kernel&m=147672030714331&w=2Reported-and-tested-by:
Sedat Dilek <sedat.dilek@gmail.com> Reported-and-tested-by:
Jörg Otte <jrg.otte@gmail.com> Signed-off-by:
Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Acked-by:
Viresh Kumar <viresh.kumar@linaro.org> Cc: 4.8+ <stable@vger.kernel.org> # 4.8+ Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 13 Oct, 2016 2 commits
-
-
Hoan Tran authored
The desired_perf is an abstract performance number. Its value should be in the range of [lowest perf, highest perf] of CPPC. The correct calculation is desired_perf = freq * cppc_highest_perf / cppc_dmi_max_khz And cppc_cpufreq_set_target() returns if desired_perf is exactly the same with the old perf. Signed-off-by:
Hoan Tran <hotran@apm.com> Reviewed-by:
Prashanth Prakash <pprakash@codeaurora.org> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Rafael J. Wysocki authored
Commit d352cf47 (cpufreq: conservative: Do not use transition notifications) overlooked the case when the "frequency step" used by the conservative governor is small relative to the distances between the available frequencies and broke the algorithm by using policy->cur instead of the previously requested frequency when computing the next one. As a result, the governor may not be able to go outside of a narrow range between two consecutive available frequencies. Fix the problem by making the governor save the previously requested frequency and select the next one relative that value (unless it is out of range, in which case policy->cur will be used instead). Fixes: d352cf47 (cpufreq: conservative: Do not use transition notifications) Link: https://bugzilla.kernel.org/show_bug.cgi?id=177171Reported-and-tested-by:
Aleksey Rybalkin <aleksey@rybalkin.org> Acked-by:
Viresh Kumar <viresh.kumar@linaro.org> Cc: 4.8+ <stable@vger.kernel.org> # 4.8+ Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 12 Oct, 2016 3 commits
-
-
Aaro Koskinen authored
Skip invalid entries when searching the frequency. This fixes cpufreq at least on loongson2 MIPS board. Fixes: da0c6dc0 (cpufreq: Handle sorted frequency tables more efficiently) Signed-off-by:
Aaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by:
Viresh Kumar <viresh.kumar@linaro.org> Cc: 4.8+ <stable@vger.kernel.org> # 4.8+ Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Rafael J. Wysocki authored
It looks like the name of struct pstate_adjust_policy was updated without updating its kerneldoc comment accordingly, so fix that mistake. Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Rafael J. Wysocki authored
The PID algorithm used by the intel_pstate driver tends to drive performance to the minimum for workloads with utilization below the setpoint, which is undesirable, so replace it with a modified "proportional" algorithm on Atom. The new algorithm will set the new P-state to be 1.25 times the available maximum times the (frequency-invariant) utilization during the previous sampling period except when the target P-state computed this way is lower than the average P-state during the previous sampling period. In the latter case, it will increase the target by 50% of the difference between it and the average P-state to prevent performance from dropping down too fast in some cases. Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by:
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
-
- 09 Oct, 2016 2 commits
-
-
Rafael J. Wysocki authored
Make the comment explaining the meaning of the perf_scaled variable in get_target_pstate_use_performance() more straightforward. Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Srinivas Pandruvada authored
This is a requirement that MSR MSR_PM_ENABLE must be set to 0x01 before reading MSR_HWP_CAPABILITIES on a given CPU. If cpufreq init() is scheduled on a CPU which is not same as policy->cpu or migrates to a different CPU before calling msr read for MSR_HWP_CAPABILITIES, it is possible that MSR_PM_ENABLE was not to set to 0x01 on that CPU. This will cause GP fault. So like other places in this path rdmsrl_on_cpu should be used instead of rdmsrl. Moreover the scope of MSR_HWP_CAPABILITIES is on per thread basis, so it should be read from the same CPU, for which MSR MSR_HWP_REQUEST is getting set. dmesg dump or warning: [ 22.014488] WARNING: CPU: 139 PID: 1 at arch/x86/mm/extable.c:50 ex_handler_rdmsr_unsafe+0x68/0x70 [ 22.014492] unchecked MSR access error: RDMSR from 0x771 [ 22.014493] Modules linked in: [ 22.014507] CPU: 139 PID: 1 Comm: swapper/0 Not tainted 4.7.5+ #1 ... ... [ 22.014516] Call Trace: [ 22.014542] [<ffffffff813d7dd1>] dump_stack+0x63/0x82 [ 22.014558] [<ffffffff8107bc8b>] __warn+0xcb/0xf0 [ 22.014561] [<ffffffff8107bcff>] warn_slowpath_fmt+0x4f/0x60 [ 22.014563] [<ffffffff810676f8>] ex_handler_rdmsr_unsafe+0x68/0x70 [ 22.014564] [<ffffffff810677d9>] fixup_exception+0x39/0x50 [ 22.014604] [<ffffffff8102e400>] do_general_protection+0x80/0x150 [ 22.014610] [<ffffffff817f9ec8>] general_protection+0x28/0x30 [ 22.014635] [<ffffffff81687940>] ? get_target_pstate_use_performance+0xb0/0xb0 [ 22.014642] [<ffffffff810600c7>] ? native_read_msr+0x7/0x40 [ 22.014657] [<ffffffff81688123>] intel_pstate_hwp_set+0x23/0x130 [ 22.014660] [<ffffffff81688406>] intel_pstate_set_policy+0x1b6/0x340 [ 22.014662] [<ffffffff816829bb>] cpufreq_set_policy+0xeb/0x2c0 [ 22.014664] [<ffffffff81682f39>] cpufreq_init_policy+0x79/0xe0 [ 22.014666] [<ffffffff81682cb0>] ? cpufreq_update_policy+0x120/0x120 [ 22.014669] [<ffffffff816833a6>] cpufreq_online+0x406/0x820 [ 22.014671] [<ffffffff8168381f>] cpufreq_add_dev+0x5f/0x90 [ 22.014717] [<ffffffff81530ac8>] subsys_interface_register+0xb8/0x100 [ 22.014719] [<ffffffff816821bc>] cpufreq_register_driver+0x14c/0x210 [ 22.014749] [<ffffffff81fe1d90>] intel_pstate_init+0x39d/0x4d5 [ 22.014751] [<ffffffff81fe13f2>] ? cpufreq_gov_dbs_init+0x12/0x12 Cc: 4.3+ <stable@vger.kernel.org> # 4.3+ Signed-off-by:
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 01 Oct, 2016 1 commit
-
-
Rafael J. Wysocki authored
-
- 26 Sep, 2016 2 commits
-
-
Colin Ian King authored
Trival fix, dev_err message is missing a \n, so add it. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Acked-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Colin Ian King authored
Trival fix, dev_err messages are missing a \n, so add it. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Acked-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 16 Sep, 2016 3 commits
-
-
Hoan Tran authored
This patch fixes overflow issue when calculating the desired_perf. Fixes: ad38677d (cpufreq: CPPC: Force reporting values in KHz to fix user space interface) Signed-off-by:
Hoan Tran <hotran@apm.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Dave Gerlach authored
Now that the cpufreq-dt-platdev is used to create the cpufreq-dt platform device for all OMAP platforms and the platform code that did it before has been removed, add ti,am33xx and ti,dra7xx to the machine list in cpufreq-dt-platdev which had relied on the removed platform code to do this previously. Fixes: 7694ca6e (cpufreq: omap: Use generic platdev driver) Signed-off-by:
Dave Gerlach <d-gerlach@ti.com> Acked-by:
Viresh Kumar <viresh.kumar@linaro.org> Cc: 4.7+ <stable@vger.kernel.org> # 4.7+ Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Srinivas Pandruvada authored
Add io_boost percent to current pstate_sample tracepoint. Signed-off-by:
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 14 Sep, 2016 1 commit
-
-
Rafael J. Wysocki authored
Modify the P-state selection algorithm for Atom processors to use the new SCHED_CPUFREQ_IOWAIT flag instead of the questionable get_cpu_iowait_time_us() function. Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 13 Sep, 2016 11 commits
-
-
Rafael J. Wysocki authored
Modify the schedutil cpufreq governor to boost the CPU frequency if the SCHED_CPUFREQ_IOWAIT flag is passed to it via cpufreq_update_util(). If that happens, the frequency is set to the maximum during the first update after receiving the SCHED_CPUFREQ_IOWAIT flag and then the boost is reduced by half during each following update. Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Looks-good-to: Steve Muckle <smuckle@linaro.org> Acked-by:
Peter Zijlstra (Intel) <peterz@infradead.org>
-
Rafael J. Wysocki authored
Testing indicates that it is possible to improve performace significantly without increasing energy consumption too much by teaching cpufreq governors to bump up the CPU performance level if the in_iowait flag is set for the task in enqueue_task_fair(). For this purpose, define a new cpufreq_update_util() flag SCHED_CPUFREQ_IOWAIT and modify enqueue_task_fair() to pass that flag to cpufreq_update_util() in the in_iowait case. That generally requires cpufreq_update_util() to be called directly from there, because update_load_avg() may not be invoked in that case. Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Looks-good-to: Steve Muckle <smuckle@linaro.org> Acked-by:
Peter Zijlstra (Intel) <peterz@infradead.org>
-
Rafael J. Wysocki authored
Merge tag 'samsung-defconfig-schedutil-4.9' of git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux into pm-cpufreq-sched The schedutil cpufreq governor will be switched from tristate to bool. Fix defconfigs. * tag 'samsung-defconfig-schedutil-4.9' of git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux: ARM: multi_v7_defconfig: Don't attempt to enable schedutil governor as module ARM: exynos_defconfig: Don't attempt to enable schedutil governor as module
-
Al Stone authored
When CPPC is being used by ACPI on arm64, user space tools such as cpupower report CPU frequency values from sysfs that are incorrect. What the driver was doing was reporting the values given by ACPI tables in whatever scale was used to provide them. However, the ACPI spec defines the CPPC values as unitless abstract numbers. Internal kernel structures such as struct perf_cap, in contrast, expect these values to be in KHz. When these struct values get reported via sysfs, the user space tools also assume they are in KHz, causing them to report incorrect values (for example, reporting a CPU frequency of 1MHz when it should be 1.8GHz). The downside is that this approach has some assumptions: (1) It relies on SMBIOS3 being used, *and* that the Max Frequency value for a processor is set to a non-zero value. (2) It assumes that all processors run at the same speed, or that the CPPC values have all been scaled to reflect relative speed. This patch retrieves the largest CPU Max Frequency from a type 4 DMI record that it can find. This may not be an issue, however, as a sampling of DMI data on x86 and arm64 indicates there is often only one such record regardless. Since CPPC is relatively new, it is unclear if the ACPI ASL will always be written to reflect any sort of relative performance of processors of differing speeds. (3) It assumes that performance and frequency both scale linearly. For arm64 servers, this may be sufficient, but it does rely on firmware values being set correctly. Hence, other approaches will be considered in the future. This has been tested on three arm64 servers, with and without DMI, with and without CPPC support. Signed-off-by:
Al Stone <ahs3@redhat.com> Signed-off-by:
Prashanth Prakash <pprakash@codeaurora.org> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Viresh Kumar authored
If a cpufreq driver is registered very early in the boot stage (e.g. registered from postcore_initcall()), then cpufreq core may generate kernel warnings for it. In this case, the CPUs are brought online, then the cpufreq driver is registered, and then the CPU topology devices are registered. However, by the time cpufreq_add_dev() gets called, the cpu device isn't stored in the per-cpu variable (cpu_sys_devices,) which is read by get_cpu_device(). So the cpufreq core fails to get device for the CPU, for which cpufreq_add_dev() was called in the first place and we will hit a WARN_ON(!cpu_dev). Even if we reuse the 'dev' parameter passed to cpufreq_add_dev() to avoid that warning, there might be other CPUs online that share the policy with the cpu for which cpufreq_add_dev() is called. Eventually get_cpu_device() will return NULL for them as well, and we will hit the same WARN_ON() again. In order to fix these issues, change cpufreq core to create links to the policy for a cpu only when cpufreq_add_dev() is called for that CPU. Reuse the 'real_cpus' mask to track that as well. Note that cpufreq_remove_dev() already handles removal of the links for individual CPUs and cpufreq_add_dev() has aligned with that now. Reported-by:
Russell King <rmk+kernel@arm.linux.org.uk> Tested-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Julia Lawall authored
For structure types defined in the same file or local header files, find top-level static structure declarations that have the following properties: 1. Never reassigned. 2. Address never taken 3. Not passed to a top-level macro call 4. No pointer or array-typed field passed to a function or stored in a variable. Declare structures having all of these properties as const. Done using Coccinelle. Based on a suggestion by Joe Perches <joe@perches.com>. Signed-off-by:
Julia Lawall <Julia.Lawall@lip6.fr> Acked-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Viresh Kumar authored
The cpufreq-dt driver is also used for systems with multiple clock/voltage domains for CPUs, i.e. multiple cpufreq policies in a system. And in such cases the platform users may want to enable "governor tunables per policy". Support that via platform data, as not all users of the driver would want that behavior. Reported-by:
Juri Lelli <Juri.Lelli@arm.com> Signed-off-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Viresh Kumar authored
The cpufreq DT driver also supports systems that have multiple clock/voltage domains for CPUs, i.e. multiple policy systems. The description of the Kconfig entry was never updated after the driver was modified to support such systems, fix it. Reported-by:
Juri Lelli <Juri.Lelli@arm.com> Signed-off-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Viresh Kumar authored
This is leftover from an earlier patch which removed the usage of platform data but forgot to remove this line. Remove it now. Signed-off-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Jean Delvare authored
I am told the cpufreq documentation updates should go to the PM list. Signed-off-by:
Jean Delvare <jdelvare@suse.de> Acked-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Geert Uytterhoeven authored
Add the compatible string for supporting the generic cpufreq driver on the Renesas R-Car V2H (r8a7792) SoC. Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Acked-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 12 Sep, 2016 1 commit
-
-
Rafael J. Wysocki authored
-
- 08 Sep, 2016 1 commit
-
-
Jean Delvare authored
The cpufreq-stats code can no longer be built as a module, so it now appears with square brackets in menuconfig. Signed-off-by:
Jean Delvare <jdelvare@suse.de> Fixes: 1aefc75b (cpufreq: stats: Make the stats code non-modular) Acked-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 04 Sep, 2016 4 commits
-
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull x86 fix from Thomas Gleixner: "A single fix for an AMD erratum so machines without a BIOS fix work" * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/AMD: Apply erratum 665 on machines without a BIOS fix
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull timer fixes from Thomas Gleixner: "Two fixlet from the timers departement: - A fix for scheduler stalls in the tick idle code affecting NOHZ_FULL kernels - A trivial compile fix" * 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: tick/nohz: Fix softlockup on scheduler stalls in kvm guest clocksource/drivers/atmel-pit: Fix compilation error
-
git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dmLinus Torvalds authored
Pull device mapper fixes from Mike Snitzer: - a stable fix in both DM crypt and DM log-writes for too large bios (as generated by bcache) - two other stable fixes for DM log-writes - a stable fix for a DM crypt bug that could result in freeing pointers from uninitialized memory in the tfm allocation error path - a DM bufio cleanup to discontinue using create_singlethread_workqueue() * tag 'dm-4.8-fixes-4' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm: dm bufio: remove use of deprecated create_singlethread_workqueue() dm crypt: fix free of bad values after tfm allocation failure dm crypt: fix error with too large bios dm log writes: fix check of kthread_run() return value dm log writes: fix bug with too large bios dm log writes: move IO accounting earlier to fix error path
-
- 03 Sep, 2016 8 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfsLinus Torvalds authored
Pull btrfs fixes from Chris Mason: "I'm still prepping a set of fixes for btrfs fsync, just nailing down a hard to trigger memory corruption. For now, these are tested and ready." * 'for-linus-4.8' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs: btrfs: fix one bug that process may endlessly wait for ticket in wait_reserve_ticket() Btrfs: fix endless loop in balancing block groups Btrfs: kill invalid ASSERT() in process_all_refs()
-
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linuxLinus Torvalds authored
Pull arm64 fixes from Catalin Marinas: "arm64 and arm/perf fixes: - arm64 fix: debug exception unmasking on the CPU resume path - ARM PMU fixes: memory leak on error path and NULL pointer dereference" * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: arm64: kernel: Fix unmasked debug exceptions when restoring mdscr_el1 drivers/perf: arm_pmu: Fix NULL pointer dereference during probe drivers/perf: arm_pmu: Fix leak in error path
-
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-miscLinus Torvalds authored
Pull char/misc driver fixes from Greg KH: "Here are a number of small driver fixes for 4.8-rc5. The largest thing here is deleting an obsolete driver, drivers/misc/bh1780gli.c, as the functionality of it was replaced by an iio driver a while ago. The other fixes are things that have been reported, or reverts of broken stuff (the binder change). All of these changes have been in linux-next for a while with no reported issues" * tag 'char-misc-4.8-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: thunderbolt: Don't declare Falcon Ridge unsupported thunderbolt: Add support for INTEL_FALCON_RIDGE_2C controller. thunderbolt: Fix resume quirk for Falcon Ridge 4C. lkdtm: Mark lkdtm_rodata_do_nothing() notrace mei: me: disable driver on SPT SPS firmware Revert "android: binder: fix dangling pointer comparison" drivers/iio/light/Kconfig: SENSORS_BH1780 cleanup android: binder: fix dangling pointer comparison misc: delete bh1780 driver
-
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-coreLinus Torvalds authored
Pull driver core fixes from Greg KH: "Here are three small fixes for 4.8-rc5. One for sysfs, one for kernfs, and one documentation fix, all for reported issues. All of these have been in linux-next for a while" * tag 'driver-core-4.8-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: sysfs: correctly handle read offset on PREALLOC attrs documentation: drivers/core/of: fix name of of_node symlink kernfs: don't depend on d_find_any_alias() when generating notifications
-
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/stagingLinus Torvalds authored
Pull staging/IIO driver fixes from Greg KH: "Here are a number of small fixes for staging and IIO drivers that resolve reported problems. Full details are in the shortlog. All of these have been in linux-next with no reported issues" * tag 'staging-4.8-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: (35 commits) arm: dts: rockchip: add reset node for the exist saradc SoCs arm64: dts: rockchip: add reset saradc node for rk3368 SoCs iio: adc: rockchip_saradc: reset saradc controller before programming it iio: accel: kxsd9: Fix raw read return iio: adc: ti_am335x_adc: Increase timeout value waiting for ADC sample iio: adc: ti_am335x_adc: Protect FIFO1 from concurrent access include/linux: fix excess fence.h kernel-doc notation staging: wilc1000: correctly check if associatedsta has not been found staging: wilc1000: NULL dereference on error staging: wilc1000: txq_event: Fix coding error MAINTAINERS: Add file patterns for ion device tree bindings MAINTAINERS: Update maintainer entry for wilc1000 iio: chemical: atlas-ph-sensor: fix typo in val assignment iio: fix sched WARNING "do not call blocking ops when !TASK_RUNNING" staging: comedi: ni_mio_common: fix AO inttrig backwards compatibility staging: comedi: dt2811: fix a precedence bug staging: comedi: adv_pci1760: Do not return EINVAL for CMDF_ROUND_DOWN. staging: comedi: ni_mio_common: fix wrong insn_write handler staging: comedi: comedi_test: fix timer race conditions staging: comedi: daqboard2000: bug fix board type matching code ...
-
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/ttyLinus Torvalds authored
Pull serial driver fixes from Greg KH: "Here are some small serial driver fixes for 4.8-rc5. One fixes an oft-reported build issue with the fintek driver, another reverts a patch that was causing problems, one fixes a crash, and some new device ids were added. All of these have been in linux-next for a while" * tag 'tty-4.8-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: serial: 8250: added acces i/o products quad and octal serial cards serial: 8250_mid: fix divide error bug if baud rate is 0 Revert "tty/serial/8250: use mctrl_gpio helpers" 8250/fintek: rename IRQ_MODE macro
-
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usbLinus Torvalds authored
Pull USB/PHY fixes from Greg KH: "Here are some USB and PHY driver fixes for 4.8-rc5 Nothing major, lots of little fixes for reported bugs, and a build fix for a missing .h file that the phy drivers needed. All of these have been in linux-next for a while with no reported issues" * tag 'usb-4.8-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (24 commits) usb: musb: Fix locking errors for host only mode usb: dwc3: gadget: always decrement by 1 usb: dwc3: debug: fix ep name on trace output usb: gadget: udc: core: don't starve DMA resources USB: serial: option: add WeTelecom 0x6802 and 0x6803 products USB: avoid left shift by -1 USB: fix typo in wMaxPacketSize validation usb: gadget: Add the gserial port checking in gs_start_tx() usb: dwc3: gadget: don't rely on jiffies while holding spinlock usb: gadget: fsl_qe_udc: signedness bug in qe_get_frame() usb: gadget: function: f_rndis: socket buffer may be NULL usb: gadget: function: f_eem: socket buffer may be NULL usb: renesas_usbhs: gadget: fix return value check in usbhs_mod_gadget_probe() usb: dwc2: Add reset control to dwc2 usb: dwc3: core: allow device to runtime_suspend several times usb: dwc3: pci: runtime_resume child device USB: serial: option: add WeTelecom WM-D200 usb: chipidea: udc: don't touch DP when controller is in host mode USB: serial: mos7840: fix non-atomic allocation in write path USB: serial: mos7720: fix non-atomic allocation in write path ...
-
Linus Torvalds authored
In commit 8ead9dd5 ("devpts: more pty driver interface cleanups") I made devpts_get_priv() just return the dentry->fs_data directly. And because I thought it wouldn't happen, I added a warning if you ever saw a pts node that wasn't on devpts. And no, that warning never triggered under any actual real use, but you can trigger it by creating nonsensical pts nodes by hand. So just revert the warning, and make devpts_get_priv() return NULL for that case like it used to. Reported-by:
Dmitry Vyukov <dvyukov@google.com> Cc: stable@vger.kernel.org # 4.6+ Cc: Eric W Biederman" <ebiederm@xmission.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-