Hi Quentin, On Tue, Jul 21, 2026 at 7:23 PM Quentin Schulz <[email protected]> wrote: > > Hi Alexey, > > On 5/8/26 4:59 PM, Quentin Schulz wrote: > > Hi Alexey, > > > > On 5/8/26 10:21 AM, Alexey Charkov wrote: > >> On Thu, May 7, 2026 at 8:48 PM Anton Burticica <[email protected]> wrote: > >>> > >>> The original idea was to _not_ disable USB3 OTG port when booted from > >>> USB: > >>> > >>> https://eur02.safelinks.protection.outlook.com/? > >>> url=https%3A%2F%2Fgithub.com%2Fflipperdevices%2Fu- > >>> boot%2Fpull%2F20%2Fchanges&data=05%7C02%7Cquentin.schulz%40cherry.de%7C2646189b068342c152fe08dead126988%7C5e0e1b5221b54e7b83bb514ec460677e%7C0%7C0%7C639138491747796890%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=xX4POW%2Be7JMSMo1g2aYdZekD5qwLAuXTtSyRuD6QVlY%3D&reserved=0 > >> > >> 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://eur02.safelinks.protection.outlook.com/? > > url=https%3A%2F%2Flore.kernel.org%2Fu-boot%2F20260507092843.358908-1- > > jens.wiklander%40linaro.org%2F&data=05%7C02%7Cquentin.schulz%40cherry.de%7C2646189b068342c152fe08dead126988%7C5e0e1b5221b54e7b83bb514ec460677e%7C0%7C0%7C639138491747835058%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=brdZsVC2x7KFqDMx5h476YybGJP0hEVubzQIixpSPjY%3D&reserved=0. > > Maybe this is something you could give a try and see if it makes things > > behave any different? > > > > Just to let you know I have marked this as "Changes requested" in > patchwork. Please send a v2 once the DWC syncing has happened if the > issue still happens (and maybe help with the effort if you can in some > ways). I'll not monitor this patch here anymore.
This patch becomes unnecessary if/when the DWC sync lands (confirmed on my RK3576 setup). I tested an early version of that and provided my Tested-by along with a link back to this issue, but Marek was skeptical about attaching the T-b to individual commits (given that they can't be tested individually by construction) so those were dropped in later iterations :) Even if the DWC sync doesn't end up being applied, the better fix (which I'm currently carrying in my local tree) is changing the ordering of reset vs. phy probe in the DWC init function, rather than a platform-specific change like this one. Best regards, Alexey
