Since we're disabling the endpoint anyway, we don't worry about
getting endpoint command completion interrupt.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

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>

Document RZ/G2E (R8A774C0) SoC bindings.
Reviewed-by: NRob Herring <robh@kernel.org>
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>

Document RZ/G2E (R8A774C0) SoC bindings.
Reviewed-by: NRob Herring <robh@kernel.org>
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>

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>

The AM654 SoC from TI contains a DWC3 controller. Add
support for it.
Reviewed-by: NRob Herring <robh@kernel.org>
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>

msm8998 USB has a dwc3 controller just like the existing sdm845 support.
Signed-off-by: NJeffrey Hugo <jhugo@codeaurora.org>
Reviewed-by: NBjorn Andersson <bjorn.andersson@linaro.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>

Pull x86 fixes from Thomas Gleixner:
 "A set of fixes for x86:

   - Fix the swapped outb() parameters in the KASLR code

   - Fix the PKEY handling at fork which missed to preserve the pkey
     state for the child. Comes with a test case to validate that.

   - Fix the entry stack handling for XEN PV to respect that XEN PV
     systems enter the function already on the current thread stack and
     not on the trampoline.

   - Fix kexec load failure caused by using a stale value when the
     kexec_buf structure is reused for subsequent allocations.

   - Fix a bogus sizeof() in the memory encryption code

   - Enforce PCI dependency for the Intel Low Power Subsystem

   - Enforce PCI_LOCKLESS_CONFIG when PCI is enabled"

* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/Kconfig: Select PCI_LOCKLESS_CONFIG if PCI is enabled
  x86/entry/64/compat: Fix stack switching for XEN PV
  x86/kexec: Fix a kexec_file_load() failure
  x86/mm/mem_encrypt: Fix erroneous sizeof()
  x86/selftests/pkeys: Fork() to check for state being preserved
  x86/pkeys: Properly copy pkey state at fork()
  x86/kaslr: Fix incorrect i8254 outb() parameters
  x86/intel/lpss: Make PCI dependency explicit

Pull x86 timer fixes from Thomas Gleixner:
 "Two commits which were missed to be sent during the merge window.

   - The TSC calibration fix turns out to be more urgent as recent
     Skylake-X systems seem to have massive trouble with calibration
     disturbance. This should go back into stable for that reason and it
     the risk of breakage is rather low.

   - Drop an unused define"

* 'x86-timers-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/hpet: Remove unused FSEC_PER_NSEC define
  x86/tsc: Make calibration refinement more robust