The DWC3 DebugFS directory and files are currently created once
during probe.  This includes creation of subdirectories for each
of the gadget's endpoints.  This works fine for peripheral-only
controllers, as dwc3_core_init_mode() calls dwc3_gadget_init()
just prior to calling dwc3_debugfs_init().

However, for dual-role controllers, dwc3_core_init_mode() will
instead call dwc3_drd_init() which is problematic in a few ways.
First, the initial state must be determined, then dwc3_set_mode()
will have to schedule drd_work and by then dwc3_debugfs_init()
could have already been invoked.  Even if the initial mode is
peripheral, dwc3_gadget_init() happens after the DebugFS files
are created, and worse so if the initial state is host and the
controller switches to peripheral much later.  And secondly,
even if the gadget endpoints' debug entries were successfully
created, if the controller exits peripheral mode, its dwc3_eps
are freed so the debug files would now hold stale references.

So it is best if the DebugFS endpoint entries are created and
removed dynamically at the same time the underlying dwc3_eps are.
Do this by calling dwc3_debugfs_create_endpoint_dir() as each
endpoint is created, and conversely remove the DebugFS entry when
the endpoint is freed.

Fixes: 41ce1456 ("usb: dwc3: core: make dwc3_set_mode() work properly")
Reviewed-by: NPeter Chen <peter.chen@kernel.org>
Signed-off-by: NJack Pham <jackp@codeaurora.org>
Link: https://lore.kernel.org/r/20210529192932.22912-1-jackp@codeaurora.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The driver incorrectly uses req->num_pending_sgs to track both the
number of pending and queued SG entries. It only prepares the next
request if the previous is done, and it doesn't update num_pending_sgs
until there is TRB completion interrupt. This may starve the controller
of more TRBs until the num_pending_sgs is decremented.

Fix this by decrementing the num_pending_sgs after they are queued and
properly track both num_mapped_sgs and num_queued_sgs.

Fixes: c96e6725 ("usb: dwc3: gadget: Correct the logic for queuing sgs")
Cc: <stable@vger.kernel.org>
Reported-by: NMichael Grzeschik <m.grzeschik@pengutronix.de>
Tested-by: NMichael Grzeschik <m.grzeschik@pengutronix.de>
Acked-by: NFelipe Balbi <balbi@kernel.org>
Signed-off-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/ba24591dbcaad8f244a3e88bd449bb7205a5aec3.1620874069.git.Thinh.Nguyen@synopsys.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If an error is received when issuing a start or update transfer
command, the error handler will stop all active requests (including
the current USB request), and call dwc3_gadget_giveback() to notify
function drivers of the requests which have been stopped.  Avoid
returning an error for kick transfer during EP queue, to remove
duplicate cleanup operations on the request being queued.

Fixes: 8d99087c ("usb: dwc3: gadget: Properly handle failed kick_transfer")
cc: stable@vger.kernel.org
Signed-off-by: NWesley Cheng <wcheng@codeaurora.org>
Link: https://lore.kernel.org/r/1620410119-24971-1-git-send-email-wcheng@codeaurora.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

As part of commit e81a7018 ("usb: dwc3: allocate gadget structure
dynamically") the dwc3_gadget_release() was added which will free
the dwc->gadget structure upon the device's removal when
usb_del_gadget_udc() is called in dwc3_gadget_exit().

However, simply freeing the gadget results a dangling pointer
situation: the endpoints created in dwc3_gadget_init_endpoints()
have their dep->endpoint.ep_list members chained off the list_head
anchored at dwc->gadget->ep_list.  Thus when dwc->gadget is freed,
the first dwc3_ep in the list now has a dangling prev pointer and
likewise for the next pointer of the dwc3_ep at the tail of the list.
The dwc3_gadget_free_endpoints() that follows will result in a
use-after-free when it calls list_del().

This was caught by enabling KASAN and performing a driver unbind.
The recent commit 568262bf ("usb: dwc3: core: Add shutdown
callback for dwc3") also exposes this as a panic during shutdown.

There are a few possibilities to fix this.  One could be to perform
a list_del() of the gadget->ep_list itself which removes it from
the rest of the dwc3_ep chain.

Another approach is what this patch does, by splitting up the
usb_del_gadget_udc() call into its separate "del" and "put"
components.  This allows dwc3_gadget_free_endpoints() to be
called before the gadget is finally freed with usb_put_gadget().

Fixes: e81a7018 ("usb: dwc3: allocate gadget structure dynamically")
Reviewed-by: NPeter Chen <peter.chen@kernel.org>
Signed-off-by: NJack Pham <jackp@codeaurora.org>
Link: https://lore.kernel.org/r/20210501093558.7375-1-jackp@codeaurora.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The device event corresponding to End of Periodic Frame is only
found on older IP revisions (2.10a and prior, according to a
cursory SNPS databook search).  On revisions 2.30a and newer,
including DWC3.1, the same event value and corresponding DEVTEN
bit were repurposed to indicate that the link has gone into
suspend state (U3 or L2/L1).

EOPF events had never been enabled before in this driver, and
going forward we expect current and future DWC3-based devices
won't likely to be using such old DWC3 IP revisions either.
Hence rather than keeping the deprecated EOPF macro names let's
rename them to indicate their usage for suspend events.
Acked-by: NFelipe Balbi <balbi@kernel.org>
Signed-off-by: NJack Pham <jackp@codeaurora.org>
Link: https://lore.kernel.org/r/20210428090111.3370-2-jackp@codeaurora.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 72704f87 ("dwc3: gadget: Implement the suspend entry event
handler") introduced (nearly 5 years ago!) an interrupt handler for
U3/L1-L2 suspend events.  The problem is that these events aren't
currently enabled in the DEVTEN register so the handler is never
even invoked.  Fix this simply by enabling the corresponding bit
in dwc3_gadget_enable_irq() using the same revision check as found
in the handler.

Fixes: 72704f87 ("dwc3: gadget: Implement the suspend entry event handler")
Acked-by: NFelipe Balbi <balbi@kernel.org>
Signed-off-by: NJack Pham <jackp@codeaurora.org>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20210428090111.3370-1-jackp@codeaurora.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

DWC_usb32 IP introduces a new behavior when handling NoStream event for
IN endpoints. If the controller is capable of DEV_TXF_FLUSH_BYPASS, then
the driver does not need to force to restart stream for IN endpoints.
The controller will generate ERDY and restart the stream periodically.
Acked-by: NFelipe Balbi <balbi@kernel.org>
Signed-off-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/65c3070c666cd6b8beeee62d7f8e3e704ebf2d32.1619134559.git.Thinh.Nguyen@synopsys.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The programming guide incorrectly stated that the DCFG.bInterval_m1 must
be set to 0 when operating in fullspeed. There's no such limitation for
all IPs. See DWC_usb3x programming guide section 3.2.2.1.

Fixes: a1679af8 ("usb: dwc3: gadget: Fix setting of DEPCFG.bInterval_m1")
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/5d4139ae89d810eb0a2d8577fb096fc88e87bfab.1618472454.git.Thinh.Nguyen@synopsys.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The START_TRANSFER command needs to be executed while in ON/U0 link
state (with an exception during register initialization). Don't use
dwc->link_state to check this since the driver only tracks the link
state when the link state change interrupt is enabled. Check the link
state from DSTS register instead.

Note that often the host already brings the device out of low power
before it sends/requests the next transfer. So, the user won't see any
issue when the device starts transfer then. This issue is more
noticeable in cases when the device delays starting transfer, which can
happen during delayed control status after the host put the device in
low power.

Fixes: 799e9dc8 ("usb: dwc3: gadget: conditionally disable Link State change events")
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/bcefaa9ecbc3e1936858c0baa14de6612960e909.1618884221.git.Thinh.Nguyen@synopsys.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If the device doesn't support LPM, make sure to disable the LPM
capability and don't advertise to the host that it supports it.
Acked-by: NFelipe Balbi <balbi@kernel.org>
Signed-off-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/9e68527ff932b1646f92a7593d4092a903754666.1618366071.git.Thinh.Nguyen@synopsys.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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>