This changes the HCDP/PCDP support to use the early uart console
rather than using early_serial_setup().

As a consequence, ia64 serial device names will now stay constant
regardless of firmware console settings.  (A serial device selected as
an EFI console device on HP ia64 boxes used to automatically become
ttyS0.)

This also removes the ia64 early-boot kludge of assuming legacy COM
ports at 0x3f8 and 0x2f8.  For boxes that have legacy ports but no
HCDP, "console=ttyS0" will still work, but the console won't start
working until after the serial driver initializes and discovers the
devices.

WARNING:

If you have an HP machine and you're using the MP serial console port
(the connector labelled "console" on the 3-headed cable), this patch
will break your console!

HOW TO FIX IT:

 1) The console device will change from /dev/ttyS0 to /dev/ttyS1,
    ttyS2, or ttyS3, so:

    1a) Edit /etc/inittab to add a getty entry for
           /dev/ttyS1 (rx4640, rx5670, rx7620, rx8620, Superdome),
           /dev/ttyS2 (rx1600), or
           /dev/ttyS3 (rx2600).

    1b) Edit /etc/securetty to add ttyS1, ttyS2, or ttyS3.

    1c) Leave the existing ttyS0 entries in /etc/inittab and
        /etc/securetty so you can still boot old kernels.

 2) Edit /etc/elilo.conf to remove any "console=" arguments (see [1]).

 3) Run elilo to install the bootloader with new configuration.

 4) Reboot and use the EFI boot option maintenance menu to select
    exactly one device for console output, input, and standard error.
    Then do a cold reset so the changes take effect.

    For the MP console, be careful to select the device with
    "Acpi(HWP0002,700)/Pci(...)/Uart" in the path (see [2]).

DETAILS:

  - Prior to this patch, serial device names depended on the HCDP,
    which in turn depends on EFI console settings.  After this patch,
    the naming always stays the same, regardless of firmware settings.

    For example, an rx1600 with a single built-in serial port plus
    an MP has these ports:
                                   Old             Old
                  MMIO         (EFI console    (EFI console
                 address        on builtin)     on MP port)      New
                ==========      ==========      ==========     ======
    builtin     0xff5e0000        ttyS0           ttyS1         ttyS0
    MP UPS      0xf8031000        ttyS1           ttyS2         ttyS1
    MP Console  0xf8030000        ttyS2           ttyS0         ttyS2
    MP 2        0xf8030010        ttyS3           ttyS3         ttyS3
    MP 3        0xf8030038        ttyS4           ttyS4         ttyS4

  - If you want to have multiple devices in the EFI console path, you
    can, but Linux won't be able to deduce which console to use, so it
    will default to using VGA.  You can use "console=hcdp" (the UART
    device from the EFI path) or "console=ttyS<n>" to select the
    device directly.

TROUBLESHOOTING:

  - No kernel output after "Uncompressing Linux... done":

        -> You're using an MP port as the console and specified
           "console=ttyS0".  This port is now named something else.
           Remove the "console=" option.

        -> Multiple UARTs selected as EFI console devices, and you're
           looking at the wrong one.  Make sure only one UART is
           selected (use the EFI Boot Manager "Boot option maintenance"
           menu).

        -> You're physically connected to the MP port but have a
           non-MP UART selected as EFI console device.  Either move
           the console cable to the non-MP UART, or change the EFI
           console path to the MP UART (the MP UART is the one with
           "Acpi(HWP0002,700)/Pci(...)/Uart" in it.)

  - Long pause (60+ seconds) between "Uncompressing Linux... done"
    and start of kernel output:

        -> No early console, probably because you used "console=ttyS<n>".
           Remove the "console=" option.

  - Kernel and init script output works fine, but no "login:" prompt:

        -> Add getty entry to /etc/inittab for console tty.  Use the table
           in (1a) above or look for the "Adding console on ttyS<n>" message
           that tells you which device is the console.

  - "login:" prompt, but can't login as root:

        -> Add entry to /etc/securetty for console tty.

[1] When the EFI console path contains exactly one device (either
    serial or VGA), 2.6.6 and newer kernels default to that device
    automatically.  So if you remove "console=" arguments, you can use
    the same elilo configuration to boot any 2.6.6 or newer kernel
    with or without this patch.

    If you need to boot kernels older than 2.6.6 (including RHEL3 and
    SLES9), keep an 'append="console=ttyS0"' line in those elilo.conf
    stanzas.

    Non-HP machines will still need "console=" for serial consoles
    because they don't supply the HCDP table.

[2] The HP management card (MP) causes confusion because it is always
    active as an EFI console, even if it doesn't appear in the EFI
    console path.  If your console path is set to a non-MP UART, and
    you happen to be attached to the MP UART, everything works in EFI,
    but the kernel will think the non-MP UART is the console, so you
    won't see any kernel output.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

This adds an early polled-mode "uart" console driver, based on Andi Kleen's
early_printk work.

The difference is that this locates the UART device directly by its MMIO or
I/O port address, so we don't have to make assumptions about how ttyS
devices will be named.  After the normal serial driver starts, we try to
locate the matching ttyS device and start a console there.

Sample usage:
    console=uart,io,0x3f8
    console=uart,mmio,0xff5e0000,115200n8

If the baud rate isn't specified, we peek at the UART to figure it out.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Fixes oops (reference to cdrom_root_table->child->) when CONFIG_SYSCTL=y
and CONFIG_PROC_FS=n.
Signed-off-by: Randy Dunlap <rddunlap@osdl.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Fix ia64 build error: implicit declaration of function `flush_tlb_page'
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

This patch fixes the problem reported by Stas Sergeev, that kprobes steals
the virtual-8086 exceptions.  This fix modifies kprobe_handler() to return
0 when in virtual-8086 mode.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

mempolicy.c code will return the wrong policy in some cases.
Signed-off-by: Andrea Arcangeli <andrea@novell.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

With the inline symlink shmem_inode_info structure is overwritten with data
until vfs_inode, and that caused the ->policy to be a corrupted pointer
during unlink.  It wasn't immediatly easy to see what was going on due the
random mm corruption that generated a weird oops, it looked more like a
race condition on freed memory at first.

There's simply no need to set a policy for inodes, since the idx is always
zero.  All we have to do is to initialize the data structure (the semaphore
may need to run during the page allocation for the non-inline symlink) but
we don't need to allocate the rb nodes.  This way we don't need to call
mpol_free during the destroy_inode (not doable at all if the policy rbtree
is corrupt by the inline symlink ;).

An equivalent version of this patch based on a 2.6.5 tree with additional
numa features on top of this (i.e.  interleaved by default, and that's
prompted me to add a comment in the LNK init path), works fine in a numa
simulation on my laptop (untested on the bare hardware).
Signed-off-by: Andrea Arcangeli <andrea@novell.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

The modification of "Changes for arch/m32r/mm/fault.c@1.3" was
prepared for enforce-a-gap-between-heap-and-stack.patch(*) of -mm tree,
but it has not been merged into mainline.
  (*) "heap-stack-gap for 2.6" (Sep. 25, 2004)
       http://www.uwsg.iu.edu/hypermail/linux/kernel/0409.3/0435.html

So, this patch is for withdrawing the previous arch/m32r/mm/fault.c.
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>

Stomp a couple of warnings which several people have tried to fix.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

The following patch fixes these build errors on machines with CONFIG_PCI=n:

drivers/parport/parport_pc.c:3199: error: `parport_init_mode' undeclared (first use in this function)
drivers/parport/parport_pc.c:3199: error: (Each undeclared identifier is reported only once
drivers/parport/parport_pc.c:3199: error: for each function it appears in.)
Signed-off-by: Russell King <rmk@arm.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

It appears that the PURR emulation patch was the victim of the renaming of
a structure element.  The current BK kernel will not build for iSeries
without this patch.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

PREEMPT_RT on SMP systems triggered weird (very high) load average
values rather easily, which turned out to be a mainline kernel
->nr_uninterruptible handling bug in try_to_wake_up().

the following code:

        if (old_state == TASK_UNINTERRUPTIBLE) {
                old_rq->nr_uninterruptible--;

potentially executes with old_rq potentially being != rq, and hence
updating ->nr_uninterruptible without the lock held. Given a
sufficiently concurrent preemption workload the count can get out of
whack and updates might get lost, permanently skewing the global count. 
Nothing except the load-average uses nr_uninterruptible() so this
condition can go unnoticed quite easily.

the fix is to update ->nr_uninterruptible always on the runqueue where
the task currently is. (this is also a tiny performance plus for
try_to_wake_up() as a stackslot gets freed up.)

while fixing this bug i found three other ->nr_uninterruptible related
bugs:

 - the update should be moved from deactivate_task() into schedule(),
   beacause e.g. setscheduler() does deactivate_task()+activate_task(),
   which in turn may result in a -1 counter-skew if setscheduler() is
   done on a task asynchronously, which task is still on the runqueue
   but has already set ->state to TASK_UNINTERRUPTIBLE.

   sys_sched_setscheduler() is used rarely, but the bug is real. (The
   fix is also a small performance enhancement.)

   The rules for ->nr_uninterruptible updating are the following: it
   gets increased by schedule() only, when a task is moved off the
   runqueue and it has a state of TASK_UNINTERRUPTIBLE. It is decreased
   by try_to_wake_up(), by the first wakeup that materially changes the
   state from TASK_UNINTERRUPTIBLE back to TASK_RUNNING, and moves the
   task to the runqueue.

 - on CPU-hotplug down we might zap a CPU that has a nonzero counter.
   Due to the fuzzy nature of the global counter a CPU might hold a
   nonzero ->nr_uninterruptible count even if it has no tasks anymore.
   The solution is to 'migrate' the counter to another runqueue.

 - we should not return negative counter values from the
   nr_uninterruptible() function, since it accesses them without taking
   the runqueue locks, so the total sum might be slightly above or
   slightly below the real count.

I tested the attached patch on x86 SMP and it solves the load-average
problem. (I have tested CPU_HOTPLUG compilation but not functionality.) 
I think this is a must-have for 2.6.10, because there are apps that go
berzerk if load-average is too high (e.g. sendmail).
Signed-off-by: Ingo Molnar <mingo@elte.hu>
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

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

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

If security_load_policy() fails on the first try, the cache is never cleaned
up. When the policy is fixed and a reload is attempted, the old cache will
still exist, causing a BUG() in kmem_cache_create().

This patch adds a destroy operation to clean up the cache on failure.
Signed-off-by: Jeff Mahoney <jeffm@novell.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

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

Fix async IPI to not return before stack data is used.
This can fix reboot crashes and apparently helps vmware.
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Signed-off-by: Rolf Eike Beer <eike-kernel@sf-tec.de>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

drivers/pci/hotplug/cpcihp_generic.c:214: warning: return from
incompatible pointer type
Signed-off-by: Randy Dunlap <rddunlap@osdl.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

this patch improves rpaphp_find_pci_dev. First it uses the for_each_pci_dev
macro instead of the while loop, making this hotplug safe (which is a good
idea in a hotplug driver, isn't it?). Then it removes retval_dev. retval_dev
is set to the found device when something is found, NULL otherwise. If
nothing is found dev will be NULL at the end of the loop anyway and the
found device if we found something, no need for retval_dev then. And a very
small coding style fix.
Signed-off-by: Rolf Eike Beer <eike-hotplug@sf-tec.de>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Remove unused the drivers/pci/hotplug/pciehp_sysfs.c
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

This patch started as as405 from Alan Stern.  It has been re-generated
against the current tip of the BK tree.

For quite a while we've had a bunch of state-transition testing code in the
driver, to report if anything bad ever happens (like the SCSI midlayer
trying to queue a second command before the first one finishes).  None of
those tests triggered in a very long time; this aspect of the code appears
to be extremely stable.

So this patch removes all those tests for illegal values of us->sm_state.
It turns out that sm_state was used only for one other purpose: to check
whether a command had timed out and caused a SCSI abort.  That piece of
information can easily be stored in a single new bitflag (which is called
calling US_FLIDX_TIMED_OUT) and doing so makes us->sm_state completely
unused.  Hence the patch removes it from the structure.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

This is patch as399, originally from Alan Stern.

A recent change to the scsi_probe_lun() routine now allows host drivers to
specify a device's INQUIRY length in a way that cannot be overridden by
the value returned from the device.  This patch makes usb-storage set the
length to 36; now buggy devices won't be able to cause trouble by saying
that they have 37 bytes of INQUIRY data available.

The only way this value could be changed is if someone creates a SCSI
blacklist entry with the BLIST_INQUIRY_58 flag -- and no one would do that
for a USB device (I hope)!
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

This was originally patch as401 from Alan Stern.  This patch makes a couple
of small changes to the new scanning thread.

It changes the name to "usb-stor-scan", which was my original intention and
makes more sense than the current name.

It also removes the PF_NOFREEZE flag; if someone suspends their system
immediately after plugging in a USB storage device then the scanning thread
should be frozen along with everything else.  The delay will be restarted
after the system wakes up.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

 Add device ID to pl2303 usb serial driver for
 1) I/O DATA USB-RSAQ3
 2) ELECOM UC-SGT
Signed-off-by: CHIKAMA Masaki <masaki-c@nict.go.jp>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Here's another unusual_devs entry for the Tekom/Yakumo devices. While I
was there I realized two of the tekom entries were out of order, so I
fixed that as well.

From: Paul Ortyl <ortylp@3miasto.net>
Signed-off-by: Phil Dibowitz <phil@ipom.com>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

This patch for ipaq.h and ipaq.c in drivers/usb/serial/ has the
following features:

o Provides an updated table with all vendor/product IDs (except one [1])
present in Microsoft ActiveSync 3.7.1, the latest version available for
download.

o Removes #defines with vendor and product IDs from ipaq.h [2]

The table has been autogenerated from the file wceusbsh.inf (extracted
from MSASYNC.EXE with cabextract). The scripts used to generate the
table become available for download as part of the SynCE project
(http://synce.sourceforge.net).

[1] Vendor 0x45e (Microsoft) with device 0xCE is not included, because
they are used when the device is turned off but still connected to the
PC via USB. When the device is turned on, it changes vendor/product IDs
to the more specific ones.

[2] Not needed with an autogenerated device table
Signed-off-by: David Eriksson <twogood@users.sourceforge.net>
Signed-off-by: Ganesh Varadarajan <ganesh@veritas.com>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

generic_startup in visor.c was not called for some hardware, resulting
in attempts to access memory that had never been allocated, which in
turn caused the problem several people reported with recent (2.6.10ish)
kernels.
Signed-off-by: Roger Luethi <rl@hellgate.ch>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

The attached patch fixes a bug introduced by myself (a brown paper bag
one) when I posted the patch that introduced this same PID to the
id_table_FT232BM array only and not the id_table_combined array.
Signed-off-by: Paulo Marques <pmarques@grupopie.com>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

big-endian related fixes;
Signed-off-by: Petko Manolov <petkan@nucleusys.com>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

add some help text for touchkitusb. the howto there should also
work for mtouchusb and other touchscreens using the input layer.
Signed-off-by: Daniel Ritz <daniel.ritz@gmx.ch>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

This is the all new and improved version of the patch:
- following the advise from Jean Delvare I removed the redundant definition
  of the PCI IDs from the driver and just add them to the pci_ids.h file.
- the patch is now created against linux 2.6.10-RC2.
Signed-off-by: Thomas Leibold <thomas@plx.com>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

It seems so. BTW I hate wrong comments and happened to add one
in my patch. To fix my blunder, can you apply the appended one
line removal on top of Jean's patch.
Signed-off-by: Gabriel Paubert <paubert@iram.es>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

This patch cleans up the recent removal of smbus functions proposed by
Arjan and then fixed by Gabriel. Changes are as follow:

1* Discard i2c_smbus_block_process_call, as it isn't used anywhere
   either. I guess that Arjan missed it because it wasn't exported.

2* Document the functions removal, so that people have at least an idea
   that the functions can be restored later if needed.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

While working on the 2.4 version of the i2c-amd756-s4882 driver, I
noticed a few quirks on the 2.6 version I sent to you. The following
patch attempts to fix them.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

While verifying my stack of patches against what you sent to Linus last
week, I noticed this one. Looks like I simply forgot to send it to you,
as I cannot find any trace of it in the lm_sensors mailing-list
archives.

The patch prevents an smsc47m1 device from being registered when no
monitoring function is actually active within the chip. See this ticket
for background:
  http://secure.netroedge.com/~lm78/readticket.cgi?ticket=1801
This is certainly better to explicitely fail in this case than leave the
user with an empty sysfs directory (except for alarms), which tends to
make him/her think of a driver bug, which it isn't (what it really is is
a BIOS brokenness).
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

The following patch should avoid the sysfs_remove_dir() oops you are
seeing while device removal. It anyway fixes the obvious error and is
needed. But it will not make any change to the first error you are
seeing while connecting the device.


o Following patch avoids the sysfs_remove_dir() oops when it is passed
  a kobject with NULL dentry.
Signed-off-by: Maneesh Soni <maneesh@in.ibm.com>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

From: Gerd Knorr <kraxel@bytesex.org>

It uses the varargs list twice in a illegal way.  That doesn't harm on i386
by pure luck, but blows things up on amd64 machines.

Using var args list twice without calling va_start twice is illegal.
Signed-off-by: Gerd Knorr <kraxel@bytesex.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

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