[PATCH] rockchip: rk3576: Properly handle USB controller takeover from BootROM

[Quentin Schulz]

Hi Alexey,

On 5/8/26 10:21 AM, Alexey Charkov wrote:
> On Thu, May 7, 2026 at 8:48 PM Anton Burticica <mouse at ya.ru> wrote:
>>
>> The original idea was to _not_ disable USB3 OTG port when booted from USB:
>>
>> https://github.com/flipperdevices/u-boot/pull/20/changes
> 
> Hi Anton, thanks for the context!
> 
> It seems, however, that the minimal change out of your original pull
> request which fixes the observed initialization issue is just the
> assertion of the reset line. The rest may be helpful but is apparently
> not directly relevant to what I'm trying to fix here - thus the
> significantly trimmed down patch body compared to your original
> version (one change at a time).
> 
>> There is a possibility that with already running analogue blocks, disabling the port will leave the controller in some weird state and it's not possible to fully reset it via exposed reset lanes without full SoC reset.
> 
> Could be. However, having a different initial hardware state by the
> time the driver loads, depending on the original bootsource, sounds
> like future pain.
> 
> The Linux driver(s) also seem to be able to properly reinitialize the
> relevant hardware blocks regardless of where the boot ROM and U-boot
> left them, so I don't think we are dealing with a case of
> "unrecoverable weird state requiring full SoC reset". We just need to
> figure out what we are missing here, out of the substantial difference
> between the two codebases.
> 

There's an attempt at synchronizing the codebase with Linux v6.16-rc7, 
see 
https://lore.kernel.org/u-boot/20260507092843.358908-1-jens.wiklander@linaro.org/. 
Maybe this is something you could give a try and see if it makes things 
behave any different?

Cheers,
Quentin