in order to make our IRQ handler thread easier
to read, we re-factor the inner loop to a separate
function.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

that function isn't really processing any event
buffer, rather just checking whether it contains
events to be processed.

Due to that reason, we're reaning it to dwc3_check_event_buf()
instead.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

We can make use of bit 31 of the GEVNTSIZ(n)
registers to mask/unmask interrupts from that
particular interrupter.

With that feature, we can easily drop IRQF_ONESHOT
from our driver which makes it possible to
properly change IRQ priorities when using RT
patchset *and* it allows us to make use of the
scheduler to choose the proper time to handle
this IRQ thread.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

That register has more than just the event buffer
size; we can also mask and unmask that particular
interrupter on bit 31 of that register.

In this patch we introduce the necessary macros
and make sure to use the new macros while also
making sure we mask interrupts during driver
removal.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

LPM is enabled in Connection Done interrupt,
there's no need to enable it early.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

the macro DWC3_DCFG_LPM_CAP was defined twice.

This patch just removes one of the definitions,
no functional changes.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

that way we get debugging information when
enabling verbose debug of the driver.

It will be no-op otherwise.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

no functional changes, just grouping dep
initialization.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

by moving that dev_vdbg() to the internal
__dwc3_gadget_ep_enable() we get the print
even when enable ep0, which calls the internal
function directly.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

use the new devm_ioremap_resource() on core.c
Signed-off-by: NFelipe Balbi <balbi@ti.com>

use the new devm_ioremap_resource on dwc3-omap.c
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Recent versions of the core, can suspend and resume
the PHYs automatically, so we don't need to fiddle
with dwc3's Global PHY registers at all.

On versions prior to 1.94a this patch will mean
that we will never ask dwc3 to suspend the PHY.

This is an acceptable behavior or such old versions
of the core, specially considering that the only
chip known to have a version prior to 1.94a was
OMAP5 ES1.0 and that's not supported in mainline
kernel, because it was just a test spin of OMAP5.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

This patch adapts the dwc3 to use the device tree helper
"of_usb_get_dr_mode" for the mode of operation of the dwc3 instance
being probed.

[ balbi@ti.com : make of_usb_get_dr_mode() conditional on
	dev->of_node and let pdata pass dr_mode too ]
Reviewed-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NRuchika Kharwar <ruchika@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

stmp_reset_block() may fail, so let's check its return value and propagate it
in the case of error.
Acked-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

The musb driver no longer uses procfs, so get rid of the proc_dir_entry
variable in struct musb.
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

This patch adds OF match table to the driver to allow instantiating it
using device tree.
Signed-off-by: NTomasz Figa <t.figa@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

all other drivers using Synopsys IPs with DT
have a compatible of snps,$driver, in order
to add consistency, we are switching over to
snps,dwc3 but keeping synopsys,dwc3 in the core
driver to maintain backwards compatibility.

New DTS bindings should NOT use synopsys,dwc3.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

in order to allow different instances of the
core work in different maximum speeds, we will
move the maximum_speed module_parameter to
both DeviceTree (making use the new maximum-speed
DT property) and platform_data.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

in case we're not in a DT boot, we should
still be able to tell the driver how to behave.

In order to be able to pass flags to the driver,
we introduce platform_data structure which the
core driver should use.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

this helper will be used for controllers which
want to work at a lower speed even though they
support higher USB transfer rates.

One such case is Texas Instruments' AM437x
SoC where it uses a USB3 controller without
a USB3 PHY, rendering the controller USB2-only.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

This is a Linux-only driver which makes use
of GPL-only symbols. It makes no sense to
maintain Dual BSD/GPL licensing for this driver.

Considering that the amount of work to use this
driver in any different operating system would likely
be as large as developing the driver from scratch and
considering that we depend on GPL-only symbols, we
will switch over to a GPL v2-only license.

Cc: Anton Tikhomirov <av.tikhomirov@samsung.com>
Acked-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

@list is not as a parameter of dwc3_event_buffer, so remove it in
comments.
Signed-off-by: NHuang Rui <ray.huang@amd.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

We cannot request an IRQ with spinlocks held
as that would trigger a sleeping inside
spinlock warning.

Cc: <stable@vger.kernel.org> # v3.10
Reported-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

That driver hasn't been really maintained for
a long time. It doesn't compile in any way, it
includes non-existent headers, has no users,
and is just plain broken.

The person who used to work with that driver
has publicly stated that he has no plans to
touch that driver again and is ok with removal[1].

Due to these factors, imx_udc is now removed from
the tree, if someone really believe it needs to
be kept, please fix the bugs in that driver.

[1] http://marc.info/?l=linux-usb&m=136197620417636&w=2Signed-off-by: NFelipe Balbi <balbi@ti.com>

Glue layers are starting to have separate
requirements. For example, OMAP's glue layer
is starting to use extcon framework which
no one else needs.

In order to make it clear the proper dependencies,
we are now allowing glue layers to be selectable
so that each glue layer can list their own dependencies
without messing with the core IP driver.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

If the descriptor is missing the reqeust is never unmapped. This patch
changes this and renames the cleanup label to unlock since there is no
cleanup done. The cleanup would revert the allocation of ressource (i.e.
this dma mapping) but it does not, it simply unlocks and returns.
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

The cleanup in the error is missing the dma controller. The structure is
allocated at runtime and ux500 allocates even a little more than just
this struct. So cleanup!
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

This patch removes is_dma_capable() and an ifdef in the init/exit path
around init/de-init of the dma_controller. Since we have the empty stubs
in the PIO code we can call it without gcc trouble. Earlier we had an
ifdef and the is_dma_capable() macro where gcc ignored the if (0) path
even that the function was not around :)
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Add a dma_controller_create() returning NULL so a few ifdefs can
dropped.
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

The core code creates a controller and immediately after that it calls
the ->start() callback. This one might drop an error but nobody cares.
The same thing happens in the destroy corner: First ->stop() called
followed by destroy callback. So why not merge those two into the same
function since there is no difference.
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

This check is hardly required and alas is wrong. 'c' might be NULL but
the chances are low that 'controller' after the container_of() becomes
NULL.

Since no other DMA implementation is doing that and musb-core does not
call it with a NULL pointer it can dropped.
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

The ifdef reads somehow better than an ifndef
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Control transfers have both IN and OUT (or SETUP) packets, so when
clearing TT buffers for a control transfer it's necessary to send
two HUB_CLEAR_TT_BUFFER requests to the hub.
Signed-off-by: NWilliam Gulland <wgulland@google.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fix memory leaks introduced in commits:

40d133d7
usb: gadget: f_ncm: convert to new function interface with backward compatibility

fee562a6
usb: gadget: f_ecm: convert to new function interface with backward compatibility

fcbdf12e
usb: gadget: f_phonet: convert to new function interface with backward compatibility

b29002a1
usb: gadget: f_eem: convert to new function interface with backward compatibility

8cedba7c
usb: gadget: f_subset: convert to new function interface with backward compatibility

f466c635
usb: gadget: f_rndis: convert to new function interface with backward compatibility
Signed-off-by: NAndrzej Pietrasiewicz <andrzej.p@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Allocated urbs and buffers were never freed on errors in open.

Cc: stable@vger.kernel.org
Signed-off-by: NJohan Hovold <jhovold@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Some (very few) early devices like mine, where not exposting a proper CDC
descriptor. This was fixed with an immediate firmware update from the vendor,
and pre-installed on newer devices.
So actual devices can be driven by cdc_acm.c + cdc_ether.c.
Signed-off-by: NEnrico Mioso <mrkiko.rs@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Speaks AT on interfaces 5 (command & PPP) and 3 (secondary), other
interface protocols are unknown.
Signed-off-by: NDan Williams <dcbw@redhat.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Prevent the option driver from binding itself to the QMI/WWAN interface, making
it unusable by the proper driver.
Signed-off-by: Nenrico Mioso <mrkiko.rs@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

in some cases where device is attched to xhci port and do not responding,
for example ath9k_htc with stalled firmware, kernel will
crash on ring_doorbell_for_active_rings.
This patch check if pointer exist before it is used.

This patch should be backported to kernels as old as 2.6.35, that
contain the commit e9df17eb "USB: xhci:
Correct assumptions about number of rings per endpoint"
Signed-off-by: NOleksij Rempel <linux@rempel-privat.de>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org

Xhci controllers with hci_version > 0.96 gives spurious success
events on short packet completion. During webcam capture the
"ERROR Transfer event TRB DMA ptr not part of current TD" was observed.
The same application works fine with synopsis controllers hci_version 0.96.
The same issue is seen with Intel Pantherpoint xhci controller. So enabling
this quirk in xhci_gen_setup if controller verion is greater than 0.96.
For xhci-pci move the quirk to much generic place xhci_gen_setup.

Note from Sarah:

The xHCI 1.0 spec changed how hardware handles short packets.  The HW
will notify SW of the TRB where the short packet occurred, and it will
also give a successful status for the last TRB in a TD (the one with the
IOC flag set).  On the second successful status, that warning will be
triggered in the driver.

Software is now supposed to not assume the TD is not completed until it
gets that last successful status.  That means we have a slight race
condition, although it should have little practical impact.  This patch
papers over that issue.

It's on my long-term to-do list to fix this race condition, but it is a
much more involved patch that will probably be too big for stable.  This
patch is needed for stable to avoid serious log spam.

This patch should be backported to kernels as old as 3.0, that
contain the commit ad808333 "Intel xhci:
Ignore spurious successful event."

The patch will have to be modified for kernels older than 3.2, since
that kernel added the xhci_gen_setup function for xhci platform devices.
The correct conflict resolution for kernels older than 3.2 is to set
XHCI_SPURIOUS_SUCCESS in xhci_pci_quirks for all xHCI 1.0 hosts.
Signed-off-by: NGeorge Cherian <george.cherian@ti.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org