When ohci-hcd is shutting down, call ohci_usb_reset reset ohci-hcd, the
root hub generate an interrupt, but ohci->rh_state is OHCI_RH_HALTED,
and ohci_irq ignore the interrupt, the kernel trigger warning "irq
nobody cared". ehci-hcd is first disable interrupts, then reset ehci.

This patch disable ohci interrupt before reset ohci.

The patch is tested at the arm cortex-a9 demo board.
Signed-off-by: caizhiyong <caizhiyong@huawei.com>
Reviewed-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 57f6ce07 ("usb: phy:
add a new driver for usb3 phy") added the new Kconfig option
OMAP_USB3, but it had no dependencies whatsoever, and hence
became available across all arch/platforms.

Which presumably caused this to show up in x86 randconfig:

    warning: (USB_MUSB_HDRC && OMAP_USB3) selects \
        OMAP_CONTROL_USB which has unmet direct \
        dependencies (USB_SUPPORT && ARCH_OMAP2PLUS)

Then commit 6992819f ("usb: phy:
fix Kconfig warning") was added.  However, this just deleted the
ARCH_OMAP2PLUS dependency from OMAP_CONTROL_USB, further
compounding the problem by opening up OMAP_CONTROL_USB to
all arch/platforms as well.

Earlier it was suggested[1] that we revert the change of 6992819f
to restore the dependency, and add a same ARCH_OMAP2PLUS dependency
to the new OMAP_USB3 entry.  However that was discouraged on the
grounds of people wanting the extra sanity compile testing on x86,
even though the driver could probably never be used there.

Now we have CONFIG_COMPILE_TEST, so developers who value the ability
to compile drivers on an architecture that it never can be used for
can have that, and people who want dependencies to shield them from
seeing options that aren't relevant to their platform get what they
want too.

Here we restore the dependency but couple it with COMPILE_TEST, in
order to achieve both of the above goals.

[1] https://patchwork.kernel.org/patch/2194511/Acked-by: Felipe Balbi <balbi@ti.com>
Cc: Kishon Vijay Abraham I <kishon@ti.com>
Cc: Moiz Sonasath <m-sonasath@ti.com>
Cc: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Merge the usb_hcd_ep93xx_probe() into ohci_hcd_ep93xx_drv_probe() and
the usb_hcd_ep93xx_remove() into ohci_hcd_ep93xx_drv_remove(). As Alan
Stern pointed out, there is no reason for them to be separate.

Also, as Alan Stern suggested, eliminate the ep93xx_start_hc() and
ep93xx_stop_hc() routines and simply call clk_enable() and clk_disable()
directly. The extra level of redirection does not add any clarity.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: Lennert Buytenhek <kernel@wantstofly.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Use devm_clk_get() to make the code a bit cleaner and simpler.

This also fixes a bug where a clk_put() is not done if usb_add_hcd()
fails.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: Lennert Buytenhek <kernel@wantstofly.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Use platform_get_irq() instead of accessing the platform_device
resources directly.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: Lennert Buytenhek <kernel@wantstofly.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Use devm_ioremap_resource() to make the code a bit cleaner and
simpler.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: Lennert Buytenhek <kernel@wantstofly.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Updated skel_read() in usb-skeleton.c. When there is no data in the
buffer, we would allow retry for both blocking and nonblocking cases.
Original logic give retry only for blocking case. Actually we can also
allow retry for nonblocking case. This will reuse the existing retry
logic and handle the return of -EAGAIN in one place. Also if the data to
be read is short and can be retrieved in quick time, we can also give a
chance for nonblocking case and may catch the data and copy it back to
userspace in one read() call too.
Signed-off-by: Chen Wang <unicornxx.wang@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

kfree(data) will be called implicitly.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

There is a few cases where braces are not needed. This patch removes
unnecessary '& 255' pieces as well when lvalue type is u8.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Additionally remove useless label.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Recent patch series introduces few trailing spaces. This patch removes them.
No functional change.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

For certain (HP) printers the printer device_id does not only contain a
static part identifying the printer, but it also contains a dynamic part
giving printer status, ink level, etc.

To get to this info various userspace utilities need to be able to make a
printer class 'get_device_id' request without first claiming the interface
(as that is in use for the actual printer driver).

Since the printer class 'get_device_id' request does not change interface
settings in anyway, allowing this without claiming the interface should not
cause any issues.

CC: Sanjay Kumar <sanjay.kumar14@hp.com>
CC: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Most HCD drivers are doing the same thing in their ".shutdown" callback
so it makes sense to use the generic usb_hcd_platform_shutdown()
handler there.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Reviewed-by: Felipe Balbi <balbi@ti.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch removes a redundant nested "#ifdef CONFIG_PM" from the hub
driver.  It also adds a label to the "#endif" line corresponding to
the outer "#ifdef CONFIG_PM".
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

An Embedded Host High-Speed Electrical Test (EHSET) test fixture is
used to initiate test modes on a host controller in order to perform
the high speed electrical testing procedure for USB-IF compliance.
When this test fixture is connected to a host, it can enumerate as
one of several selectable VID/PID pairs, each corresponding to one
of the following test modes:

* TEST_SE0_NAK
* TEST_J
* TEST_K
* TEST_PACKET
* HS_HOST_PORT_SUSPEND_RESUME
* SINGLE_STEP_GET_DEV_DESC
* SINGLE_STEP_SET_FEATURE

The USB EHSET procedure can be found here:
http://www.usb.org/developers/onthego/EHSET_v1.01.pdfSigned-off-by: Manu Gautam <mgautam@codeaurora.org>
[jackp@codeaurora.org: imported from commit 073c9409 on codeaurora.org;
 minor cleanup and updated author email]
Signed-off-by: Jack Pham <jackp@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

bInterval must be within the range 1 - 16
when running at High/Super speed, and within
the range 1 - 255 when running at Full/Low speed.

In order to catch drivers passing a too
large bInterval on Super/High speed scenarios
(thus overflowing urb->interval), let's clamp()
the argument to the allowed ranges.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

bInterval must be on the range 1 - 16, if we
want to pass the maximum allowed, we should
be passing 16.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

bInterval must be on the range 1 - 16, if we
want to pass the maximum allowed, we should
be passing 16
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit 1dd3d123.

The email address for the developer now bounces, which means they have
moved on, so remove the driver until someone else from the company steps
up to maintain it.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

FOTG210 is an OTG controller which can be configured as an
USB2.0 host. FOTG210 host is an ehci-like controller with
some differences. First, register layout of FOTG210 is
incompatible with EHCI. Furthermore, FOTG210 is lack of
siTDs which means iTDs are used for both HS and FS ISO
transfer.
Signed-off-by: Yuan-Hsin Chen <yhchen@faraday-tech.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB spec stats that short packet can only appear at the end
of transfer. Because lost of HC(EHCI/UHCI/OHCI/...) can't
build a full packet from discontinuous buffers, we introduce
the limit in usb_submit_urb() to avoid such kind of bad sg buffers
coming from driver.

The limit might be a bit strict:
	- platform has iommu to do sg list mapping
	- some host controllers may support to build full packet from
	discontinuous buffers.

But considered that most of HCs don't support that, and driver
need work well or keep consistent on different HCs and ARCHs, we
have to introduce the limit.

Currently, only usbtest is reported to pass such sg buffers to HC,
and other users(mass storage, usbfs) don't have the problem.

We don't check it on USB wireless device, because:
	- wireless devices can't be attached to common USB
	  bus(EHCI/UHCI/OHCI/...)
	- the max packet size of endpoint may be odd, and often can't
	devide 4KB which is a typical usage in usb mass storage application
Reported-by: Konstantin Filatov <kfilatov@parallels.com>
Reported-by: Denis V. Lunev <den@openvz.org>
Cc: Felipe Balbi <balbi@ti.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Drivers should not be putting debug files in /proc/ that is what debugfs
is for, so move the isp1362 driver's debug file to debugfs.
Reviewed-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Drivers should not be putting debug files in /proc/ that is what debugfs
is for, so move the sl811 driver's debug file to debugfs.
Reviewed-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

None of these USB files need idr.h, so don't include it.

Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Reviewed-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Merge tag 'for-usb-next-2013-07-23' of git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci into usb-next

Sarah writes:

xhci: Features for 3.12

In the spirit of "let's stop gossiping around the water cooler and get to work",
here's some xHCI patches for 3.12.

They include a patch for suspend/resume support for xhci platform hosts, two
patches to support showing USB 2.1 link status, and a patch to future-proof the
Intel EHCI to xHCI port switchover.

Sarah Sharp

This removes the dependency of the driver on CONFIG_USB_DEBUG and moves
it to us the dynamic debug subsystem instead.  Bonus is the fact that we
can now properly determine the exact hardware that is spitting out the
messages.

This lets debugging be enabled without having to rebuild the driver, an
important thing for users that can not do it.
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Move all debugging messages in the driver to use the dynamic debug
subsystem, and not rely on CONFIG_USB_DEBUG to turn them on or off.

This lets debugging be enabled without having to rebuild the driver, an
important thing for users that can not do it.

It also removes the pointless IRQ_TEST() macro, as that was totally
useless and obviously never used.

Cc: Olav Kongas <ok@artecdesign.ee>
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Now that the debugging macros are cleaned up, just rely on the dynamic
debug code in the kernel to do the debug messages for the driver.

This lets debugging be enabled without having to rebuild the driver, an
important thing for users that can not do it.
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

If you want a debug call, just make it, so move to using the
already-there DBG() call.  No need to make things more complex than they
really need to be.
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Like _BUG_ON(), _WARN_ON() wasn't ever being used, so just delete it, as
obviously things are working properly now (if not, we have bigger
problems...)
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

We shouldn't ever panic in a driver, and these calls were never being
used, so just delete them, as obviously the driver is working properly
now (right?)
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

This endif is for CONFIG_USB_GADGET_DEBUG_FILES, not CONFIG_USB_DEBUG,
so document it properly.
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Now that no USB phy driver is using CONFIG_USB_DEBUG, remove it from the
Makefile.
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Use the in-kernel pr_debug() calls instead of trying to roll your own
DBG macro.  This means the dynamic debugging calls now work here, and
there is no dependency on CONFIG_USB_DEBUG for the phy code anymore.
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Now that no USB atm driver is relying on the CONFIG_USB_DEBUG option
(well, really the DEBUG option, thanks to some Makefile fun), remove it
from the Makefile.

Also remove two last vestiges of DEBUG in the usbatm.c driver, moving
one to VERBOSE_DEBUG, which no one ever really cares about, and the
other to use the dynamic debug subsystem.

Cc: Duncan Sands <duncan.sands@free.fr>
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Move the atm_dbg() call to use the dynamic debug subsystem, and not rely
on CONFIG_USB_DEBUG for if things should be printed out or not.

This also means the drivers do not have to be rebuilt to get debugging
messages, important for getting information from users who can not
rebuild their kernels.
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Enable the USB atm drivers to use the dynamic debugging subsystem, and
not rely on if CONFIG_USB_DEBUG is enabled or not for debugging
messages. This also provides a saner debug message, pointing out the
exact device the message is coming from.

This also means the drivers do not have to be rebuilt to get debugging
messages, important for getting information from users who can not
rebuild their kernels.

Cc: Duncan Sands <duncan.sands@free.fr>
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

We have an in-kernel trace subsystem, so use that instead of printk for
trying to figure out what functions are being called.

Cc: Duncan Sands <duncan.sands@free.fr>
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

If this code isn't triggering this assert by now, it never will, so just
remove it, it's pointless.

Cc: Duncan Sands <duncan.sands@free.fr>
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Remove the vendor and product module parameters which were added a long
time ago when we did not have the dynamic sysfs interface to add
new device ids (and which isn't limited to five new vid/pid pair).

A vid/pid pair can be added dynamically using sysfs, for example:

  echo 0451 1234 >/sys/bus/usb-serial/drivers/ti_usb_3410_5052_1/new_id

for 1-port adapters, or

  echo 0451 1234 >/sys/bus/usb-serial/drivers/ti_usb_3410_5052_2/new_id

for 2-port adapters.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>