By simply setting a flag, we drop some boilerplate
code.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

By simply setting a flag, we drop some boilerplate
code.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

By simply setting a flag, we can delete a little
boilerplate code.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

We don't need to register that device ourselves
if we simply set gadget->register_my_device.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Currently all UDC drivers are calling
device_register() before calling
usb_add_gadget_udc(). In order to avoid
code duplication, we can allow udc-core.c
register that device.

However that would become a really large patch,
so to cope with the meanwhile and allow us
to write bite-sized patches, we're adding
a flag which will be set by UDC driver once
it removes the code for registering the
gadget device.

Once all are converted, the new flag will
be removed.
Reviewed-by: NTomasz Figa <tomasz.figa@gmail.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Now that we have drivers for omap-usb2 phy and omap-usb3 phy, stop
using nop-usb-xceiv.
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

omap5 is not going to have support for non-dt boot making the platform
data associated with dwc3 useless. Removed it here.
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Includes few minor fixes in dwc3-omap like populating the compatible
string in a correct way, extracting the utmi-mode property properly and
changing the index of get_irq since irq of core is removed from hwmod
entry.

Also updated the documentation with dwc3-omap device tree binding
information.
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>

[ balbi@ti.com : fix a compile warning introduced by
	this commit ]
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Add 2 flags, needs_vcc and needs_reset to platform data.
If the flag is set and the regulator couldn't be found
then we bail out with -EPROBE_DEFER.

For device tree boot we depend on presensce of vcc-supply/
reset-supply properties to decide if we should bail out
with -EPROBE_DEFER or just continue in case the regulator
can't be found.

This is required for proper functionality in cases where the
regulator is needed but is probed later than the PHY device.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

The PHY clock, clock rate, VCC regulator and RESET regulator
can now be provided via device tree.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

We would need to support multiple PHYs of the same type
so use the new PHY API usb_add_phy_dev() to register the PHY.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

We expect the RESET line to be modeled as a regulator with supply
name "reset". The regulator should be modeled such that enabling
the regulator brings the PHY device out of RESET and disabling the
regulator holds the device in RESET.

They PHY will be held in RESET in .shutdown() and brought out of
RESET in .init().
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

We use "vcc" as the supply name for the PHY's power supply.
The power supply will be enabled during .init() and disabled
during .shutdown()
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

If the PHY has a clock associated to it then manage the clock.
We just enable the clock in .init() and disable it in .shutdown().

Add clk_rate parameter in platform data and configure the
clock rate during probe if supplied.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Use resource managed kzalloc.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

The commit 2e124b4a removed the checks
that prevented qt2_process_read_urb() from trying to put chars into
ttys that weren't actually opened.  This resulted in 'tty is NULL'
warnings from flush_to_ldisc() when the device was used.

The devices use just one read urb for all ports.  As a result
qt2_process_read_urb() may be called with the current port set to a
port number that has not been opened.  Add a check if the port is open
before calling tty_flip_buffer_push().
Signed-off-by: NBill Pemberton <wfp5p@virginia.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Turns out we just need altsetting 1 and then we can talk to it.
Signed-off-by: NDan Williams <dcbw@redhat.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The buffer for responses must not overflow.
If this would happen, set a flag, drop the data and return
an error after user space has read all remaining data.
Signed-off-by: NOliver Neukum <oliver@neukum.org>
CC: stable@kernel.org
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The Rigblaster Advantage is an amateur radio interface sold by West Mountain
Radio. It contains a cp210x serial interface but the device ID is not in
the driver.
Signed-off-by: NSteve Conklin <sconklin@canonical.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

4 ports; AT/PPP is standard CDC-ACM.  The other three (added by this
patch) are QCDM/DIAG, possibly GPS, and unknown.
Signed-off-by: NDan Williams <dcbw@redhat.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

when making commit e574d570 (usb: musb: fix
compile warning) I forgot to git add this
part of the patch which ended up introducing
a possible build error.
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch adds support for the Lake Shore Cryotronics devices to
the CP210x driver.

These lines are ported from cp210x driver distributed by Lake Shore web site:
   http://www.lakeshore.com/Documents/Lake%20Shore%20cp210x-3.0.0.tar.gz
and licensed under the terms of GPLv2.

Moreover, I've tested this changes with Lake Shore 335 in my labs.
Signed-off-by: NMatwey V. Kornilov <matwey@sai.msu.ru>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

when commit 6166c246 (usb: gadget: pxa25x_udc:
convert to udc_start/udc_stop) converted
this driver to udc_start/udc_stop, it failed
to consider the fact that stop_activity()
is called from disconnect interrupt.

Fix the problem so that gadget drivers know
about proper disconnect sequences.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

drivers/usb/dwc3/ep0.c: In function `__dwc3_ep0_do_control_data':
drivers/usb/dwc3/ep0.c:905: error: `typeof' applied to a bit-field

Looks like a gcc-3.4.5/sparc64 bug.

Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

RetryCnt value in c67x00 TD should be 3 (both bits set to 1). Reference
Cypress Semiconductor BIOS User's Manual 1.2, page 3-14
Signed-off-by: NDave Tubbs <dave.tubbs@portalislc.com>
Acked-by: NPeter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

TD data length is 10 bits, correct TD_PORTLENMASK_DL. Reference
Cypress Semiconductor BIOS User's Manual 1.2, page 3-10
Signed-off-by: NDave Tubbs <dave.tubbs@portalislc.com>
Acked-by: NPeter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

drivers/usb/phy/ should be compiled everytime
we have CONFIG_USB_OTG_UTILS enabled.

phy/ should've been part of the build process based
on CONFIG_USB_OTG_UTILS, don't know where I had my head
when I allowed CONFIG_USB_COMMON there.

In fact commit c6156328
tried to fix a previous issue but it made things even
worse.

The real solution is to compile phy/ based on
CONFIG_USB_OTG_UTILS which gets selected by all PHY
drivers.

I only triggered the error recently after accepting a
patch which moved a bunch of code from otg/otg.c to
phy/phy.c and running 100 randconfig cycles.
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

add support for Cinterion's products AH6 and PLS8 by adding Product IDs
and USB_DEVICE tuples.
Signed-off-by: NChristian Schmiedl <christian.schmiedl@gemalto.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

1bf0cf60 "usb: gadget: omap_udc: convert to udc_start/udc_stop"
made some trivial changes but was missing a ';' character.

8c4cc005 "ARM: OMAP1: DMA: Moving OMAP1 DMA channel definitions
to mach-omap1" added a definition for OMAP_DMA_USB_W2FC_TX0 to
the driver while making the header file it was defined in
unavailable for drivers, but this driver actually needs
OMAP_DMA_USB_W2FC_RX0 as well.

Both changes appear trivial, so let's add the missing semicolon
and the macro definition.
Acked-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit 200e0d99 ("USB: storage: optimize to match the
Huawei USB storage devices and support new switch command" and the
followup bugfix commit cd060956 ("USB: storage: properly handle
the endian issues of idProduct").

The commit effectively added a large number of Huawei devices to
the deprecated usb-storage mode switching logic.  Many of these
devices have been in use and supported by the userspace
usb_modeswitch utility for years.  Forcing the switching inside
the kernel causes a number of regressions as a result of ignoring
existing onfigurations, and also completely takes away the ability
to configure mode switching per device/system/user.

Known regressions caused by this:
 - Some of the devices support multiple modes, using different
  switching commands.  There are existing configurations taking
  advantage of this.

 - There is a real use case for disabling mode switching and
  instead mounting the exposed storage device. This becomes
  impossible with switching logic inside the usb-storage driver.

 - At least on device fail as a result of the usb-storage switching
  command, becoming completely unswitchable. This is possibly a
  firmware bug, but still a regression because the device work as
  expected using usb_modeswitch defaults.

In-kernel mode switching was deprecated years ago with the
development of the more user friendly userspace alternatives. The
existing list of devices in usb-storage was only kept to prevent
breaking already working systems.  The long term plan is to remove
the list, not to add to it. Ref:
http://permalink.gmane.org/gmane.linux.usb.general/28543

Cc: <fangxiaozhi@huawei.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Acked-by: NMatthew Dharm <mdharm-usb@one-eyed-alien.net>
Signed-off-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Another device using CDC ACM with vendor specific protocol to mark
serial functions.

Cc: stable <stable@vger.kernel.org>
Signed-off-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fix the following sparse warning:

drivers/usb/musb/omap2430.c:54:33: warning: symbol '_glue' was not \
	declared. Should it be static?
Signed-off-by: NAaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Commit 80ab72e1 (usb: musb: omap2430: fix the readiness check
in omap_musb_mailbox) made the check incorrect, as we will lose the
glue/link status during the normal built-in probe order (twl4030_usb is
probed after musb omap2430, but before musb core is ready).

As a result, if you boot with USB cable on and load g_ether, the
connection does not work as the code thinks the cable is off and the
phy gets powered down immediately. This is a major regression in 3.9-rc1.

So the proper check should be: exit if _glue is NULL, but if it's
initialized we memorize the status, and then check if the musb core
is ready.
Signed-off-by: NAaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

When running 100 randconfig iterations, I found
the following warning:

drivers/usb/musb/musb_core.c: In function ‘musb_init_controller’:
drivers/usb/musb/musb_core.c:1981:1: warning: label ‘fail5’ defined \
	but not used [-Wunused-label]

this patch fixes it by removing the unnecessary
ifdef CONFIG_SYSFS.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

those are quite unnecessary, the only thing
we need to be careful about is USB_OTG_UTILS
which get properly selected by PHY drivers.

For now, MUSB will select only USB_OTG_UTILS
until we add stubs for the cases when PHY
layer isn't enabled.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

A few trivial fixes for composite driver:

Warning(include/linux/usb/composite.h:165): No description found for parameter
	'fs_descriptors'
Warning(include/linux/usb/composite.h:165): Excess struct/union/enum/typedef
	member 'descriptors' description in 'usb_function'
Warning(include/linux/usb/composite.h:321): No description found for parameter
	'gadget_driver'
Warning(drivers/usb/gadget/composite.c:1777): Excess function parameter 'bind'
	description in 'usb_composite_probe'

Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Kosina <trivial@kernel.org>
Cc: linux-usb@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

This patch (as1661) fixes a rather obscure bug in ehci-hcd.  In a
couple of places, the driver compares the DMA address stored in a QH's
overlay region with the address of a particular qTD, in order to see
whether that qTD is the one currently being processed by the hardware.
(If it is then the status in the QH's overlay region is more
up-to-date than the status in the qTD, and if it isn't then the
overlay's value needs to be adjusted when the QH is added back to the
active schedule.)

However, DMA address in the overlay region isn't always valid.  It
sometimes will contain a stale value, which may happen by coincidence
to be equal to a qTD's DMA address.  Instead of checking the DMA
address, we should check whether the overlay region is active and
valid.  The patch tests the ACTIVE bit in the overlay, and clears this
bit when the overlay becomes invalid (which happens when the
currently-executing URB is unlinked).

This is the second part of a fix for the regression reported at:

	https://bugs.launchpad.net/bugs/1088733Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Reported-by: NJoseph Salisbury <joseph.salisbury@canonical.com>
Reported-and-tested-by: NStephen Thirlwall <sdt@dr.com>
CC: <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch (as1660) works around a hardware problem present in some
(if not all) Intel EHCI controllers.  After a QH has been unlinked
from the async schedule and the corresponding IAA interrupt has
occurred, the controller is not supposed access the QH and its qTDs.
There certainly shouldn't be any more DMA writes to those structures.
Nevertheless, Intel's controllers have been observed to perform a
final writeback to the QH's overlay region and to the most recent qTD.
For more information and a test program to determine whether this
problem is present in a particular controller, see

	http://marc.info/?l=linux-usb&m=135492071812265&w=2
	http://marc.info/?l=linux-usb&m=136182570800963&w=2

This patch works around the problem by always waiting for two IAA
cycles when unlinking an async QH.  The extra IAA delay gives the
controller time to perform its final writeback.

Surprisingly enough, the effects of this silicon bug have gone
undetected until quite recently.  More through luck than anything
else, it hasn't caused any apparent problems.  However, it does
interact badly with the path that follows this one, so it needs to be
addressed.

This is the first part of a fix for the regression reported at:

	https://bugs.launchpad.net/bugs/1088733Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Tested-by: NStephen Thirlwall <sdt@dr.com>
CC: <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

USB uses the .find_bridge() callback from struct acpi_bus_type
incorrectly, because as a result of the way it is used by USB every
device in the system that doesn't have a bus type or parent is
passed to usb_acpi_find_device() for inspection.

What USB actually needs, though, is to call usb_acpi_find_device()
for USB ports that don't have a bus type defined, but have
usb_port_device_type as their device type, as well as for USB
devices.

To fix that replace the struct bus_type pointer in struct
acpi_bus_type used for matching devices to specific subsystems
with a .match() callback to be used for this purpose and update
the users of struct acpi_bus_type, including USB, accordingly.
Define the .match() callback routine for USB, usb_acpi_bus_match(),
in such a way that it will cover both USB devices and USB ports
and remove the now redundant .find_bridge() callback pointer from
usb_acpi_bus.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: NYinghai Lu <yinghai@kernel.org>
Acked-by: NJeff Garzik <jgarzik@pobox.com>