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: NHoan Tran <hotran@apm.com>
Reviewed-by: NPrashanth Prakash <pprakash@codeaurora.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

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: NAleksey Rybalkin <aleksey@rybalkin.org>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Cc: 4.8+ <stable@vger.kernel.org> # 4.8+
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

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: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

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: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>

Make the comment explaining the meaning of the perf_scaled variable
in get_target_pstate_use_performance() more straightforward.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

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: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Trival fix, dev_err message is missing a \n, so add it.
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Trival fix, dev_err messages are missing a \n, so add it.
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

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: NHoan Tran <hotran@apm.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

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: NDave Gerlach <d-gerlach@ti.com>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Cc: 4.7+ <stable@vger.kernel.org> # 4.7+
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Add io_boost percent to current pstate_sample tracepoint.
Signed-off-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

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: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

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: NAl Stone <ahs3@redhat.com>
Signed-off-by: NPrashanth Prakash <pprakash@codeaurora.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

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: NRussell King <rmk+kernel@arm.linux.org.uk>
Tested-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

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: NJulia Lawall <Julia.Lawall@lip6.fr>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

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: NJuri Lelli <Juri.Lelli@arm.com>
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

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: NJuri Lelli <Juri.Lelli@arm.com>
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

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: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Add the compatible string for supporting the generic cpufreq driver on
the Renesas R-Car V2H (r8a7792) SoC.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The driver emits invalid self test error message even though the init
succeeds.
Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Fixes: cae8b441 ("tpm: Factor out common startup code")
Reviewed-by: NJames Morris <james.l.morris@oracle.com>
Signed-off-by: NJames Morris <james.l.morris@oracle.com>

Commit e647b532 ("ACPI: Add early device probing infrastructure")
introduced code that allows inserting driver specific
struct acpi_probe_entry probe entries into ACPI linker sections
(one per-subsystem, eg irqchip, clocksource) that are then walked
to retrieve the data and function hooks required to probe the
respective kernel components.

Probing for all entries in a section is triggered through
the __acpi_probe_device_table() function, that in turn, according
to the table ID a given probe entry reports parses the table
with the function retrieved from the respective section structures
(ie struct acpi_probe_entry). Owing to the current ACPI table
parsing implementation, the __acpi_probe_device_table() function
has to share global variables with the acpi_match_madt() function, so
in order to guarantee mutual exclusion locking is required
between the two functions.

Current kernel code implements the locking through the acpi_probe_lock
spinlock; this has the side effect of requiring all code called
within the lock (ie struct acpi_probe_entry.probe_{table/subtbl} hooks)
not to sleep.

However, kernel subsystems that make use of the early probing
infrastructure are relying on kernel APIs that may sleep (eg
irq_domain_alloc_fwnode(), among others) in the function calls
pointed at by struct acpi_probe_entry.{probe_table/subtbl} entries
(eg gic_v2_acpi_init()), which is a bug.

Since __acpi_probe_device_table() is called from context
that is allowed to sleep the acpi_probe_lock spinlock can be replaced
with a mutex; this fixes the issue whilst still guaranteeing
mutual exclusion.
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Fixes: e647b532 (ACPI: Add early device probing infrastructure)
Cc: 4.4+ <stable@vger.kernel.org> # 4.4+
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Patch 7f1d642f ("drivers/perf: arm-pmu: Fix handling of SPI lacking
interrupt-affinity property") unintended also fixes perf_event support
for bcm2835 which doesn't have PMU interrupts. Unfortunately this change
introduce a NULL pointer dereference on bcm2835, because irq_is_percpu
always expected to be called with a valid IRQ. So fix this regression
by validating the IRQ before.
Tested-by: NKevin Hilman <khilman@baylibre.com>
Signed-off-by: NStefan Wahren <stefan.wahren@i2se.com>
Fixes: 7f1d642f ("drivers/perf: arm-pmu: Fix handling of SPI lacking "interrupt-affinity" property")
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>

In case of a IRQ type mismatch in of_pmu_irq_cfg() the
device node for interrupt affinity isn't freed. So fix this
issue by calling of_node_put().
Signed-off-by: NStefan Wahren <stefan.wahren@i2se.com>
Fixes: fa8ad788 ("arm: perf: factor arm_pmu core out to drivers")
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>

Fix incorrect condition to identify involvment of a address translation
mechanism.

This bug results in NULL pointer kernel crash dump in cases when mapping
of inbound RapidIO address range is requested within existing aprture.

Link: http://lkml.kernel.org/r/20160901173144.2983-1-alexandre.bounine@idt.comSigned-off-by: NAlexandre Bounine <alexandre.bounine@idt.com>
Cc: Matt Porter <mporter@kernel.crashing.org>
Cc: Andre van Herk <andre.van.herk@prodrive-technologies.com>
Cc: Barry Wood <barry.wood@idt.com>
Cc: <stable@vger.kernel.org>	[4.6+]
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Convert it to the preferred const struct pci_device_id instead.

Link: http://lkml.kernel.org/r/95c5e4100c3cd4eda643624f5b70e8d7abceb86c.1472660229.git.joe@perches.comSigned-off-by: NJoe Perches <joe@perches.com>
Reviewed-by: NBart Van Assche <bart.vanassche@sandisk.com>
Cc: "James E.J. Bottomley" <jejb@linux.vnet.ibm.com>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Since cpufreq_policy_alloc() doesn't use its dev variable for
anything useful, drop that variable from there along with the
NULL check against it.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>

Otherwise we may miss errors.
Signed-off-by: NChunming Zhou <David1.Zhou@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

unhalt Instrction Fetch Unit after all rings are inited.
Signed-off-by: NJimQu <Jim.Qu@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

SDMA could be fail in the thaw() and restore() processes, do software reset
if each SDMA engine is busy.
Signed-off-by: NJimQu <Jim.Qu@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Added devices ids for acces i/o products quad and octal serial cards
that make use of existing Pericom PI7C9X7954 and PI7C9X7958
configurations .
Signed-off-by: NJimi Damon <jdamon@accesio.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Since the commit c1a67b48 ("serial: 8250_pci: replace switch-case by
formula for Intel MID"), the 8250 driver crashes in the byt_set_termios()
function with a divide error. This is caused by the fact that a baud rate of 0
(B0) is not handled properly. Fix it by falling back to B9600 in this case.
Reported-by: N"Mendez Salinas, Fernando" <fernando.mendez.salinas@intel.com>
Fixes: c1a67b48 ("serial: 8250_pci: replace switch-case by formula for Intel MID")
Cc: stable@vger.kernel.org
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Serial console is broken in v4.8-rcX. Mika and I independently bisected down to
commit 4ef03d32 ("tty/serial/8250: use mctrl_gpio helpers").

Since neither author nor anyone else didn't propose a solution we better revert
it for now.

This reverts commit 4ef03d32.

Link: https://lkml.kernel.org/r/20160809130229.GN1729@lahna.fi.intel.comSigned-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Falcon Ridge 4C has been supported by the driver from the beginning,
Falcon Ridge 2C support was just added. Don't irritate users with a
warning declaring the opposite.
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Signed-off-by: NAndreas Noever <andreas.noever@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

From: Xavier Gnata <xavier.gnata@gmail.com>

Add support to INTEL_FALCON_RIDGE_2C controller and corresponding quirk
to support suspend/resume.
Tested against 4.7 master on a MacBook Air 11" 2015.
Signed-off-by: NAndreas Noever <andreas.noever@gmail.com>
Reviewed-by: NLukas Wunner <lukas@wunner.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The quirk 'quirk_apple_wait_for_thunderbolt' did not fire on Falcon
Ridge 4C controllers with subdevice/subvendor set to zero. This lead
to lost pci devices on system resume.

Older thunderbolt controllers (pre Falcon Ridge) used the same device id
for bridges and for the controller. On Apple hardware the subvendor- &
subdevice-ids were set for the controller, but not for bridges. So that
is what was used to differentiate between the two. Starting with Falcon
Ridge bridges and controllers received different device ids.
Additionally on some MacBookPro models (but not all) the
subvendor/subdevice was zeroed.

Starting with a42fb351 (thunderbolt: Allow loading of module on recent
Apple MacBooks with thunderbolt 2 controller) the thunderbolt driver
binds to all Falcon Ridge 4C controllers (irregardless of
subvendor/subdevice). The corresponding quirk was not updated.

This commit changes the quirk to check the device class instead of its
subvendor-/subdeviceids. This works for all generations of Thunderbolt
controllers.
Signed-off-by: NAndreas Noever <andreas.noever@gmail.com>
Reviewed-by: NLukas Wunner <lukas@wunner.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

lkdtm_rodata_do_nothing() is an empty function which is generated in
order to test the non-executability of rodata.

Currently if function tracing is enabled then an mcount callsite will be
generated for lkdtm_rodata_do_nothing(), and it will appear in the list
of available functions for function tracing (available_filter_functions).

Given it's purpose purely as a test function, it seems preferable for
lkdtm_rodata_do_nothing() to be marked notrace, so it doesn't appear as
traceable.

This also avoids triggering a linker bug on powerpc:

  https://sourceware.org/bugzilla/show_bug.cgi?id=20428

When the linker sees code that needs to generate a call stub, eg. a
branch to mcount(), it assumes the section is executable and
dereferences a NULL pointer leading to a linker segfault. Marking
lkdtm_rodata_do_nothing() notrace avoids triggering the bug because the
function contains no other function calls.
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
Signed-off-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Even if PR3 support is available on the bridge, it will not be used if
the PCI layer considers it unavailable (i.e. on all laptops from 2013
and 2014). Ensure that this condition is checked to allow a fallback to
the Optimus DSM for device poweroff.

Initially I wanted to call pci_d3cold_enable before checking bridge_d3
(in case the user changed d3cold_allowed), but that is such an unlikely
case and likely fragile anyway. The current patch is suggested by Mika
in http://www.spinics.net/lists/linux-pci/msg52599.html

Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NPeter Wu <peter@lekensteyn.nl>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This commit appends a few _rcuidle suffixes to fix the following
RCU-used-from-idle bug:

> ===============================
> [ INFO: suspicious RCU usage. ]
> 4.6.0-rc5-next-20160426+ #1116 Not tainted
> -------------------------------
> include/trace/events/rpm.h:95 suspicious rcu_dereference_check() usage!
>
> other info that might help us debug this:
>
>
> RCU used illegally from idle CPU!
> rcu_scheduler_active = 1, debug_locks = 0
> RCU used illegally from extended quiescent state!
> 1 lock held by swapper/0/0:
>  #0:  (&(&dev->power.lock)->rlock){-.-...}, at: [<c052cc2c>] __rpm_callback+0x58/0x60
>
> stack backtrace:
> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.6.0-rc5-next-20160426+ #1116
> Hardware name: Generic OMAP36xx (Flattened Device Tree)
> [<c0110290>] (unwind_backtrace) from [<c010c3a8>] (show_stack+0x10/0x14)
> [<c010c3a8>] (show_stack) from [<c047fd68>] (dump_stack+0xb0/0xe4)
> [<c047fd68>] (dump_stack) from [<c052d5d0>] (rpm_suspend+0x580/0x768)
> [<c052d5d0>] (rpm_suspend) from [<c052ec58>] (__pm_runtime_suspend+0x64/0x84)
> [<c052ec58>] (__pm_runtime_suspend) from [<c04bf25c>] (omap2_gpio_prepare_for_idle+0x5c/0x70)
> [<c04bf25c>] (omap2_gpio_prepare_for_idle) from [<c0125568>] (omap_sram_idle+0x140/0x244)
> [<c0125568>] (omap_sram_idle) from [<c01269dc>] (omap3_enter_idle_bm+0xfc/0x1ec)
> [<c01269dc>] (omap3_enter_idle_bm) from [<c0601bdc>] (cpuidle_enter_state+0x80/0x3d4)
> [<c0601bdc>] (cpuidle_enter_state) from [<c0183b08>] (cpu_startup_entry+0x198/0x3a0)
> [<c0183b08>] (cpu_startup_entry) from [<c0b00c0c>] (start_kernel+0x354/0x3c8)
> [<c0b00c0c>] (start_kernel) from [<8000807c>] (0x8000807c)

In the immortal words of Steven Rostedt, "*Whack* *Whack* *Whack*!!!"
Reported-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
Tested-by: NTony Lindgren <tony@atomide.com>
Tested-by: NGuenter Roeck <linux@roeck-us.net>
WhACKED-by: NSteven Rostedt <rostedt@goodmis.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

This commit applies another _rcuidle suffix to fix an RCU use from
idle.

> ===============================
> [ INFO: suspicious RCU usage. ]
> 4.6.0-rc5-next-20160426+ #1122 Not tainted
> -------------------------------
> include/trace/events/rpm.h:69 suspicious rcu_dereference_check() usage!
>
> other info that might help us debug this:
>
>
> RCU used illegally from idle CPU!
> rcu_scheduler_active = 1, debug_locks = 0
> RCU used illegally from extended quiescent state!
> 1 lock held by swapper/0/0:
>  #0:  (&(&dev->power.lock)->rlock){-.-...}, at: [<c052e3dc>] __pm_runtime_resume+0x3c/0x64
>
> stack backtrace:
> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.6.0-rc5-next-20160426+ #1122
> Hardware name: Generic OMAP36xx (Flattened Device Tree)
> [<c0110290>] (unwind_backtrace) from [<c010c3a8>] (show_stack+0x10/0x14)
> [<c010c3a8>] (show_stack) from [<c047fd68>] (dump_stack+0xb0/0xe4)
> [<c047fd68>] (dump_stack) from [<c052e178>] (rpm_resume+0x5cc/0x7f4)
> [<c052e178>] (rpm_resume) from [<c052e3ec>] (__pm_runtime_resume+0x4c/0x64)
> [<c052e3ec>] (__pm_runtime_resume) from [<c04bf2c4>] (omap2_gpio_resume_after_idle+0x54/0x68)
> [<c04bf2c4>] (omap2_gpio_resume_after_idle) from [<c01269dc>] (omap3_enter_idle_bm+0xfc/0x1ec)
> [<c01269dc>] (omap3_enter_idle_bm) from [<c060198c>] (cpuidle_enter_state+0x80/0x3d4)
> [<c060198c>] (cpuidle_enter_state) from [<c0183b08>] (cpu_startup_entry+0x198/0x3a0)
> [<c0183b08>] (cpu_startup_entry) from [<c0b00c0c>] (start_kernel+0x354/0x3c8)
> [<c0b00c0c>] (start_kernel) from [<8000807c>] (0x8000807c)
Reported-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
Tested-by: NTony Lindgren <tony@atomide.com>
Tested-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Make sure of_device_id tables are NULL terminated.
Signed-off-by: NWei Yongjun <weiyongjun1@huawei.com>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Fixes: f56aad1d (cpufreq: dt: Add generic platform-device creation support)
CC: 4.7+ <stable@vger.kernel.org> # 4.7+
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>