The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons.  Pass the easily
available struct device from the platform_device to remedy this.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

dma_map_single already transfers ownership to the device.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

My @samusung.com address is going to cease existing soon, so change it to
an address which can actually be used to contact me.
Signed-off-by: NAndrzej Pietrasiewicz <andrzej.p@samsung.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Since the 5.0 merge window opened, I've been seeing frequent
crashes on suspend and reboot with the trace:

[   36.911170] Unable to handle kernel paging request at virtual address ffffff801153d660
[   36.912769] Unable to handle kernel paging request at virtual address ffffff800004b564
...
[   36.950666] Call trace:
[   36.950670]  queued_spin_lock_slowpath+0x1cc/0x2c8
[   36.950681]  _raw_spin_lock_irqsave+0x64/0x78
[   36.950692]  complete+0x28/0x70
[   36.950703]  ffs_epfile_io_complete+0x3c/0x50
[   36.950713]  usb_gadget_giveback_request+0x34/0x108
[   36.950721]  dwc3_gadget_giveback+0x50/0x68
[   36.950723]  dwc3_thread_interrupt+0x358/0x1488
[   36.950731]  irq_thread_fn+0x30/0x88
[   36.950734]  irq_thread+0x114/0x1b0
[   36.950739]  kthread+0x104/0x130
[   36.950747]  ret_from_fork+0x10/0x1c

I isolated this down to in ffs_epfile_io():
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/usb/gadget/function/f_fs.c#n1065

Where the completion done is setup on the stack:
  DECLARE_COMPLETION_ONSTACK(done);

Then later we setup a request and queue it, and wait for it:
  if (unlikely(wait_for_completion_interruptible(&done))) {
    /*
    * To avoid race condition with ffs_epfile_io_complete,
    * dequeue the request first then check
    * status. usb_ep_dequeue API should guarantee no race
    * condition with req->complete callback.
    */
    usb_ep_dequeue(ep->ep, req);
    interrupted = ep->status < 0;
  }

The problem is, that we end up being interrupted, dequeue the
request, and exit.

But then the irq triggers and we try calling complete() on the
context pointer which points to now random stack space, which
results in the panic.

Alan Stern pointed out there is a bug here, in that the snippet
above "assumes that usb_ep_dequeue() waits until the request has
been completed." And that:

    wait_for_completion(&done);

Is needed right after the usb_ep_dequeue().

Thus this patch implements that change. With it I no longer see
the crashes on suspend or reboot.

This issue seems to have been uncovered by behavioral changes in
the dwc3 driver in commit fec9095b ("usb: dwc3: gadget:
remove wait_end_transfer").

Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Felipe Balbi <balbi@kernel.org>
Cc: Zeng Tao <prime.zeng@hisilicon.com>
Cc: Jack Pham <jackp@codeaurora.org>
Cc: Thinh Nguyen <thinh.nguyen@synopsys.com>
Cc: Chen Yu <chenyu56@huawei.com>
Cc: Jerry Zhang <zhangjerry@google.com>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Vincent Pelletier <plr.vincent@gmail.com>
Cc: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Linux USB List <linux-usb@vger.kernel.org>
Suggested-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

i.MX6QP and i.MX7D platform use a PCIe controller with the same VID and
PID as this USB controller. The system may incorrectly match this driver
to that PCIe controller. To workaround this, specifically use class type
USB with PCI device ID to prevent incorrect driver matching.
Signed-off-by: NThinh Nguyen <thinhn@synopsys.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

usb_ep_autoconfig() treats the passed descriptor as if it were an fs
descriptor. In particular, for bulk endpoints, it clips wMaxPacketSize
to 64. This patch preserves the original value.
Signed-off-by: NAndrzej Pietrasiewicz <andrzej.p@collabora.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

The moved code refers to non-super speed endpoints only. This patch also
makes the comment stress the fact, that autoconfigured descriptor might
need some adjustments.
Signed-off-by: NAndrzej Pietrasiewicz <andrzej.p@collabora.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

f_uac1 audio control header descriptor default set
baInterfaceNr[]={1,2}, but usb gadget make a configuration descriptor
with more interfaces combination, it can not confirm f_uac1 function
linked first. So always keep baInterfaceNr[]={1,2} is correct, and it
is necessary to sync baInterfaceNr[] with usb_interface_id() value.
Signed-off-by: NLiang Shengjun <liangshengjun@hisilicon.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

This patch adds support for transferring requests, which are
non-contiguous in physical memory, i.e. the data buffer is described by
a scatter-list. This allows transferring large requests without relying
on error-prone contiguous buffer allocations. This way of allocating
requests is already implemented in functionfs and TCM USB functions and
automatically used if UDC driver advertises scatter-gather suppport.
Signed-off-by: NAndrzej Pietrasiewicz <andrzej.p@samsung.com>
[mszyprow: fixed null pointer issue, rewrote commit message]
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

There are a bunch of various indentation issues, clean these up.
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

In case when some EP IN is frequently reused, i.e. enabled/disabled by
function driver. It is required to clear TxFIFO number field in DIEPCTL
register before setting new number. Otherwise there is probability to
have same TxFIFO number for different EP's because of OR operator.
Signed-off-by: NMinas Harutyunyan <hminas@synopsys.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

A reset e.g. calling ep_reset_338x() can happen while endpoints
are enabled. The ep_reset_338x() sets ep->desc = NULL to mark
endpoint being invalid. A subsequent call of net2280_disable will
fail and return -EINVAL to parent function usb_ep_disable(),
which will fail, too, and do not set the member ep->enabled = false.

See:
https://elixir.bootlin.com/linux/v5.0-rc5/source/drivers/usb/gadget/udc/core.c#L139

This fix ignores dp->desc and allows net2280_disable() to succeed.
Subsequent calls to usb_ep_enable()/usb_ep_disable() succeeds.
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGuido Kiener <guido.kiener@rohde-schwarz.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Commit bf594c10 ("USB: gadget: Document that certain ep operations
can be called in interrupt context") documented that usb_ep_dequeue()
may be called in a non-process context.  It follows that the routine
must not sleep or wait for events.

However, the routine's existing kerneldoc seems to imply that it will
wait until the request being cancelled has fully completed.  This is
not so, and thus the comment needs to be improved.  Misunderstanding
this point may very well have been responsible for a bug recently
uncovered in the f_fs function.

The updated comment explicitly says that the routine may return before
the request's completion handler is called.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
CC: John Stultz <john.stultz@linaro.org>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Now that buffer size is always passed around, we don't need to rely on
strcat anymore.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Instead of assuming that our buffer is big enough, let's pass the
buffer size around so printing functions can make sure they won't
overflow the buffer.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Now that we modified the code to fix a race condition, it's clear that
DWC3_EP_END_TRANSFER_PENDING is unnecessary, considering that
DWC3_EP_TRANSFER_STARTED will remain set until End Transfer completes.
Tested-by: NThinh Nguyen <thinhn@synopsys.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

There is a rare race condition that may happen during a Disconnect
Interrupt if we have a started request that happens to be
dequeued *after* completion of End Transfer command. If that happens,
that request will be left waiting for completion of an End Transfer
command that will never happen.

If End Transfer command has already completed before, we are safe to
giveback the request straight away.
Tested-by: NThinh Nguyen <thinhn@synopsys.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

We have a proper flag for testing that we have a valid transfer in
flight, let's use that instead.

This patch is in preparation to fix a rare race condition that happens
upon Disconnect Interrupt.
Tested-by: NThinh Nguyen <thinhn@synopsys.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

We must wait until End Transfer completes in order to clear
DWC3_EP_TRANSFER_STARTED, otherwise we may confuse the driver.

This patch is in preparation to fix a rare race condition that happens
upon Disconnect Interrupt.
Tested-by: NThinh Nguyen <thinhn@synopsys.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Now that we have req->status, we don't need this extra flag
anymore. It's safe to remove it.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Queueing the same request twice can introduce hard-to-debug
problems. At least one function driver - Android's f_mtp.c - is known
to cause this problem.

While that function is out-of-tree, this is a problem that's easy
enough to avoid.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

This patch starts tracking dwc3_request status. A following patch will
build on top of this to prevent a request from being queued twice.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

RZ/G2E USB 3.0 implementation is like the one found on R-Car E3,
therefore add the same quirk.
Reviewed-by: NSimon Horman <horms+renesas@verge.net.au>
Reviewed-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: NFabrizio Castro <fabrizio.castro@bp.renesas.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

We only have uvcg_dbg, uvcg_info, and uvcg_err, so add uvcg_warn macro
to print gadget device name and function name along with format.
Signed-off-by: NPaul Elder <paul.elder@ideasonboard.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Switch RX processing from tasklet to (delayed) work queue. This allows
receiver more room to process incoming data and prevents flood of
"ttyGS0: RX not scheduled?" messages on HS receive on slow CPU.

A side effect is 2.4MB/s zmodem transfer speed (up from 1.8MB/s)
on my test board.
Signed-off-by: NMichał Mirosław <mirq-linux@rere.qmqm.pl>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Delete tab aligning a statement with the right hand side of a
preceding assignment rather than the left hand side.

Found with the help of Coccinelle.
Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Fix spelling mistake: "lenght" -> "length"
Signed-off-by: NMatteo Croce <mcroce@redhat.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

The AM654 SoC contains a DWC3 controller with TI specific
wrapper. Add support for that.

Unlike the Keystone 2 case, for AM654 We don't need to
process any IRQs for basic USB operation.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

On v3.10a in dual-role mode, if port is in device mode
and gadget driver isn't loaded, the OTG event interrupts don't
come through.

It seems that if the core is configured to be OTG2.0 only,
then we can't leave the DCFG.DEVSPD at Super-speed (default)
if we expect OTG to work properly. It must be set to High-speed.

Fix this issue by configuring DCFG.DEVSPD to the supported
maximum speed at gadget init. Device tree still needs to provide
correct supported maximum speed for this to work.

This issue wasn't present on v2.40a but is seen on v3.10a.
It doesn't cause any side effects on v2.40a.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NSekhar Nori <nsekhar@ti.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

According to Documentation/timers/timers-howto.txt, a driver should
use usleep_range() instead of udelay() on NON-ATOMIC CONTEXT if
"SLEEPING FOR ~USECS OR SMALL MSECS ( 10us - 20ms)".

Since the .hardware_init() and .power_ctrl() will run on NON-ATOMIC
CONTEXT, this patch replaces udelay() with usleep_range().
Reviewed-by: NSimon Horman <horms+renesas@verge.net.au>
Signed-off-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Add a MSM8998 specific DT compatible so that we can properly bind to the
device and enable the USB controller.
Reviewed-by: NAndy Gross <andy.gross@linaro.org>
Reviewed-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: NJeffrey Hugo <jhugo@codeaurora.org>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

'num' is a u8 variable, it never greater than 255,
So the if branch is dead code and can be removed.
Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

The keyspan_usa??msg.h files are under a BSD-3 style license, so
properly label them as such with a SPDX line at the top of the file.
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NJohan Hovold <johan@kernel.org>

This fixes autoloading the module by the OF compatible string.

Fixes: 813e18b1 ("USB: EHCI: ehci-mv: add DT support")
Cc: stable@vger.kernel.org
Signed-off-by: NLubomir Rintel <lkundrak@v3.sk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The patch "usb: simplify usbport trigger" together with "leds: triggers:
add device attribute support" caused an regression for the usbport
trigger. it will no longer enumerate any active usb hub ports under the
"ports" directory in the sysfs class directory, if the usb host drivers
are fully initialized before the usbport trigger was loaded.

The reason is that the usbport driver tries to register the sysfs
entries during the activate() callback. And this will fail with -2 /
ENOENT because the patch "leds: triggers: add device attribute support"
made it so that the sysfs "ports" group was only being added after the
activate() callback succeeded.

This version of the patch reverts parts of the "usb: simplify usbport
trigger" patch and restores usbport trigger's functionality.

Fixes: 6f7b0bad ("usb: simplify usbport trigger")
Signed-off-by: NChristian Lamparter <chunkeey@gmail.com>
Cc: stable <stable@vger.kernel.org>
Acked-by: NJacek Anaszewski <jacek.anaszewski@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

During the static checker, "data->usbmisc_data" may be NULL.
Fix it by adding this pointer judgement before using.
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NPeter Chen <peter.chen@nxp.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The README file ni the drivers/usb/usbip/ directory is not needed
anymore, so just delete it.

Cc: Valentina Manea <valentina.manea.m@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: NShuah Khan <shuah@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add new PID to support PL2303TB (TYPE_HX)
Signed-off-by: NCharles Yeh <charlesyeh522@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NJohan Hovold <johan@kernel.org>

To clear GINTSTS2_WKUP_ALERT_INT bit in GINTSTS2 register
require to write 1. This bit is implemented as "Write to clear".

Fixes: 187c5298 ("usb: dwc2: gadget: Add handler for WkupAlert interrupt")
Signed-off-by: NMinas Harutyunyan <hminas@synopsys.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

There is a bug in the current GPIO code for ftdi_sio: it failed to take USB
autosuspend into account. If the device is in autosuspend, calls to
usb_control_msg() fail with -EHOSTUNREACH. Because the standard value for
autosuspend timeout is usually 2-5 seconds, this made it almost impossible
to use the GPIOs on machines that have USB autosuspend enabled. This patch
fixes the issue by acquiring a PM lock on the device for the duration of
the USB transfers. Tested on an FT231X device.
Signed-off-by: NKaroly Pados <pados@pados.hu>
[ johan: simplify code somewhat ]
Fixes: ba93cc7d ("USB: serial: ftdi_sio: implement GPIO support for FT-X devices")
Cc: stable <stable@vger.kernel.org>	# 4.20
Signed-off-by: NJohan Hovold <johan@kernel.org>