We used to have opencoded ehci_readl()/writel() which required no
external functions to be called.

Now with attempt to switch to generic readl()/writel() accessors
we see a missing declaration of those accessors in ehci-ppc4xx.
Something like that happens if applied
http://patchwork.ozlabs.org/patch/726714/:
---------------->8---------------
  CC      drivers/usb/host/ehci-ppc4xx.o
drivers/usb/host/ehci-ppc4xx.c: In function 'ehci_hcd_init':
drivers/usb/host/ehci-ppc4xx.c:23:3: warning: implicit declaration of function 'readl' [-Wimplicit-function-declaration]
   HC_LENGTH(ehci_readl(&(*hccr)->cr_capbase)));
   ^
---------------->8---------------

Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Tom Rini <trini@konsulko.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Stefan Roese <sr@denx.de>
Reviewed-by: Stefan Roese <sr@denx.de>

For id = 15 an out of bound access occurs in udc_setup_ep().
Increase the size of epinfo[] from 30 to 32 to encompass
ids 0..15.

The problem was highlighted by cppcheck.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

We want to check the result of musb_init_controller
and not the address were the result is stored.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

Use CONFIG_ARCH_LS1021A instead.

Signed-off-by: York Sun <york.sun@nxp.com>

We should invalidate the dcache before starting the DMA. In case there are
any dirty lines from the DMA buffer in the cache, subsequent cache-line
replacements may corrupt the buffer in memory while the DMA is still going on.
Cache-line replacement can happen if the CPU tries to bring some other memory
locations into the cache while the DMA is going on.

Signed-off-by: Eddie Cai <eddie.cai.linux@gmail.com>
Reviewed-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>

Merely using dma_alloc_coherent does not ensure that there is no stale
data left in the caches for the allocated DMA buffer (i.e. that the
affected cacheline may still be dirty).

The original code was doing the following (on AArch64, which
translates a 'flush' into a 'clean + invalidate'):
  # during initialisation:
      1. allocate buffers via memalign
      	 => buffers may still be modified (cached, dirty)
  # during interrupt processing
      2. clean + invalidate buffers
      	 => may commit stale data from a modified cacheline
      3. read from buffers

This could lead to garbage info being written to buffers before
reading them during even-processing.

To make the event processing more robust, we use the following sequence
for the cache-maintenance:
  # during initialisation:
      1. allocate buffers via memalign
      2. clean + invalidate buffers
      	 (we only need the 'invalidate' part, but dwc3_flush_cache()
	  always performs a 'clean + invalidate')
  # during interrupt processing
      3. read the buffers
      	 (we know these lines are not cached, due to the previous
	  invalidation and no other code touching them in-between)
      4. clean + invalidate buffers
      	 => writes back any modification we may have made during event
	    processing and ensures that the lines are not in the cache
	    the next time we enter interrupt processing

Note that with the original sequence, we observe reproducible
(depending on the cache state: i.e. running dhcp/usb start before will
upset caches to get us around this) issues in the event processing (a
fatal synchronous abort in dwc3_gadget_uboot_handle_interrupt on the
first time interrupt handling is invoked) when running USB mass
storage emulation on our RK3399-Q7 with data-caches on.

Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>

The dwc3_flush_cache() call was declared and used inconsistently:
 * The declaration assumed 'int' for addresses (a potential issue
   when running in a LP64 memory model).
 * The invocation cast the address to 'long'.

This change ensures that both the declaration and usage of this
function consistently uses 'uintptr_t' for correct behaviour even
when the allocated buffers (to be flushed) reside outside of the
lower 32bits of memory.

Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>

Both these numbers are calculated in runtime and dynamically assigned
to the device descriptor during bind().

Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>

We don't want to claim that we support a serial number string and
later return nothing. Because of that, if g_dnl_serial is an empty
string, let's skip setting iSerialNumber to a valid number.

Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>

A USB String descriptor can be up to 255 characters long and it's not
NULL terminated according to the USB spec. This means our
MAX_STRING_SERIAL should be 256 (to cope with NULL terminator).

Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>