* pm-acpi: (24 commits)
olpc-xo15-sci: Use struct dev_pm_ops for power management
ACPI / PM: Drop PM callbacks from the ACPI bus type
ACPI / PM: Drop legacy driver PM callbacks that are not used any more
ACPI / PM: Do not execute legacy driver PM callbacks
acpi_power_meter: Use struct dev_pm_ops for power management
fujitsu-tablet: Use struct dev_pm_ops for power management
classmate-laptop: Use struct dev_pm_ops for power management
xo15-ebook: Use struct dev_pm_ops for power management
toshiba_bluetooth: Use struct dev_pm_ops for power management
panasonic-laptop: Use struct dev_pm_ops for power management
sony-laptop: Use struct dev_pm_ops for power management
hp_accel: Use struct dev_pm_ops for power management
toshiba_acpi: Use struct dev_pm_ops for power management
ACPI: Use struct dev_pm_ops for power management in the SBS driver
ACPI: Use struct dev_pm_ops for power management in the power driver
ACPI: Use struct dev_pm_ops for power management in the button driver
ACPI: Use struct dev_pm_ops for power management in the battery driver
ACPI: Use struct dev_pm_ops for power management in the AC driver
ACPI: Use struct dev_pm_ops for power management in processor driver
ACPI: Use struct dev_pm_ops for power management in the thermal driver
...
Remove the latency_ticks field as it is not used.
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Pull ACPI patch from Len Brown.
* 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux:
ACPICA: Fix possible fault in return package object repair code
This fixes a regression preventing the ACPI cpufreq driver from loading on some
systems where it worked previously without any problems.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
iQIcBAABAgAGBQJQAWv6AAoJEKhOf7ml8uNsUXcQAINIZmqe/VCYC3jsYwn0OURQ
Ua9g51czYvyFS+9tDc5V6b4DrG6B6rIjOBywO1qTXQkRyfpbEx4CVvCOij/0sApg
Jw/VwImYlIL88uqfGniFv/LW1qUA4v1QcfyDcdbsBGGTwvQwekeYomLRwYWthqkO
VEC/hYXtTAkfHnJJSWG2PtYpUbicmOdVDwh2SQuf/dmXVZXmMmljQFVvyPHNMwbd
X6ENqhYiTr5tJ5k0e9mAGwfpRmG7YoXQE7pM1hl4kcv0CgdN3U71WEK3LfxJBeTW
lGawcA0pu/4o/+X9NYJHo1QosXQAHAeqMkn38pv8K4EwqnnXqLK35+wTYBf00kdg
lJHGNvg1kuQEp32nXT3y4kzASNHHnTV2IU2YbERZ61+2x3sU3DSLjNo2ZL/kqd8k
fxN+RWXEBA1lI5TRL4ENENT0c/m+RDQCJkHXwAEOwTZwMZDUKWfiaZwoRcs1xTEC
JjcBIe1wMmHJDxH+fh4KBdqjFiPDoBqHi4AWWIavJJG/W+LJLrd/i90o99GOHZ/0
q/pouYurt05ec7dwX3rMqlLGQz8hVkp6flg0DgrJCe0tGaQarZ0bkp6RaQpEAfxi
y1eIgYbCy61YvUMxhBp/SWoD9/wAoYuWZFtq1CgwYmkRJ25lT6zoOFiJAn3GF5PG
2thM5M0vuLVhG/BPZMo3
=XZHs
-----END PGP SIGNATURE-----
Merge tag 'cpufreq-for-3.5-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull cpufreq fix from Rafael Wysocki:
"This fixes a regression preventing the ACPI cpufreq driver from
loading on some systems where it worked previously without any
problems."
* tag 'cpufreq-for-3.5-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
cpufreq / ACPI: Fix not loading acpi-cpufreq driver regression
Fixes a problem that can occur when a lone package object is
wrapped with an outer package object in order to conform to
the ACPI specification. Can affect these predefined names:
_ALR,_MLS,_PSS,_TRT,_TSS,_PRT,_HPX,_DLM,_CSD,_PSD,_TSD
https://bugzilla.kernel.org/show_bug.cgi?id=44171
This problem was introduced in 3.4-rc1 by commit
6a99b1c94d
(ACPICA: Object repair code: Support to add Package wrappers)
Reported-by: Vlastimil Babka <caster@gentoo.org>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Cc: <stable@vger.kernel.org> # 3.4
Signed-off-by: Len Brown <len.brown@intel.com>
Commit d640113fe8 introduced a regression on SMP
systems where the processor core with ACPI id zero is disabled
(typically should be the case because of hyperthreading).
The regression got spread through stable kernels.
On 3.0.X it got introduced via 3.0.18.
Such platforms may be rare, but do exist.
Look out for a disabled processor with acpi_id 0 in dmesg:
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x10] disabled)
This problem has been observed on a:
HP Proliant BL280c G6 blade
This patch restricts the introduced workaround to platforms
with nr_cpu_ids <= 1.
Signed-off-by: Thomas Renninger <trenn@suse.de>
CC: stable@vger.kernel.org
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
This is an old suspend/resume lockup fix:
commit 2780cc4660e1
Author: Len Brown <len.brown@intel.com>
Date: Thu Dec 23 13:43:30 2004 -0500
[ACPI] Fix suspend/resume lockup issue
by leaving Bus Master Arbitration enabled.
The ACPI spec mandates it be disabled only for C3.
http://bugzilla.kernel.org/show_bug.cgi?id=3599
Signed-off-by: David Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
The bug snuck back in in commit 2feec47d4c (ACPICA: ACPI 5: Support
for new FADT SleepStatus, SleepControl registers, 2012-02-14),
presumably by copy/pasting a copy of the code without that fix for the
legacy case.
On affected machines, after that commit, the machine locks up hard on
resume from suspend. The same fix as seven years ago still works.
Addresses <https://bugzilla.kernel.org/show_bug.cgi?id=43641>.
Reported-bisected-and-tested-by: Octavio Alvarez <alvarezp@alvarezp.com>
Reported-by: Adrian Knoth <adi@drcomp.erfurt.thur.de>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
On certain bios, resume hangs if cpus are allowed to enter idle states
during suspend [1].
This was fixed in apci idle driver [2].But intel_idle driver does not
have this fix. Thus instead of replicating the fix in both the idle
drivers, or in more platform specific idle drivers if needed, the
more general cpuidle infrastructure could handle this.
A suspend callback in cpuidle_driver could handle this fix. But
a cpuidle_driver provides only basic functionalities like platform idle
state detection capability and mechanisms to support entry and exit
into CPU idle states. All other cpuidle functions are found in the
cpuidle generic infrastructure for good reason that all cpuidle
drivers, irrepective of their platforms will support these functions.
One option therefore would be to register a suspend callback in cpuidle
which handles this fix. This could be called through a PM_SUSPEND_PREPARE
notifier. But this is too generic a notfier for a driver to handle.
Also, ideally the job of cpuidle is not to handle side effects of suspend.
It should expose the interfaces which "handle cpuidle 'during' suspend"
or any other operation, which the subsystems call during that respective
operation.
The fix demands that during suspend, no cpus should be allowed to enter
deep C-states. The interface cpuidle_uninstall_idle_handler() in cpuidle
ensures that. Not just that it also kicks all the cpus which are already
in idle out of their idle states which was being done during cpu hotplug
through a CPU_DYING_FROZEN callbacks.
Now the question arises about when during suspend should
cpuidle_uninstall_idle_handler() be called. Since we are dealing with
drivers it seems best to call this function during dpm_suspend().
Delaying the call till dpm_suspend_noirq() does no harm, as long as it is
before cpu_hotplug_begin() to avoid race conditions with cpu hotpulg
operations. In dpm_suspend_noirq(), it would be wise to place this call
before suspend_device_irqs() to avoid ugly interactions with the same.
Ananlogously, during resume.
References:
[1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/674075.
[2] http://marc.info/?l=linux-pm&m=133958534231884&w=2
Reported-and-tested-by: Dave Hansen <dave@linux.vnet.ibm.com>
Signed-off-by: Preeti U Murthy <preeti@linux.vnet.ibm.com>
Reviewed-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
When the system is booted with some cpus offline, the idle
driver is not initialized. When a cpu is set online, the
acpi code call the intel idle init function. Unfortunately
this code introduce a dependency between intel_idle and acpi.
This patch is intended to remove this dependency by using the
notifier of intel_idle. This patch has the benefit of
encapsulating the intel_idle driver and remove some exported
functions.
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Acked-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Since the ACPI bus type's PM callbacks only execute the driver ones
without doing anything else, they can be dropped, because the driver
callbacks will be executed by the PM core directly if bus type
(or other subsystem) callbacks are not present.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Since all ACPI drivers in the tree should have been switched
to power management handling based on struct dev_pm_ops,
modify the ACPI bus type driver so that is doesn't execute
legacy driver power management callbacks from the functions
pointed to by the members of the acpi_bus_pm structure.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Make the ACPI Smart Battery System driver define its PM callbacks
through a struct dev_pm_ops object rather than by using legacy PM
hooks in struct acpi_device_ops.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Make the ACPI power resource driver define its PM callbacks through
a struct dev_pm_ops object rather than by using legacy PM hooks
in struct acpi_device_ops.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Make the ACPI button driver define its PM callbacks through
a struct dev_pm_ops object rather than by using legacy PM hooks
in struct acpi_device_ops.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Make the ACPI battery driver define its PM callbacks through
a struct dev_pm_ops object rather than by using legacy PM hooks
in struct acpi_device_ops.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Make the ACPI AC adapter driver define its PM callbacks through
a struct dev_pm_ops object rather than by using legacy PM hooks
in struct acpi_device_ops.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Make the ACPI processor driver define its PM callbacks through
a struct dev_pm_ops object rather than by using legacy PM hooks
in struct acpi_device_ops.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Make the ACPI thermal driver define its PM callbacks through
a struct dev_pm_ops object rather than by using legacy PM hooks
in struct acpi_device_ops.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Make the ACPI fan driver define its PM callbacks through
a struct dev_pm_ops object rather than by using legacy PM hooks
in struct acpi_device_ops.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Modify acpi_bus_type so that it executes PM callbacks provided
by drivers through their struct dev_pm_ops objects, if present,
while still allowing the legacy ACPI PM callbacks to take precedence.
This will make it possible to convert ACPI drivers one by one to
handling PM through struct dev_pm_ops instead of the legacy way.
The code added by this change is temporary and will be removed
when all of the drivers in question have been switched over to
the PM handling based on struct dev_pm_ops.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Make the acpi_bus_type bus type define its PM callbacks through
a struct dev_pm_ops object rather than by using legacy PM hooks
in struct bus_type.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
None of the drivers implementing the ACPI device suspend callback
uses the pm_message_t argument of it, so this argument may be dropped
entirely from that callback. This will simplify switching the ACPI
bus type to PM handling based on struct dev_pm_ops.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Pull ACPI & Power Management patches from Len Brown.
* 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux:
acpi_pad: fix power_saving thread deadlock
ACPI video: Still use ACPI backlight control if _DOS doesn't exist
ACPI, APEI, Avoid too much error reporting in runtime
ACPI: Add a quirk for "AMILO PRO V2030" to ignore the timer overriding
ACPI: Remove one board specific WARN when ignoring timer overriding
ACPI: Make acpi_skip_timer_override cover all source_irq==0 cases
ACPI, x86: fix Dell M6600 ACPI reboot regression via DMI
ACPI sysfs.c strlen fix
The acpi_pad driver can get stuck in destroy_power_saving_task()
waiting for kthread_stop() to stop a power_saving thread. The problem
is that the isolated_cpus_lock mutex is owned when
destroy_power_saving_task() calls kthread_stop(), which waits for a
power_saving thread to end, and the power_saving thread tries to
acquire the isolated_cpus_lock when it calls round_robin_cpu(). This
patch fixes the issue by making round_robin_cpu() use its own mutex.
https://bugzilla.kernel.org/show_bug.cgi?id=42981
Cc: stable@vger.kernel.org
Signed-off-by: Stuart Hayes <Stuart_Hayes@Dell.com>
Signed-off-by: Len Brown <len.brown@intel.com>
This fixes a regression in 3.4-rc1 caused by commit
ea9f8856bd
(ACPI video: Harden video bus adding.)
Some platforms don't have _DOS control method, but the ACPI
backlight still works.
We should not invoke _DOS for these platforms.
https://bugzilla.kernel.org/show_bug.cgi?id=43168
Cc: Igor Murzov <intergalactic.anonymous@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Commit e978aa7d7d ( cpuidle: Move
dev->last_residency update to driver enter routine; remove dev->last_state)
was breaking suspend on laptops, as reported in the below link
- https://lkml.org/lkml/2011/11/11/164
This was fixed in commit 3439a8da16
(ACPI / cpuidle: Remove acpi_idle_suspend (to fix suspend regression)
by removing acpi_idle_suspend flag.
- https://lkml.org/lkml/2011/11/14/74
But this did fix did not work on all systems
as Suspend/resume regression was reported on Lenovo S10-3
recently by Dave.
- https://lkml.org/lkml/2012/5/27/115
It looked like with commit e978aa7d broke suspend and
with commit 3439a8da resume was not working with acpi_idle driver.
This patch fixes the regression that caused this issue
in the first place. acpi_idle_suspend flag is essential on
some x86 systems to prevent the cpus from going to deeper C-states
when suspend is triggered ( commit b04e7bdb98 )
So reverting the commit 3439a8da is essential.
By default, irqs are disabled in cpu_idle arch specific call
and re-enabled in idle state return path . During suspend,
the acpi_idle_suspend flag is set, which
prevents the cpus from going to deeper idle states,
it is essential to enabling the irqs in this return path too.
To address the suspend issue,
we were not re-enabling the interrupts while returning from
acpi_idle_enter_bm() routine if acpi_idle_suspend flag is set.
and this caused suspend failure.
In addition to the above, to improve the readability of the code,
return of -ENIVAL is replaced with -EBUSY in acpi_idle_suspend
return path. Implying that the system is currently busy when suspend
is in progress, which prevents the cpus from entering deeper C-states.
Reported-and-Tested-by: Dav Hansen <dave@linux.vnet.ibm.com>
Tested-by: Preeti Murthy <preeti@linux.vnet.ibm.com>
Signed-off-by: Deepthi Dharwar <deepthi@linux.vnet.ibm.com>
Reviewed-by: Srivatsa S Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
This patch fixed the following bug.
https://bugzilla.kernel.org/show_bug.cgi?id=43282
This is caused by a firmware bug checking (checking generic address
register provided by firmware) in runtime. The checking should be
done in address mapping time instead of runtime to avoid too much
error reporting in runtime.
Reported-by: Pawel Sikora <pluto@agmk.net>
Signed-off-by: Huang Ying <ying.huang@intel.com>
Tested-by: Jean Delvare <khali@linux-fr.org>
Cc: stable@vger.kernel.org
Signed-off-by: Len Brown <len.brown@intel.com>
Update bugfix-video branch to 2.5-rc1
so I don't have to again resolve the
conflict in these patches vs. upstream.
Conflicts:
drivers/gpu/drm/gma500/psb_drv.c
text conflict: add comment vs delete neighboring line
keep just this:
/* igd_opregion_init(&dev_priv->opregion_dev); */
/* acpi_video_register(); */
Signed-off-by: Len Brown <len.brown@intel.com>
Fix the following build warning:
warning: (ACPI_HOTPLUG_CPU) selects ACPI_CONTAINER which has unmet direct dependencies (ACPI && EXPERIMENTAL)
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Len Brown <len.brown@intel.com>
We can't use "input" anymore after calling input_unregister_device().
The call to input_free_device() is a double free. The normal way to
deal with this is to make input_register_device() the last function
called in the function.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Dmitry Torokhov <dtor@mail.ru>
Signed-off-by: Len Brown <len.brown@intel.com>
Stop it poking at random registers on the i740 cards that may be out there
still.
As per Matthew's feedback remove the conditional checks and never enable the
opregion handling unless an appropriate driver has been loaded.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Revert usage of acpi_wakeup_address and move definition
to x86 architecture code in order to make compilation work
in ia64.
[jsakkine: tested compilation in ia64/x86-64 and added
proper commit message]
Reported-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Originally-by: H. Peter Anvin <hpa@kernel.org>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@intel.com>
Link: http://lkml.kernel.org/r/1338370421-27735-1-git-send-email-jarkko.sakkinen@intel.com
Cc: Tony Luck <tony.luck@intel.com>
Cc: Len Brown <lenb@kernel.org>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Pull x86 trampoline rework from H. Peter Anvin:
"This code reworks all the "trampoline"/"realmode" code (various bits
that need to live in the first megabyte of memory, most but not all of
which runs in real mode at some point) in the kernel into a single
object. The main reason for doing this is that it eliminates the last
place in the kernel where we needed pages to be mapped RWX. This code
separates all that code into proper R/RW/RX pages."
Fix up conflicts in arch/x86/kernel/Makefile (mca removed next to reboot
code), and arch/x86/kernel/reboot.c (reboot code moved around in one
branch, modified in this one), and arch/x86/tools/relocs.c (mostly same
code came in earlier due to working around the ld bugs just before the
3.4 release).
Also remove stale x86-relocs entry from scripts/.gitignore as per Peter
Anvin.
* commit '61f5446169046c217a5479517edac3a890c3bee7': (36 commits)
x86, realmode: Move end signature into header.S
x86, relocs: When printing an error, say relative or absolute
x86, relocs: More relocations which may end up as absolute
x86, relocs: Workaround for binutils 2.22.52.0.1 section bug
xen-acpi-processor: Add missing #include <xen/xen.h>
acpi, bgrd: Add missing <linux/io.h> to drivers/acpi/bgrt.c
x86, realmode: Change EFER to a single u64 field
x86, realmode: Move kernel/realmode.c to realmode/init.c
x86, realmode: Move not-common bits out of trampoline_common.S
x86, realmode: Mask out EFER.LMA when saving trampoline EFER
x86, realmode: Fix no cache bits test in reboot_32.S
x86, realmode: Make sure all generated files are listed in targets
x86, realmode: build fix: remove duplicate build
x86, realmode: read cr4 and EFER from kernel for 64-bit trampoline
x86, realmode: fixes compilation issue in tboot.c
x86, realmode: move relocs from scripts/ to arch/x86/tools
x86, realmode: header for trampoline code
x86, realmode: flattened rm hierachy
x86, realmode: don't copy real_mode_header
x86, realmode: fix 64-bit wakeup sequence
...
The comparison between the system sleep state being entered
and the lowest system sleep state the given device may wake up
from in acpi_pm_device_sleep_state() is reversed, because the
specification (ACPI 5.0) says that for wakeup to work:
"The sleeping state being entered must be less than or equal to the
power state declared in element 1 of the _PRW object."
In other words, the state returned by _PRW is the deepest
(lowest-power) system sleep state the device is capable of waking up
the system from.
Moreover, acpi_pm_device_sleep_state() also should check if the
wakeup capability is supported through ACPI, because in principle it
may be done via native PCIe PME, for example, in which case _SxW
should not be evaluated.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
After recent changes of the ACPI device power states definitions, if
power resources are not used for the device's power management, the
state returned by __acpi_bus_get_power() cannot exceed D3hot, because
the return values of _PSC are 0 through 3. However, if the _PR3
method is not present for the device and _PS3 returns 3, we have to
assume that the device is in D3cold, so the value returned by
__acpi_bus_get_power() in that case should be 4.
Similarly, acpi_power_get_inferred_state() should take the power
resources for the D3hot state into account in general, so that it
can return 3 if those resources are "on" or 4 (D3cold) otherwise.
Fix the the above two issues and make sure that if both _PSC and
_PR3 are present for the device, the power resources listed by _PR3
will be used to determine if the number 3 returned by _PSC is meant
to represent D3cold or D3hot.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
After recent changes of the ACPI device low-power states definitions
kernel messages in drivers/acpi/bus.c need to be updated so that they
include the correct names of the states in question (currently is
"D3" for D3hot and "D4" for D3cold, which is incorrect).
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
When the system is woken up by the ACPI fixed power button, currently there
is no way of userspace becoming aware that the power button was pressed.
OLPC would like to know this, so that we can respond appropriately.
For example, if the system was woken up by a network packet, we know
we can go back to sleep very quickly. But if the user explicitly woke the
system with the power button, we're going to want to stay awake for a
while.
The wakeup count mechanism seems like a good fit for communicating this.
Mark the fixed power button as wakeup-enabled, and increment its wakeup
counter when the system is woken with the power button. (The wakeup counter
is also incremented when the power button is pressed during system
operation; this is already handled by an existing acpi-button codepath).
Signed-off-by: Daniel Drake <dsd@laptop.org>
Acked-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Here's the driver core, and other driver subsystems, pull request for
the 3.5-rc1 merge window.
Outside of a few minor driver core changes, we ended up with the
following different subsystem and core changes as well, due to
interdependancies on the driver core:
- hyperv driver updates
- drivers/memory being created and some drivers moved into it
- extcon driver subsystem created out of the old Android staging switch
driver code
- dynamic debug updates
- printk rework, and /dev/kmsg changes
All of this has been tested in the linux-next releases for a few weeks
with no reported problems.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
iEYEABECAAYFAk+7q28ACgkQMUfUDdst+ykXmwCfcPASzC+/bDkuqdWsqzxlWZ7+
VOQAnAriySv397St36J6Hz5bMQZwB1Yq
=SQc+
-----END PGP SIGNATURE-----
Merge tag 'driver-core-3.5-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core
Pull driver core updates from Greg Kroah-Hartman:
"Here's the driver core, and other driver subsystems, pull request for
the 3.5-rc1 merge window.
Outside of a few minor driver core changes, we ended up with the
following different subsystem and core changes as well, due to
interdependancies on the driver core:
- hyperv driver updates
- drivers/memory being created and some drivers moved into it
- extcon driver subsystem created out of the old Android staging
switch driver code
- dynamic debug updates
- printk rework, and /dev/kmsg changes
All of this has been tested in the linux-next releases for a few weeks
with no reported problems.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>"
Fix up conflicts in drivers/extcon/extcon-max8997.c where git noticed
that a patch to the deleted drivers/misc/max8997-muic.c driver needs to
be applied to this one.
* tag 'driver-core-3.5-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (90 commits)
uio_pdrv_genirq: get irq through platform resource if not set otherwise
memory: tegra{20,30}-mc: Remove empty *_remove()
printk() - isolate KERN_CONT users from ordinary complete lines
sysfs: get rid of some lockdep false positives
Drivers: hv: util: Properly handle version negotiations.
Drivers: hv: Get rid of an unnecessary check in vmbus_prep_negotiate_resp()
memory: tegra{20,30}-mc: Use dev_err_ratelimited()
driver core: Add dev_*_ratelimited() family
Driver Core: don't oops with unregistered driver in driver_find_device()
printk() - restore prefix/timestamp printing for multi-newline strings
printk: add stub for prepend_timestamp()
ARM: tegra30: Make MC optional in Kconfig
ARM: tegra20: Make MC optional in Kconfig
ARM: tegra30: MC: Remove unnecessary BUG*()
ARM: tegra20: MC: Remove unnecessary BUG*()
printk: correctly align __log_buf
ARM: tegra30: Add Tegra Memory Controller(MC) driver
ARM: tegra20: Add Tegra Memory Controller(MC) driver
printk() - restore timestamp printing at console output
printk() - do not merge continuation lines of different threads
...
Here is the big USB 3.5-rc1 pull request for the 3.5-rc1 merge window.
It's touches a lot of different parts of the kernel, all USB drivers,
due to some API cleanups (getting rid of the ancient err() macro) and
some changes that are needed for USB 3.0 power management updates.
There are also lots of new drivers, pimarily gadget, but others as well.
We deleted a staging driver, which was nice, and finally dropped the
obsolete usbfs code, which will make Al happy to never have to touch
that again.
There were some build errors in the tree that linux-next found a few
days ago, but those were fixed by the most recent changes (all were due
to us not building with CONFIG_PM disabled.)
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
iEYEABECAAYFAk+7qs0ACgkQMUfUDdst+ymjOgCfeoWqWk1bsKKt6SZULvQois5i
3csAn1Uapcm8Uswwpnj2v1/2Zh4rBHLA
=4jM1
-----END PGP SIGNATURE-----
Merge tag 'usb-3.5-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Pull USB 3.5-rc1 changes from Greg Kroah-Hartman:
"Here is the big USB 3.5-rc1 pull request for the 3.5-rc1 merge window.
It's touches a lot of different parts of the kernel, all USB drivers,
due to some API cleanups (getting rid of the ancient err() macro) and
some changes that are needed for USB 3.0 power management updates.
There are also lots of new drivers, pimarily gadget, but others as
well. We deleted a staging driver, which was nice, and finally
dropped the obsolete usbfs code, which will make Al happy to never
have to touch that again.
There were some build errors in the tree that linux-next found a few
days ago, but those were fixed by the most recent changes (all were
due to us not building with CONFIG_PM disabled.)
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>"
* tag 'usb-3.5-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (477 commits)
xhci: Fix DIV_ROUND_UP compile error.
xhci: Fix compile with CONFIG_USB_SUSPEND=n
USB: Fix core compile with CONFIG_USB_SUSPEND=n
brcm80211: Fix compile error for .disable_hub_initiated_lpm.
Revert "USB: EHCI: work around bug in the Philips ISP1562 controller"
MAINTAINERS: Add myself as maintainer to the USB PHY Layer
USB: EHCI: fix command register configuration lost problem
USB: Remove races in devio.c
USB: ehci-platform: remove update_device
USB: Disable hub-initiated LPM for comms devices.
xhci: Add Intel U1/U2 timeout policy.
xhci: Add infrastructure for host-specific LPM policies.
USB: Add macros for interrupt endpoint types.
xhci: Reserve one command for USB3 LPM disable.
xhci: Some Evaluate Context commands must succeed.
USB: Disable USB 3.0 LPM in critical sections.
USB: Add support to enable/disable USB3 link states.
USB: Allow drivers to disable hub-initiated LPM.
USB: Calculate USB 3.0 exit latencies for LPM.
USB: Refactor code to set LPM support flag.
...
Conflicts:
arch/arm/mach-exynos/mach-nuri.c
arch/arm/mach-exynos/mach-universal_c210.c
drivers/net/wireless/ath/ath6kl/usb.c
Commit 1cc0c998fd ("ACPI: Fix D3hot v D3cold confusion") introduced a
bug in __acpi_bus_set_power() and changed the behavior of
acpi_pci_set_power_state() in such a way that it generally doesn't work
as expected if PCI_D3hot is passed to it as the second argument.
First off, if ACPI_STATE_D3 (equal to ACPI_STATE_D3_COLD) is passed to
__acpi_bus_set_power() and the explicit_set flag is set for the D3cold
state, the function will try to execute AML method called "_PS4", which
doesn't exist.
Fix this by adding a check to ensure that the name of the AML method
to execute for transitions to ACPI_STATE_D3_COLD is correct in
__acpi_bus_set_power(). Also make sure that the explicit_set flag
for ACPI_STATE_D3_COLD will be set if _PS3 is present and modify
acpi_power_transition() to avoid accessing power resources for
ACPI_STATE_D3_COLD, because they don't exist.
Second, if PCI_D3hot is passed to acpi_pci_set_power_state() as the
target state, the function will request a transition to
ACPI_STATE_D3_HOT instead of ACPI_STATE_D3. However,
ACPI_STATE_D3_HOT is now only marked as supported if the _PR3 AML
method is defined for the given device, which is rare. This causes
problems to happen on systems where devices were successfully put
into ACPI D3 by pci_set_power_state(PCI_D3hot) which doesn't work
now. In particular, some unused graphics adapters are not turned
off as a result.
To fix this issue restore the old behavior of
acpi_pci_set_power_state(), which is to request a transition to
ACPI_STATE_D3 (equal to ACPI_STATE_D3_COLD) if either PCI_D3hot or
PCI_D3cold is passed to it as the argument.
This approach is not ideal, because generally power should not
be removed from devices if PCI_D3hot is the target power state,
but since this behavior is relied on, we have no choice but to
restore it at the moment and spend more time on designing a
better solution in the future.
References: https://bugzilla.kernel.org/show_bug.cgi?id=43228
Reported-by: rocko <rockorequin@hotmail.com>
Reported-by: Cristian Rodríguez <crrodriguez@opensuse.org>
Reported-and-tested-by: Peter <lekensteyn@gmail.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The ACPI BGRT driver uses ioremap() and memcpy_fromio(), which means
it needs to #include <linux/io.h>.
[ hpa: This was hidden because <asm/acpi.h> used to include <asm/trampoline.h>,
which then included <asm/io.h> ]
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Link: http://lkml.kernel.org/r/1336597442-9399-1-git-send-email-hpa@linux.intel.com
Cc: Matthew Garrett <mjg@redhat.com>
Cc: Len Brown <lenb@kernel.org>
Add a simple helper function to allow drivers to obtain the physical
device location data.
Acked-by: Len Brown <len.brown@intel.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
It's unreasonable to have CONFIG_ACPI for these in drivers, so add some
stub functions.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
