Both xhci_hub_control and xhci_disable_slot tries to hold spinlock, the
spinlock recursion occurs when enters USB2 test mode. Fix it by unlock
spinlock before calling xhci_disable_slot.
Cc: <stable@vger.kernel.org>
Fixes: 0f1d832ed1 ("usb: xhci: Add port test modes support for usb2")
Signed-off-by: Peter Chen <peter.chen@nxp.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
A uncleared PLC (port link change) bit will prevent furuther port event
interrupts for that port. Leaving it uncleared caused get_port_status()
to timeout after 20000ms while waiting to get the final port event
interrupt for resume -> U0 state change.
This is a targeted fix for a specific case where we get a port resume event
racing with xhci resume. The port event interrupt handler notices xHC is
not yet running and bails out early, leaving PLC uncleared.
The whole xhci port resuming needs more attention, but while working on it
it anyways makes sense to always ensure PLC is cleared in get_port_status
before setting a new link state and waiting for its completion.
Cc: <stable@vger.kernel.org>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
on AMD platforms with SNPS 3.1 USB controller if stop endpoint command is
issued the controller does not respond, when the EP is not in running
state. HW completes the command execution and reports
"Context State Error" completion code. This is as per the spec. However
HW on receiving the second command additionally marks EP to Flow control
state in HW which is RTL bug. This bug causes the HW not to respond
to any further doorbells that are rung by the driver. This makes the EP
to not functional anymore and causes gross functional failures.
As a workaround, not to hit this problem, it's better to check the EP state
and issue a stop EP command only when the EP is in running state.
As a sidenote, even with this patch there is still a possibility of
triggering the RTL bug if the context state races with the stop endpoint
command as described in xHCI spec 4.6.9
[code simplification and reworded sidenote in commit message -Mathias]
Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Signed-off-by: Nehal Shah <Nehal-bakulchandra.Shah@amd.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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: Jiahau Chang <Lars_chang@asmedia.com.tw>
Signed-off-by: Ian Pilcher <arequipeno@gmail.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg 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: rocko r <rockorequin@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Felipe writes:
usb: fixes for v4.13-rc2
First set of fixes for the current -rc cycle. Only three fixes on dwc3
this time around (proper order for getting a PHY reference, fix for
unmapping DMA and a fix for requesting IRQ on the OMAP glue layer).
Most fixes are on the renesas USB controller, fixing several old bugs
with most going to stable.
dwc2 also learned that it *must* reset USB Address to zero on Reset
interrupts.
Apart from these, some drivers needed HAS_DMA dependency and there's a
sparse warning fix for bdc udc.
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: 2f98382dc ("usb: renesas_usbhs: Add Renesas USBHS Gadget")
Cc: <stable@vger.kernel.org> # v3.0+
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Felipe 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: ca8a282a53 ("usb: gadget: renesas_usbhs: add suspend/resume support")
Cc: <stable@vger.kernel.org> # v3.2+
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Felipe 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: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Felipe 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 2d4aa21a73 ("usb:
gadget: udc: renesas_usb3: add support for dedicated DMAC") didn't set
the bits to 1. So, this patch fixes it.
Fixes: 2d4aa21a73 ("usb: gadget: udc: renesas_usb3: add support for dedicated DMAC)
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
The commit 2d4aa21a73 ("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: 2d4aa21a73 ("usb: gadget: udc: renesas_usb3: add support for dedicated DMAC")
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Felipe 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: Ruslan Bilovol <ruslan.bilovol@gmail.com>
Signed-off-by: Felipe 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: Ruslan Bilovol <ruslan.bilovol@gmail.com>
Signed-off-by: Felipe 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: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Felipe 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: John Youn <johnyoun@synopsys.com>
Signed-off-by: Minas Harutyunyan <hminas@synopsys.com>
Signed-off-by: Felipe 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: Colin Ian King <colin.king@canonical.com>
Cc: stable <stable@vger.kernel.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg 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: c1b0bc2dab ("usb: typec: Add support for UCSI interface")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg 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: cdb55b39fa ("usb: dwc3: gadget: lazily map requests for DMA")
Signed-off-by: Jack Pham <jackp@codeaurora.org>
Signed-off-by: Felipe 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: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
IRQ_NOAUTOEN cannot be used with shared IRQs, since commit 04c848d398
("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 12a7f17fac ("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: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Vignesh R <vigneshr@ti.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
commit f54edb539c ("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: Carlos Hernandez <ceh@ti.com>
Signed-off-by: Vignesh R <vigneshr@ti.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
