Use msleep() instead of schedule_timeout() to
guarantee the task delays for the desired time.
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
Signed-off-by: Mark McClelland <mark@alpha.dyndns.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Use msleep() instead of schedule_timeout() to
guarantee the task delays for the desired time.
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

This removes a copy of d_unhash() from drivers/usb/core/inode.c and
and exports d_unhash() from fs/namei.c as dentry_unhash().
Tested - compiled and running.
Signed-off-by: Dan Aloni <da-x@gmx.net>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

I forgot to add an entry in MAINTAINERS about the new SN9C10[12] driver.
Signed-off-by: Luca Risolia <luca.risolia@studio.unibo.it>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

In view of the comments below, I think we should modify this
unusual_devs.h entry to suppress the warning messages.  Please apply.



On Mon, 28 Jun 2004, Joël Bourquard wrote:

> There seem to be two different flavors of ISD-300 (ie: 05ab,0060)
> devices, one of which needs this entry to work, and the other doesn't.
>
> I have a 2 1/2'' HDD enclosure which (just like your device) doesn't
> need the entry (so when I plug it, I get the same warning as you).
>
> However, I also happen to own two 5 1/4'' CD-ROM enclosures, for which
> this entry *is* necessary. I tried again, very recently to remove my
> unusual_devs.h entry, and it prevented them from working.
>
> So, I think the entry should be kept (it does more good than harm), but
> maybe it could get some tweaking ? If there's a way to recognize these
> "CD-ROM enclosure" bridge chips and exclude the others, I'm all for it.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Just like in as347, we have another example of descriptors that vary from
device to device.  Please apply this patch to suppress the warning
message.

On Fri, 16 Jul 2004, Ken Yap wrote:

> Jul 16 21:44:20 media kernel: usb-storage: This device (090a,1001,0100 S 06 P 50) has an unneeded Protocol entry in unusual_devs.h
> Jul 16 21:44:20 media kernel:    Please send a copy of this message to <linux-usb-devel@lists.sourceforge.net>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Please merge this new entry for the unusual_devs.h database.

From: Johann Cardon <johann.cardon@free.fr>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Signed-off-by: Maximilian Attems <janitor@sternwelten.at>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Signed-off-by: Maximilian Attems <janitor@sternwelten.at>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Signed-off-by: Maximilian Attems <janitor@sternwelten.at>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

as per pete and greg's input, fixing only the uninitialized variable.
Signed-off-by: Ganesh Varadarajan <ganesh@veritas.com>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

This is a simple patch to fix a debug statement where the arguements are
in the wrong order. Resending it with a CC to Greg and a signed-off-by line.
Signed-off-by: Phil Dibowitz <phil@ipom.com>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

According to Jonas Fährmann, the very first entry in unusual_devs.h isn't
needed.  In fact, I can't tell why it was there in the first place...
unless some earlier device in the product line had incorrect descriptor
values.


On Mon, 26 Jul 2004, Jonas Fährmann wrote:

> usb-storage: This device (03ee,0000,0045 S 02 P 00) has unneeded SubClass and Protocol entries in unusual_devs.h
>    Please send a copy of this message to <linux-usb-devel@lists.sourceforge.net>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

This patch adds support for the FTDI FT2232C USB to dual serial port
converter to the ftdi_sio driver.

The patch is based on a fork of the 2.4 ftdi_sio driver by Steven
Turner of FTDI, and a preliminary port of these changes to the 2.6
ftdi_sio driver by Rus V. Brushkoff.  I've tidied it up and fixed a
couple of things.

I don't have a FT2232C to test it with, but Steven Turner of FTDI
has tested it.  He mentioned a couple of known problems with the
driver, but nothing to do with this patch.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

I've dredged up another old ftdi_sio patch that I never Cc'd to you
the first time.  Please see Nathan's description below.

It applies okay against your usb-2.6 tree, with or without the patch
I posted yesterday to support the FT2232C chip and neither patch
invalidates the other in any way.


On 25/06/2004 21:56, Croy, Nathan wrote:
> SUMMARY
> =======
> ftdi_sio never reasserts modem control lines once the baud has been set to
> B0.
>
> DESCRIPTION
> ===========
> Setting the baud to B0 (hangup) drops DTR.  When the baud is raised again,
> DTR is not raised.  This can cause a modem to ignore any commands sent to it
> until the device is closed and reopened.  This renders minicom (and other
> software) useless, unless you instruct the modem to ignore DTR.
>
> The following patch is intended to make ftdi_sio act like other serial
> devices I have used (i.e. the standard serial ports (/dev/ttyS*) and
> stallion ports (/dev/ttyE*)).  Upon setting the baud to something other than
> B0, it ensures the modem control lines are set back to the way they were
> when the port was opened.
>
> Thanks to Ian Abbott for confirming my suspicions:
> http://sourceforge.net/mailarchive/forum.php?thread_id=4984710&forum_id=12120

Nathan's email suffered from a line-folding bug (blame M$,
probably!), so his patch came out corrupted. I'm reposting an
uncorrupted version.


Signed off by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

The following patch is in use by REINER-SCT customres for some time and
works for them in about 90% of all cases.  I would really appreciate
this going in before 2.6.8-final, since the device doesn't work at all
with current 2.6.x driver.

Changes:
- bump version number
- open interrupt endpoint in startup() rather than open
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

From: Andi Kleen <ak@muc.de>

Trivial gcc-3.5 build fixes.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Please merge; the CONFIG_USB_SUSPEND patch depends on it.

This hub patch:

 - updates internal docs about locking, matching current usage
   for device state spinlock and dev->serialize semaphore

 - adds locktree() to use with signaling that affect everything
   downstream of a given device ... right now just khubd uses it,
   but usb_reset_device() should too (not just with hub resets...)

 - adds hub_quiesce()/hub_reactivate() ... former is used now
   during shutdown, both are needed in suspend/resume paths

Net change in behavior for current systems should be nothing.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

This is the core of the USB_SUSPEND functionality.  Please merge.

This adds an experimental CONFIG_USB_SUSPEND option, which supports the
USB "suspend" state.  Linux-USB hosts have previously ignored that state.

    -	New driver API calls, usb_suspend_device() and its
	sibling usb_resume_device().

    -	Access to those calls through sysfs, such as
		echo -n 2 > power/state
		echo -n 0 > power/state

That can be used to reduce the power consumption of any given USB device,
then re-activate it later.  Eventually, most USB device drivers should
probably suspend idle USB devices.

One problem with this patch:  USB drivers without suspend() callbacks
may badly misbehave.  Right now only hub drivers know suspend().  If the
driver core didn't self-deadlock when we try it, unbinding those drivers
from those devices (then re-enumerating on resume) would be perfect...
the current compromise is just to emit a warning message.

In conjunction with host controller driver support (already merged for
OHCI and EHCI), PCI host controllers will issue the PME# wakeup signal
when a USB keyboard starts remote wakeup signaling.  (But the keyboard
wasn't usable later, since HID doesn't try to suspend.)

I understand some ACPI patches are circulating, and maybe already in
the MM tree, to make a suspended system wake up given PME# signaling.
It'd be great if someone made that work transparently with USB, but
for now I'm told it'll need some sysfs setup first.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

This patch follows the suggestions sent by Todd Fischer and Diego Dompe
for making removable-LUN support part of the normal non-testing version of
the g_file_storage driver.  It also moves LUN device registration to the
correct place and eliminates a code path that stalls the bulk-out pipe in
a racy way.

There are also some smaller changes: update some comments, add initial
debugging support for USB suspend/resume, and miscellaneous code cleanups.
Last but not least, the driver has been sufficiently stable for
sufficiently long that it's fair to remove the "(DEVELOPMENT)" warning in
Kconfig.
Sent-by: Todd Fischer <toddf@cadenux.com>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

This patch fixes a NULL-pointer-dereference bug in the dummy_hcd driver.
It also makes the code slightly more elegant and removes an unnecessary
buffer-overflow test.  Unfortunately it's still a little bit racy, but
this is a fault it shares with other gadget controller drivers, like
net2280.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

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

fb_set_cmap() and fb_copy_cmap() split into kernel and userland versions.
fb_cmap, fb_image and fb_cursor split and annotated.
fixed bug in sbuslib.c that used to call "userland" version of fb_set_cmap()
when kernel one was need (RGB data was already copied into kernel space).
Signed-off-by: Al Viro <viro@parcelfarce.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Massive leaks fixed in fb_cursor().
Signed-off-by: Al Viro <viro@parcelfarce.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

->vc_font switched to console_font (from console_font_op, of all things!)
console_font_op annotated (->data is finally makred __user).
Signed-off-by: Al Viro <viro@parcelfarce.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

->con_font_get() sanitized.  We pass console_font * to method instead of
console_font_op * and do not mess with mixing ->data in these guys.
Signed-off-by: Al Viro <viro@parcelfarce.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

	fbcon internal cleanup.  Instead of passing console_font_op into
fbcon_do_set_font() we pass width/height directly.  Amusing (but harmless)
bug fixed there:
	if (!w > 32) {
		bogus code that fortunately never got triggered
	}
Fixed by removal of the junk in question (and yes, it's verifiable junk -
it would not do anything even if we replaced the check with intended
!(w > 32)).
Signed-off-by: Al Viro <viro@parcelfarce.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

con_font_set() sanitized.  We are passing console_font and flags into
the method in separate arguments and we are not messing with
console_font_op->data anymore - it's a userland pointer (to be annotated
several patches later in the series, due to another abuse of console_font_op
that needs to be fixed first), while console_font->data is kernel one
and they don't mix anymore.

We also do a sanity check (font width > 0) in the caller instead of
method instances, since we are already checking for width <= 32 and
height <= 32 there; doesn't make sense leaving that one in method
instances.
Signed-off-by: Al Viro <viro@parcelfarce.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

->con_font_copy() sanitized.  We extract the number of console to copy the
font from in the caller (it's taken from the field of console_font_op that
is normally used for font height - messy even for an ioctl, but that animal
used to be passed all the way down into console drivers).

With decoding done in con_font_copy(), we simply pass source console number
into the method.
Signed-off-by: Al Viro <viro@parcelfarce.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

->con_font_default() sanitized.  We copy font name (if any) from userland
in the caller and pass it explicitly.  We are also beginning to get rid
of console_font_op in method arguments.
Signed-off-by: Al Viro <viro@parcelfarce.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Preparations for cleanups: con_font_op() is turned into a switch calling
con_font_{get,set,default,copy} depending on the operation required;
method ->con_font_op() also split, with NULL resulting in -ENOSYS on
operation in question.

Code that used to be in con_font_op() got slightly cleaned up after move
into new helpers (we are beginning to untangle the mess; there will be
more cleanups in the next patches).

Methods are currently using exact same arguments as old ->con_font_op().
That will change in subsequent patches, method by method (right now there's
a hell of a scary field reuse between them, making impossible to do any
static checks and practically begging for bugs).
Signed-off-by: Al Viro <viro@parcelfarce.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

The ppc64 implementation of memcpy_to/from_io was bogus (used memcpy
which uses cache hints and thus is broken on non cacheable IO space).

This re-implements them with some simple/gross C code doing 32 bits
accesses when aligned and bytes accesses when not. 
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

This fixes some possible rare issues with the hash code beeing called
with interrupts enabled from update_mmu_cache, and fixes some races in
the iSeries low level htab code by adding an array of spinlocks

This is actually an old patch already present in SLES kernel and that
got "missed" somewhat in the main tree, adapted to recent changes.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Signed-off-by: Steve French (sfrench@us.ibm.com)

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

into kernel.bkbits.net:/home/davem/sparc-2.6

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