Conflicts:

	drivers/misc/Kconfig
Signed-off-by: Len Brown <len.brown@intel.com>

the Sony Programmable I/O Control driver uses a semaphore as
mutex. use the mutex API instead of the (binary) semaphore
Signed-off-by: Matthias Kaehlcke <matthias.kaehlcke@gmail.com>
Acked-by: Mattia Dongili <malattia@linux.it>
Signed-off-by: Len Brown <len.brown@intel.com>

Avoid giving the user the possibility to shoot his own foot and let
the meye driver enable/disable the camera wisely (PCI_ID based).
Signed-off-by: Mattia Dongili <malattia@linux.it>
Signed-off-by: Len Brown <len.brown@intel.com>

Change sonypi_camera_command() calls to sony_pic_camera_command() and use
the renamed macros.
Signed-off-by: Mattia Dongili <malattia@linux.it>
Signed-off-by: Len Brown <len.brown@intel.com>

Copy and rename (for easier co-existence) the MEYE-wise exported interface.
Signed-off-by: Mattia Dongili <malattia@linux.it>
Signed-off-by: Len Brown <len.brown@intel.com>

Add the exported sony_pic_camera_command() function to make the MEYE
driver happy.
Signed-off-by: Mattia Dongili <malattia@linux.it>
Signed-off-by: Len Brown <len.brown@intel.com>

Get the IO resources list in sony-laptop in the same order as listed
in sonypi and make sonypi check if one of those is already busy.
The sonypi check can be disabled by a module parameter in case the user
thinks we are plainly wrong (check_ioport=0).
Signed-off-by: Mattia Dongili <malattia@linux.it>
Signed-off-by: Len Brown <len.brown@intel.com>

Try to migrate sonypi users to sony-laptop gracefully.
Signed-off-by: Mattia Dongili <malattia@linux.it>
Signed-off-by: Len Brown <len.brown@intel.com>

Some SZ Vaios have a gsm built-in modem. Allow powering on/off this device.
Thanks to Joshua Wise for the base code.
Signed-off-by: Mattia Dongili <malattia@linux.it>
Signed-off-by: Len Brown <len.brown@intel.com>

Better avoid having ioport commands mixing and global variables reading/writing.
Signed-off-by: Mattia Dongili <malattia@linux.it>
Signed-off-by: Len Brown <len.brown@intel.com>

Use a parameter to enable/disable motion eye camera (for C1VE/C1VN models)
controls and avoid entering an infinite loop if the camera is not present
and the HW doesn't answer as we expect on io commands.
Signed-off-by: Mattia Dongili <malattia@linux.it>
Signed-off-by: Len Brown <len.brown@intel.com>

This patch makes the needlessly global fan_mutex static.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len Brown <len.brown@intel.com>

Add support to sysfs to the wan and bluetooth subdrivers.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len Brown <len.brown@intel.com>

Add the hotkey sysfs support.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len Brown <len.brown@intel.com>

The dock sub-driver has split-personality (two subdrivers), and it was
doing some unoptimal things on init because of that.  Fix it so that the
second half of it will only init when necessary, and only if the first half
initialized sucessfully in the first place.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len Brown <len.brown@intel.com>

Some issues with the dock subdriver proved that a slightly improved
debugging setup for ACPI notifiers and handler helpers would be useful.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len Brown <len.brown@intel.com>

Improve fan control documentation and fix one mistake.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len Brown <len.brown@intel.com>

Currently, all fan control operations return ENXIO if unsupported
operations are requested, but return EINVAL if invalid fan modes are
requested on a given ThinkPad.

This is not strictly correct for sysfs, so map ENXIO to EINVAL in the sysfs
attribute store handlers, as we do benefit from the ENXIO in other parts of
the driver code.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len Brown <len.brown@intel.com>

The fan control watchdog was being called in one place even when the fan
control operation had failed.  Fix it.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len Brown <len.brown@intel.com>

Do not enable/rearm the fan control safety watchdog if we would not be able
to do anything to the fan anyway.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len Brown <len.brown@intel.com>

Len Brown considers that an active by default fan control interface in
laptops may be too close to giving users enough rope.  There is a good
chance he is quite correct on this, especially if someone decides to use
that interface in applets and users are not aware of its risks.

This patch adds a master switch to thinkpad-acpi that enables or disables
the entire fan-control feature as a module parameter: "fan_control".  It
defaults to disabled.  Set it to non-zero to enable fan control.

Also, the patch removes the expermiental status from fan control, since it
is stable enough to not be called experimental, and the master switch makes
it safe enough to do so.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len Brown <len.brown@intel.com>

Linux-2.6.21 stopped booting on a P4/HT because Linux
wrote the FADT.CST_CNT value to the SMI_CMD.
Apparently this stumbled over some SMM instability,
such as confusing SMM when invoking it from cpu1.

Linux did this because even though the r2 FADT reserves
the CST_CNT field, this BIOS set that field and Linux
used it.

Turns out that up through 2.6.20 we explicitly cleared
cst_control for r2 FADTs.  So here we go back to doing that,
plus also clear some additional fields that are reserved
until FADT r3.

http://bugzilla.kernel.org/show_bug.cgi?id=8346Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>

.. ok, enough waffling about it already. "Just do it!"
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

* master.kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6:
  [PARPORT] SUNBPP: Fix OOPS when debugging is enabled.
  [SPARC] openprom: Switch to ref counting PCI API

* master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6:
  [NETLINK]: Infinite recursion in netlink.

The packet driver is assuming (reasonably) that the (undocumented)
request.errors is an errno.  But it is in fact some mysterious bitfield.  When
things go wrong we return weird positive numbers to the VFS as pointers and it
goes oops.

Thanks to William Heimbigner for reporting and diagnosis.

(It doesn't oops, but this driver still doesn't work for William)

Cc: William Heimbigner <icxcnika@mar.tar.cc>
Cc: Peter Osterlund <petero2@telia.com>
Cc: Jens Axboe <jens.axboe@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Reply to NETLINK_FIB_LOOKUP messages were misrouted back to kernel,
which resulted in infinite recursion and stack overflow.

The bug is present in all kernel versions since the feature appeared.

The patch also makes some minimal cleanup:

1. Return something consistent (-ENOENT) when fib table is missing
2. Do not crash when queue is empty (does not happen, but yet)
3. Put result of lookup
Signed-off-by: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Signed-off-by: David S. Miller <davem@davemloft.net>

Signed-off-by: Zachary Amsden <zach@vmware.com>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len Brown <len.brown@intel.com>

The following patch prevent this warning to be displayed again & again (eg:
nine times on my NForce2 motherboard) and thus improve signal to noise
ratio in logs.

The ATI quirk below probably needs a similar "fix" but I don't have
the hardware to test.

Btw arch/x86_64/kernel/early-quirks.c::nvidia_bugs() would probably need to
be synced (but I don't have an x86_64 NVidia motherboard to boot test it).
Still it shows the usefullity of the recent x86 merge thread.

[akpm@linux-foundation.org: cleanup]
Signed-off-by: Thierry Vignaud <tvignaud@mandriva.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len Brown <len.brown@intel.com>

This updates /proc/acpi/wakeup to be more informative, primarily by showing
the sysfs node associated with each wakeup-enabled device.  Example:

	Device	S-state	  Status   Sysfs node
	PCI0	  S4	 disabled  no-bus:pci0000:00
	PS2M	  S4	 disabled  pnp:00:05
	PS2K	  S4	 disabled  pnp:00:06
	UAR1	  S4	 disabled  pnp:00:08
	USB1	  S3	 disabled  pci:0000:00:03.0
	USB2	  S3	 disabled  pci:0000:00:03.1
	USB3	  S3	 disabled
	USB4	  S3	 disabled  pci:0000:00:03.3
	S139	  S4	 disabled
	LAN	  S4	 disabled  pci:0000:00:04.0
	MDM	  S4	 disabled
	AUD	  S4	 disabled  pci:0000:00:02.7
	SLPB	  S4	*enabled

Eventually this file should be removed, but until then it's almost the only
way we have to tell how the relevant ACPI tables are broken (and cope).  In
that example, two devices don't actually exist (USB3, S139), one can't issue
wakeup events (PCI0), and two seem harmlessly (?) confused (MDM and AUD are
the same PCI device, but it's the _modem_ that does wake-on-ring).

In particular, we need to be sure driver model nodes are properly hooked
up before we can get rid of this ACPI-only interface for wakeup events.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len Brown <len.brown@intel.com>

Signed-off-by: <bbpetkov@yahoo.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len Brown <len.brown@intel.com>

Signed-off-by: Daniel Walker <dwalker@mvista.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len Brown <len.brown@intel.com>

Be explicit about what "device->status = 0x0F" really means.

syntax only.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len Brown <len.brown@intel.com>