By printing enqueue/dequeue pointers, we can make sure that our TRB
handling is correct. We've had a recent situation where we were not
always dequeueing all TRBs in an SG list and this helped figure out
what the problem was.
Change-Id: Ied1c5d57b4f324c40dd219153b49a1e244b6773c
Signed-off-by: Felipe Balbi <balbi@kernel.org>
Git-commit: 30ad6273adad76017ddad737d45f8931cac554ad
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: Mayank Rana <mrana@codeaurora.org>
If dwc3 fails to issue START_TRANSFER/UPDATE_TRANSFER command, then we
should properly end an active transfer and give back all the started
requests. However if it's for an isoc endpoint, the failure maybe due to
bus-expiry status. In this case, don't give back the requests and wait
for the next retry.
Change-Id: I64ff69a663a9ad7701f877a0cf3bcd87b93c792a
Fixes: 72246da40f ("usb: Introduce DesignWare USB3 DRD Driver")
Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
Git-commit: 8d99087c2db863c5fa3a4a1f3cb82b3a493705ca
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: Mayank Rana <mrana@codeaurora.org>
A request may not be completed because not all the TRBs are prepared for
it. This happens when we run out of available TRBs. When some TRBs are
completed, the driver needs to prepare the rest of the TRBs for the
request. The check dwc3_gadget_ep_request_completed() shouldn't be
checking the amount of data received but rather the number of pending
TRBs. Revise this request completion check.
Change-Id: If806e69c32a84caa0c839286a33ee0b092cd372a
Cc: stable@vger.kernel.org
Fixes: e0c42ce590 ("usb: dwc3: gadget: simplify IOC handling")
Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
Git-commit: 49e0590e3a60e75b493e5df879e216e5073c7663
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: Mayank Rana <mrana@codeaurora.org>
The flow from function dwc3_gadget_ep_dequeue() is not easy to follow.
Refactor it for easier read. No functional change in this commit.
Change-Id: I254081abaf3ff7c6a7a598bf859804ecf3454a15
Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
Git-commit: fcd2def6639293c2bde2dc4f5dab63641a60b5b3
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
[mrana@codeaurora.org: resolve merge conflict related to debug log]
Signed-off-by: Mayank Rana <mrana@codeaurora.org>
Remove 2 unnecessary checks:
1) A request in the started_list must have its trb field set. So
checking for req->trb is unnecessary.
2) An endpoint must have started (and have not ended) for the request to
still be in the started_list. There's no point to check if the endpoint
is started. We had this check because previously the driver didn't
handle the endpoint's started/ended flags for END_TRANSFER command
properly. See commit 9f45581f5e ("usb: dwc3: gadget: early giveback
if End Transfer already completed").
Change-Id: I5d55f02d25abe06d5601730f1d1d88ee24809d2c
Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
Git-commit: 8411993e79df8e54da67613025d620a8a23a24fe
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: Mayank Rana <mrana@codeaurora.org>
Supplier virtual machines (VMs) support exporting dma-bufs to
a consumer VM. However, consumers do not support importing dma-bufs
into their VMs, so add an IOCTL command to import a dma-buf into
a consumer VM.
The client must provide a memory parcel handle that corresponds to a
dma-buf that has been shared with the consumer VM, as well as an
access control list that is used for validating the access control
rules for the buffer. Upon success, the client is given a dma-buf
fd, which they can use to map the buffer and access it from both
the CPU, and peripherals.
Change-Id: I548e004e73543421b932430fbd9f84ad76658ef8
Signed-off-by: Isaac J. Manjarres <isaacm@codeaurora.org>
Currently, mem-buf suppliers can only provide a consumer with a memory
buffer if the consumer requests for the memory buffer, in which case
the supplier has no control over the contents of the buffer that is
given to the consumer. This is not ideal in cases where the supplier
virtual machine (VM) may have data that is of interest to the consumer,
which can be shared using a memory buffer.
Introduce a new IOCTL command which allows a client to specify a
dma-buf that they would like to share with a consumer VM, as well
as the access control rules that should be applied to the buffer.
Change-Id: I1e4ec1205ad4e69039ec0ab26b4209512896a354
Signed-off-by: Isaac J. Manjarres <isaacm@codeaurora.org>
The current rules for determining if a buffer can or cannot be mapped
to depend on how a buffer was allocated. This is restrictive
in environments where the security state of a buffer can change
dynamically, as the accessibility of the buffer has to change with
respect to the security state of the buffer.
Thus, add support to track the number of userspace mappings associated
with an ION buffer, as well as an interface to allow drivers to lock
and unlock a buffer. In this context, locking a buffer means that the
buffer will no longer be mappable, and the buffer does not
have any outstanding mappings at the time the buffer is locked.
Unlocking the buffer means that the buffer can be mapped again.
Change-Id: I6aa73b9ac7c301b12106ad3d3bcb4c2aac959e55
Signed-off-by: Isaac J. Manjarres <isaacm@codeaurora.org>
Debugfs is used for bringup support and debug. Ignore debugfs
setup failure if it is not supported in kernel config.
Change-Id: I07a56a0ce4adf53e0aa5b00ce73310d0c7ed2f6a
Signed-off-by: Manikandan Mohan <manikand@codeaurora.org>
