Simple fix to make pci_enable/disable symetric and avoid the warning on
module unload.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Added M6Ne PCI IDs in asus_hides_smbus_hostbridge() function
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Stephen Rothwell noted a case where one CPU was sitting in userspace, one
in stop_machine() waiting for everyone to enter stopmachine().  This can
happen if migration occurs at exactly the wrong time with more than 2 CPUS.
 Say we have 4 CPUS:

1) stop_machine() on CPU 0creates stopmachine() threads for CPUS 1, 2
   and 3, and yields waiting for them to migrate to their CPUs and
   ack.

2) stopmachine(2) gets rebalanced (probably on exec) to CPU 1.

3) stopmachine(2) calls set_cpus_allowed on CPU 1, sleeps awaiting
   migration thread.

4) stopmachine(1) calls set_cpus_allowed on CPU 0, moves onto CPU1 and
   starts spinning.

Now the migration thread never runs, and we deadlock.  The simplest
solution is for stopmachine() to yield until they are all in place.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

You can't call module_param et al inside a function.  It doesn't make
sense, and it doesn't work.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Move this error-handling into a separate function so that its sizeable stack
utilisation is avoided - generic_make_request() can be called recursively by
stacking drivers.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Here's a patch which fixes the deadlock Brad Fitzpatrick reported here:
http://lkml.org/lkml/2004/11/14/98

The meat of the problem is a locking order reversal between the XFS I/O
lock and the inode semaphore (i_sem).  When we mix a number of threads
doing both direct reads and writes, we hit an ABBA deadlock after a while
because direct-io.c is taking and dropping i_sem after the XFS read path
has already taken its I/O lock.  This is the wrong way around from XFS's
point of view, in particular its the opposite order to the XFS write path. 
So this patch changes the logic for direct reads in the DIO_OWN_LOCKING
case (i.e.  XFS-only case), but leaves things as is for the other two types
of locking.

Not real pretty, but fixes up the lock ordering and deadlock.

Oh, I have tested direct reads and writes on ext3 and block devices as
well, to ensure they still function correctly with the change (i.e.  they
don't regress, should be a no-op there) which covers the other locking
cases in __blockdev_direct_IO.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

When cont_prepare_write() is padding out the "hole" with zeroed pages it
doesn't increase i_size at the same time.  If writeback comes in during the
execution of cont_prepare_write(), block_write_full_page() will think that
these pages are outside i_size and will just clean the page without writing
it.

Fix that up by using generic_commit_write(), which will advance i_size for
each page as it is dirtied.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

This patch fix a deadlock in CAPI device driver registration code and
reenable SMP for the activ AVM cards., also some minor cleanup and fixes.
Signed-off-by: Karsten Keil <kkeil@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Here is a patch to update AR camera device driver.

drivers/media/video/arv.c:

- Remove warnings; use module_param() instead of MODULE_PARM(), because
  MODULE_PARM() is deprecated.

- Fix white-space damages.
Signed-off-by: Hirokazu Takata <takata@linux-m32r.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Vadim says:

I was reading through the kernel/power/Kconfig file, and noticed that
the wording was slightly unclear. I poked at it a bit, hopefully making
the description a tad more straightforward, but you be the judge. :)
Diffed against 2.6.10-rc2.

From: Vadim Lobanov <vlobanov@speakeasy.net>
Signed-off-by: Vadim Lobanov <vlobanov@speakeasy.net>
Signed-off-by: Pavel Machek <pavel@suse.cz>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Use time_after_eq instead of >=

From: Michal Schmidt <xschmi00@stud.feec.vutbr.cz>
Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

raid10 performs resync by reading all blocks, comparing to look for The
requires re-tasking a bio that was used to read, so that it can be re-used
for write.  So a number of fields need to be reset.

The bi_bdev field was not being reset.  However when using on a partition
of a device, it gets changed by generic_make_request.

This patch simply resets bi_bdev to the correct value.
Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

With Chris Wright <chrisw@osdl.org>

struct task_struct.comm is defined to be 16 chars, but
arch/x86_64/sys_ia32.c:sys32_ni_syscall() and sys32_vm86_warning() copy it
into a static 8 byte buffer, which will surely cause problems.  This patch
makes lastcomm[] the right size, and makes sure it can't be overrun.  Since
the code also goes to the effort of getting a local copy of current in "me",
we may as well use it for printing the message.
Signed-off-by: Chris Wright <chrisw@osdl.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

 o General updates of MIPS to 2.6.10-rc2
 o Remove the Baget platform due to lack of maintenance over several years.
   Some of the drivers remain and will be removed in a separate patch.
 o Remove the HP Laserjet platform.  No user reports ever and no patches from
   the original submitters made this port a neat hack - and a directory full
   of clutter.
 o SMP support for the PMC-Sierra.
Signed-Off-By: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

into ppc970.osdl.org:/home/torvalds/v2.6/linux

Patch from Holger Hans Peter Freyther

arch/arm/mach-sa1100/KConfig had options for USB client. The related code was removed early in 2.6. releases.
I think it is appropriate to remove the Config options for it itself, as they're void.



Signed-off-by: Holger Hans Peter Freyther
Signed-off-by: Russell King

Patch from Tony Lindgren

This patch by Tuukka Tikkanen & me cleans up the OMAP MPU timer
code to allow adding 32KHz timer support. Functionality is the
same as earlier.

Signed-off-by: Tony Lindgren 
Signed-off-by: Russell King

Patch from Nicolas Pitre

Those functions are marked __init and called from __init context
as well.  They have no business with modules what so ever.

Signed-off-by: Nicolas Pitre
Signed-off-by: Russell King

into ppc970.osdl.org:/home/torvalds/v2.6/linux

Patch from Nicolas Pitre

Signed-off-by: Nicolas Pitre
Signed-off-by: Russell King

into ppc970.osdl.org:/home/torvalds/v2.6/linux

into intel.com:/home/lenb/src/26-latest-dev

Now "max_cstate=" instead of "acpi_cstate_limit="
Delete redundant static cstate flags .c2 and .c3

http://bugme.osdl.org/show_bug.cgi?id=3549
   
   For static processor driver, boot cmdline:
   processor.max_cstate=2
   
   For processor module, /etc/modprobe.conf:
   options processor max_cstate=2
   or
   # modprobe processor max_cstate=2
   
   From kernel or kernel module:
   #include <linux/acpi.h>
   acpi_set_cstate_limit(2);
 
Suggested-by: Pavel Machek
Signed-off-by: Len Brown <len.brown@intel.com>

into intel.com:/home/lenb/src/26-latest-dev

http://bugzilla.kernel.org/show_bug.cgi?id=3643Signed-off-by: Alexey Y Starikovskiy <alexey.y.starikovskiy@intel.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Len Brown <len.brown@intel.com>

into ppc970.osdl.org:/home/torvalds/v2.6/linux

into intel.com:/home/lenb/src/26-latest-dev

into intel.com:/home/lenb/src/26-latest-dev

Signed-off-by: Len Brown <len.brown@intel.com>

http://bugzilla.kernel.org/show_bug.cgi?id=3669Signed-off-by: David Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>

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

into ppc970.osdl.org:/home/torvalds/v2.6/linux

Signed-off-by: Thomas Graf <tgraf@suug.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>

so call it ioapic_renumber_irq().

A note to google:
GSI is a Global System Interrupt -- a flat, linear, global IRQ number.

Suggested-by: Linus Torvalds
Signed-off-by: Len Brown <len.brown@intel.com>

Alternate workaround for blocking usage of select() by UDP applications.
The problem is Linux optimizes the UDP receive checksum path so that checksum
validation is not performed until the application read. This is a performance win
but can cause applications that do select with blocking file descriptors to get false
positives if the received message has a checksum error.
There is a long running thread about this on LKML.

This patch makes these applications work, but keeps the one-pass performance gain
for those applications smart enough to use non-blocking file descriptors with
select/poll. There is still a possibility to get a false positive if application does
select on non-blocking fd then makes it blocking before doing the receive, but that
is unlikely.

Tested by injecting bad packets with SOCK_RAW.
Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

into ppc970.osdl.org:/home/torvalds/v2.6/linux

into ppc970.osdl.org:/home/torvalds/v2.6/linux