summaryrefslogtreecommitdiff
path: root/scripts/dtc/libfdt/libfdt_internal.h
diff options
context:
space:
mode:
authorLukasz Czechowski <lukasz.czechowski@thaumatec.com>2025-07-22 11:55:35 +0200
committerTom Rini <trini@konsulko.com>2025-07-30 07:57:17 -0600
commit42a025412d737cd57874b81de8c8f49fea538c8b (patch)
treefb76fcdb136a7869db687a56c19b3faf8c50f514 /scripts/dtc/libfdt/libfdt_internal.h
parent480753ca92352e69a08455ad487089388fac9d88 (diff)
usb: onboard-hub: Set the reset gpio pin before freeing
In the usb_onboard_hub_remove, the reset gpio, if available, is freed. The pin state however, remains unchanged, as set in the usb_onboard_hub_reset. The hub is then left enabled. During second onboard hub probing, the hub is initially enabled (reset pin in state "0"), and then it is being reset by the reset function (transition to "1" and then to "0"). Because of this, the hub first disconnects from root hub, and then it connects again. When the devices are being discovered in the usb_scan_port in the usb_hub driver, initially there is the USB_PORT_STAT_CONNECTION bit not set in portstatus, but USB_PORT_STAT_C_CONNECTION set in portchange data (which is because disconnect event occurred first). In this condition, the driver does not wait for devices to appear. This can cause the hub (and all child devices) to be not enumerated when rescanning on "usb reset" command. To fix this, set the reset gpio to active in usb_onboard_hub_remove, to put the hub into reset state. However, in case the hub reset pin is by default held in high state by HW before U-Boot takes over, in which case the USB hub is active, then during the first probe it gets reset and we might get into the same issue of the hub being not enumerated. Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de> Signed-off-by: Lukasz Czechowski <lukasz.czechowski@thaumatec.com>
Diffstat (limited to 'scripts/dtc/libfdt/libfdt_internal.h')
0 files changed, 0 insertions, 0 deletions