This implements support for autosuspend in the sierra driver while online.
Remote wakeup is used for reception. Transmission is facilitated with a queue
and the asynchronous autopm mechanism. To prevent races a private flag
for opened ports and a counter of running transmissions needs to be added.
Signed-off-by: Oliver Neukum <oliver@neukum.org>
Tested-by: Elina Pasheva <epasheva@sierrawireless.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

In order for the dbgp driver to survive suspend/resume, on every ehci
resume operation the debug controller must get re-initialized.
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: dbrownell@users.sourceforge.net
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Add missing information about requirements of using the EHCI usb debug
controller as well as to mention you can use a debug controller other
than the first one in the system.
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Sarah Sharp <sarah.a.sharp@intel.com>
Cc: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

On some EHCI debug controllers after the host controller driver is
activated, the debug controller will occasionally fail to submit a
bulk write URB.  On controllers that exhibit this behavior a dummy
bulk write must get submitted to resynchronize the device.

The "dummy bulk write" does not get received by the host attached to
the other end of the usb debug device.  The usb debug device simply
acknowledges the "dummy bulk write" and returns to a usable state.

The behavior, without this patch is that you see missing text from a
complete kernel boot when using the keep option to the earlyprintk
kernel argument.
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

On some EHCI usb debug controllers, the EHCI debug device will fail to
be seen after a port reset, after a warm reset.  Two options exist to
get the device to initialize correctly.

Option 1 is to unplug and plug in the device.

Option 2 is to use the EHCI port test to get the usb debug device to
start talking again.  At that point the debug controller port reset
will succeed.
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
CC: dbrownell@users.sourceforge.net
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

If the EHCI debug port is initialized and in use, the EHCI host
controller driver must follow two rules.

1) If the EHCI host driver issues a controller reset, the debug
   controller driver re-initialization must get called after the reset
   is completed.

2) The EHCI host driver should ignore any requests to the physical
   EHCI debug port when the EHCI debug port is in use.

The code to check for the debug port was moved from ehci_pci_reinit()
to ehci_pci_setup because it must get called prior to ehci_reset()
which will clear the debug port registers.
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: dbrownell@users.sourceforge.net
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

This patch implements several changes:

1) Improve the capability to debug the dbgp driver

   The dbgp_ehci_status() was added in a number of places to report
   the critical ehci registers to diagnose the cause of a failure of
   the ehci-dbgp driver.

2) Capability to survive the host controller initialization

   The dbgp_external_startup(), dbgp_not_safe, and dbgp_phys_port were
   added so as to allow the ehci-dbgp to re-initialize after the ehci
   host controller is reset by the standard host controller driver.
   This same routine is common for the early startup or
   re-initialization.

   This resulted in the need to move some of the initialization code
   out of the __init section because the ehci driver has the
   possibility to be loaded later on as a kernel module.

3) Stability improvements for device initialization

   The device enumeration from 0 to 127 has the possibility to fail
   the first time after a warm reset on some older EHCI debug
   controllers.  The enumeration will be tried up to 3 times to
   account for this failure case.

   The dbg_wait_until_complete() was changed to wait up to 250 ms
   before failing which only comes into play during device
   initialization. The maximum delay will never get hit during the
   course of normal operation of the driver, unless the device got
   unplugged or there was a ehci controller failure, in which case the
   dbgp device driver will shut itself down.
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: dbrownell@users.sourceforge.net
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

It is desirable to be able to use one early boot device to debug
another or to have multiple places you can see the early boot
diagnostics, such as the vga screen or serial device.

This patch changes the early_printk console device registration to
allow more than one early printk device to get registered via
register_console().
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

When using the EHCI host controller as a polled device, a bit more
tolerance is required in terms of delays.  On some 3+ghz systems the
cpu loops were faster than the EHCI device mmio and resulted in the
controller failing to initialize.

On at least one first generation EHCI controller when it was not
operating in interrupt mode, it would fail to report a port change
status, but executing the port reset allowed the debug controller to
work correctly anyway.  This errata causes a one time 300ms delay in
the boot time, where as the typical delay is 1-5ms for an EHCI
controller that does not have this errata.

The debug printk's were fixed to have the correct state messages, and
there was a conversion from using early_printk to printk to avoid
calling the dbgp driver while debugging the initialization.
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

The PCI quirk code executes a BIOS hand off to obtain full control of
the EHCI host controller, the self contained ehci-dbgp driver must do
the same thing using the early PCI API, else the BIOS can cause a
fatal fault.
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: dbrownell@users.sourceforge.net
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

The rs232 drivers send a carriage return prior to a new line in the
early printk code.

The usb debug driver should do the same because you want to be able to
use the same terminal programs and tools for analysis of early printk
data.
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Move the dbgp early printk driver in advance of refactoring and adding
new code, so the changes to this code are tracked separately from the
move of the code.

The drivers/usb/early directory will be the location of the current
and future early usb code for driving usb devices prior initializing
the standard interrupt driven USB drivers.
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

We set pdt_1f_for_no_lun for UFI devices, so most floppy entiries should
be unnecessary. This patch removes three entries which I'm certain are.
 - For Mitsumi I have a customer with RHEL 5 (bz#514296)
 - For SMSC I accessed Novell's Bugzilla and verified the entry
 - For Y-E I tested the patch with the actual device
Signed-off-by: Pete Zaitcev <zaitcev@redhat.com>
Signed-off-by: Phil Dibowitz <phil@ipom.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Hi there.

On Aug 21 2009, Alan Stern wrote:
> On Thu, 20 Aug 2009, Rogério Brito wrote:
> > Again, just reiterating, what I said before, even though I am not sure
> > if I can reproduce it, I will try to.
> 
> A usbmon trace showing what happens when you plug in the drive and 
> when you run smartctl would help.

The documentation for usbmon in the kernel 2.6.31-rc7 kernel doesn't
match what the kernel exposes in the debug fs tree. This patch fixes it.
Signed-off-by: Rogério Brito <rbrito@ime.usp.br>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

OMAP: ISP1301: Compile fix

Fix this build error on non- OMAP-H2/H3/H4 systems:
(factored out two empty functions as part of the fix)

  CC      drivers/usb/otg/isp1301_omap.o
drivers/usb/otg/isp1301_omap.c: In function 'otg_update_isp':
drivers/usb/otg/isp1301_omap.c:635: error: implicit declaration of function 'notresponding'
drivers/usb/otg/isp1301_omap.c: In function 'b_peripheral':
drivers/usb/otg/isp1301_omap.c:973: error: implicit declaration of function 'enable_vbus_draw'
drivers/usb/otg/isp1301_omap.c: In function 'isp_update_otg':
drivers/usb/otg/isp1301_omap.c:1003: error: implicit declaration of function 'enable_vbus_source'
make[2]: *** [drivers/usb/otg/isp1301_omap.o] Error 1
make[1]: *** [drivers/usb/otg] Error 2
make: *** [drivers] Error 2
Signed-off-by: Anand Gadiyar <gadiyar@ti.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

If request_irq() fails, udp_irq is freed twice.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

The previous code had a bug that would add a trailing null byte to
the returned descriptor.
Signed-off-by: George Spelvin <linux@horizon.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

If the driver cannot be registered, put_tty_driver(gs_tty_driver)
occurred here as well as at label fail.

put_tty_driver() already occurs at label fail
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

usb_buffer_map_sg should return negative on error according to
its documentation. But dma_map_sg returns 0 on error. Take this
into account and return -ENOMEM in such situation.

While at it, return -EINVAL instead of -1 when wrong input is
passed in.

If this wasn't done, usb_sg_* operations used after usb_sg_init
which returned 0 may cause oopses/deadlocks since we don't init
structures/entries, esp. completion and status entry.
Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

This patch (as1281) changes the way ehci-hcd deschedules interrupt
QHs, copying the approach used for async QHs.  The caller is no longer
responsible for rescheduling the QH if its queue is non-empty; instead
the reschedule is done directly by intr_deschedule(), after calling
qh_completions().  This is exactly the same as how end_unlink_async()
works.

ehci_urb_dequeue() and intr_deschedule() now correctly handle the case
where they are called while another interrupt URB for the same QH is
being given back.  This was a surprisingly large blind spot.  And
scan_periodic() now respects the new needs_rescan flag.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: David Brownell <david-b@pacbell.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

This patch (as1280) fixes an obscure bug in ehci-hcd's dequeuing logic
for async URBs.  If a later URB is unlinked and the completion
routine unlinks an earlier URB, then the earlier URB won't be given
back in a timely manner because the endpoint queue isn't rescanned as
it should be.

Similar bugs occur if an endpoint is reset or a halt is cleared while
a completion routine is running, because the subroutines don't test
for the COMPLETING state.

All these problems are solved by adding a new needs_rescan flag to the
ehci_qh structure.  If the flag is set while scanning through an idle
QH, the scan will be repeated.  If the QH isn't idle then an unlink
cycle will be initiated, and the proper action will be taken when it
becomes idle.

Also, an unnecessary test is removed from qh_link_async(): That
routine is never called if the QH's state isn't IDLE.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: David Brownell <david-b@pacbell.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Current bindings specify that "fsl,mpc8323-qe-usb" compatible entry
should be used as a base match for QE UDCs, so update the driver to
comply with the bindings.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

This is how "real" UARTs (e.g. 16550) work and AFAIK what RS232 specifies, too.
Make the driver more compliant.
Signed-off-by: Frank Schaefer <schaefer.frank@gmx.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

The device supports it, so why not use it ? Works fine !
Signed-off-by: Frank Schaefer <schaefer.frank@gmx.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

According to the datasheets, the PL2303 supports a set of 25 baudrates.
The baudrate is set as a 4 byte value directly.

During my experiments with device 067b:2303 (PL2303X), I noticed that
 - the bridge-controller always uses 9600 baud if invalid/unsupported baud rate
   values are set
 - the baud rate value returned by usb_control_msg(..., GET_LINE_REQUEST, ...)
   does not reflect the actually used baudrate. Always the last set value is
   returned, even if it was invalid and not used by the controller.

This patch fixes the following issues with the current code:
1.) make sure that only supported baudrates are set (are there any buggy
    chip revisions out there which don't "like" other values... ?).
2.) always set the baudrate to the next nearest supported baudrate.
3.) applications can now read back the resulting baudrate properly, because
    tty_encode_baud_rate(...) is now fed with the actually used baudrate.
Signed-off-by: Frank Schaefer <schaefer.frank@gmx.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Using the module parameter vcc_default, you can choose the default VCC value.
Signed-off-by: Olivier Bornet <Olivier.Bornet@puck.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Signed-off-by: Olivier Bornet <Olivier.Bornet@puck.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

You can now set the IUU reader to 3.3V VCC instead of 5V VCC, using the sysfs
parameter vcc_mode. Valid values are 3 and 5.
Signed-off-by: Olivier Bornet <Olivier.Bornet@puck.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Signed-off-by: Olivier Bornet <Olivier.Bornet@puck.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Resetting the device cause the device to have a new name in the /dev.
Signed-off-by: Olivier Bornet <Olivier.Bornet@puck.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Follow T&M convention of obeying EOM flag.  Avoid exception cases where
instrument response size matches a buffer size.
Signed-off-by: Steve Holland <sdh4@iastate.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Limit data copied to userspace to amount requested.  Prevents a faulty
instrument from overwriting user memory.
Signed-off-by: Steve Holland <sdh4@iastate.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

The header size should not be included in the number of bytes requested of the
instrument
Signed-off-by: Steve Holland <sdh4@iastate.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Here is a patch to the ch341 driver which adds serial break support.
Signed-off-by: Tim Small <tim@seoss.co.uk>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

This patch (as1275) fixes the s3c2410 device controller driver.  Its
usb_gadget_unregister_driver() routine is supposed to call the gadget
driver's unbind method, not the disconnect method.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

This patch adds a CDC EEM ethernet gadget driver.  CDC EEM is a newer
USB ethernet specification that uses a simpler interface than the older
CDC ECM.  This makes CDC EEM usable by a wider set of USB hardware.
By default the ethernet gadget will still use CDC ECM/Subset, but kernel
configuration and/or a module parameter will allow alternative use of
the CDC EEM protocol.

Changes since last version:
	- Brought in missing RNDIS changes that caused compile error
	- Modified 'sentinel CRC' checking to match EEM host driver
Signed-off-by: Brian Niebuhr <bniebuhr@efjohnson.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

These printks can be removed as they only provide information
about the driver not the device and nobody has ever provided
feedback.
Signed-off-by: Oliver Neukum <oliver@neukum.org>

When do_output_char() attempts to write a carriage return/line feed sequence,
it first checks to see how much buffer room is available. If there are at least
two characters free, it will write the carriage return/line feed with two calls
to tty_put_char(). It calls the tty_operation functions write() for devices that
don't support the tty_operations function put_char(). If the USB generic serial
device's write URB is not in use, it will return the buffer size when asked how
much room is available. The write() of the carriage return will cause it to mark
the write URB busy, so the subsequent write() of the line feed will be ignored.

This patch uses the kfifo infrastructure to implement a write FIFO that
accurately returns the amount of space available in the buffer.
Signed-off-by: David VomLehn <dvomlehn@cisco.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Remove unused variable in ohci-ep93xx.c.

This only shows up when CONFIG_PM is enabled.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Cc: Lennert Buytenhek <kernel@wantstofly.org>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

subsys_initcall_sync() is only defined for built-in code, not for
loadable modules, so this driver build fails when built as a module.
However, the _sync() forms of the initcalls are not implemented,
so this should not be used -- just use the non-sync form of it.

drivers/usb/otg/twl4030-usb.c:777: warning: data definition has no type or storage class
drivers/usb/otg/twl4030-usb.c:777: warning: type defaults to 'int' in declaration of 'subsys_initcall_sync'
drivers/usb/otg/twl4030-usb.c:777: warning: parameter names (without types) in function declaration
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Cc: Felipe Balbi <felipe.balbi@nokia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>