usb: chipidea: move vbus regulator operation to core

The vbus regulator is a common element for USB vbus operation,
So, move it from glue layer to core.

Tested-by: Marek Vasut <marex@denx.de>
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: chipidea: remove previous MODULE_ALIAS

After the rename to ci_hdrc we ended up with two MODULE_ALIAS entries, so
remove the old one.

Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Reviewed-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: chipidea: prevent endless loop registering platform_devices when probe fails

Commit 40dcd0e ("usb: chipidea: add PTW, PTS and STS handling") introduced
the following code to the ci_hdrc_probe() function:

+       if (!dev->of_node && dev->parent)
+               dev->of_node = dev->parent->of_node;

This inadvertently associates the ci_hdrc device with the ci_hdrc_imx
driver (which created the ci_hdrc device in the first place).

This results in ci_hdrc_imx_probe() being run for the ci_hdrc device
if ci_hdrc_probe() fails for some reason.
ci_hdrc_imx_probe() will happily create a new ci_hdrc platform_device
whose probing will likewise fail and trigger a new invocation of
ci_hdrc_imx_probe() ... ad nauseam.

Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
Reviewed-and-tested-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: chipidea: don't clobber return value of ci_role_start()

If a role fails to start, propagate the error code up the call stack
from probe.

Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: chipidea: ci_hdrc_imx: remove an unsolicited module_put() call from ci_hdrc_imx_remove()

This prevents the USB PHY refcount to be decremented below zero upon
unloading the ci-hdrc-imx module.

Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
Acked-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: chipidea: improve kconfig 2.0

This patch provides a cleaner solution to the problem described in
commit 20a677fd ("usb: chipidea: improve kconfig").

The goal to be achieved is to force USB_CHIPIDEA=m if either
USB_EHCI_HCD=m or USB_GADGET=m.
If both are 'y' USB_CHIPIDEA may be selected to be 'm' or 'y'.

The old patch had the drawback, that USB_CHIPIDEA could be chosen as
'y' though USB_EHCI_HCD or USB_GADGET (or both) were 'm' leading to a
situation where USB_CHIPIDEA_HOST or USB_CHIPIDEA_UDC vanished from
the config options producing a compilable but dysfunctional driver.

Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
Reviewed-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: chipidea: imx: delete the dead code

Remove an unused macro leftover from the old initialization code.

Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: chipidea: move hw_phymode_configure() into probe

Currently hw_phymode_configure() is located inside hw_device_reset(), which is
only called by chipidea udc driver.

When operating in host mode, we also need to call hw_phymode_configure() in
order to properly configure the PHY mode, so move this function into probe.

After this change, USB Host1 port on mx53qsb board is functional.

Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Tested-by: Arnaud Patard <arnaud.patard@rtp-net.org>
Reviewed-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: chipidea: ci_hdrc_imx: remove unused variable 'res'

'res' is not used anywhere, so let's get rid of it.

Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Acked-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Documentation sysfs-bus-usb: Document all files used by libusb

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: dwc3: core: cope with NULL pdata

if pdata is a NULL pointer we could cause a
kernel oops when probing the driver. Make sure
to cope with systems which won't pass pdata
to the driver.

Tested-by: Paul Zimmerman <paulz@synopsys.com>
Reported-by: Paul Zimmerman <paulz@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: rh_call_control tbuf overflow fix

rh_call_control() contains a buffer, tbuf, which it uses to hold
USB descriptors. These discriptors are eventually copied into the
transfer_buffer in the URB. The buffer in the URB is dynamically
defined and is always large enough to hold the amount of data it
requests.

tbuf is currently statically allocated on the stack with a size
of 15 bytes, regardless of the size specified in the URB.
This patch dynamically allocates tbuf, and ensures that tbuf is
at least as big as the buffer in the URB.

If an hcd attempts to write a descriptor containing more than
15 bytes ( such as the Standard BOS Descriptor for hubs, defined
in the USB3.0 Spec, section 10.13.1 ) the write would overflow
the buffer and corrupt the stack. This patch addresses this
behavior.

Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Sean O. Stalley <sean.stalley@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: host: add Kconfig option for EHSET

commit 9841f37a1c ("usb: ehci: Add support for SINGLE_STEP_SET_FEATURE
test of EHSET") added additional code to the EHCI hub driver but it is
anticipated to only have a limited audience (e.g. embedded silicon
vendors and integrators). Avoid subjecting all EHCI (and in the future
maybe xHCI/OHCI, etc.) HCD users to code bloat by conditionally
compiling the EHSET-specific additions with a new Kconfig option,
CONFIG_USB_HCD_TEST_MODE.

Signed-off-by: Jack Pham <jackp@codeaurora.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

pl2303: improve the chip type detection/distinction

The driver currently knows about 3 different PL2303 chip types:
The two legacy chip types type_0 and type_1 (PL2303H ?) and the HX
type.
The device distinction is currently completely based on the examination
of the USB descriptors.
During the last years, Prolific has introduced further PL2303 chips,
such as the HXD (HX rev. D), TA (which replaced the X/HX chips), SA,
RA, EA and TB variants.
Unfortunately, all these new chips are currently detected as HX chips,
because they are all using the same bMaxPacketSize0 = 0x40 value in the
USB device descriptor.

At this point it is not clear if these chips are really working with
the driver, there are just some positive indicators (like device
manufacturers claiming Linux support for these devices or commit
8d48fdf689 "correctly handle baudrates above 115200" which should only
be necessary for newer devices, ...)

For a complete support of all devices, we need to distinguish between
them, because they differ in several functional aspects, such  as the
maximum supported baud rate (HXD, TB, EA: 12Mbps, HX, TA: 6Mbps,
RA: 1Mbps, SA: 115.2kbps), handshaking line support, RS422/485 and
GPIO ports support (currently not supported by the driver).
And there might be further differences that we don't know yet.

This patch improves the chip type detection by evaluating the bcdDevice
value of the device descriptor. The values are taken from the
datasheets and are safe to use because manufacturers can't change them:

3.00: X/HX, TA
4.00: HXD, EA, RA, SA
5.00: TB

The rest of the device descriptors is completely identical, so no
further distinction is possible this way.
Anyway, Prolifics "checkChipVersion.exe"-tool is definitely able to
distinguish for example between the X/HX and the TA chips, so there
must be a possibility to improve the distinction further...

Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

pl2303: improve the chip type information output on startup

The chip type distinction is getting more and more relevant and
complicating, so always print the chip type.
Printing a name string is also much better than just printing an
internal index number.

Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

pl2303: simplify the else-if contruct for type_1 chips in pl2303_startup()

There is no need for two else-if constructs for the type_1 chip
detection in pl2303_startup(), so merge them.

Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Merge tag 'usb-for-v3.12' of git://git./linux/kernel/git/balbi/usb into usb-next

Felipe writes:

usb: patches for v3.12 merge window

All patches here have been pending on linux-usb
and sitting in linux-next for a while now.

The biggest things in this tag are:

DWC3 learned proper usage of threaded IRQ
handlers and now we spend very little time
in hardirq context.

MUSB now has proper support for BeagleBone and
Beaglebone Black.

Tegra's USB support also got quite a bit of love
and is learning to use PHY layer and generic DT
attributes.

Other than that, the usual pack of cleanups and
non-critical fixes follow.

Signed-of-by: Felipe Balbi <balbi@ti.com>
Conflicts:
drivers/usb/gadget/udc-core.c
drivers/usb/host/ehci-tegra.c
drivers/usb/musb/omap2430.c
drivers/usb/musb/tusb6010.c

usb: phy: am335x: include linux/err.h

Stephen Rothwell reported that this driver does not compile on PowerPC
due to this missing include. One could argue why this driver is enabled
on PowerPC in the first place but it sure isn't wrong to include headers
for used function instead of to rely that they sneak in.

Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>

usb: musb: cppi41: Enable in device-TX mode

Since the musb-gadget code now calls the dma engine properly it is
possible to enable it for the TX path in device mode.
AM335x Advisory 1.0.13 says that we may lose the toggle bit on multiple
RX transfers. There is a workaround in host mode but none in device mode
and therefore RX transfers are disabled.

Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>

usb: musb: Use is_cppi_enabled() and tusb_dma_omap() instead of the ifdef

This patch makes use of the two function is_cppi_enabled() and
tusb_dma_omap() instead of the ifdef for the proper DMA implementation
setup code. It basically shifts the code right by one indention level
and adds a few line breaks once the chars are crossed.

Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>

usb: pl2303: add two comments concerning the supported baud rates with HX chips

I've found some new datasheets which describe some additionally
supported standard baud rates and I've verified them with my HX
(rev. 3A) device. But adding support for individual (chip type
specific) baud rates would add a good amount of extra code (especially
when support for further chips will be added to the driver one day),
which makes no sense as long as we are not using the direct baud rate
encoding method for newer chips.
So for now, just drop a comment about these additionally supported baud
rates.

The second comment is about the baud rate differences between the two
encoding methods. In theory, we could optimize the code a bit by
comparing the resulting baud rates of both methods and selecting the
one which is closer to the requested baud rate. But that seems to be a
bit overkill, because the differences are very small and the device
likely uses the same baud rate generator for both methods so that the
resulting baud rate would be the same.

Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: pl2303: also use the divisor based baud rate encoding method for baud rates < 115200 with HX chips

Now that the divisor based baud rate encoding method has been fixed and
extended, it can also be used for baud rates < 115200 baud with HX
chips.
This makes it possible to adjust the baud rate almost continuously
instead of just beeing able to select between 16 fixed standard values.

Tested with a PL2303HX 04463A (week 46, 2004, rev 3A).

Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: pl2303: increase the allowed baud rate range for the divisor based encoding method

Reinhard Max has done some tests with a PL2303HX (rev A) and a logic
analyzer and it seems, that although the PL2303HX is specified for baud
rates from 75 to 6M baud, the full divisor range can be used with the
divisor based baud rate encoding method. This corresponds to baud rates
from 46 to 24M baud.
Baud rates down to 46 baud (max. divisor) have been confirmed to work
even under heavy/permanent load, so remove the lower limit.
Baud rates up to 24M baud should really be tested carefully in "real
life" scenarios before removing the upper limit completely.
Anyway, the Windows driver allows maximum baud rates of 110% of the
specified limit, so for now, increase the upper limit to this value.

Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Reinhard Max <max@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: pl2303: move the two baud rate encoding methods to separate functions

Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: pl2303: remove 500000 baud from the list of standard baud rates

Commit 0c967e7e "USB: serial: pl2303 works at 500kbps" added 500000
baud to the list of supported standard baud rates.
But the reason why the driver works with this baud rate is, that since
commit 8d48fdf6 "USB: PL2303: correctly handle baudrates above 115200"
a second (divisor based) baud rate encoding method is used for values
above 115200 baud, which is not limited to a fixed set of standard baud
rates.

Remove the 500000 baud value from the list of standard baud rates
again, because this list is only used with the direct baud rate
encoding method and 500000 baud is not supported with this method.

Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: pl2303: do not round to the next nearest standard baud rate for the divisor based baud rate encoding method

In opposition to the direct baud rate encoding method, the divisor
based method is not limited to a fixed set of standard baud rates.
Hence, there is no need to round to the next nearest standard value.

Reported-by: Mastro Gippo <gipmad@gmail.com>
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Reinhard Max <max@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: pl2303: fix+improve the divsor based baud rate encoding method

Based on the formula in the code description, Reinhard Max and me have
investigated the devices behavior / functional principle of the divisor
based baud rate encoding method.

It turned out, that (although beeing a good starting point) the current
code has some flaws. It doesn't work correctly for a wide range of baud
rates and the divisor resolution can be improved. It also doesn't
report the actually set baud rate.

This patch fixes and improves the code for the divisor based baud rate
encoding method a lot. It can now be used for the whole range of baud
rates from 46 baud to 24M baud with a very good divisor resolution and
userspace can read back the resulting baud rate.

It also documents the formula used for encoding and the hardware
behavior (including special cases).

The basic algorithm, rounding and several code comments/explanations
are provided by Reinhard Max.
I've added some minor fixes, the handling of the special cases and
further code/algorithm descriptions.

Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Reinhard Max <max@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

UWB: fix sysfs warning on HWA device unplug.

In the disconnect routine for the hwa_hc interface, it calls
uwb_pal_unregister to unregister itself from the UWB subsystem.  This
function attempts to clean up the link to the host controller directory in
the device's UWB radio control interface directory.  If the disconnect
routine for the radio control interface has already run, the uwb directory
will be gone so the call to sysfs_remove_link generates a warning.

Signed-off-by: Thomas Pugliese <thomas.pugliese@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

HWA: avoid constant suspend and resume on the root hub

Prevent the USB core from suspending the HWA root hub since bus_suspend
and bus_resume are not yet supported.  Otherwise the PM system will chew
up CPU time constantly attempting to suspend and resume the root hub but
never succeeding.

Signed-off-by: Thomas Pugliese <thomas.pugliese@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

HWA RC: fix a kernel panic when unplugging the HWA dongle

This patch fixes a kernel panic that can occur when unplugging the HWA
dongle while a downstream device is in the process of disconnecting.
This involved 2 changes.  First, call usb_lock_device_for_reset before
usb_reset_device to synchronize the HWA's post_rest and disconnect
routines.  Second, set the hwarc->neep_urb and hwarc->rd_buffer to NULL
when they are freed in the error path in the post_reset routine.  This
prevents a double free when the disconnect routine is called and attempts
to free those resources again.

Signed-off-by: Thomas Pugliese <thomas.pugliese@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: cdc-wdm: fix race between interrupt handler and tasklet

Both could want to submit the same URB. Some checks of the flag
intended to prevent that were missing.

Signed-off-by: Oliver Neukum <oneukum@suse.de>
CC: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

wusbcore: clean up list locking in urb enqueue

wa_urb_enqueue_run locks and unlocks its list lock as it traverses the
list of queued transfers.  This was done to prevent deadlocking due to
acquiring locks in reverse order in different places.  The problem is that
releasing the lock during the list traversal could allow the dequeue
routine to corrupt the list while it is being iterated over.  This patch
moves all list entries to a temp list while holding the list lock, then
traverses the temp list with no lock held.

Signed-off-by: Thomas Pugliese <thomas.pugliese@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

wusbcore: fix root hub hub_status_data to only return > 0 if status has actually changed

The hub_status_data function on the wireless USB root hub controller
(wusbhc_rh_status_data) always returns a positive value even if no ports
have changed.  This patch updates wusbhc_rh_status_data to only return a
positive value if the root hub status needs to be queried.  The current
implementation can also leave the upper bits of the port bitmap
uninitialized if wusbhc->ports_max is not one less than an even multiple
of 8.  This patch fixes that as well by initializing the buffer to 0.

Signed-off-by: Thomas Pugliese <thomas.pugliese@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: ehci: Add support for SINGLE_STEP_SET_FEATURE test of EHSET

The USB Embedded High-speed Host Electrical Test (EHSET) defines the
SINGLE_STEP_SET_FEATURE test as follows:

1) The host enumerates the test device with VID:0x1A0A, PID:0x0108
2) The host sends the SETUP stage of a GetDescriptor(Device)
3) The device ACKs the request
4) The host issues SOFs for 15 seconds allowing the test operator to
   raise the scope trigger just above the SOF voltage level
5) The host sends the IN packet
6) The device sends data in response, triggering the scope
7) The host sends an ACK in response to the data

This patch adds additional handling to the EHCI hub driver and allows
the EHSET driver to initiate this test mode by issuing a a SetFeature
request to the root hub with a Test Selector value of 0x06. From there
it mimics ehci_urb_enqueue() but separately submits QTDs for the
SETUP and DATA/STATUS stages in order to insert a delay in between.

Signed-off-by: Manu Gautam <mgautam@codeaurora.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
[jackp@codeaurora.org: imported from commit c2084930 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>

usb/hcd: Log error code if reset() fails

If someone provided meaningful error codes from reset() we should tell the
user what they were.

Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Documentation sysfs-bus-usb: Correct use of devnum

Correct use of devnum in supports_autosuspend documentation, the sysfs path
contains busnum-port.port.port not busnum-devnum (which is the usb bus device
address).

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

proc_usb_info.txt: Correct documentation about endianness of config descriptors

The config descriptors as read from /proc/bus/usb/BBB/DDD are in *bus* endian
format. Correct proc_usb_info.txt to correctly reflect that.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: config->desc.bLength may not exceed amount of data returned by the device

While reading the config parsing code I noticed this check is missing, without
this check config->desc.wTotalLength can end up with a value larger then the
dev->rawdescriptors length for the config, and when userspace then tries to
get the rawdescriptors bad things may happen.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: misc: usb3503: Support operation with no I2C control

Refactor so that register writes for configuration are only performed if
the device has a regmap provided and also register as a platform driver.
This allows the driver to be used to manage GPIO based control of the
device.

Signed-off-by: Mark Brown <broonie@linaro.org>
Cc: devicetree@vger.kernel.org
Reviewed-by: Dongjin Kim <tobetter@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: misc: usb3503: Don't specify all DT properties as required

The binding document says that all properties are required but in fact
almost all are optional (and should be) - update the document to reflect
this.

Signed-off-by: Mark Brown <broonie@linaro.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: misc: usb3503: Add USB3503A to the compatible list

There are no software visible differences that I am aware of but in case
any are discovered allow the DTS to specify exactly which device is
present.

Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: misc: usb3503: Default to hub mode

Since there is no runtime interface for changing modes this is probably
the most sensible default.

Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: misc: usb3503: Fix typos in error messages

Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: misc: usb3503: Factor out I2C probe

In preparation for supporting operation without an I2C control interface
factor out the I2C-specific parts of the probe routine from those that
don't do any register I/O.

Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: misc: usb3503: Convert to regmap

This will give access to the diagnostic infrastructure regmap has but
the main point is to support future refactoring.

Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: misc: usb3503: Actively manage Hub Connect GPIO

If the connect signal is pulled high then the device will start up meaning
that if we just pull it high on probe then the device will start running
prior to the configuration being written out. Fix this by pulling the GPIO
low when we reset and only pulling it high when configuration is finished.

Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: misc: usb3503: Use gpio_set_value_cansleep()

The /RESET GPIO is not manipulated from atomic context so support GPIOs
that can't be written from atomic context by using _cansleep().

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: Move definition of USB_EHCI_BIG_ENDIAN_MMIO et al. out side of the ifs.

When CONFIG_USB_SUPPORT is not selected we get things like:

scripts/kconfig/mconf Kconfig
warning: (MIPS_SEAD3 && PMC_MSP && CPU_CAVIUM_OCTEON) selects USB_EHCI_BIG_ENDIAN_MMIO which has unmet direct dependencies (USB_SUPPORT && USB)

It is much cleaner to make the various system Kconfigs select
USB_EHCI_BIG_ENDIAN_MMIO rather than move the system config
information into USB's Kconfig, but the warnings are annoying.

Eliminate the warning by moving the definition of
USB_EHCI_BIG_ENDIAN_MMIO outside of all the Kconfig if statements.
While we are at it move USB_OHCI_BIG_ENDIAN_DESC,
USB_OHCI_BIG_ENDIAN_MMIO, USB_OHCI_LITTLE_ENDIAN and
USB_EHCI_BIG_ENDIAN_DESC too, as they could very well suffer similar
problems for other systems.

Get rid of the redundant "default n" in USB_OHCI_BIG_ENDIAN_DESC and
USB_OHCI_BIG_ENDIAN_MMIO

Signed-off-by: David Daney <david.daney@cavium.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: misc: usb3503: Convert to devm_ APIs

Saves us a bit of code.

Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: misc: Fix swapped properties in usb3503 DT parsing

The intn and connect GPIO properties are swapped in the code which will
cause failures at runtime if these are connected, fix the code.

There are currently no in-tree users of this device to check or update.

Signed-off-by: Mark Brown <broonie@linaro.org>
Acked-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: serial: move the "simple" drivers into usb-serial-simple.c

Instead of having to create a new driver for a "simple" usb to serial
device, mush them all into one file, with a macro, so as to make it easy
to add new ones.

Cc: "René Bürgel" <rene.buergel@sohard.de>
Acked-by: Wei Shuai <cpuwolf@gmail.com>
Cc: Josh Triplett <josh@joshtriplett.org>
Acked-by: Frans Klaver <frans.klaver@xsens.com>
Cc: "Wesley W. Terpstra" <w.terpstra@gsi.de>
Cc: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USBNET: ax88179_178a: enable tso if usb host supports sg dma

This patch enables 'can_dma_sg' flag for ax88179_178a device
if the attached host controller supports building packet from
discontinuous buffers(DMA SG is possible), so TSO can be enabled
and skb fragment buffers can be passed to usb stack via urb->sg
directly.

With the patch, system CPU utilization decreased ~50% and throughput
increased by ~10% when doing iperf client test on one ARM A15 dual
core board.

Cc: Ben Hutchings <bhutchings@solarflare.com>
Cc: Grant Grundler <grundler@google.com>
Cc: Oliver Neukum <oneukum@suse.de>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Freddy Xin <freddy@asix.com.tw>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Acked-by: Eric Dumazet <edumazet@gmail.com>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USBNET: support DMA SG

This patch introduces support of DMA SG if the USB host controller
which usbnet device is attached to is capable of building packet from
discontinuous buffers.

The patch supports passing the skb fragment buffers to usb stack directly
via urb->sg.

Cc: Ben Hutchings <bhutchings@solarflare.com>
Cc: Grant Grundler <grundler@google.com>
Cc: Freddy Xin <freddy@asix.com.tw>
Cc: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: musb: dsps: make it depend on OF_IRQ

musb_dsps.c utilizes a symbol which is only
available when CONFIG_OF_IRQ is set, so make
it depend on that.

Signed-off-by: Felipe Balbi <balbi@ti.com>

USB: XHCI: mark no_sg_constraint

This patch marks all xHCI controllers as no_sg_constraint
since xHCI supports building packet from discontinuous buffers.

Cc: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: introduce usb_device_no_sg_constraint() helper

Some host controllers(such as xHCI) can support building
packet from discontinuous buffers, so introduce one flag
and helper for this kind of host controllers, then the
feature can help some applications(such as usbnet) by
supporting arbitrary length of sg buffers.

Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: EHCI: support running URB giveback in tasklet context

All 4 transfer types can work well on EHCI HCD after switching to run
URB giveback in tasklet context, so mark all HCD drivers to support
it.

Also we don't need to release ehci->lock during URB giveback any more.

>From below test results on 3 machines(2 ARM and one x86), time
consumed by EHCI interrupt handler droped much without performance
loss.

1 test description
1.1 mass storage performance test:
- run below command 10 times and compute the average performance

    dd if=/dev/sdN iflag=direct of=/dev/null bs=200M count=1

- two usb mass storage device:
A: sandisk extreme USB 3.0 16G(used in test case 1 & case 2)
B: kingston DataTraveler G2 4GB(only used in test case 2)

1.2 uvc function test:
- run one simple capture program in the below link

   http://kernel.ubuntu.com/~ming/up/capture.c

- capture format 640*480 and results in High Bandwidth mode on the
uvc device: Z-Star 0x0ac8/0x3450

- on T410(x86) laptop, also use guvcview to watch video capture/playback

1.3 about test2 and test4
- both two devices involved are tested concurrently by above test items

1.4 how to compute irq time(the time consumed by ehci_irq)
- use trace points of irq:irq_handler_entry and irq:irq_handler_exit

1.5 kernel
3.10.0-rc3-next-20130528

1.6 test machines
Pandaboard A1: ARM CortexA9 dural core
Arndale board: ARM CortexA15 dural core
T410: i5 CPU 2.67GHz quad core

2 test result
2.1 test case1: single mass storage device performance test
--------------------------------------------------------------------
upstream  | patched
perf(MB/s)+irq time(us) | perf(MB/s)+irq time(us)
--------------------------------------------------------------------
Pandaboard A1:  25.280(avg:145,max:772) | 25.540(avg:14, max:75)
Arndale board:  29.700(avg:33, max:129) | 29.700(avg:10,  max:50)
T410:  34.430(avg:17, max:154*)| 34.660(avg:12, max:155)
---------------------------------------------------------------------

2.2 test case2: two mass storage devices' performance test
--------------------------------------------------------------------
upstream  | patched
perf(MB/s)+irq time(us) | perf(MB/s)+irq time(us)
--------------------------------------------------------------------
Pandaboard A1:  15.840/15.580(avg:158,max:1216) | 16.500/16.160(avg:15,max:139)
Arndale board:  17.370/16.220(avg:33 max:234) | 17.480/16.200(avg:11, max:91)
T410:  21.180/19.820(avg:18 max:160) | 21.220/19.880(avg:11, max:149)
---------------------------------------------------------------------

2.3 test case3: one uvc streaming test
- uvc device works well(on x86, luvcview can be used too and has
same result with uvc capture)
--------------------------------------------------------------------
upstream  | patched
irq time(us) | irq time(us)
--------------------------------------------------------------------
Pandaboard A1:  (avg:445, max:873) | (avg:33, max:44)
Arndale board:  (avg:316, max:630) | (avg:20, max:27)
T410:  (avg:39,  max:107) | (avg:10, max:65)
---------------------------------------------------------------------

2.4 test case4: one uvc streaming plus one mass storage device test
--------------------------------------------------------------------
upstream  | patched
perf(MB/s)+irq time(us) | perf(MB/s)+irq time(us)
--------------------------------------------------------------------
Pandaboard A1:  20.340(avg:259,max:1704)| 20.390(avg:24, max:101)
Arndale board:  23.460(avg:124,max:726) | 23.370(avg:15, max:52)
T410:  28.520(avg:27, max:169) | 28.630(avg:13, max:160)
---------------------------------------------------------------------

2.5 test case5: read single mass storage device with small transfer
- run below command 10 times and compute the average speed

 dd if=/dev/sdN iflag=direct of=/dev/null bs=4K count=4000

1), test device A:
--------------------------------------------------------------------
upstream  | patched
perf(MB/s)+irq time(us) | perf(MB/s)+irq time(us)
--------------------------------------------------------------------
Pandaboard A1:  6.5(avg:21, max:64) | 6.5(avg:10, max:24)
Arndale board:  8.13(avg:12, max:23) | 8.06(avg:7,  max:17)
T410:  6.66(avg:13, max:131)   | 6.84(avg:11, max:149)
---------------------------------------------------------------------

2), test device B:
--------------------------------------------------------------------
upstream  | patched
perf(MB/s)+irq time(us) | perf(MB/s)+irq time(us)
--------------------------------------------------------------------
Pandaboard A1:  5.5(avg:21,max:43) | 5.49(avg:10, max:24)
Arndale board:  5.9(avg:12, max:22) | 5.9(avg:7, max:17)
T410:  5.48(avg:13, max:155) | 5.48(avg:7, max:140)
---------------------------------------------------------------------

* On T410, sometimes read ehci status register in ehci_irq takes more
than 100us, and the problem has been reported on the link:

http://marc.info/?t=137065867300001&r=1&w=2

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>

USB: EHCI: improve interrupt qh unlink

ehci-hcd currently unlinks an interrupt QH when it becomes empty, that
is, after its last URB completes.  This works well because in almost
all cases, the completion handler for an interrupt URB resubmits the
URB; therefore the QH doesn't become empty and doesn't get unlinked.

When we start using tasklets for URB completion, this scheme won't work
as well.  The resubmission won't occur until the tasklet runs, which
will be some time after the completion is queued with the tasklet.
During that delay, the QH will be empty and so will be unlinked
unnecessarily.

To prevent this problem, this patch adds a 5-ms time delay before empty
interrupt QHs are unlinked.  Most often, during that time the interrupt
URB will be resubmitted and thus we can avoid unlinking the QH.

Signed-off-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>

USB: EHCI: improve ehci_endpoint_disable

The patch does the below improvement:

- think QH_STATE_COMPLETING as unlinking state since all URBs on the
endpoint should be in unlinking or unlinked when doing endpoint_disable()

- add "WARN_ON(!list_empty(&qh->qtd_list));" if qh->qh_state is
QH_STATE_LINKED because there shouldn't be any active transfer in qh

- when qh->qh_state is QH_STATE_LINKED, the QH(async or periodic)
should be in its corresponding list, so the search through the async
list isn't necessary.

- unlink periodic QH to speed up unlinking if the QH is in linked
state

Basically, only the last one is related with this patchset because
the assumption of "periodic qh self-unlinks on empty" isn't true
any more when we introduce unlink-wait for periodic qh.

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>

USB: URB documentation: claim complete() will be run with IRQs enabled

There is no good reason to run complete() in hard interrupt
disabled context.

After switch to run complete() in tasklet, we will enable local IRQs
when calling complete() since we can do it at that time.

Even though we still disable IRQs now when calling complete()
in tasklet, the URB documentation is updated to claim complete()
will be run in tasklet context and local IRQs will be enabled, so
that USB drivers can know the change and avoid one deadlock caused
by: assume IRQs disabled in complete() and call spin_lock() to
hold lock which might be acquired in interrupt context.

Current spin_lock() usages in drivers' complete() will be cleaned
up at the same time, and once the cleanup is finished, local IRQs
will be enabled when calling complete() in tasklet.

Also fix description about type of usb_complete_t, and remove the
advice of running completion handler in tasklet for decreasing
system latency.

Cc: Oliver Neukum <oliver@neukum.org>
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>

USB: HCD: support giveback of URB in tasklet context

This patch implements the mechanism of giveback of URB in
tasklet context, so that hardware interrupt handling time for
usb host controller can be saved much, and HCD interrupt handling
can be simplified.

Motivations:

1), on some arch(such as ARM), DMA mapping/unmapping is a bit
time-consuming, for example: when accessing usb mass storage
via EHCI on pandaboard, the common length of transfer buffer is 120KB,
the time consumed on DMA unmapping may reach hundreds of microseconds;
even on A15 based box, the time is still about scores of microseconds

2), on some arch, reading DMA coherent memoery is very time-consuming,
the most common example is usb video class driver[1]

3), driver's complete() callback may do much things which is driver
specific, so the time is consumed unnecessarily in hardware irq context.

4), running driver's complete() callback in hardware irq context causes
that host controller driver has to release its lock in interrupt handler,
so reacquiring the lock after return may busy wait a while and increase
interrupt handling time. More seriously, releasing the HCD lock makes
HCD becoming quite complicated to deal with introduced races.

So the patch proposes to run giveback of URB in tasklet context, then
time consumed in HCD irq handling doesn't depend on drivers' complete and
DMA mapping/unmapping any more, also we can simplify HCD since the HCD
lock isn't needed to be released during irq handling.

The patch should be reasonable and doable:

1), for drivers, they don't care if the complete() is called in hard irq
context or softirq context

2), the biggest change is the situation in which usb_submit_urb() is called
in complete() callback, so the introduced tasklet schedule delay might be a
con, but it shouldn't be a big deal:

- control/bulk asynchronous transfer isn't sensitive to schedule
  delay

- the patch schedules giveback of periodic URBs using
  tasklet_hi_schedule, so the introduced delay should be very
  small

- for ISOC transfer, generally, drivers submit several URBs
  concurrently to avoid interrupt delay, so it is OK with the
  little schedule delay.

- for interrupt transfer, generally, drivers only submit one URB
  at the same time, but interrupt transfer is often used in event
  report, polling, ... situations, and a little delay should be OK.

Considered that HCDs may optimize on submitting URB in complete(), the
patch may cause the optimization not working, so introduces one flag to mark
if the HCD supports to run giveback URB in tasklet context. When all HCDs
are ready, the flag can be removed.

[1], http://marc.info/?t=136438111600010&r=1&w=2

Cc: Oliver Neukum <oliver@neukum.org>
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>

usb: host: tegra: Tegra30 support

The Tegra30 EHCI controller is mostly compatible with the Tegra20
controller, except Tegra30 includes the HOSTPC register extension.
The has_hostpc capability bit must be set in the ehci_hcd structure if
the controller has such extensions. The new tegra_ehci_soc_config
structure is added to describe the differences between the SoCs.

Signed-off-by: Tuomas Tynkkynen <ttynkkynen@nvidia.com>
Tested-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

usb: phy: tegra: Program new PHY parameters

The Tegra30 TRM recommends configuration of certain PHY parameters for
optimal quality. Program the following registers based on device tree
parameters:

- UTMIP_XCVR_HSSLEW: HS slew rate control.
- UTMIP_HSSQUELCH_LEVEL: HS squelch detector level
- UTMIP_HSDISCON_LEVEL: HS disconnect detector level.

These registers exist in Tegra20, but programming them hasn't been
necessary, so these parameters won't be set on Tegra20 to keep the
device trees backward compatible.

Additionally, the UTMIP_XCVR_SETUP parameter can be set from fuses
instead of a software-programmed value, as the optimal value can
vary between invidual boards. The boolean property
nvidia,xcvr-setup-use-fuses can be used to enable this behaviour.

Signed-off-by: Tuomas Tynkkynen <ttynkkynen@nvidia.com>
Tested-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

Documentation: New DT parameters for tegra30-usb-phy

Document the new device tree parameters for Tegra30 USB PHY.

Signed-off-by: Tuomas Tynkkynen <ttynkkynen@nvidia.com>
Tested-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

usb: phy: tegra: Tegra30 support

The Tegra30 USB PHY is a bit different than the Tegra20 PHY:

- The EHCI controller supports the HOSTPC register extension, and some
  of the fields that the PHY needs to modify (PHCD and PTS) have moved
  to the new HOSTPC register.
- Some of the UTMI PLL configuration registers have moved from the USB
  register space to the Clock-And-Reset controller space. In Tegra30
  the clock driver is responsible for configuring the UTMI PLL.
- The USBMODE register must be explicitly written to enter host mode.
- Certain PHY parameters need to be programmed for optimal signal
  quality. Support for this will be added in the next patch.

The new tegra_phy_soc_config structure is added to describe the
differences between the SoCs.

Signed-off-by: Tuomas Tynkkynen <ttynkkynen@nvidia.com>
Tested-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

usb: phy: tegra: Fix wrong PHY parameters

Some of the PHY parameters are not set according to the TRMs:

- UTMIP_FS_PREABMLE_J should be set, not cleared
- UTMIP_XCVR_LSBIAS_SEL should be cleared, not set
- UTMIP_PD_CHRG should be set in host mode and cleared in device mode
- UTMIP_XCVR_SETUP is a two-part field; the upper bits were not set
  properly

Signed-off-by: Tuomas Tynkkynen <ttynkkynen@nvidia.com>
Tested-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

usb: host: add has_tdi_phy_lpm capability bit

The has_hostpc capability bit indicates that the host controller has the
HOSTPC register extensions, but at the same time enables clock disabling
power saving features with the PHY Low Power Clock Disable (PHCD) bit.

However, some host controllers have the HOSTPC extensions but don't
support the low-power feature, so the PHCD bit must not be set on those
controllers. Add a separate capability bit for the low-power feature
instead, and change all existing users of has_hostpc to use this new
capability bit.

The idea for this commit is taken from an old 2012 commit that never got
merged ("disociate chipidea PHY low power suspend control from hostpc")

Inspired-by: Matthieu CASTET <matthieu.castet@parrot.com>
Signed-off-by: Tuomas Tynkkynen <ttynkkynen@nvidia.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

usb: dwc3: core: clarify usb-phy array binding

The binding spec wasn't clear that the order of the phandles in the
usb-phy array has meaning.  Clarify this point in the binding that
it should be <USB2-HS-PHY, USB3-SS-PHY>.

Signed-off-by: Kumar Gala <galak@codeaurora.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>

usb: gadget: uvc: Fix error handling in uvc_queue_buffer()

The conversion to videobuf2 failed to check the return value of
vb2_qbuf(). Fix it.

Cc: stable@vger.kernel.org
Reported-by: Michael Grzeschik <mgr@pengutronix.de>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-By: Michael Grzeschik <mgr@pengutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>

usb: musb dma: add cppi41 dma driver

This driver is currently used by musb' cppi41 couter part. I may merge
both dma engine user of musb at some point but not just yet.

The driver seems to work in RX/TX mode in host mode, tested on mass
storage. I increaed the size of the TX / RX transfers and waited for the
core code to cancel a transfers and it seems to recover.

v2..3:
- use mall transfers on RX side and check data toggle.
- use rndis mode on tx side so we haveon interrupt for 4096 transfers.
- remove custom "transferred" hack and use dmaengine_tx_status() to
  compute the total amount of data that has been transferred.
- cancel transfers and reclaim descriptors

v1..v2:
- RX path added
- dma mode 0 & 1 is working
- device tree nodes re-created.

Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <djbw@fb.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>

usb: musb: dsps: use proper child nodes

This moves the two instances from the big node into two child nodes. The
glue layer ontop does almost nothing.

There is one devices containing the control module for USB (2) phy,
(2) usb and later the dma engine. The usb device is the "glue device"
which contains the musb device as a child. This is what we do ever since.

The new file musb_am335x is just here to prob the new bus and populate
child devices.

There are a lot of changes to the dsps file as a result of the changes:

- musb_core_offset
  This is gone. The device tree provides memory ressources information
  for the device there is no need to "fix" things

- instances
  This is gone as well. If we have two instances then we have have two
  child enabled nodes in the device tree. For instance the SoC in beagle
  bone has two USB instances but only one has been wired up so there is
  no need to load and init the second instance since it won't be used.

- dsps_glue is now per glue device
  In the past there was one of this structs but with an array of two and
  each instance accessed its variable depending on the platform device
  id.

- no unneeded copy of structs
  I do not know why struct dsps_musb_wrapper is copied but it is not
  necessary. The same goes for musb_hdrc_platform_data which allocated
  on demand and then again by platform_device_add_data(). One copy is
  enough.

Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>

usb: musb: dsps: remove the hardcoded phy pieces

dsps uses a nop driver which is added in dsps itself and does the PHY
on/off calls within dsps. Since those calls are now moved the nop driver
itself, we can now request the phy proper phy and remove those calls.
Currently only the first musb interface is used so we only add one phy
node for now.

Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>

usb: phy: Add AM335x PHY driver

This driver is a redo of my earlier attempt. It uses parts of the
generic PHY driver and uses the new control driver for the register
the phy needs to power on/off the phy. It also enables easy access for
the wakeup register which is not yet implemented.
The difference between the omap attempt is:
- no static holding variable
- one global visible function which exports a struct with callbacks to
  access the "control" registers.

Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>

usb: phy: phy-generic: export init functions

This patch exports the mostly generic functions so they can be used from
other phy driver instead of duplicating the code.

Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>

Merge branch 'nop-phy-rename' into next

Signed-off-by: Felipe Balbi <balbi@ti.com>
Conflicts:
drivers/usb/phy/phy-generic.c

usb: phy: rename nop_usb_xceiv => usb_phy_gen_xceiv

The "nop" driver isn't a do-nothing-stub but supports a couple functions
like clock on/off or is able to use a voltage regulator. This patch
simply renames the driver to "generic" since it is easy possible to
extend it by a simple function istead of writing a complete driver.

Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>

usb: phy: mv-usb: remove incorrect __exit_p annotation

When platform_driver_probe() is not used, bind/unbind via sysfs
is enabled.  Thus, __exit_p annotation should be removed from
remove().

Also, mv_otg_remove() is staticized, because this function is
used only in this file. Fix the following sparse warning:

drivers/usb/phy/phy-mv-usb.c:656:5: warning: symbol 'mv_otg_remove' was not declared. Should it be static?

Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

usb: phy: mv-u3d: Staticize mv_u3d_phy_shutdown()

mv_u3d_phy_shutdown() is used only in this file.
Fix the following sparse warning:

drivers/usb/phy/phy-mv-u3d-usb.c:85:6: warning: symbol 'mv_u3d_phy_shutdown' was not declared. Should it be static?

Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

usb: gadget: f_uac1: Staticize local functions

control_selector_init() is used only in this file.
audio_bind_config() is used only in audio.c file to which
f_uac1.c is included. Thus, these functions are staticized
to fix the following warnings.

drivers/usb/gadget/f_uac1.c:698:12: warning: symbol 'control_selector_init' was not declared. Should it be static?
drivers/usb/gadget/f_uac1.c:722:12: warning: symbol 'audio_bind_config' was not declared. Should it be static?

Acked-by: Jassi Brar <jaswinder.singh@linaro.org>
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

usb: gadget: u_uac1: add __user annotation

Added __user annotation to fix the following sparse warning.

drivers/usb/gadget/u_uac1.c:194:52: warning: incorrect type in argument 2 (different address spaces)
drivers/usb/gadget/u_uac1.c:194:52:    expected void const [noderef] <asn:1>*buf
drivers/usb/gadget/u_uac1.c:194:52:    got void *buf

Acked-by: Jassi Brar <jaswinder.singh@linaro.org>
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

usb: gadget: rndis: Staticize rndis_init()/rndis_exit()

rndis_init() and rndis_exit() are used only in this file.
Fix the following sparse warnings:

drivers/usb/gadget/rndis.c:1145:5: warning: symbol 'rndis_init' was not declared. Should it be static?
drivers/usb/gadget/rndis.c:1179:6: warning: symbol 'rndis_exit' was not declared. Should it be static?

Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

usb: gadget: f_mass_storage: use NULL instead of 0

The local variables such as 'filename', 'vendor_name', and
'product_name' are pointers; thus, use NULL instead of 0 to fix
the following sparse warnings

drivers/usb/gadget/f_mass_storage.c:3046:27: warning: Using plain integer as NULL pointer
drivers/usb/gadget/f_mass_storage.c:3050:28: warning: Using plain integer as NULL pointer
drivers/usb/gadget/f_mass_storage.c:3051:29: warning: Using plain integer as NULL pointer

Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

usb: gadget: amd5536udc: unconditionally use GFP_ATOMIC in udc_queue()

As far as prep_dma() is called with spinlock held,
we have to pass GFP_ATOMIC regardless of gfp argument.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Signed-off-by: Felipe Balbi <balbi@ti.com>

Merge 3.11-rc4 into usb-next

We want those fixes in here also.

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Linux 3.11-rc4

Merge branch 'fixes' of git://git.infradead.org/users/vkoul/slave-dma

Pull dmaengine fixes from Vinod Koul:
 "Two fixes for slave dmaengine.  The first fixes cyclic dma transfers
  for pl330 and the second one makes us return the correct error code on
  probe"

* 'fixes' of git://git.infradead.org/users/vkoul/slave-dma:
  dma: pl330: Fix cyclic transfers
  pch_dma: fix error return code in pch_dma_probe()

Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux

Pull drm fix from Dave Airlie:
 "Just a quick fix that a few people have reported, be nice to have in
  asap"

The drm tree seems to be very confused about 64-bit divides.  Here it
uses a slow 64-by-64 bit divide to divide by a small constant.  Oh well.
Doesn't look performance-critical, just stupid.

* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
  drm/radeon: fix 64 bit divide in SI spm code

tmpfs: fix SEEK_DATA/SEEK_HOLE regression

Commit 46a1c2c7ae53 ("vfs: export lseek_execute() to modules") broke the
tmpfs SEEK_DATA/SEEK_HOLE implementation, because vfs_setpos() converts
the carefully prepared -ENXIO to -EINVAL.  Other filesystems avoid it in
error cases: do the same in tmpfs.

Signed-off-by: Hugh Dickins <hughd@google.com>
Cc: Jie Liu <jeff.liu@oracle.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Merge tag 'sound-3.11' of git://git./linux/kernel/git/tiwai/sound

Pull sound fixes from Takashi Iwai:
 "All small regression or small fixes, nothing surprising at this stage.

   - regression fix for intel Mac Mini quirk
   - compress ioctl error fix
   - ASoC fixes for control change notifications, some UI fixes,
     driver-specific fixes (resource leak, build errors, etc)"

* tag 'sound-3.11' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
  ALSA: hda - Fix missing fixup for Mac Mini with STAC9221
  ASoC: wm0010: Fix resource leak
  ASoC: au1x: Fix build
  ASoC: bf5xx-ac97: Fix compile error with SND_BF5XX_HAVE_COLD_RESET
  ASoC: bfin-ac97: Fix prototype error following AC'97 refactoring
  ALSA: compress: fix the return value for SNDRV_COMPRESS_VERSION
  ASoC: dapm: Fix return value of snd_soc_dapm_put_{volsw,enum_virt}()

drm/radeon: fix 64 bit divide in SI spm code

Forgot to use the appropriate math64 function.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>

Merge git://git./linux/kernel/git/davem/net

Pull networking fixes from David Miller:

 1) Don't ignore user initiated wireless regulatory settings on cards
    with custom regulatory domains, from Arik Nemtsov.

 2) Fix length check of bluetooth information responses, from Jaganath
    Kanakkassery.

 3) Fix misuse of PTR_ERR in btusb, from Adam Lee.

 4) Handle rfkill properly while iwlwifi devices are offline, from
    Emmanuel Grumbach.

 5) Fix r815x devices DMA'ing to stack buffers, from Hayes Wang.

 6) Kernel info leak in ATM packet scheduler, from Dan Carpenter.

 7) 8139cp doesn't check for DMA mapping errors, from Neil Horman.

 8) Fix bridge multicast code to not snoop when no querier exists,
    otherwise mutlicast traffic is lost.  From Linus Lüssing.

 9) Avoid soft lockups in fib6_run_gc(), from Michal Kubecek.

10) Fix races in automatic address asignment on ipv6, which can result
    in incorrect lifetime assignments.  From Jiri Benc.

11) Cure build bustage when CONFIG_NET_LL_RX_POLL is not set and rename
    it CONFIG_NET_RX_BUSY_POLL to eliminate the last reference to the
    original naming of this feature.  From Cong Wang.

12) Fix crash in TIPC when server socket creation fails, from Ying Xue.

13) macvlan_changelink() silently succeeds when it shouldn't, from
    Michael S Tsirkin.

14) HTB packet scheduler can crash due to sign extension, fix from
    Stephen Hemminger.

15) With the cable unplugged, r8169 prints out a message every 10
    seconds, make it netif_dbg() instead of netif_warn().  From Peter
    Wu.

16) Fix memory leak in rtm_to_ifaddr(), from Daniel Borkmann.

17) sis900 gets spurious TX queue timeouts due to mismanagement of link
    carrier state, from Denis Kirjanov.

18) Validate somaxconn sysctl to make sure it fits inside of a u16.
    From Roman Gushchin.

19) Fix MAC address filtering on qlcnic, from Shahed Shaikh.

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (68 commits)
  qlcnic: Fix for flash update failure on 83xx adapter
  qlcnic: Fix link speed and duplex display for 83xx adapter
  qlcnic: Fix link speed display for 82xx adapter
  qlcnic: Fix external loopback test.
  qlcnic: Removed adapter series name from warning messages.
  qlcnic: Free up memory in error path.
  qlcnic: Fix ingress MAC learning
  qlcnic: Fix MAC address filter issue on 82xx adapter
  net: ethernet: davinci_emac: drop IRQF_DISABLED
  netlabel: use domain based selectors when address based selectors are not available
  net: check net.core.somaxconn sysctl values
  sis900: Fix the tx queue timeout issue
  net: rtm_to_ifaddr: free ifa if ifa_cacheinfo processing fails
  r8169: remove "PHY reset until link up" log spam
  net: ethernet: cpsw: drop IRQF_DISABLED
  htb: fix sign extension bug
  macvlan: handle set_promiscuity failures
  macvlan: better mode validation
  tipc: fix oops when creating server socket fails
  net: rename CONFIG_NET_LL_RX_POLL to CONFIG_NET_RX_BUSY_POLL
  ...

qlcnic: Fix for flash update failure on 83xx adapter

Flash update routine was improperly checking register read API return value.
Modify register read API and perform proper error check.

Signed-off-by: Himanshu Madhani <himanshu.madhani@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

qlcnic: Fix link speed and duplex display for 83xx adapter

o Set link speed and duplex to unknown when link is not up.

Signed-off-by: Rajesh Borundia <rajesh.borundia@qlogic.com>
Signed-off-by: Shahed Shaikh <shahed.shaikh@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

qlcnic: Fix link speed display for 82xx adapter

o Do not obtain link speed from register when adapter
  link is down.

Signed-off-by: Rajesh Borundia <rajesh.borundia@qlogic.com>
Signed-off-by: Shahed Shaikh <shahed.shaikh@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

qlcnic: Fix external loopback test.

Driver was not handling external loopback diagnostic
test request.

Signed-off-by: Shahed Shaikh <shahed.shaikh@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

qlcnic: Removed adapter series name from warning messages.

Signed-off-by: Pratik Pujar <pratik.pujar@qlogic.com>
Signed-off-by: Shahed Shaikh <shahed.shaikh@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

qlcnic: Free up memory in error path.

Signed-off-by: Himanshu Madhani <himanshu.madhani@qlogic.com>
Signed-off-by: Shahed Shaikh <shahed.shaikh@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

qlcnic: Fix ingress MAC learning

o Delete MAC address from the adapter's filter table
  if the source MAC address of ingress packet matches.

Signed-off-by: Shahed Shaikh <shahed.shaikh@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

qlcnic: Fix MAC address filter issue on 82xx adapter

Driver was passing the address of a pointer instead of
the pointer itself.

Signed-off-by: Shahed Shaikh <shahed.shaikh@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

net: ethernet: davinci_emac: drop IRQF_DISABLED

IRQF_DISABLED is a no-op by now and should be removed.

Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Signed-off-by: David S. Miller <davem@davemloft.net>