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

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

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

I noticed the HID driver had some potential misbehavior ...


Bugfix handling for HID devices at high speed (interrupt interval encoding
is log2 not linear), and for interrupt OUT transfers (use the interval
the hardware actually supports).
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

I've had different versions of this floating around for a while;
basically, the goal is to be more robust against devices that
misbehave by returning garbage descriptors in certain cases.

Add an extra check when fetching descriptors:  the type must be
correct.  This guards against different types of firmware (or maybe
hardware) errors than the two checks already being made.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

This patch is originally from Christoph Hellwig.

This patch coverts from Scsi_Foo typefs to struct scsi_cmnd, and moved from
the SCSI data direction constants to the DMA ones.

It also switches to the proper (or so they tell me) use of <scsi/*.h>
headers.  This also includes some additional reshuffling to avoid useless
headers in the usb-storage local headers (to improve compile time).
Signed-off-by: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

This patch started life as as294.  All I did was to regenerate it to apply
cleanly against current kernels.

This just adds a couple of lines to the debugging output with some useful
information, and removes some lines that nobody has looked at in a very
long time.
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>

In theory, this is the fix we need to make Genesys Logic devices work.
This patch started life as as343, which was created based on some
information which a user finally coaxed out of Genesys Logic.  Limited
end-user testing gives good results.

As we expected, it's a bug in their device.  This is really a workaround
for what is almost certainly a timing problem.  Apparently, the 'popular'
OSes don't push the device as hard as Linux does.

Although it is likely that this workaround is not needed for all Genesys
devices, Genesys was unable/unwilling to provide us with the explicit list
of VID/PIDs which required this -- thus we apply it to all Genesys devices.

We have lots of good reports with max_sectors set to 128 with these
devices, but the official recommendation is to set that to 64.  End-users
can experiment with higher values (for higher performance) via the runtime
sysfs interface to that parameter.

I would like to give special thanks to the users who hounded Genesys into
giving up this information, and to Alan Stern for not giving up on this
vendor long after I had.
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 adds a workaround for a broken USB modem.
Signed-Off-By: Oliver Neukum <oliver@neukum.name>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Use msleep() instead of schedule_timeout() to guarantee the task delays
for the desired time. Delete unused UNLINK_TIMEOUT_JIFFIES #define.
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
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>

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>