linux.git/drivers/usb, branch v4.14-rc4

usb: dwc3: of-simple: Add compatible for Spreadtrum SC9860 platform

2017-09-28T09:41:56+00:00

Add compatible string to use this generic glue layer to support
Spreadtrum SC9860 platform's dwc3 controller.

Signed-off-by: Baolin Wang 
Signed-off-by: Felipe Balbi

usb: gadget: udc: atmel: set vbus irqflags explicitly

2017-09-28T09:39:22+00:00

The driver triggers actions on both edges of the vbus signal.

The former PIO controller was triggering IRQs on both falling and rising edges
by default. Newer PIO controller don't, so it's better to set it explicitly to
IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING.

Without this patch we may trigger the connection with host but only on some
bouncing signal conditions and thus lose connecting events.

Acked-by: Ludovic Desroches 
Signed-off-by: Nicolas Ferre 
Cc: stable  # v4.4+
Signed-off-by: Felipe Balbi

usb: gadget: ffs: handle I/O completion in-order

2017-09-28T09:37:24+00:00

By submitting completed transfers to the system workqueue there is no
guarantee that completion events will be queued up in the correct order,
as in multi-processor systems there is a thread running for each
processor and the work items are not bound to a particular core.

This means that several completions are in the queue at the same time,
they may be processed in parallel and complete out of order, resulting
in data appearing corrupt when read by userspace.

Create a single-threaded workqueue for FunctionFS so that data completed
requests is passed to userspace in the order in which they complete.

Acked-by: Michal Nazarewicz 
Signed-off-by: John Keeping 
Signed-off-by: Felipe Balbi

usb: renesas_usbhs: fix usbhsf_fifo_clear() for RX direction

2017-09-28T09:35:01+00:00

This patch fixes an issue that the usbhsf_fifo_clear() is possible
to cause 10 msec delay if the pipe is RX direction and empty because
the FRDY bit will never be set to 1 in such case.

Fixes: e8d548d54968 ("usb: renesas_usbhs: fifo became independent from pipe.")
Cc:  # v3.1+
Signed-off-by: Yoshihiro Shimoda 
Signed-off-by: Felipe Balbi

usb: renesas_usbhs: fix the BCLR setting condition for non-DCP pipe

2017-09-28T09:34:59+00:00

This patch fixes an issue that the driver sets the BCLR bit of
{C,Dn}FIFOCTR register to 1 even when it's non-DCP pipe and
the FRDY bit of {C,Dn}FIFOCTR register is set to 1.

Fixes: e8d548d54968 ("usb: renesas_usbhs: fifo became independent from pipe.")
Cc:  # v3.1+
Signed-off-by: Yoshihiro Shimoda 
Signed-off-by: Felipe Balbi

usb: gadget: udc: renesas_usb3: Fix return value of usb3_write_pipe()

2017-09-28T09:31:51+00:00

This patch fixes an issue that this driver cannot go status stage
in control read when the req.zero is set to 1 and the len in
usb3_write_pipe() is set to 0. Otherwise, if we use g_ncm driver,
usb enumeration takes long time (5 seconds or more).

Fixes: 746bfe63bba3 ("usb: gadget: renesas_usb3: add support for Renesas USB3.0 peripheral controller")
Cc:  # v4.5+
Signed-off-by: Yoshihiro Shimoda 
Signed-off-by: Felipe Balbi

usb: gadget: udc: renesas_usb3: fix Pn_RAMMAP.Pn_MPKT value

2017-09-28T09:31:47+00:00

According to the datasheet of R-Car Gen3, the Pn_RAMMAP.Pn_MPKT should
be set to one of 8, 16, 32, 64, 512 and 1024. Otherwise, when a gadget
driver uses an interrupt endpoint, unexpected behavior happens. So,
this patch fixes it.

Fixes: 746bfe63bba3 ("usb: gadget: renesas_usb3: add support for Renesas USB3.0 peripheral controller")
Cc:  # v4.5+
Signed-off-by: Yoshihiro Shimoda 
Signed-off-by: Felipe Balbi

usb: gadget: udc: renesas_usb3: fix for no-data control transfer

2017-09-28T09:31:26+00:00

When bRequestType & USB_DIR_IN is false and req.length is 0 in control
transfer, since it means non-data, this driver should not set the mode
as control write. So, this patch fixes it.

Fixes: 746bfe63bba3 ("usb: gadget: renesas_usb3: add support for Renesas USB3.0 peripheral controller")
Cc:  # v4.5+
Signed-off-by: Yoshihiro Shimoda 
Signed-off-by: Felipe Balbi

USB: dummy-hcd: Fix erroneous synchronization change

2017-09-28T09:30:59+00:00

A recent change to the synchronization in dummy-hcd was incorrect.
The issue was that dummy_udc_stop() contained no locking and therefore
could race with various gadget driver callbacks, and the fix was to
add locking and issue the callbacks with the private spinlock held.

UDC drivers aren't supposed to do this.  Gadget driver callback
routines are allowed to invoke functions in the UDC driver, and these
functions will generally try to acquire the private spinlock.  This
would deadlock the driver.

The correct solution is to drop the spinlock before issuing callbacks,
and avoid races by emulating the synchronize_irq() call that all real
UDC drivers must perform in their ->udc_stop() routines after
disabling interrupts.  This involves adding a flag to dummy-hcd's
private structure to keep track of whether interrupts are supposed to
be enabled, and adding a counter to keep track of ongoing callbacks so
that dummy_udc_stop() can wait for them all to finish.

A real UDC driver won't receive disconnect, reset, suspend, resume, or
setup events once it has disabled interrupts.  dummy-hcd will receive
them but won't try to issue any gadget driver callbacks, which should
be just as good.

Signed-off-by: Alan Stern 
Fixes: f16443a034c7 ("USB: gadgetfs, dummy-hcd, net2280: fix locking for callbacks")
CC: 
Signed-off-by: Felipe Balbi

USB: dummy-hcd: fix infinite-loop resubmission bug

2017-09-28T09:30:56+00:00

The dummy-hcd HCD/UDC emulator tries not to do too much work during
each timer interrupt.  But it doesn't try very hard; currently all
it does is limit the total amount of bulk data transferred.  Other
transfer types aren't limited, and URBs that transfer no data (because
of an error, perhaps) don't count toward the limit, even though on a
real USB bus they would consume at least a minimum overhead.

This means it's possible to get the driver stuck in an infinite loop,
for example, if the host class driver resubmits an URB every time it
completes (which is common for interrupt URBs).  Each time the URB is
resubmitted it gets added to the end of the pending-URBs list, and
dummy-hcd doesn't stop until that list is empty.  Andrey Konovalov was
able to trigger this failure mode using the syzkaller fuzzer.

This patch fixes the infinite-loop problem by restricting the URBs
handled during each timer interrupt to those that were already on the
pending list when the interrupt routine started.  Newly added URBs
won't be processed until the next timer interrupt.  The problem of
properly accounting for non-bulk bandwidth (as well as packet and
transaction overhead) is not addressed here.

Signed-off-by: Alan Stern 
Reported-by: Andrey Konovalov 
Tested-by: Andrey Konovalov 
CC: 
Signed-off-by: Felipe Balbi