On Wed Apr 3, 2024 at 7:22 PM IST, Sebastian Reichel wrote: > Hi, > > On Wed, Apr 03, 2024 at 01:03:07AM +0000, Pratham Patel wrote: > > > > > Also, can you give the output of <debugfs>/devices_deferred for the > > > > > good vs bad case? > > > > > > > > I can't provide you with requested output from the bad case, since the > > > > kernel never moves past this to an initramfs rescue shell, but following > > > > is the output from v6.8.1 (**with aforementioned patch reverted**). > > > > > > > > # cat /sys/kernel/debug/devices_deferred > > > > fc400000.usb platform: wait for supplier /phy@fed90000/usb3-port > > > > 1-0022 typec_fusb302: cannot register tcpm port > > > > fc000000.usb platform: wait for supplier /phy@fed80000/usb3-port > > > > > > > > It seems that v6.8.2 works _without needing to revert the patch_. I will > > > > have to look into this sometime this week but it seems like > > > > a8037ceb8964 (arm64: dts: rockchip: drop rockchip,trcm-sync-tx-only from rk3588 i2s) > > > > seems to be the one that fixed the root issue. I will have to test it > > > > sometime later this week. > > > > > > Ok, once you find the patch that fixes things, let me know too. > > > > Will do! > > FWIW the v6.8.1 kernel referenced above is definitely patched, since > upstream's Rock 5B DT does neither describe fusb302, nor the USB > port it is connected to. > > We have a few Rock 5B in Kernel CI and upstream boots perfectly > fine: > > https://lava.collabora.dev/scheduler/device_type/rk3588-rock-5b Hmm, weird then. I can confirm that v6.8.1 doesn't _always_ boot. It boots some times but still fails a majority of times. There is a 2 out of 10 chance that v6.8.1 will not boot. If you keep rebooting enough times, you might get it to boot but the next boot is likely to be borked. :( That said, v6.8.2 might still have the same issue, but the probably of a failed boot might be _lesser_ than v6.8.1 (from what I saw). I will verify that behaviour sometime tomorrow or day after tomorrow. > > So it could be one of your downstream patches, which is introducing > this problem. I thought so too. So I built a vanilla kernel from the release tarball of v6.8.1, using GCC + arm64 defconfig. I also tried using LLVM just in case but noticed the same result. -- Pratham Patel
