The memory subsystem has already had similar message for it.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

The memory subsystem has already had similar message for it.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

The memory subsystem has already had similar message for it.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

The memory subsystem has already had similar message for it.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

The memory subsystem has already had similar message for it.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

The memory subsystem has already had similar message for it.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

The memory subsystem has already had similar message for it.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

The memory subsystem has already had similar message for it.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

The memory subsystem has already had similar message for it.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

The memory subsystem has already had similar message for it.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

The memory subsystem has already had similar message for it.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

The memory subsystem has already had similar message for it.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

The memory subsystem has already had similar message for it.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

The memory subsystem has already had similar message for it.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

The memory subsystem has already had similar message for it.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

The memory subsystem has already had similar message for it.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

Some gadget/function drivers might want to do
improper request recycling by allocating a single
request from one particular endpoint and queueing
it to another completely unrelated endpoint.

One such case was found with f_loopback.c.

To prevent such cases from happening again, let's
WARN() so we get a loud enough failure and persuade
users to report errors.
Signed-off-by: Felipe Balbi <balbi@ti.com>

whenever we get a Disconnect Interrupt, we should
make sure to update out udc state to NOT_ATTACHED,
otherwise sysfs will show wrong values.
Signed-off-by: Felipe Balbi <balbi@ti.com>

I noticed that this has been missing for quite
some time so I decided it was about time to
document it.
Signed-off-by: Felipe Balbi <balbi@ti.com>

USB gadgets composed with configfs lack suspend and resume
methods. This patch uses composite_suspend()/composite_resume()
the same way e.g. composite_setup() or composite_disconnect()
are used in a configfs-based gadget.
Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

This NULL check sets off a static checker warning because we already
dereferenced "card" earlier in the function.  However, since "card" is
never NULL so we can just remove the check.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

when disconnecting from host using our soft_connect
sysfs interface, also let the gadget driver know about
it by calling the gadget driver's ->disconnect()
method.

No problems have been found while not calling ->disconnect()
so far, it's just good convention.
Signed-off-by: Felipe Balbi <balbi@ti.com>

Using ->prepare()/->complete() to mask/unmask
IRQs is wrong at least for dwc3. We need to
make sure that by the end of ->resume(), IRQs
are working and ready to fire because a child
device may need working IRQs for its own ->resume()
method.
Signed-off-by: Felipe Balbi <balbi@ti.com>

Enabling the core interrupts in complete is too late for
XHCI, and stops it from proper operation. The root of the
problem is due to a disagreement between dwc3-omap and XHCI
about when IRQs should be enabled.

As it turns out, ->resume's documentation states that:

"... generally the driver is expected to start working
again, responding to hardware events and software requests
(the device itself may be left in a low-power state, waiting
for a runtime resume to occur) ..."

From that we infer that IRQs must be unmasked by the end of
->resume().

Due to that, we will remove ->prepare() and ->complete() and
disable/enable interrupts in ->suspend()/->resume().
Acked-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: George Cherian <george.cherian@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

Add support for device-tree device discovery. If devicetree is not
provided, fallback to legacy platform data "discovery".
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Cc: devicetree@vger.kernel.org
Signed-off-by: Felipe Balbi <balbi@ti.com>

Convert the mach info, and store the udc_command in the pxa_udc control
structure.

It is to be noticed that the udc_is_connected() in mach info is not
transfered. This was not used, as mioa701 machine doesn't need it,
balloon3 doesn't really use it, and most importantly the current driver
never uses it.
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Felipe Balbi <balbi@ti.com>

For this preparation, a preliminary cleanup is done :
  - convert the probing of pxa27x_udc to gpio_desc.
    The conversion is partial because :
     - the platform data still provides a gpio number, not a gpio desc
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Felipe Balbi <balbi@ti.com>

This patch adds support for the generic PHY. The generic PHY will be
used in multiplatform environment.
Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

To support both usb PHY and generic PHY, this patch cleans up rcar2.c.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

To support a generic phy driver in this driver later, this patch
renames "struct usb_phy *phy" to "struct usb_phy *usb_phy".
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

Add TRB tracepoints for ep0 TRBs as that
might help finding bugs with ep0 handling.
Signed-off-by: Felipe Balbi <balbi@ti.com>

In case we unload a gadget driver while any of
os_desc_req or req are still pending, we need
to make sure to dequeue them.

By using our setup_pending and os_desc_pending
flags we achieve that in a way that doesn't
cause any regressions because we won't dequeue
a request which was already completed.

The original idea came from Li Jun's commit
f2267089
(usb: gadget: composite: dequeue cdev->req
before free it in composite_dev_cleanup) which,
unfortunately, caused two regressions (kfree()
being called before usb_ep_dequeue() and calling
usb_ep_dequeue() when the request was already
completed). That commit also didn't take care
of os_desc_req which can fall into the same
situation so we must care for that one too.

Note that in order to make code slightly easier
to read, we introduce composite_ep_queue() which
hides details about how to fiddle with our pending
flags.
Signed-off-by: Felipe Balbi <balbi@ti.com>

by doing that we will be able to match our
requests against req and os_desc_req and also
clear our pending flags from complete callback.
Signed-off-by: Felipe Balbi <balbi@ti.com>

These flags we be set to true whenever their
matching request is queued. They will be cleared
to false when that request completes.
Signed-off-by: Felipe Balbi <balbi@ti.com>

Adding ACPI ID used on newer Intel SoCs.
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

If the probe drivers have already set the dma_mask, not
replacing the value.
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

tracing infrastructure already adds those for us.
Signed-off-by: Felipe Balbi <balbi@ti.com>

DWC3's GUID register is supposed to be used to write
any sort of version we might want. It helps when getting
bug reports for platforms you don't have HW to know
which kernel version of the driver was running on the
platform.

Because we don't really track driver version, but we _do_
track the kernel version, let's write LINUX_VERSION_CODE to
that register and use it for debugging.
Reviewed-by: Paul Zimmerman <paulz@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

Pull MTD fixes from Brian Norris:
 "Three main MTD fixes for 3.18:

   - A regression from 3.16 which was noticed in 3.17.  With the
     restructuring of the m25p80.c driver and the SPI NOR library
     framework, we omitted proper listing of the SPI device IDs.  This
     means m25p80.c wouldn't auto-load (modprobe) properly when built as
     a module.  For now, we duplicate the device IDs into both modules.

   - The OMAP / ELM modules were depending on an implicit link ordering.
     Use deferred probing so that the new link order (in 3.18-rc) can
     still allow for successful probing.

   - Fix suspend/resume support for LH28F640BF NOR flash"

* tag 'for-linus-20141102' of git://git.infradead.org/linux-mtd:
  mtd: cfi_cmdset_0001.c: fix resume for LH28F640BF chips
  mtd: omap: fix mtd devices not showing up
  mtd: m25p80,spi-nor: Fix module aliases for m25p80
  mtd: spi-nor: make spi_nor_scan() take a chip type name, not spi_device_id
  mtd: m25p80: get rid of spi_get_device_id