Currently the controller handles single stream only. So, Ignore Packet
Pending bit for stream selection and don't search for another stream if
the host sends Data Packet with PP=0 (for OUT direction) or ACK with
NumP=0 and PP=0 (for IN direction). This slightly improves the stream
performance.
Acked-by: NFelipe Balbi <balbi@kernel.org>
Signed-off-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/097ba9e104c143f7ba0195ebff29390ec3043692.1618282705.git.Thinh.Nguyen@synopsys.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Currently, when dwc3 handles request cancelled, dwc3 just returns
-ECONNRESET for all requests. It will cause USB function drivers
can't know if the requests are cancelled by other reasons.

This patch will replace DWC3_REQUEST_STATUS_CANCELLED with the
reasons below.
  - DWC3_REQUEST_STATUS_DISCONNECTED
  - DWC3_REQUEST_STATUS_DEQUEUED
  - DWC3_REQUEST_STATUS_STALLED
Reviewed-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com>
Signed-off-by: NRay Chi <raychi@google.com>
Link: https://lore.kernel.org/r/20210327181742.1810969-1-raychi@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Different controller IPs check different HW parameters for MDWIDTH.
To help with maintainability, create a helper function to consolidate
the logic in a single place.
Signed-off-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/456329d36e8c188df5c234f3282595b630bf1470.1616892233.git.Thinh.Nguyen@synopsys.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Currently, vbus_draw callback used wrong scale for power_supply.
The unit of power supply should be uA.
Therefore, this patch will fix this problem.

Fixes: 99288de3 ("usb: dwc3: add an alternate path in vbus_draw callback")
Reported-by: NSebastian Reichel <sre@kernel.org>
Signed-off-by: NRay Chi <raychi@google.com>
Link: https://lore.kernel.org/r/20210327182809.1814480-2-raychi@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Ensure that dep->flags are cleared until after stop active transfers
is completed.  Otherwise, the ENDXFER command will not be executed
during ep disable.

Fixes: f09ddcfc ("usb: dwc3: gadget: Prevent EP queuing while stopping transfers")
Cc: stable <stable@vger.kernel.org>
Reported-and-tested-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Tested-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NWesley Cheng <wcheng@codeaurora.org>
Link: https://lore.kernel.org/r/1616610664-16495-1-git-send-email-wcheng@codeaurora.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If the gadget driver doesn't specify a max_speed, then use the
controller's maximum supported speed as default. For DWC_usb32 IP, the
gadget's speed maybe limited to gen2x1 rate only if the driver's
max_speed is unknown. This scenario should not occur with the current
implementation since the default gadget driver's max_speed should always
be specified. However, to make the driver more robust and help with
readability, let's cover all the scenarios in __dwc3_gadget_set_speed().

Fixes: 450b9e9f ("usb: dwc3: gadget: Set speed only up to the max supported")
Cc: <stable@vger.kernel.org>
Signed-off-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/55ac7001af73bfe9bc750c6446ef4ac8cf6f9313.1615254129.git.Thinh.Nguyen@synopsys.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Set the dwc->gadget_max_speed to SuperSpeed Plus if the user sets the
ssp_rate. The udc_set_ssp_rate() is intended for setting the gadget's
speed to SuperSpeed Plus at the specified rate.

Fixes: 072cab8a ("usb: dwc3: gadget: Implement setting of SSP rate")
Cc: <stable@vger.kernel.org>
Signed-off-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/0b2732e2f380d9912ee87f39dc82c2139223bad9.1615254129.git.Thinh.Nguyen@synopsys.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The current dwc3_gadget_reset_interrupt() will stop any active
transfers, but only addresses blocking of EP queuing for while we are
coming from a disconnected scenario, i.e. after receiving the disconnect
event.  If the host decides to issue a bus reset on the device, the
connected parameter will still be set to true, allowing for EP queuing
to continue while we are disabling the functions.  To avoid this, set the
connected flag to false until the stop active transfers is complete.
Signed-off-by: NWesley Cheng <wcheng@codeaurora.org>
Link: https://lore.kernel.org/r/1616146285-19149-3-git-send-email-wcheng@codeaurora.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add checks similar to dwc3_gadget_ep_queue() before kicking off
transfers after getting an endpoint completion event.   Since cleaning
up completed requests will momentarily unlock dwc->lock, there is a
chance for a sequence like pullup disable to be executed.  This can
lead to preparing a TRB, which will be removed by the pullup disable
routine.
Signed-off-by: NWesley Cheng <wcheng@codeaurora.org>
Link: https://lore.kernel.org/r/1616146285-19149-2-git-send-email-wcheng@codeaurora.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

None of the DWC_usb3x IPs (and all their versions) supports low-speed
setting in device mode. In the early days, our "Early Adopter Edition"
DWC_usb3 databook shows that the controller may be configured to operate
in low-speed, but it was revised on release. Let's remove this invalid
speed setting to avoid any confusion.
Signed-off-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/258b1c7fbb966454f4c4c2c1367508998498fc30.1615509438.git.Thinh.Nguyen@synopsys.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

In the situations where the DWC3 gadget stops active transfers, once
calling the dwc3_gadget_giveback(), there is a chance where a function
driver can queue a new USB request in between the time where the dwc3
lock has been released and re-aquired.  This occurs after we've already
issued an ENDXFER command.  When the stop active transfers continues
to remove USB requests from all dep lists, the newly added request will
also be removed, while controller still has an active TRB for it.
This can lead to the controller accessing an unmapped memory address.

Fix this by ensuring parameters to prevent EP queuing are set before
calling the stop active transfers API.

Fixes: ae7e8610 ("usb: dwc3: Stop active transfers before halting the controller")
Signed-off-by: NWesley Cheng <wcheng@codeaurora.org>
Link: https://lore.kernel.org/r/1615507142-23097-1-git-send-email-wcheng@codeaurora.org
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch adds an alternate path in vbus_draw callback through
power supply property POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT.
Signed-off-by: NRay Chi <raychi@google.com>
Link: https://lore.kernel.org/r/20210222115149.3606776-3-raychi@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The dep->interval captures the number of frames/microframes per interval
from bInterval. Fullspeed interrupt endpoint bInterval is the number of
frames per interval and not 2^(bInterval - 1). So fix it here. This
change is only for debugging purpose and should not affect the interrupt
endpoint operation.

Fixes: 72246da4 ("usb: Introduce DesignWare USB3 DRD Driver")
Cc: <stable@vger.kernel.org>
Signed-off-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/1263b563dedc4ab8b0fb854fba06ce4bc56bd495.1612820995.git.Thinh.Nguyen@synopsys.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Valid range for DEPCFG.bInterval_m1 is from 0 to 13, and it must be set
to 0 when the controller operates in full-speed. See the programming
guide for DEPCFG command section 3.2.2.1 (v3.30a).

Fixes: 72246da4 ("usb: Introduce DesignWare USB3 DRD Driver")
Cc: <stable@vger.kernel.org>
Signed-off-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/3f57026f993c0ce71498dbb06e49b3a47c4d0265.1612820995.git.Thinh.Nguyen@synopsys.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The check for bounded gadget driver in dwc3_gadget_start() was to
prevent going through the initialization again without any cleanup. The
recent commit 49d08cfc ("usb: udc: core: Introduce started state")
updated the UDC framework and guarantees this won't happen while the UDC
is started. Also, this check doesn't prevent requesting threaded irq to
the same dev_id, which will mess up the irq freeing logic. Let's remove
it.
Signed-off-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/ccc90f316cf78bb5f7d46d3fd84f4c7f2c3020b1.1612518764.git.Thinh.Nguyen@synopsys.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The setting of the device speed should be limited by the device's
maximum_speed. Check and prevent the driver from attempting to configure
higher than the maximum_speed.
Signed-off-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/4fae4a9ebb60464d64d8b8f6fdfc2777a2206a69.1611106162.git.Thinh.Nguyen@synopsys.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Track the number of connected lanes and speed in corresponding enum
usb_ssp_rate for SuperSpeed Plus capable device.
Signed-off-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/2389592188d2e37a2ee45edaf04d942b19f3af82.1611106162.git.Thinh.Nguyen@synopsys.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Implement gadget ops udc_set_ssp_rate(). This allows the gadget/core
driver to select SSP signaling rate and number of lanes to for DWC_usb32
controller.
Signed-off-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/8998b65fddfa02cab57bfc6aa35e9f101b252068.1611106162.git.Thinh.Nguyen@synopsys.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The DWC_usb32 controller supports dual-lane SuperSpeed Plus. Check the
maximum_speed property for any limitation in the HW to initialize and
validate the maximum number of lanes and speed the device will operate.

Currently the controller has no visibility into the HW parameter to
determine the maximum number of lanes the HW supports. If the number of
lanes is not specified for SSP, then set the default rate to gen2x2 for
DWC_usb32 and gen2x1 for DWC_usb31.
Signed-off-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/08d43f2a99198bed84895c272340449a6d03710e.1611106162.git.Thinh.Nguyen@synopsys.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Some users questioned why Vendor Test LMP Received event was enabled.
The driver currently doesn't handle this event. Let's disable it to
avoid confusion.
Acked-by: NFelipe Balbi <balbi@kernel.org>
Signed-off-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/4e785ba5d5e95801b6fcf96116f6090216e70760.1610596478.git.Thinh.Nguyen@synopsys.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If an active transfer is dequeued, then the endpoint is freed to start a
new transfer. Make sure to clear the endpoint's transfer wait flag for
this case.

Fixes: e0d19563 ("usb: dwc3: gadget: Wait for transfer completion")
Cc: stable@vger.kernel.org
Acked-by: NFelipe Balbi <balbi@kernel.org>
Signed-off-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/b81cd5b5281cfbfdadb002c4bcf5c9be7c017cfd.1609828485.git.Thinh.Nguyen@synopsys.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

usb_gadget_deactivate/usb_gadget_activate does not execute the UDC start
operation, which may leave EP0 disabled and event IRQs disabled when
re-activating the function. Move the enabling/disabling of USB EP0 and
device event IRQs to be performed in the pullup routine.

Fixes: ae7e8610 ("usb: dwc3: Stop active transfers before halting the controller")
Tested-by: NMichael Tretter <m.tretter@pengutronix.de>
Cc: stable <stable@vger.kernel.org>
Reported-by: NMichael Tretter <m.tretter@pengutronix.de>
Signed-off-by: NWesley Cheng <wcheng@codeaurora.org>
Link: https://lore.kernel.org/r/1609282837-21666-1-git-send-email-wcheng@codeaurora.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The USB gadget/UDC driver can restrict the DWC3 controller speed using
dwc3_gadget_set_speed().  Store this setting into a variable, in order for
this setting to persist across controller resets due to runtime PM.
Signed-off-by: NWesley Cheng <wcheng@codeaurora.org>
Link: https://lore.kernel.org/r/1609283136-22140-3-git-send-email-wcheng@codeaurora.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The DWC3 runtime suspend routine checks for the USB connected parameter to
determine if the controller can enter into a low power state.  The
connected state is only set to false after receiving a disconnect event.
However, in the case of a device initiated disconnect (i.e. UDC unbind),
the controller is halted and a disconnect event is never generated.  Set
the connected flag to false if issuing a device initiated disconnect to
allow the controller to be suspended.
Signed-off-by: NWesley Cheng <wcheng@codeaurora.org>
Link: https://lore.kernel.org/r/1609283136-22140-2-git-send-email-wcheng@codeaurora.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Some devices support charging while in device mode.  In these situations,
the USB gadget will notify the DWC3 gadget driver to modify the current
based on the enumeration and device state.  The usb_phy_set_power() API
will allow external charger entities to adjust the charge current through
the notifier block.
Reviewed-by: NPeter Chen <peter.chen@nxp.com>
Signed-off-by: NWesley Cheng <wcheng@codeaurora.org>
Link: https://lore.kernel.org/r/1609283011-21997-2-git-send-email-wcheng@codeaurora.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

DWC3 IPs can use the maximum stream id (up to 2^16) specified by the
USB 3.x specs. Don't limit to stream id 2^15 only. Note that this does
not reflect the number of concurrent streams the controller handles
internally.
Signed-off-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

If the transfer had already started and there's no TRB to update, then
there's no need to go through __dwc3_gadget_kick_transfer(). There is
no problem reissuing UPDATE_TRANSFER command. This change just saves
the driver from doing a few operations. This happens when we run out of
TRB and function driver still queues for more requests.
Signed-off-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

If we couldn't finish preparing all the TRBs of a request, don't prepare
the next request. Otherwise, the TRBs order will be mixed up and the
controller will process the wrong TRB. This is a corner case where
there's not enough TRBs for a request that needs the extra TRB but
there's still 1 available TRB in the pool.
Signed-off-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

To keep the setting of interrupt-on-completion (IOC) when out of TRBs
consistent and easier to read, the caller of dwc3_prepare_one_trb()
will determine if the TRB must have IOC bit set. This also reduces the
number of times we need to call dwc3_calc_trbs_left(). Note that we only
care about setting IOC from insufficient number of TRBs for SG and not
linear requests (because we don't need to split linear requests).
Signed-off-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

Previously if we run out of TRBs for the last SG entry that requires
an extra TRB, we set interrupt-on-completion (IOC) bit to an already
prepared TRB (i.e. HWO=1). This logic is not clean, and it's not a
typical way to prepare TRB. Also, this prevents showing IOC setup in
tracepoint when __dwc3_prepare_one_trb() is executed. Instead, let's
look ahead when preparing TRB to know whether to set the IOC bit before
the last SG entry. This requires adding a new parameter "must_interrupt"
to dwc3_prepare_one_trb().
Signed-off-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

It's possible that there's no new TRBs prepared when kicking a transfer.
This happens when we need to stop and restart a transfer such as in the
case of reinitiating a stream or retrying isoc transfer. For streams,
sometime host may reject a stream and the device may need to reinitiate
that stream by stopping and restarting a transfer. In this case, all the
TRBs may have already been prepared. Allow the function
__dwc3_gadget_kick_transfer() to go through even though there's no new
TRB.
Signed-off-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

In the DWC3 databook, for a device initiated disconnect or bus reset, the
driver is required to send dependxfer commands for any pending transfers.
In addition, before the controller can move to the halted state, the SW
needs to acknowledge any pending events.  If the controller is not halted
properly, there is a chance the controller will continue accessing stale or
freed TRBs and buffers.
Signed-off-by: NWesley Cheng <wcheng@codeaurora.org>
Reviewed-by: NThinh Nguyen <thinhn@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

The functions dwc3_prepare_one_trb_sg and dwc3_prepare_one_trb_linear
are not necessarily preparing "one" TRB, it can prepare multiple TRBs.
Rename these functions as follow:

dwc3_prepare_one_trb_sg -> dwc3_prepare_trbs_sg
dwc3_prepare_one_trb_linear -> dwc3_prepare_trbs_linear
Signed-off-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

There are a lot of common codes for preparing SG and linear TRBs.
Refactor them for easier read.
Signed-off-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

If we run out of TRBs because we need extra TRBs, make sure to set the
IOC bit for the previously prepared TRB to get completion notification
to free up TRBs to resume later.
Signed-off-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

By returning the number of TRBs prepared, we know whether to execute
__dwc3_gadget_kick_transfer(). This allows us to check if we ran out of
TRBs when extra TRBs are needed for OUT transfers. It also allows us to
properly handle usb_gadget_map_request_by_dev() error.

Fixes: c6267a51 ("usb: dwc3: gadget: align transfers to wMaxPacketSize")
Signed-off-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

In preparation for fixing the check for number of remaining TRBs,
revise dwc3_prepare_one_trb_linear() and dwc3_prepare_one_trb_sg() to
return the number of prepared TRBs.
Signed-off-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

For OUT requests that requires extra TRBs for ZLP. We don't need to
prepare the 0-length TRB and simply prepare the MPS size TRB. This
reduces 1 TRB needed to prepare for ZLP.
Signed-off-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

When the driver prepares the extra TRB, it uses bounce buffer. If we
just add a new parameter to dwc3_prepare_one_trb() to indicate this,
then we can refactor and simplify the driver quite a bit.
dwc3_prepare_one_trb() also checks if a request had been moved to the
started list. This is a prerequisite to subsequence patches improving
the handling of extra TRBs.
Signed-off-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

An SG request may be partially completed (due to no available TRBs).
Don't reclaim extra TRBs and clear the needs_extra_trb flag until the
request is fully completed. Otherwise, the driver will reclaim the wrong
TRB.

Cc: stable@vger.kernel.org
Fixes: 1f512119 ("usb: dwc3: gadget: add remaining sg entries to ring")
Signed-off-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>