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>
Similar change was done by commit b4c2c151b1 ("Kconfig: Remove all
default n/no options") and again sync is required.
default n/no doesn't need to be specified. It is default option anyway.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Reviewed-by: Svyatoslav Ryhel <clamor95@gmail.com> # tegra
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Angelo Dureghello <angelo@kernel-space.org>
Make sure we have an IMX header before calling spl_load_imx_container,
since if we don't it will fail with -ENOENT. This allows us to fall back to
legacy/raw images if they are also enabled.
This is a functional change, one which likely should have been in place
from the start, but a functional change nonetheless. Previously, all
non-IMX8 images (except FITs without FIT_FULL) would be optimized out if
the only image load method enabled supported IMX8 images. With this change,
support for other image types now has an effect.
There are seven boards with SPL_LOAD_IMX_CONTAINER enabled: three with
SPL_BOOTROM_SUPPORT:
imx93_11x11_evk_ld imx93_11x11_evk imx8ulp_evk
and four with SPL_MMC:
deneb imx8qxp_mek giedi imx8qm_mek
All of these boards also have SPL_RAW_IMAGE_SUPPORT and
SPL_LEGACY_IMAGE_FORMAT enabled as well. However, none have FIT support
enabled. Of the six load methods affected by this patch, only SPL_MMC and
SPL_BOOTROM_SUPPORT are enabled with SPL_LOAD_IMX_CONTAINER.
spl_romapi_load_image_seekable does not support legacy or raw images, so
there is no growth. However, mmc_load_image_raw_sector does support loading
legacy/raw images. Since these images could not have been booted before, I
have disabled support for legacy/raw images on these four boards. This
reduces bloat from around 800 bytes to around 200.
There are no in-tree boards with SPL_LOAD_IMX_CONTAINER and AHAB_BOOT both
enabled, so we do not need to worry about potentially falling back to
legacy images in a secure boot scenario.
Future work could include merging imx_container.h with imx8image.h, since
they appear to define mostly the same structures.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Since commit 4fcba5d556 ("regulator: implement basic reference
counter") the return value of regulator_set_enable() may be EALREADY or
EBUSY for fixed/GPIO regulators.
Switch to using the more relaxed regulator_set_enable_if_allowed() to
continue if regulator already was enabled or disabled.
This fixes the following error when running the 'ums' command:
=> ums 0 mmc 0
UMS: LUN 0, dev mmc 0, hwpart 0, sector 0x0, count 0xece000
Error enabling VBUS supply
g_dnl_register: failed!, error: -114
g_dnl_register failed
Signed-off-by: Fabio Estevam <festevam@denx.de>
Reviewed-by: Marek Vasut <marex@denx.de>
Use dev_ofnode() to retrieve the USB node pointer from the udevice
structure.
This fixes the following build error:
drivers/usb/host/ehci-mxs.c:143:38: error: 'struct udevice' has no member named 'node_'
Signed-off-by: Fabio Estevam <festevam@denx.de>
Reviewed-by: Marek Vasut <marex@denx.de>
In the existing implementation, multiple requests queued up on an
endpoint are subject to getting evicted without transmission.
For both control and bulk endpoints, their respective logic found in
usba_control_irq()/usba_ep_irq() guarantees that TX FIFO is empty before
data is sent out, and that request_complete() gets called once the
transaction has been finished. At this point however, if any additional
requests are found on the endpoint queue, they will be processed by
submit_next_request(), which makes no checks against the above
conditions, trashing data on a busy FIFO and neglecting completion
handlers.
Fix the above issues by removing the calls to submit_next_request(),
and thus forcing the pending requests to be processed on the next pass
of the respective endpoint logic. While at it, remove a DBG message, as
that branch becomes part of regular flow.
This restores mass storage mode operation on Microchip ATSAMA5D27 SoC.
Signed-off-by: Artur Rojek <artur@conclusive.pl>
This old patch was marked as deferred. Bring it back to life, to continue
towards the removal of common.h
Move this out of the common header and include it only where needed.
Signed-off-by: Simon Glass <sjg@chromium.org>
When 'usb stop' is run, doing 'bootflow scan' does not run the USB hunter
again so does not see any devices. Fix this by telling bootstd about the
state of USB.
Signed-off-by: Simon Glass <sjg@chromium.org>
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 <mkorpershoek@baylibre.com>
Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> # on khadas vim3
Signed-off-by: Marek Vasut <marex@denx.de>
Remove legacy functions limited by the dev_array array,
those are no longer used anywhere, all the code uses
plain udevice based access now.
The usb_gadget_handle_interrupts() is doing udevice look up
until all call sites use dm_usb_gadget_handle_interrupts().
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Signed-off-by: Marek Vasut <marex@denx.de>
Convert to plain udevice interaction with UDC controller
device, avoid the use of UDC uclass dev_array .
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Convert to plain udevice interaction with UDC controller
device, avoid the use of UDC uclass dev_array .
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Convert to plain udevice interaction with UDC controller
device, avoid the use of UDC uclass dev_array .
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Convert to plain udevice interaction with UDC controller
device, avoid the use of UDC uclass dev_array .
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Signed-off-by: Marek Vasut <marex@denx.de>
Convert to plain udevice interaction with UDC controller
device, avoid the use of UDC uclass dev_array .
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> # on khadas vim3
Signed-off-by: Marek Vasut <marex@denx.de>
Remove local usb_gadget_register_driver()/usb_gadget_unregister_driver()
implementation which is implemented in udc-core.c instead if DM_USB_GADGET
is enabled. Add no-op dm_usb_gadget_handle_interrupts() implementation.
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Marek Vasut <marex@denx.de>
Pull the functionality of UDC uclass that operates on plain udevice
and does not use this dev_array array into separate functions and
expose those functions, so that as much code as possible can be
switched over to these functions and the dev_array can be dropped.
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Signed-off-by: Marek Vasut <marex@denx.de>
The documentation for struct phy state that "The content of the
structure is managed solely by the PHY API and PHY drivers".
Change to use the generic_phy_valid() helper to check if phy is valid.
Also remove setting phy->dev to NULL now that generic_phy_get_by_name()
properly initialize phy->dev to NULL.
Fixes: 142d50fbce ("usb: dwc3: Add support for usb3-phy PHY configuration")
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Make usage of clock and reset bulk API in order to simplify the code
Reviewed-by: Marek Vasut <marex@denx.de>
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com>
Reviewed-by: Xavier Drudis Ferran <xdrudis@tinet.cat>
EHCI is usually used with companion controller (like OHCI) as companion
controller. This information on the companion is missing currently in
companion drivers.
So, if the usb-uclass isn't aware, it may scan busses in any order: OHCI
first, then EHCI.
This is seen on STM32MP1 where DT probing makes the probe order to occur
by increasing address (OHCI address < EHCI address).
When a low speed or full-speed device is plugged in, it's not detected as
EHCI should first detect it, and give ownership (handover) to OHCI.
Current situation on STM32MP1 (with a low speed device plugged-in)
STM32MP> usb start
starting USB...
Bus usb@5800c000: USB OHCI 1.0
Bus usb@5800d000: USB EHCI 1.00
scanning bus usb@5800c000 for devices... 1 USB Device(s) found
scanning bus usb@5800d000 for devices... 1 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
The "companion" property in the device tree allow to retrieve companion
controller information, from the EHCI node. This allow marking the
companion driver as such.
With this patch (same low speed device plugged in):
STM32MP> usb start
starting USB...
Bus usb@5800c000: USB OHCI 1.0
Bus usb@5800d000: USB EHCI 1.00
scanning bus usb@5800d000 for devices... 1 USB Device(s) found
scanning bus usb@5800c000 for devices... 2 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
STM32MP> usb tree
USB device tree:
1 Hub (12 Mb/s, 0mA)
| U-Boot Root Hub
|
+-2 Human Interface (1.5 Mb/s, 100mA)
HP HP USB 1000dpi Laser Mouse
1 Hub (480 Mb/s, 0mA)
u-boot EHCI Host Controller
This also optimize bus scan when a High speed device is plugged in, as
the usb-uclass skips OHCI in this case:
STM32MP> usb reset
resetting USB...
Bus usb@5800c000: USB OHCI 1.0
Bus usb@5800d000: USB EHCI 1.00
scanning bus usb@5800d000 for devices... 2 USB Device(s) found
scanning usb for storage devices... 1 Storage Device(s) found
STM32MP> usb tree
USB device tree:
1 Hub (480 Mb/s, 0mA)
| u-boot EHCI Host Controller
|
+-2 Mass Storage (480 Mb/s, 200mA)
SanDisk Cruzer Blade 03003432021922011407
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com>
Reviewed-by: Marek Vasut <marex@denx.de>
The original logic always enables USB_DR_MODE_HOST operation mode in
dwc3_layerscape_bind() in u-boot. Prevent choosing USB_DR_MODE_HOST
operation mode if USB_HOST is not enabled.
Fixes: 2b0b51d0be ("usb: dwc3: add layerscape support")
Signed-off-by: Oleksandr Suvorov <oleksandr.suvorov@foundries.io>
In the usb/dwc3-layerscape driver the first option should be renamed
to the latter as well. Do it.
Fix original logic in dwc3_layerscape_bind() - do not enable
Fixes: 333e4a621d ("Rename SPL_USB_HOST_SUPPORT to SPL_USB_HOST")
Signed-off-by: Oleksandr Suvorov <oleksandr.suvorov@foundries.io>
As ulpi_reset gpio is now optional, we need to check it when doing
the 'dwc3_generic_remove' function. Check if it is declared before
accessing the ulpi_reset.
Fixes: 237d1f60b1 ("usb: dwc3: Use the devm_gpiod_get_optional()
API for reset gpio")
Reported-by: Thomas Nizan <tnizan@witekio.com>
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
With the commit 4fcba5d556 ("regulator: implement basic reference
counter") the return value of regulator_set_enable may be EALREADY or
EBUSY for fixed/gpio regulators.
Change to use the more relaxed regulator_set_enable_if_allowed to
continue if regulator already was enabled or disabled.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Marek Vasut <marex@denx.de>
With the commit 4fcba5d556 ("regulator: implement basic reference
counter") the return value of regulator_set_enable may be EALREADY or
EBUSY for fixed/gpio regulators.
Change to use the more relaxed regulator_set_enable_if_allowed to
continue if regulator already was enabled or disabled.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org> # rockpro64-rk3399
Reviewed-by: Marek Vasut <marex@denx.de>
When USB finds no devices it currently returns -EPERM which bootstd does
not understand. This causes other bootdevs of the same priority to be
skipped.
Fix this by returning the correct error code.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
It is not a parse error to have a default value of "0" for a "hex" type
entry, instead of "0x0". However, "0" and "0x0" are not treated the
same even by the tools themselves. Correct this by changing the default
value from "0" to "0x0" for all hex type questions that had the
incorrect default. Fix one instance (in two configs) of a default of "0"
being used on a hex question to be "0x0". Remove the cases where a
defconfig had set a value of "0x0" to be used as the default had been
"0".
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Move the ethernet gadget driver registration and removal from ethernet
bind and unbind callbacks into driver DM probe and remove callbacks.
This way, when the driver is bound, which is triggered deliberately
using 'bind' command, the USB ethernet gadget driver is instantiated
and bound to the matching UDC. In reverse, when the driver is unbound,
which is again triggered deliberately using 'unbind' command, the USB
ethernet gadget driver instance is removed.
Effectively, this now behaves like running either 'ums' or 'dfu' or
any other commands utilizing USB gadget functionality.
This also drops use of usb_gadget_release() and moves the use of
usb_gadget_initialize() into usb_ether_init() used only by legacy
platforms that do not use 'bind' command properly yet. Those have
no place in drivers.
Signed-off-by: Marek Vasut <marex@denx.de>
Tested-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Move the driver probe function above the driver structure, so it
can be placed alongside other related functions, like upcoming
remove function. No functional change.
Signed-off-by: Marek Vasut <marex@denx.de>
Tested-by: Tom Rini <trini@konsulko.com>
Tested-by: Miquel Raynal <miquel.raynal@bootlin.com>
Tested-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
These functions here are only ever called once since drop of non-DM
networking code. Inline them. No functional change.
Signed-off-by: Marek Vasut <marex@denx.de>
Tested-by: Tom Rini <trini@konsulko.com>
Tested-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Like Rockchip RK3568, the RK3328 also have single node to
represent the glue and ctrl for USB 3.0.
So, use the driver data to use single ctrl for RK3328 DWC3.
Reviewed-by: Marek Vasut <marex@denx.de>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
RK3568 share glue and ctrl in a single node. Use glue_get_ctrl_dev to
return the glue node as the ctrl node.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Marek Vasut <marex@denx.de>
When dr_mode is peripheral or otg and U-Boot has not been built with
DM_USB_GADGET support, booting such device may end up with:
dwc3_glue_bind_common: subnode name: usb@fcc00000
Error binding driver 'dwc3-generic-wrapper': -6
Some drivers failed to bind
initcall sequence 00000000effbca08 failed at call 0000000000a217c8 (err=-6)
### ERROR ### Please RESET the board ###
Instead fail gracfully with ENODEV to allow board continue booting.
dwc3_glue_bind_common: subnode name: usb@fcc00000
dwc3_glue_bind_common: unsupported dr_mode 3
Also use CONFIG_IS_ENABLED(USB_HOST) and change switch to if statements
to improve readability of the code.
Fixes: 446e3a205b ("dwc3-generic: Handle the PHYs, the clocks and the reset lines")
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Marek Vasut <marex@denx.de>
The current error check for device_find_first_child is not working as
expected, the documentation for device_find_first_child mention:
@devp: Returns first child device, or NULL if none
Return: 0
Change to return early when there is no child node to avoid any possible
null pointer dereference.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Marek Vasut <marex@denx.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
drivers/core/device.c will call `device_free()` after xhci_register
already frees the private device data. This can cause a crash later
during the boot process, observed on aarch64 RPi4b as a synchronous
exception. All callers of xhci_register use priv_auto, so this won't
lead to memory leaks.
Signed-off-by: Richard Habeeb <richard.habeeb@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
When one of the functions does not support super speed, the composite
driver forces the gadget to high speed. But the speed is never
configured in the cdns3 gadget driver. So configure the speed
in cdns3_gadget_udc_start just like in the kernel.
Signed-off-by: Ravi Gunasekaran <r-gunasekaran@ti.com>
Reviewed-by: Marek Vasut <marex@denx.de>
Remove the regulator_set_enable() call from device probe which
resolves a regulator imbalance. This is unnecessary as
regulator_set_enable() will be called when ehci_register calls the
init_after_reset hook.
Suggested-by: Marek Vasut <marex@denx.de>
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
At the moment we use "select" in each Allwinner SoC's Kconfig section to
include the USB PHY driver in the build. This means it cannot be disabled
via Kconfig, although USB is not really a strictly required core
functionality, and a particular board might not even include USB ports.
Rework the Kconfig part by removing the "select" lines for each SoC's
section, and instead letting it default to "y" in the PHY driver section
itself. We use "depends on !" to exclude the few SoCs we don't support
(yet). The Allwinner V3s does not enable USB (PHY) support at the moment,
even though it should work: let the PHY default to "n" to keep the
current behaviour.
Also the MUSB USB driver directly calls some functions from the PHY
driver, so let the former depend on the PHY driver.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Tested-by: Sam Edwards <CFSworks@gmail.com>
It seems better to call this a 'bootdev' since this is name used in the
documentation. The older 'Bootdevice' name is no-longer used and may cause
confusion with the 'bootdevice' environment variable.
Update throughout to use bootdev.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
