Changes:

- Add support for SN9C103 based devices. The audio capability is already
  supported but not released in this version. I will release
  it once someone donates two SN9C103 based devices.
- Implement VIDIOC_G_CTRL for TAS5110C1B and TAS51130D1B
- Replace "SN9C10[12]" strings with "SN9C10x"
- Add red, green, blue gain controls to the SN9C103
- Memory offsets are now page-aligned
- Fix typos in the documentation
- Documentation updates
- Setting bounds are checked by the core module
- Add exposure control for TAS51130D1B
Signed-off-by: Luca Risolia <luca.risolia@studio.unibo.it>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

This patch changes a couple of new routines in the suspend/resume code.
Internally they use port numbers starting from 1, unlike every other
routine in the hub driver.  This changes the port numbers to origin-0, for
consistency's sake.  Of course, messages sent to the system log will
continue to start counting from 1.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

This patch takes some code that was only used in one place in the hub
driver, and packages it up into a subroutine which is now called from
several places.  The routine does a logical disconnect -- for example,
after issuing a port reset, if the device descriptors have changed
(because of a firmware update perhaps) we logically disconnect the old
device structure and create a new one.  Or if a resume fails for any
reason we can do the same thing.

This touches some of David Brownell's suspend/resume code, obviously.
(It also fixes a couple of small errors in there.)  He has said it looks
okay.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Make code more readable with list_for_each_entry.
Compile tested.
Signed-off-by: Domen Puncer <domen@coderock.org>
Signed-off-by: Maximilian Attems <janitor@sternwelten.at>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Make code more readable with list_for_each_entry.
Compile tested.
Signed-off-by: Domen Puncer <domen@coderock.org>
Signed-off-by: Maximilian Attems <janitor@sternwelten.at>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Use list_for_each_entry to make code more readable.
Compile tested.
Signed-off-by: Domen Puncer <domen@coderock.org>
Signed-off-by: Maximilian Attems <janitor@sternwelten.at>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Make code more readable with list_for_each_entry_safe.
(Is this a non i386? I can't compile it.)
Signed-off-by: Domen Puncer <domen@coderock.org>
Signed-off-by: Maximilian Attems <janitor@sternwelten.at>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Use list_for_each_entry_safe to make code more readable.
Compile tested.
Signed-off-by: Domen Puncer <domen@coderock.org>
Signed-off-by: Maximilian Attems <janitor@sternwelten.at>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Make code more readable with list_for_each_entry.
Compile tested.

Patch incremental on the list_for_each() change.
Signed-off-by: Domen Puncer <domen@coderock.org>
Signed-off-by: Maximilian Attems <janitor@sternwelten.at>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

This has been publicised for years now, and the usvfs name will work just
fine with a 2.4 kernel, so we are not breaking backwards compatibility.
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Here is an additional patch for pl2303 in 2.6.9-rc1,
to be applied after my previous circular buffer patch.
This patch waits for the buffer to drain on close and
then clears the buffer.  In addition to the obvious
features, this also fixes a bug where closing a port
with a full buffer would accidentally disable writes
when the port was re-opened.

The original pl2303 could lose data that was still going
out the port on close, and even this patch only solves
the problem completely for data rates of 1200 bps and
above.

Waiting for data to drain from the circular buffer is
easy, but the problem is waiting for data to drain from
the 256 byte hardware buffer on the device.  I don't know
how much data is in the hardware buffer, so I just wait
long enough for a potentially full hardware buffer to
drain, but I don't want to wait that long for low data
rates if the buffer isn't full.  There is probably some
way to query the pl2303 to find out how much data is in
its hardware buffer, maybe snooping would reveal that.

- Added a wait for data to drain from the driver
  write buffer when closing.

- Added a wait for the data to drain from the
  device hardware buffer when closing.

- Cleared the driver write buffer when closing.
Signed-off-by: Al Borchers <alborchers@steinerpoint.com>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Here is the patch adding a circular buffer to pl2303
updated to 2.6.9-rc1.  Phil and I both tested this.
(Phil tested a slightly different earlier version.)

This fixes the carriage return newline problem Olaf
Hering reported and helps Phil with hotsyncing his
phone.  This patch also fixes a problem that would
sometimes leave a pl2303 port unable to send data,
reporting "already writing", after closing the port
while writing was in progress.  This happened about
1/3 of the time in my tests with the stock 2.6.9-rc1
pl2303 driver.


- Added a circular write buffer, protected by the
  existing spin lock.

- Write_room and chars_in_buffer now report room and
  chars in the circular buffer.

- Added a "bounce buffer" when transfering data from
  user space to the circular buffer--needed for locking.

- Replaced (urb->status != -EINPROGRESS) with a private
  write_urb_in_use flag protected by the existing spin
  lock.  Clear this flag when the urb is unlinked.

- Free memory on failed startup.

- These changes make ONLCR mapping work and fix a bug
  that would sometimes leave the port unable to write,
  reporting "already writing", after closing the port
  while writing was in progress.
Signed-off-by: Al Borchers <alborchers@steinerpoint.com>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

This patch is only for nuisance value.  It puts a nag message in the
system log every time usb_unlink_urb() is called for synchronous
unlinking.  My hope is this will speed the process of converting drivers
to use usb_kill_urb().

Don't apply this if it generates too much noise, but otherwise go ahead.
A little prodding never hurt anyone.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

After discussing this patch with Mark Hollomon, I think it is much safer
/ better to leave the conditional check within the while loop. This way
the mutex state is as expected and maintainability is not compromised.
The previous patch should not be applied.


Description: Inserts appropriate set_current_state() call so that
schedule_timeout() functions as expected.
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
Signed-off-by: Maximilian Attems <janitor@sternwelten.at>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Insert set_current_state() so schedule_timeout() functions as expected.
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
Signed-off-by: Maximilian Attems <janitor@sternwelten.at>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

I think the USB HCD should print the actual PCI memory address, not the
ioremapped address.  AFAIK, there's no reason the ioremapped address has
to have any fixed relationship to the actual address.  Also, this makes
it match what's in /proc/iomem.  I also added a leading "0x".  Example
from ia64:

    - ehci_hcd 0000:00:01.2: irq 52, pci mem c000000080021000
    + ehci_hcd 0000:00:01.2: irq 52, pci mem 0x80021000



USB HCD: print actual PCI mem address, not the ioremapped value.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

A couple of months ago you applied a patch from Torsten Scherer to create
a new unusual_devs.h entry.  In further discussions with him I learned
that the entry wasn't needed to access the device; the only reason for it
was as a workaround for some old, buggy hotplug program on his system.

Now Evan Fletcher reports that the entry actively prevents him from using
his device.  For me that's the last straw, so here's a patch to remove the
entry.  Torsten should be okay if he simply upgrades his hotplug package
or removes the buggy program.

On Mon, 30 Aug 2004, Evan Fletcher wrote:
> Hi list,
>
> I have a Bytecc 5.25" External Enclosure, model ME-320U2F, that has
> both USB 2.0 and Firewire connections
> (http://www.byteccusa.com/product/enclosure/ME-320.htm).  It used to
> work fine on earlier Linux 2.6 kernels, but stopped working a few
> revisions ago.
>
> I tracked the problem down to an entry in unusual_devs.h:
>
> /* <torsten.scherer@uni-bielefeld.de>: I don't know the name of the bridge
>  * manufacturer, but I've got an external USB drive by the Revoltec company
>  * that needs this. otherwise the drive is recognized as /dev/sda, but any
>  * access to it blocks indefinitely.
>  */
> UNUSUAL_DEV(  0x0402, 0x5621, 0x0103, 0x0103,
>                 "Revoltec",
>                 "USB/IDE Bridge (ATA/ATAPI)",
>                 US_SC_DEVICE, US_PR_DEVICE, NULL, US_FL_FIX_INQUIRY),

<...>
> So, is there some way that this entry can be modified so that my DVD+R
> works properly, and Mr. Scherer can still use his Revoltec external
> disk?
>
> Thank you,
> Evan Fletcher
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

From: <fgalea@prism.uvsq.fr>

http://bugme.osdl.org/show_bug.cgi?id=3286

The kernel keeps printing "Lost sync on frames" error messages as soon as a
program tries to access the webcam.  No video data can be retrieved from
the webcam.

The following patch seems enough to solve the problem.  (just inverting the
order at which the old and new data blocks are sent to the user).
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

This patch adds VID/PIDs for a few FTDI-based USB serial devices
from B&B Electronics to the ftdi_sio driver.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

This ought to fix the NS9750 init issue, and make the AMD756 case
at least somewhat better.  It makes the init go "by the book" in more
ways, and formalizes one quirk.

Various OHCI init/reset cleanups for different silicion environments:

 - Reset a bit more "by the book".

    * Define a new quirk flag for the SiS and OPTi problem seen earlier.
      Since 2.4 we've always worked around that quirk, even though we've
      not seen that on other chips; but it's "wrong" and doesn't work on
      some chips (notably NetSilicon NS9750).

      The quirk still seems to be needed for SiS, but either this test
      machine is too fast for the OPTi problem to show up, or the frame
      timing setup problem there came from a now-fixed bug.

    * Look at the HC state before resetting it; depending on whether
      it was previously owned by BIOS, SMM, an OS, or nobody, different
      USB signaling (and timings) might be needed.

    * Re-init the frame timings right after soft reset, rather than
      later (potentially too much later).

    * Restore a reset in the PCI startup code, so this logic more closely
      resembles the non-PCI paths (future code sharing).  It also makes it
      easier to guarantee a 1-millisecond ceiling between reset and "go".

      An earlier reset is being done to help workaround BIOS-related
      problems on some boards, but we may need an even earlier one
      (as a PCI quirk, before IRQs get reconfigured).

 - Add an explicit #define to disable the BIOS/SMM handoff; it's
   not just HPPA, many embedded chips don't expect BIOS either.

 - There are reports of AMD 756 machines disliking the OHCI suspend
   patch of a few months back.  Erratum #10 partly explains that, so
   now root hubs won't autosuspend on those Slot-A era chips.

 - Other minor fixes

    * We've got lots of non-PCI OHCI now too, so comments shouldn't
      be assuming all-is-pci!

    * Hey, it's unsafe to call hc_reset() in IRQ (after unrecoverable
      error); so just force a soft reset, don't do the whole thing.

Tested on half a dozen different OHCI versions, but maybe some other
versions of OHCI will be sensitive to one of these changes.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

- Fixed hang on disconnect in digi_acceleport USB serial driver.
  See http://bugme.osdl.org/show_bug.cgi?id=2459.  Close after
  disconnect no longer tries to communicate with the device.
Signed-off-by: Al Borchers <alborchers@steinerpoint.com>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Am Dienstag, 31. August 2004 17:41 schrieb Alan Stern:
> On Tue, 31 Aug 2004, Oliver Neukum wrote:
>
> Alan Stern
>
>
>
>
> > @@ -822,9 +822,8 @@
> >
> >  	usb_set_intfdata(intf, NULL);
> >
> > +	usb_kill_urb(desc->urb);
> >  	scsi_remove_host(desc->host);
> > -	usb_unlink_urb(desc->urb);
> > -	scsi_host_put(desc->host);
> >
> >  	usb_free_urb(desc->urb);
> >  	kfree(desc);
>
> I think you still need the scsi_host_put(), to account for the fact that
> scsi_host_alloc() sets the refcount to 1 initially.

Right you are. Greg, please also apply this one.
Signed-Off-By: Oliver Neukum <oliver@neukum.name>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

this one make rtl8150 auto-load its register values at reset.  Not doing
so is known to cause improper setup when the device is being reseted
frequently.
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Doh. Fixed.

  - overriding the media check interrupt interval
Signed-Off-By: Oliver Neukum <oliver@neukum.name>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

This patch adds support for suspending, resuming, and remote wakeup
detection on root hub ports to the UHCI driver.  It doesn't add support
for suspending or resuming the root hub itself (beyond what's already
there) -- that will require considerably more work.  But at least devices
plugged directly into the computer will interact nicely with power
management.

Of lesser importance, the patch also simplifies some constant expressions.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

This patch changes the only places in usbcore where usb_unlink_urb() is
still used for synchronous unlinking; now they will use usb_kill_urb().
As it turns out, there were only a couple of changes needed.

This still leaves all the drivers to audit!
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

- Set the allocation size in REQUEST SENSE (Pat LaVarre)
- Move add_timer invocations to safer places (Oliver Neukum)
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

this reworks the microtek driver's disconnect method, now that
usb_kill_urb is available.
Signed-Off-By: Oliver Neukum <oliver@neukum.name>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Signed-Off-By: Oliver Neukum <oliver@neukum.name>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

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

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

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

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

Signed-off-by: Domen Puncer <domen@coderock.org>
Signed-off-by: Maximilian Attems <janitor@sternwelten.at>
Signed-off-by: David S. Miller <davem@davemloft.net>

Signed-off-by: David S. Miller <davem@davemloft.net>

Signed-off-by: David S. Miller <davem@davemloft.net>

Both work, but the latter can cause warnings in user space
from compilers that don't like using undefined identifiers
in preprocessor expressions (quite reasonable).

Pointed out by Randy Dunlap.