summaryrefslogtreecommitdiff
path: root/drivers/ddr/imx/imx8ulp/ddr_init.c
diff options
context:
space:
mode:
authorSimon Holesch <simon@holesch.de>2023-11-20 01:08:34 +0100
committerMattijs Korpershoek <mkorpershoek@baylibre.com>2023-11-21 09:19:48 +0100
commitb272c87925025a44ad6ff851711c68847a4cff4a (patch)
treef88121f4ace7af1d92b7b2dd4519618e7877de20 /drivers/ddr/imx/imx8ulp/ddr_init.c
parent24ca49b33af98d54d6cd2e845f071f6565345ffd (diff)
usb: ci: Fix gadget reinit
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 <simon@holesch.de> Reviewed-by: Marek Vasut <marex@denx.de> Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> Link: https://lore.kernel.org/r/20231120002024.32865-1-simon@holesch.de Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Diffstat (limited to 'drivers/ddr/imx/imx8ulp/ddr_init.c')
0 files changed, 0 insertions, 0 deletions