When CONFIG_ACPI_SYSFS_POWER=n and CONFIG_ACPI_PROCFS_POWER=n, then
we're warned by the following warning:

drivers/acpi/sbs.c: In function `acpi_battery_remove':
drivers/acpi/sbs.c:825: warning: unused variable `battery'
Signed-off-by: NRakib Mullick <rakib.mullick@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLen Brown <len.brown@intel.com>

The ids field of the struct acpi_driver is constant in <linux/acpi/acpi_bus.h>
so it is worth to make the initialization data also constant.

The semantic match that finds this kind of pattern is as follows:
(http://coccinelle.lip6.fr/)

// <smpl>
@r@
disable decl_init,const_decl_init;
identifier I1, I2, x;
@@
	struct I1 {
	  ...
	  const struct I2 *x;
	  ...
	};
@s@
identifier r.I1, y;
identifier r.x, E;
@@
	struct I1 y = {
	  .x = E,
	};
@c@
identifier r.I2;
identifier s.E;
@@
	const struct I2 E[] = ... ;
@depends on !c@
identifier r.I2;
identifier s.E;
@@
+	const
	struct I2 E[] = ...;
// </smpl>
Signed-off-by: NMárton Németh <nm127@freemail.hu>
Cc: Julia Lawall <julia@diku.dk>
Cc: cocci@diku.dk
Signed-off-by: NLen Brown <len.brown@intel.com>

CC [M]  drivers/platform/x86/sony-laptop.o
drivers/platform/x86/sony-laptop.c: In function 'sony_nc_rfkill_setup':
drivers/platform/x86/sony-laptop.c:1162: warning: 'i' may be used uninitialized in this function
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
Acked-by: NMattia Dongili <malattia@linux.it>
Signed-off-by: NLen Brown <len.brown@intel.com>

Alex Chiang introduced acpi_early_processor_set_pdc() in commit:
 ACPI: processor: call _PDC early
 78f16996

But this results in a section mismatch:

WARNING: drivers/acpi/acpi.o(.text+0xa9c1): Section mismatch in reference from the
function acpi_early_processor_set_pdc() to the variable .cpuinit.data:processor_idle_dmi_table
The function acpi_early_processor_set_pdc() references
the variable __cpuinitdata processor_idle_dmi_table.
This is often because acpi_early_processor_set_pdc lacks a __cpuinitdata
annotation or the annotation of processor_idle_dmi_table is wrong.

The only caller of acpi_early_processor_set_pdc() is acpi_bus_init() which
is an "__init" function. So the correct fix here is to mark
acpi_early_processor_set_pdc() "__init" too.
Signed-off-by: NTony Luck <tony.luck@intel.com>
Acked-by: NAlex Chiang <achiang@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

The struct seq_file 'private' member is a void *, the cast is not needed.
Also, remove an extra whitespace line.
Signed-off-by: NH Hartley Sweeten <hsweeten@visionengravers.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

In bbc_envctrl_init() we have to unlink the fan and temp instances
from the lists because our caller is going to free up the 'bp' object
if we return an error.

We can't rely upon bbc_envctrl_cleanup() to do this work for us in
this case.
Reported-by: NPatrick Finnegan <pat@computer-refuge.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

We kill the guest, but then we blatt random stuff.
Reported-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Cc: stable@kernel.org
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

We wrap the smm calls and other bits with the BKL push down as a
precaution but they can probably go
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Nobody seems to want to own I2O patches so sending this one directly.
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The BKL is in this function because of the BKL pushdown (see commit
f8f2c79d)

It is not needed here because the mutex_lock sonypi_device.lock provides
the necessary locking.

sonypi_misc_ioctl can be converted to unlocked ioctls since it relies on
its own locking (the mutex sonypi_device.lock) and not the bkl

Document that llseek is not needed by explictly setting it to no_llseek

LKML-Reference: <alpine.LFD.2.00.0910192019420.3563@localhost.localdomain>
Signed-off-by: NJohn Kacur <jkacur@redhat.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Revamp the qdio performance statistics and move them from procfs to
debugfs using the seq_file interface. Since the statistics are not
intended for the general user the removal of /proc/qdio_perf should
not surprise anyone.

The per device statistics are disabled by default, writing 1 to
/<debugfs mountpoint>/qdio/<device bus ID>/statistics enables the
statistics for the given device.
Signed-off-by: NJan Glauber <jang@linux.vnet.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

Commit 239007b8 ("genirq: Convert irq_desc.lock to raw_spinlock")
seems to have missed this driver, leaving it to use the normal spin-lock
functions for the irq descriptor lock, which is now a raw lock.
Reported-and-compile-tested-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Introduced by commit 5b889bf2 ("PCI: Fix build if quirks are not
enabled"), which made the pci_dev_reset_methods[] array static and
'const', but didn't then change the code to match, and use a const
pointer when moving it to quirks.c.

Trivially fixed by just adding the required 'const' to the iterator
variable.
Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

After commit b9c3b266 ("PCI: support
device-specific reset methods") the kernel build is broken if
CONFIG_PCI_QUIRKS is unset.

Fix this by moving pci_dev_specific_reset() to drivers/pci/quirks.c and
providing an empty replacement for !CONFIG_PCI_QUIRKS builds.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Reported-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Introduce kernel parameter acpi_sleep=sci_force_enable

some laptop requires SCI_EN being set directly on resume,
or else they hung somewhere in the resume code path.

We already have a blacklist for these laptops but we still need
this option, especially when debugging some suspend/resume problems,
in case there are systems that need this workaround and are not yet
in the blacklist.
Signed-off-by: NZhang Rui <rui.zhang@intel.com>
Acked-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NLen Brown <len.brown@intel.com>

dell-wmi: sys_init_module: 'dell_wmi'->init suspiciously returned 21, it should follow 0/-E convention

wmi_install_notify_handler() returns an acpi_error,
but dell_wmi_init() needs return a -errno style error.
Signed-off-by: NLen Brown <len.brown@intel.com>
Tested-by: NPaul Rolland <rol@as2917.net>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: rol@as2917.net <Paul Rolland>
Signed-off-by: NLen Brown <len.brown@intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

We need to wait for the command to disable FF effects to complete before
continuing with closing the device.
Tested-by: NJohannes Ebke <johannes.ebke@physik.uni-muenchen.de>
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>

with CONFIG_GART_IOMMU enabled drivers/char/agp/amd64-agp.c has:

 #ifndef CONFIG_GART_IOMMU
 module_init(agp_amd64_init);
 module_exit(agp_amd64_cleanup);
 #endif

agp_amd64_init() was called via gart_iommu_init with
CONFIG_GART_IOMMU=y agp_amd64_init() was called via module_init
with CONFIG_GART_IOMMU=n

The commit 75f1cdf1 changes the
x86 dma initialization routine: gart_iommu_init() is called only
when GART IOMMU is detected. So when GART IOMMU isn't detected,
agp_amd64_init isn't called.

Marin Mitov reported this issue:

 http://marc.info/?l=linux-kernel&m=126192729110083&w=2

With this patch, agp_amd64_init() is always called via
module_init (the above ifndef is removed). If agp_amd64_init()
is called via gart_iommu_init() earlier, agp_amd64_init()
finishes without doing anything (when it is called via
module_init).
Reported-by: NMarin Mitov <mitov@issp.bas.bg>
Tested-by: NMarin Mitov <mitov@issp.bas.bg>
Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: davej@redhat.com
LKML-Reference: <20091228181118C.fujita.tomonori@lab.ntt.co.jp>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

It would appear that in BIOS's with nVidia hooks, the GUID
05901221-D566-11D1-B2F0-00A0C9062910 is duplicated. For now, the simplest
solution is to just ignore any duplicate GUIDs. These particular hooks are not
currently supported/ used in the kernel, so whoever does that can figure out
what the 'right' solution should be (if there's a better one).

http://bugzilla.kernel.org/show_bug.cgi?id=14846Signed-off-by: NCarlos Corbacho <carlos@strangeworlds.co.uk>
Reported-by: NLarry Finger <Larry.Finger@lwfinger.net>
Reported-by: NOldřich Jedlička <oldium.pro@seznam.cz>
Signed-off-by: NLen Brown <len.brown@intel.com>

From: Dmitry Torokhov <dmitry.torokhov@gmail.com>

The commit 1fdd407f incorrectly made driver
abort loading when known GUID is present when it should have done exactly
the opposite.
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
Signed-off-by: NLen Brown <len.brown@intel.com>

Signed-off-by: NPaul Rolland <rol@as2917.net>
Signed-off-by: NLen Brown <len.brown@intel.com>

When acpi_evaluate_object() is passed ACPI_ALLOCATE_BUFFER,
the caller must kfree the returned buffer if AE_OK is returned.

The callers of wmi_get_event_data() pass ACPI_ALLOCATE_BUFFER,
and thus must check its return value before accessing
or kfree() on the buffer.
Signed-off-by: NLen Brown <len.brown@intel.com>

Emphasize that that wmi_install_notify_handler() returns an acpi_status
rather than -errno by by testing ACPI_SUCCESS(), ACPI_FAILURE().

No functional change in this patch, but this confusion caused a bug in dell-wmi.
Signed-off-by: NLen Brown <len.brown@intel.com>

follow 0/-E convention

wmi_install_notify_handler() returns an acpi_error,
but dell_wmi_init() needs return a -errno style error.
Tested-by: NPaul Rolland <rol@as2917.net>
Signed-off-by: NLen Brown <len.brown@intel.com>

Signed-off-by: NFelipe Balbi <felipe.balbi@nokia.com>
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>

Signed-off-by: NFelipe Balbi <felipe.balbi@nokia.com>
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>

Lifebook protocol can only be activated if we find known DMI signature.
It is useles without DMI.
Reported-by: NRakib Mullick <rakib.mullick@gmail.com>
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>

This should fix the following compile warning:

drivers/input/misc/wistron_btns.c:1331:5: warning: "CONFIG_PM" is not defined
Signed-off-by: NRakib Mullick <rakib.mullick@gmail.com>
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>

The variable 'dev' is unused in function 'hgpk_register'.
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>

backlight_device_register may return an ERR_PTR
value rather than a valid pointer.

Problem found by Julia Lawall, properly fixed by Zhang Rui.
Signed-off-by: NZhang Rui <rui.zhang@intel.com>
Acked-by: NJulia Lawall <julia@diku.dk>
Signed-off-by: NLen Brown <len.brown@intel.com>

AML code always sends notifications to ACPI video device,
even if we disable the ACPI backlight control by using
boot option "acpi_backlight=vendor".

In this case we should not print any warning message.
http://bugzilla.kernel.org/show_bug.cgi?id=13671#c14Sigend-off-by: NZhang Rui <rui.zhang@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Today's -tip failed to build because commit
9e368fa0 ("ipmi: add PNP discovery (ACPI
namespace via PNPACPI)") from today's upstream kernel causes the following
build failure on x86, for CONFIG_ACPI=n && CONFIG_IPMI_SI=y:

 drivers/char/ipmi/ipmi_si_intf.c:3208: error: 'ipmi_pnp_driver' undeclared (first use in this function)
 drivers/char/ipmi/ipmi_si_intf.c:3208: error: (Each undeclared identifier is reported only once
 drivers/char/ipmi/ipmi_si_intf.c:3208: error: for each function it appears in.)
 drivers/char/ipmi/ipmi_si_intf.c:3334: error: 'ipmi_pnp_driver' undeclared (first use in this function)

The reason is that the ipmi_pnp_driver depends on ACPI facilities and is only
made available under ACPI - while the registration and unregistration is made
dependent on CONFIG_PNP:

 #ifdef CONFIG_PNP
 	pnp_register_driver(&ipmi_pnp_driver);
 #endif

The solution is to only register this driver under ACPI. (Also, the CONFIG_PNP
dependency is not needed because pnp_register_driver() is stubbed out in the
!CONFIG_PNP case.)
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Acked-by: NMyron Stowe <myron.stowe@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

If two arrays share a device, then they will not both resync at the
same time.  One will wait for the other to complete.
While waiting, the MD_RECOVERY_INTR flag is not checked so a device
failure, which would make the resync pointless, does not cause the
resync to abort, so the failed device cannot be removed (as it cannot
be remove while a resync is happening).

So add a test for MD_RECOVERY_INTR.
Reported-by: NBrett Russ <bruss@netezza.com>
Signed-off-by: NNeilBrown <neilb@suse.de>

Since commit dfc70645,
->hot_remove_disks has not removed non-failed devices from
an array until recovery is no longer possible.
So the code in do_md_run to get around the fact that
md_check_recovery (which calls ->hot_remove_disks) would
remove partially-in-sync devices is no longer needed.

So remove it.
Signed-off-by: NNeilBrown <neilb@suse.de>

By default md_do_sync() will perform recovery if no other actions are
specified.  However, action_show() relies on MD_RECOVERY_RECOVER to be
set otherwise it returns 'idle'.  So, add a missing set
MD_RECOVERY_RECOVER when starting recovery.
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NNeilBrown <neilb@suse.de>

The start_ro modules parameter can be used to force arrays to be
started in 'auto-readonly' in which they are read-only until the first
write.  This ensures that no resync/recovery happens until something
else writes to the device.  This is important for resume-from-disk
off an md array.

However if an array is started 'readonly' (by writing 'readonly' to
the 'array_state' sysfs attribute) we want it to be really 'readonly',
not 'auto-readonly'.

So strengthen the condition to only set auto-readonly if the
array is not already read-only.
Signed-off-by: NNeilBrown <neilb@suse.de>

evms configures md arrays by:
  open device
  send ioctl
  close device

for each different ioctl needed.
Since 2.6.29, the device can disappear after the 'close'
unless a significant configuration has happened to the device.
The change made by "SET_ARRAY_INFO" can too minor to stop the device
from disappearing, but important enough that losing the change is bad.

So: make sure SET_ARRAY_INFO sets mddev->ctime, and keep the device
active as long as ctime is non-zero (it gets zeroed with lots of other
things when the array is stopped).

This is suitable for -stable kernels since 2.6.29.
Signed-off-by: NNeilBrown <neilb@suse.de>
Cc: stable@kernel.org

This reverts commit 9bd568a5.

That commit is shown to cause allocation failures during initialization
on some machines.

http://bugzilla.kernel.org/show_bug.cgi?id=14844Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Update the Kconfig help texts of both stacks to encourage a general move
from the older to the newer drivers.  However, do not label ieee1394 as
"Obsolete" yet, as the newer drivers have not been deployed as default
stack in the majority of Linux distributions yet, and those who start
doing so now may still want to install the old drivers as fallback for
unforeseen issues.

Since Linux 2.6.32, FireWire audio devices can be driven by the newer
firewire driver stack too, hence remove an outdated comment about audio
devices.  Also remove comments about library versions since the 2nd
generation of libraw1394 and libdc1394 is now in common use; details on
library versions can be read at the wiki link from the help texts.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>