When USB Ethernet is plugged in ASMEDIA ASM1042A xHCI host, bad
performance was manifesting in Web browser use (like download
large file such as ISO image). It is known limitation of
ASM1042A that is not compatible with driver scheduling,
As a workaround we can modify flow control handling of ASM1042A.
The register we modify is changes the behavior

[use quirk bit 28, usleep_range 40-60us, empty non-pci function -Mathias]
Cc: <stable@vger.kernel.org>
Signed-off-by: NJiahau Chang <Lars_chang@asmedia.com.tw>
Signed-off-by: NIan Pilcher <arequipeno@gmail.com>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This off by one in stream_id indexing caused NULL pointer dereference and
soft lockup on machines with USB attached SCSI devices connected to a
hotpluggable xhci controller.

The code that cleans up pending URBs for dead hosts tried to dereference
a stream ring at the invalid stream_id 0.
ep->stream_info->stream_rings[0] doesn't point to a ring.

Start looping stream_id from 1 like in all the other places in the driver,
and check that the ring exists before trying to kill URBs on it.
Reported-by: Nrocko r <rockorequin@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

A gadget driver will not disable eps immediately when ->disconnect()
is called. But, since this driver assumes all eps stop after
the ->disconnect(), unexpected behavior happens (especially in system
suspend).
So, this patch disables all eps in usbhsg_try_stop(). After disabling
eps by renesas_usbhs driver, since some functions will be called by
both a gadget and renesas_usbhs driver, renesas_usbhs driver should
protect uep->pipe. To protect uep->pipe easily, this patch adds a new
lock in struct usbhsg_uep.

Fixes: 2f98382d ("usb: renesas_usbhs: Add Renesas USBHS Gadget")
Cc: <stable@vger.kernel.org> # v3.0+
Signed-off-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

This patch fixes an issue that some registers may be not initialized
after resume if the USBHSF_RUNTIME_PWCTRL is not set. Otherwise,
if a cable is not connected, the driver will not enable INTENB0.VBSE
after resume. And then, the driver cannot detect the VBUS.

Fixes: ca8a282a ("usb: gadget: renesas_usbhs: add suspend/resume support")
Cc: <stable@vger.kernel.org> # v3.2+
Signed-off-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

This patch fixes an issue that unexpected behavior happens when
both the interrupt handler and renesas_usb3_ep_enable() are called.
In this case, since usb3_start_pipen() checked the usb3_ep->started,
but the flags was not protected. So, this patch protects the flag
by usb3->lock. Since renesas_usb3_ep_enable() for EP0 will be not called,
this patch doesn't take care of usb3_start_pipe0().
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

The dedicated dmac can transfer a zero-length-packet (zlp) if some bits
of the USB_COM_CON register. However, the commit 2d4aa21a ("usb:
gadget: udc: renesas_usb3: add support for dedicated DMAC") didn't set
the bits to 1. So, this patch fixes it.

Fixes: 2d4aa21a ("usb: gadget: udc: renesas_usb3: add support for dedicated DMAC)
Signed-off-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

The commit 2d4aa21a ("usb: gadget: udc: renesas_usb3: add support
for dedicated DMAC") has a bug in the renesas_usb3_dma_free_prd().
The size of dma_free_coherent() should be the same with dma_alloc_coherent()
Otherwise, this code causes a WARNING by mm/page_alloc.c when
renesas_usb3_dma_free_prd() is called. So, this patch fixes it.

Fixes: 2d4aa21a ("usb: gadget: udc: renesas_usb3: add support for dedicated DMAC")
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

As per USB spec, multiple-bytes fields are stored
in little-endian order. Use CPU<->LE helpers for
such fields.
Signed-off-by: NRuslan Bilovol <ruslan.bilovol@gmail.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

As per USB spec, multiple-bytes fields are stored
in little-endian order. Use CPU<->LE helpers for
such fields.
Signed-off-by: NRuslan Bilovol <ruslan.bilovol@gmail.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Fixes the following Sparse warnings:

>> drivers/usb/gadget/udc/snps_udc_plat.c:31:6: sparse: symbol 'start_udc' was not declared. Should it be static?
>> drivers/usb/gadget/udc/snps_udc_plat.c:41:6: sparse: symbol 'stop_udc' was not declared. Should it be static?
>> drivers/usb/gadget/udc/snps_udc_plat.c:79:6: sparse: symbol 'udc_drd_work' was not declared. Should it be static?
Signed-off-by: NFengguang Wu <fengguang.wu@intel.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Reseted DEVADDR field in DCFG to zero on USB RESET.

Device address in DCFG register does not reset to zero,
which required to pass enumeration, after disconnect and
reconnect.
Acked-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NMinas Harutyunyan <hminas@synopsys.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

When us->extra is null the driver is not initialized, however, a
later call to osd200_scsi_to_ata is made that dereferences
us->extra, causing a null pointer dereference.  The code
currently detects and reports that the driver is not initialized;
add a return to avoid the subsequent dereference issue in this
check.

Thanks to Alan Stern for pointing out that srb->result needs setting
to DID_ERROR << 16

Detected by CoverityScan, CID#100308 ("Dereference after null check")
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Cc: stable <stable@vger.kernel.org>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The new driver causes a build failure in some configurations:

In file included from /git/arm-soc/drivers/usb/typec/ucsi/trace.h:9:0,
                 from /git/arm-soc/drivers/usb/typec/ucsi/trace.c:2:
drivers/usb/typec/ucsi/ucsi.h:331:39: error: 'struct device' declared inside parameter list will not be visible outside of this definition or declaration [-Werror]

This includes the required header file.

Fixes: c1b0bc2d ("usb: typec: Add support for UCSI interface")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add device-id entry for DATECS FP-2000 fiscal printer needing the
NO_UNION_NORMAL quirk.
Reported-by: NAnton Avramov <lukav@lukav.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NJohan Hovold <johan@kernel.org>
Acked-by: NOliver Neukum <oneukum@suse.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

A recent optimization was made so that a request put on the
pending_list wouldn't get mapped for DMA until just before
preparing a TRB for it. However, this poses a problem in case
the request is dequeued or the endpoint is disabled before the
mapping is done as that would lead to dwc3_gadget_giveback()
unconditionally calling usb_gadget_unmap_request_for_dev() with
an invalid request->dma handle. Depending on the platform's DMA
implementation the unmap operation could result in a panic.

Since we know a successful mapping is a prerequisite for getting
a TRB, the unmap can be conditionally called only when req->trb
is non-NULL.

Fixes: cdb55b39 ("usb: dwc3: gadget: lazily map requests for DMA")
Signed-off-by: NJack Pham <jackp@codeaurora.org>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

If NO_DMA=y:

    ERROR: "usb_gadget_map_request" [drivers/usb/gadget/udc/snps_udc_core.ko] undefined!
    ERROR: "dma_pool_destroy" [drivers/usb/gadget/udc/snps_udc_core.ko] undefined!
    ERROR: "usb_gadget_unmap_request" [drivers/usb/gadget/udc/snps_udc_core.ko] undefined!
    ERROR: "dma_pool_free" [drivers/usb/gadget/udc/snps_udc_core.ko] undefined!
    ERROR: "dma_pool_alloc" [drivers/usb/gadget/udc/snps_udc_core.ko] undefined!
    ERROR: "dma_pool_create" [drivers/usb/gadget/udc/snps_udc_core.ko] undefined!

As USB_SNP_CORE is selected by USB_SNP_UDC_PLAT and USB_AMD5536UDC,
these should depend on HAS_DMA, too.  For USB_AMD5536UDC, this is
already fulfilled through the dependency on USB_PCI (PCI implies
HAS_DMA).

Add dependencies on HAS_DMA to fix this.
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

If NO_DMA=y:

    ERROR: "usb_gadget_map_request" [drivers/usb/gadget/udc/renesas_usb3.ko] undefined!
    ERROR: "usb_gadget_unmap_request" [drivers/usb/gadget/udc/renesas_usb3.ko] undefined!
    ERROR: "bad_dma_ops" [drivers/usb/gadget/udc/renesas_usb3.ko] undefined!

Add a dependency on HAS_DMA to fix this.
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

It is wrong to do --i in the for loop.

Fixes: dd02ea5a ("usb: gadget: mass_storage: Use static array for luns")
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Reviewed-by: NKrzysztof Opasiak <k.opasiak@samsung.com>
Acked-by: NMichal Nazarewicz <mina86@mina86.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

IRQ_NOAUTOEN cannot be used with shared IRQs, since commit 04c848d3
("genirq: Warn when IRQ_NOAUTOEN is used with shared interrupts") and
kernel now throws a warn dump. But OMAP DWC3 driver uses this flag. As
per commit 12a7f17f ("usb: dwc3: omap: fix race of pm runtime with
irq handler in probe") that introduced this flag, PM runtime can race
with IRQ handler when deferred probing happens due to extcon,
therefore IRQ_NOAUTOEN needs to be set so that irq is not enabled until
extcon is registered.

Remove setting of IRQ_NOAUTOEN and move the registration of
shared irq to a point after dwc3_omap_extcon_register() and
of_platform_populate(). This avoids possibility of probe deferring and
above said race condition.
Reviewed-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: NVignesh R <vigneshr@ti.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

commit f54edb53 ("usb: dwc3: core: initialize ULPI before trying to
get the PHY") moved call to dwc3_core_get_phy() from dwc3_probe() to
dwc3_core_init() after dwc3_core_soft_reset(). But
dwc3_core_soft_reset() calls phy_init(), therefore dwc3_core_get_phy()
needs to be called before dwc3_core_soft_reset().

Fix this by moving call to dwc3_core_get_phy() before
dwc3_core_soft_reset().

This fixes the following abort seen on DRA7xx platforms
[   24.769118] usb usb2: SerialNumber: xhci-hcd.1.auto
[   24.781144] hub 2-0:1.0: USB hub found
[   24.787836] hub 2-0:1.0: 1 port detected
[   24.809939] Unhandled fault: imprecise external abort (0x1406) at 0x00000000
Reported-by: NCarlos Hernandez <ceh@ti.com>
Signed-off-by: NVignesh R <vigneshr@ti.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Make the code like the rest of the kernel.
Also use inline instead of __inline__.

Link: http://lkml.kernel.org/r/a5072b74b6c293e6ec93c4900482e9d3267f15b2.1499284835.git.joe@perches.comSigned-off-by: NJoe Perches <joe@perches.com>
Cc: Johan Hovold <johan@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

The USB core and sysfs will attempt to enumerate certain parameters
which are unsupported by the au0828 - causing inconsistent behavior
and sometimes causing the chip to reset.  Avoid making these calls.

This problem manifested as intermittent cases where the au8522 would
be reset on analog video startup, in particular when starting up ALSA
audio streaming in parallel - the sysfs entries created by
snd-usb-audio on streaming startup would result in unsupported control
messages being sent during tuning which would put the chip into an
unknown state.
Signed-off-by: NDevin Heitmueller <dheitmueller@kernellabs.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Rework smelling code (goto inside compound statement). Perhaps this is
legacy. Anyway such code is not appropriate for Linux kernel.
Signed-off-by: NEugene Korenevsky <ekorenevsky@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

clk_prepare_enable() can fail here and we must check its return value.
Signed-off-by: NArvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Added the USB serial device ID for the CEL ZigBee EM3588
radio stick.
Signed-off-by: NJeremie Rapin <rapinj@gmail.com>
Cc: stable <stable@vger.kernel.org>
Acked-by: NJohan Hovold <johan@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The run_wake flag in struct dev_pm_info is used to indicate whether
or not the device is capable of generating remote wakeup signals at
run time (or in the system working state), but the distinction
between runtime remote wakeup and system wakeup signaling has always
been rather artificial.  The only practical reason for it to exist
at the core level was that ACPI and PCI treated those two cases
differently, but that's not the case any more after recent changes.

For this reason, get rid of the run_wake flag and, when applicable,
use device_set_wakeup_capable() and device_can_wakeup() instead of
device_set_run_wake() and device_run_wake(), respectively.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: NBjorn Helgaas <bhelgaas@google.com>

The patch 03cd00d5: "usbip: vhci-hcd: Set the vhci structure up
to work" introduced a bug which uses a vairable without initialization
in error handling code. Fix it.
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NYuyang Du <yuyang.du@intel.com>
Acked-by: NShuah Khan <shuahkh@osg.samsung.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This uses DT info to read relation description of LEDs and USB ports. If
DT has properly described LEDs, trigger will know when to turn them on.
Signed-off-by: NRafał Miłecki <rafal@milecki.pl>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Driver for ACPI UCSI interface method. This driver replaces
the previous UCSI driver drivers/usb/misc/ucsi.c.
Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

UCSI - USB Type-C Connector System Software Interface - is a
specification that defines set of registers and data
structures for controlling the USB Type-C ports. It's
designed for systems where an embedded controller (EC) is in
charge of the USB Type-C PHY or USB Power Delivery
controller. It is designed for systems with EC, but it is
not limited to them, and for example some USB Power Delivery
controllers will use it as their direct control interface.

With UCSI the EC (or USB PD controller) acts as the port
manager, implementing all USB Type-C and Power Delivery state
machines. The OS can use the interfaces for reading the
status of the ports and controlling basic operations like
role swapping.

The UCSI specification highlights the fact that it does not
define the interface method (PCI/I2C/ACPI/etc.).
Therefore the driver is implemented as library and every
supported interface method needs its own driver. Driver for
ACPI is provided in separate patch following this one.

The initial driver includes support for all required
features from UCSI specification version 1.0 (getting
connector capabilities and status, and support for power and
data role swapping), but none of the optional UCSI features
(alternate modes, power source capabilities, and cable
capabilities).
Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Simplify return logic to avoid unnecessary variable assignment.
Signed-off-by: NGustavo A. R. Silva <garsilva@embeddedor.com>
Acked-by: NBin Liu <b-liu@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Propagate errnos for late probe errors (e.g. -ENOMEM on allocation
failures) instead of always returning -EIO.

Note that some drivers are currently returning -ENODEV from their attach
callbacks when a device is not supported, but this has also been mapped
to -EIO.
Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NJohan Hovold <johan@kernel.org>

Make the probe callback more readable by refactoring the port
endpoint-resource setup by adding four helper functions.
Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NJohan Hovold <johan@kernel.org>

Signed-off-by: Nyuan linyu <Linyu.Yuan@alcatel-sbell.com.cn>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

With the port_window support in DMAengine and the sDMA driver we can
convert the driver to DMAengine.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NBin Liu <b-liu@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Handle the DMA TX in a similar way as we do for the RX: in the DMA
completion callback.

Since we are no longer using DMA completion interrupt for the TX we can as
wall keep these interrupts disabled, but keep the handler for debug
purposes.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NBin Liu <b-liu@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Instead of requesting the DMA channel in tusb_omap_dma_allocate() do it
when the controller is created and in runtime work from the DMA channel
pool.

This change is needed for the DMAengine conversion of the driver since the
tusb_omap_dma_allocate() is called in interrupt context which might lead
to lock within the DMAengine API when requesting channel.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NBin Liu <b-liu@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

For the DMA we have ch (channel), dmareq and sync_dev parameters both
within the tusb_omap_dma_ch and tusb_omap_dma struct.
By creating a common struct the code can be simplified when selecting
between the shared or multichannel DMA parameters.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NBin Liu <b-liu@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Having one musb_ep_select() instead the two calls in if/else is the same
thing, but makes the code a bit simpler to follow.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NBin Liu <b-liu@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>