u-boot.git/drivers/usb/gadget/ci_udc.c, branch master

usb: gadget: Mark udc_disconnect as static

2026-03-03T08:09:43+00:00

With the last external callers of udc_disconnect long removed, mark this
function as static now and remove it from headers.

Signed-off-by: Tom Rini 
Reviewed-by: Mattijs Korpershoek 
Link: https://patch.msgid.link/20260224154504.85301-1-trini@konsulko.com
Signed-off-by: Mattijs Korpershoek

usb: ci_udc: cosmetics: EP and requests debug info

2026-01-09T08:24:39+00:00

Make a note in an unexpected situation, e.g. queuing a request
on a disabled endpoint, enabling an enabled endpoint...

Reviewed-by: Mattijs Korpershoek 
Signed-off-by: Petr Beneš 
Link: https://lore.kernel.org/r/20251218142737.3169753-2-petr.benes@ysoft.com
Signed-off-by: Mattijs Korpershoek

usb: ci_udc: Check ci_ep->desc before use

2026-01-09T08:24:39+00:00

There are two places where ci_ep->desc could be accessed despite it is
not valid at that moment. Either the endpoint has not been enabled yet
or it has been disabled meanwhile (The ethernet gadged behaves this way
at least.). That results in dereferencing a null pointer.

Moreover, the patch gets rid of possible outstanding requests if the
endpoint's state changes to disabled.

Signed-off-by: Petr Beneš 
Reviewed-by: Mattijs Korpershoek 
Link: https://lore.kernel.org/r/20251218142737.3169753-1-petr.benes@ysoft.com
Signed-off-by: Mattijs Korpershoek

usb: ci_udc: don't use "advance" feature when setting address

2024-11-26T08:56:03+00:00

In the older USB controllers like for example in ChipIdea controller
used by the Tegra 2 the "USBADRA: Device Address Advance" bitflag
does not exist, so the new device address set during SET_ADDRESS
can't be deferred by hardware, which causes the host to not recognize
the device and give an error.

Instead store it until ep completes to apply the change into the hw
register as Linux kernel does. This should fix regression on old and
and be compatible with newer controllers.

Inspired by: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ef15e5490edc7edf808d3477ab32e0e320792f65

Signed-off-by: Ion Agorria 
Signed-off-by: Svyatoslav Ryhel 
Reviewed-by: Mattijs Korpershoek 
Link: https://lore.kernel.org/r/20241126072956.64778-2-clamor95@gmail.com
Signed-off-by: Mattijs Korpershoek

Restore patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet"

2024-05-20T19:35:03+00:00

As part of bringing the master branch back in to next, we need to allow
for all of these changes to exist here.

Reported-by: Jonas Karlman 
Signed-off-by: Tom Rini

Revert "Merge patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet""

2024-05-19T14:16:36+00:00

When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay
Ethernet"' I failed to notice that b4 noticed it was based on next and
so took that as the base commit and merged that part of next to master.

This reverts commit c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing
changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35.

Reported-by: Jonas Karlman 
Signed-off-by: Tom Rini

usb: Remove and add needed includes

2024-05-07T14:00:56+00:00

Remove  from this driver directory and when needed
add missing include files directly.

Reviewed-by: Mattijs Korpershoek 
Signed-off-by: Tom Rini

usb: ci: Fix gadget reinit

2023-11-21T08:19:48+00:00

The ChipIdea device controller wasn't properly cleaned up when disabled.
So enabling it again left it in a broken state. The problem occurred for
example when the host unbinds the driver and binds it again.

During the first setup, when the out request is queued, the endpoint is
primed (`epprime`). If the endpoint is then disabled, it stayed primed
with the initial buffer. So after the endpoint is re-enabled, the device
controller and device driver were out of sync: the new out request was
in the driver queue head, yet not submitted, but the "complete" function
was still called, since the endpoint was primed with the old buffer.

With the fastboot function this error led to the (rather confusing)
error message "buffer overflow".

Fixed by clearing the primed buffers with the `epflush` (`ENDPTFLUSH`)
register.

Signed-off-by: Simon Holesch 
Reviewed-by: Marek Vasut 
Reviewed-by: Mattijs Korpershoek 
Link: https://lore.kernel.org/r/20231120002024.32865-1-simon@holesch.de
Signed-off-by: Mattijs Korpershoek

board: usb: Replace legacy usb_gadget_handle_interrupts()

2023-09-15T21:38:02+00:00

The usb_gadget_handle_interrupts() is no longer used anywhere,
replace the remaining uses with dm_usb_gadget_handle_interrupts()
which takes udevice as a parameter.

Some of the UDC drivers currently ignore the index parameter altogether,
those also ignore the udevice and have to be reworked. Other like the
dwc3_uboot_handle_interrupt() had to be switched from index to udevice
look up to avoid breakage.

Reviewed-by: Mattijs Korpershoek 
Tested-by: Mattijs Korpershoek  # on khadas vim3
Signed-off-by: Marek Vasut

global: Finish CONFIG -> CFG migration

2023-01-20T17:27:24+00:00

At this point, the remaining places where we have a symbol that is
defined as CONFIG_... are in fairly odd locations. While as much dead
code has been removed as possible, some of these locations are simply
less obvious at first. In other cases, this code is used, but was
defined in such a way as to have been missed by earlier checks.  Perform
a rename of all such remaining symbols to be CFG_... rather than
CONFIG_...

Signed-off-by: Tom Rini 
Reviewed-by: Simon Glass