This fixes https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=128916Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Add comment/NOTE that USB_STORAGE probably needs BLK_DEV_SD also.
Add a few device types to help text and reformat it.
Signed-off-by: Randy Dunlap <rddunlap@osdl.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

The warning about using unlink_urb needs to be rate limited, because
if a driver is still doing it will overrun the system logs.
Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

>   This patch is to fix unnecessary increment of 'i' used to
> specify an element of an arry 'envp[]' in firmware_class_hotplug().
> The 'i' is already incremented in add_hotplug_env_var(), actually.

you are right. The incrementation is wrong, but it doesn't have any
negative effect. However the same applies for the usb_hotplug() function
in drivers/usb/core/usb.c.
Signed-off-by: Keiichiro Tokunaga <tokunaga.keiich@jp.fujitsu.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

This adds an unusual devs entry for another Yakumo camera - it suffers
from the residue problem.

Originally reported by Michele Alzetta <michele.alzetta@aliceposta.it>.

Greg, please apply.
Signed-off-by: Phil Dibowitz <phil@ipom.com>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Turns out that this macro doesn't work in usb-serial drivers, I had forgotten
about that :(
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

The problem I'm having is that the field index is always returned as 0
when reading struct hiddev_usage_ref and I need something to
distinguish the input data as the usage code is the same.  I looked
through hid-core.c and hiddev.c and hiddev_hid_event is the only place
I could see field->index being used.  It wasn't being initialized
causing the input to always be returned as zero.
Signed-off-by: David Fries <dfries@mail.win.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

This removes some nasty might_sleep() warnings.
Worth fixing before 2.6.10-final IMO; we don't
actually _know_ of oopses this bug caused ...

The AX8817x link detection code was calling usb_submit_urb() with
GFP_KERNEL in a completion handler (IRQ handler).  That's a no-no.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

please consider applying the attached patch which adds an identifier for
another variant of the X10 RF remote. This one is very common everywhere
in Europe where Aldi (a supermarket discounter) sells their PCs
(Netherlands, Belgium, northern Germany, France, Spain, ...).
Considering that they ship a few 100,000 PCs once or twice every year
you can imagine there are quite a few of these remotes kicking around.

I've tested with 2.6.10-rc2 and various versions of XMMS and lirc with
the devinput driver. It does play well with lirc-0.7.0-pre8 but not so
nice with 0.7.0. I don't know why, but according to some posts on the
lirc list it seems to be in lirc.

By the way, there seem to be even more variants of this device,
according to:

http://cvs.sourceforge.net/viewcvs.py/lirc/lirc/drivers/lirc_atiusb/lirc_atiusb.c

From: Armijn Hemel <armijn@uulug.nl>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

This patch adds the gadget serial documentation.
Signed-off-by: Al Borchers <alborchers@steinerpoint.com>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

This adds "sparse -Wcontext" annotations to the main HCDs, reflecting that
they all need to drop their (schedule) lock while issuing URB completion
callbacks.  (Some completion callbacks will resubmit that URB, relying on
that to keep the endpoint queue from emptying and getting descheduled.)
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

This would be rare with HCDs that maintain chains of DMA
transfers, except if the HC dies in the middle of an I/O
request; so no rush to merge this.  It'd happen in a PIO
based HCD though ... :)


Async unlink of an URB from an endpoint's I/O queue _normally_ involves a
delay from handshaking with the host controller, to be sure the DMA queue
is inactive.  So urb->complete() runs after usb_unlink_urb() returns, and
from a different context.  But not always...

The completion may run immediately whenever the HCD knows that HC isn't
busy with the URB.  Maybe that HCD is in a HALT state, or the endpoint
queue is is temporarily off-schedule (halted, or dead after PM resume
from D3cold, etc) ... or maybe the HCD doesn't use DMA, so most unlinks
just list_del_init() and return.

This makes usb_sg_cancel() and sg_complete() drop the io->lock when they
cancel active urbs, preventing potential self-deadlock when that completion
handler runs immediately.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

This has two minor patches to make this driver work better with
the Genesys GL880S:  don't report hardware port indicators (until
the root hub code supports them); and patch the misreported number
of ports (two, not four).
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

The UDC in Intel's "Bulverde" processors is incompatible with the
one in their PXA 25x/26x/21x processors, and has different sorts
of restrictions.  For example, it can implement real CDC Ethernet,
while the earlier (PXA 25x etc) can't.


This adds a gadget_is_pxa27x() function and uses it appropriately in the
current set of gadget drivers.  (And moves an LH7A40X entry to the right
place in "ether.c").

From: Dmitry Krivoschokov <dkrivoschokov@dev.rtsoft.ru>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

I admit that the code should be locked properly instead, but the global plan
is to drop all P3 tagged printks anyway. So let it be guarded for the moment.
Signed-off-by: Pete Zaitcev <zaitcev@yahoo.com>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

The major 180 has been allocated by LANANA. This is needed for people who
insist on running 2.6 without udev (imagine that).


From: Pete Zaitcev <zaitcev@redhat.com>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Incrementing the outstanding_urbs counter twice for the same URB can't
be good. No wonder Simon didn't get far syncing his Palm.
Signed-off-by: Roger Luethi <rl@hellgate.ch>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Building with gcc -W revealed this warning:
arch/i386/kernel/traps.c: In function `do_general_protection':
arch/i386/kernel/traps.c:506: warning: empty body in an if-statement

upon inspecting the code I see what looks like a mistakenly placed ";"

        if (!fixup_exception(regs)) {
                if (notify_die(DIE_GPF, "general protection fault", regs,
                                error_code, 13, SIGSEGV) == NOTIFY_STOP);
                        return;
                die("general protection fault", regs, error_code);
        }

That ";" after the second if should go away so the return; before die()
is not unconditional.
Signed-off-by: Jesper Juhl <juhl-lkml@dif.dk>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Signed-off-by: Tony Luck <tony.luck@intel.com>

into intel.com:/data/home/aegl/BK/linux-ia64-release-2.6.10

Len Brown convinced me that the problem with disabling
PCI routing entries wasn't the disable as much as the
fact that ELCR needs to be updated when removing the PCI
routing. So this reverts the previous cset and updates
ELCR as suggested by Len.

Ignore offline CPUs when registering IOSAPIC interrupts.  We previously
directed interrupts even to offline CPUs, which means that if you have some
unused CPUs (e.g., you used "maxcpus="), some interrupts won't work.

This really hurts because distro installs typically use "maxcpus=1".

Patch by Alex Williamson.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>

This fixes at least some interrupt polarity setup cases.
The ACPI guys may want to eventually do this differently, but
in the meantime this makes ACPI behaviour closer to non-ACPI
behaviour, and fixes known problems.

I'll further argue that this protects non-PCI devices that may
just share the irq routing from being screwed, but that may or
may not be an argument that everybody buys into.

This depends on the previous ptrace single-step cleanup,
and makes sure that signal handling does not lose TF events.

This allows debuggers to trace programs that set TF on their
own.

(This makes the naming of "DTRACE" purely historical, since
on x86 it now means "single step in progress").

Update for the tuner module: add support for a new tuner chip.
Signed-off-by: Gerd Knorr <kraxel@bytesex.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

convert more modules to new-style insmod options.
Signed-off-by: Gerd Knorr <kraxel@bytesex.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

#ifdef out a currently unused (in-kernel) function, lets see if any
out-of-kernel users cry.  If not we can drop it altogether later on.
Signed-off-by: Gerd Knorr <kraxel@bytesex.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Some places which need adaption to the last video-buf API change where
forgotten, this patches fixes them up.  Hope I really caught them all now.
Signed-off-by: Gerd Knorr <kraxel@bytesex.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Prevents user-space including spinlock.h which breaks the build.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Patch below fixes a typo in init/Kconfig for option CC_ALIGN_FUNCTIONS.
Signed-off-by: Cal Peake <cp@absolutedigital.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

The patch below fixes wrong arguments to outw in smc91c92_cs.c
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>

Fix the mmput bug introduced while fixing cmdline race.
Signed-off-by: Prasanna Meda <pmeda@akamai.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Here's a patch to include Dell's 4th generation Remote Access Controller
ids.
Acked-by: Russell King <rmk@arm.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

This patch for SELinux fixes a bug in the mapping of socket types to
security classes and ensures that Unix seqpacket sockets are mapped to an
appropriate security class.  The Unix stream security class is re-used in
this case as it has the same permission checking applied as for seqpacket. 
Signed-off-by: Stephen Smalley <sds@epoch.ncsc.mil>
Signed-off-by: James Morris <jmorris@redhat.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

We just spent some days fighting a rare race in one of the distro's who backported
some of timer.c from 2.6 to 2.4 (though they missed a bit).

The actual race we found didn't happen in 2.6 _but_ code inspection showed that a
similar race is still present in 2.6, explanation below:

Code removing a timer from a list (run_timers or del_timer) takes that CPU list
lock, does list_del, then timer->base = NULL.

It is mandatory that this timer->base = NULL is visible to other CPUs only after
the list_del() is complete. If not, then mod timer could see it NULL, thus take it's
own CPU list lock and not the one for the CPU the timer was beeing removed from the
list, and thus the list_add in mod_timer() could race with the list_del() from
run_timers() or del_timer().

Our race happened with run_timers(), which _DOES_ contain a proper smp_wmb() in the
right spot in 2.6, but didn't in the "backport" we were fighting with.

However, del_timer() doesn't have such a barrier, and thus is subject to this race in
2.6 as well. This patch fixes it.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

The "udbg" code used on ppc64 for early consoles including early serial
console recently got a new "default speed" option. This was implemented
as a switch case that missed a few important cases, one beeing necessary
for a board beeing released soon.

This patch fixes it by using the proper division to calculate the dll
value for the uart instead of that bogus switch/case.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

The pci_bus_to_host() inline function used on ppc64 to find the pci_contoller
structure a give pci_bus resides on used to contain bogus tree walking code,
which fortunately ended up never beeing necessary since "sysdata" always points
to a device_node structure that has the proper "phb" field (even if it is not
the device-node of the actual P2P, which happens during boot).
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

This patch fixes a typo in the code that parse Open Firmware properties
for devices under an "isa" node, the incorrect struct size was used when
parsing the "reg" property of these.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

The ppc64 kernel can be built with a default command line (CONFIG_CMDLINE)
for cases where none is provided by the firmware.

However, some OF implementation always pass a "bootargs" property that only
contains the "0" terminating byte of a C string which caused us to think
there was a command line, and not use the built-in one. This patch fixes it.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>