Fixing the devicetree of Rock 5 Model B (and possibly others)

Fixing the devicetree of Rock 5 Model B (and possibly others)

[Pratham Patel]

[-- Attachment #1.1: Type: text/plain, Size: 1961 bytes --]

Since the introduction of the `of: property: fw_devlink: Fix stupid bug in remote-endpoint parsing` patch, an issue with the device-tree of the Rock 5 Model B has been detected. All the stable kernels (6.7.y and 6.8.y) work on the Orange Pi 5, which has the Rockchip RK3588S SoC (same as the RK3588, but less I/O basically). So, being an owner of only two SBCs which use the RK3588* SoC, it appears that the Rock 5 Model B's DT is incorrect.

I looked at the patch and tried several things, neither resulted in anything that would point me to the core issue. Then I tried this:

```
$ grep -C 3 remote-endpoint arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts

                port {
                        es8316_p0_0: endpoint {
                                remote-endpoint = <&i2s0_8ch_p0_0>;
                        };
                };
        };
--
                i2s0_8ch_p0_0: endpoint {
                        dai-format = "i2s";
                        mclk-fs = <256>;
                        remote-endpoint = <&es8316_p0_0>;
                };
        };
};
```

So, from a cursory look, the issue seems to be related to either the DT node for the audio codec or related to the es8316's binding itself. Though I doubt that the later is the issue because if that were the issue, _someone_ with a Pine64 Pinebook Pro would've raised alarms. So far, this seems to be related to the `rk3588-rock-5b.dts` and possibly with the `rk3588s-rock-5a.dts` too.

I would **love** to help but I'm afraid I device-trees are not something that I am at-all familiar with. That said, I am open to methods of debugging this issue to provide a fix myself.

I would have replied to the patch's link but unfortunately, I haven't yet setup neomutt and my email provider's web UI doesn't have a [straightforward] way to reply using the 'In-Reply-To' header, hence a new thread. Apologies for the inconvenience caused.

  -- Pratham Patel

[-- Attachment #1.2: publickey - prathampatel@thefossguy.com - 0xF2DDE54D.asc --]
[-- Type: application/pgp-keys, Size: 669 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]

Re: Fixing the devicetree of Rock 5 Model B (and possibly others)

[Pratham Patel]

[-- Attachment #1.1: Type: text/plain, Size: 2170 bytes --]

Ugh, just now noticing that I forgot to send the boot log captured over UART and forgot to disable sending the pubkey as an attachment.

The word wrap is broken because of course the web UI isn't mindful of that.

Sorry!

 -- Pratham Patel


On Saturday, March 23rd, 2024 at 22:32, Pratham Patel <prathampatel@thefossguy.com> wrote:

> 

> 

> Since the introduction of the `of: property: fw_devlink: Fix stupid bug in remote-endpoint parsing` patch, an issue with the device-tree of the Rock 5 Model B has been detected. All the stable kernels (6.7.y and 6.8.y) work on the Orange Pi 5, which has the Rockchip RK3588S SoC (same as the RK3588, but less I/O basically). So, being an owner of only two SBCs which use the RK3588* SoC, it appears that the Rock 5 Model B's DT is incorrect.
> 

> I looked at the patch and tried several things, neither resulted in anything that would point me to the core issue. Then I tried this:
> 

> ```
> $ grep -C 3 remote-endpoint arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts
> 

> port {
> es8316_p0_0: endpoint {
> remote-endpoint = <&i2s0_8ch_p0_0>;
> 

> };
> };
> };
> --
> i2s0_8ch_p0_0: endpoint {
> dai-format = "i2s";
> mclk-fs = <256>;
> 

> remote-endpoint = <&es8316_p0_0>;
> 

> };
> };
> };
> ```
> 

> So, from a cursory look, the issue seems to be related to either the DT node for the audio codec or related to the es8316's binding itself. Though I doubt that the later is the issue because if that were the issue, someone with a Pine64 Pinebook Pro would've raised alarms. So far, this seems to be related to the `rk3588-rock-5b.dts` and possibly with the `rk3588s-rock-5a.dts` too.
> 

> I would love to help but I'm afraid I device-trees are not something that I am at-all familiar with. That said, I am open to methods of debugging this issue to provide a fix myself.
> 

> I would have replied to the patch's link but unfortunately, I haven't yet setup neomutt and my email provider's web UI doesn't have a [straightforward] way to reply using the 'In-Reply-To' header, hence a new thread. Apologies for the inconvenience caused.
> 

> -- Pratham Patel

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: rock5b-boot.log --]
[-- Type: text/x-log; filename="rock5b-boot.log"; name="rock5b-boot.log", Size: 30299 bytes --]

\x1e\x1en/{24/02/04-10:09:20,fwver: v1.16
LPDDR4X, 2112MHz
channel[0] BW=16 Col=10 Bk=8 CS0 Row=17 CS1 Row=17 CS=2 Die BW=16 Size=4096MB
channel[1] BW=16 Col=10 Bk=8 CS0 Row=17 CS1 Row=17 CS=2 Die BW=16 Size=4096MB
channel[2] BW=16 Col=10 Bk=8 CS0 Row=17 CS1 Row=17 CS=2 Die BW=16 Size=4096MB
channel[3] BW=16 Col=10 Bk=8 CS0 Row=17 CS1 Row=17 CS=2 Die BW=16 Size=4096MB
Manufacturer ID:0xff
CH0 RX Vref:28.9%, TX Vref:21.8%,21.8%
CH1 RX Vref:28.9%, TX Vref:22.8%,23.8%
CH2 RX Vref:27.1%, TX Vref:22.8%,21.8%
CH3 RX Vref:26.7%, TX Vref:22.8%,21.8%
change to F1: 528MHz
change to F2: 1068MHz
change to F3: 1560MHz
change to F0: 2112MHz
out

U-Boot SPL 2024.01 (Jan 08 2024 - 15:37:48 +0000)
Trying to boot from SPI
## Checking hash(es) for config config-1 ... OK
## Checking hash(es) for Image atf-1 ... sha256+ OK
## Checking hash(es) for Image u-boot ... sha256+ OK
## Checking hash(es) for Image fdt-1 ... sha256+ OK
## Checking hash(es) for Image atf-2 ... sha256+ OK
NOTICE:  BL31: v2.10.0	(release):
NOTICE:  BL31: Built : 00:00:00, Jan  1 1980


U-Boot 2024.01 (Jan 08 2024 - 15:37:48 +0000)

Model: Radxa ROCK 5 Model B
DRAM:  16 GiB (effective 15.7 GiB)
Core:  761 devices, 30 uclasses, devicetree: separate
MMC:   mmc@fe2c0000: 1, mmc@fe2d0000: 2, mmc@fe2e0000: 0
Loading Environment from nowhere... OK
In:    serial@feb50000
Out:   serial@feb50000
Err:   serial@feb50000
Model: Radxa ROCK 5 Model B
Net:   No ethernet found.
Hit any key to stop autoboot:  2 \b\b\b 1 \b\b\b 0 
Card did not respond to voltage select! : -110
pcie_dw_rockchip pcie@fe170000: PCIe-4 Link Fail
** Booting bootflow 'nvme#0.blk#1.bootdev.part_1' with efi
^[7^[[r^[[999;999H^[[6n^[8Card did not respond to voltage select! : -110
Card did not respond to voltage select! : -110
Booting /efi\boot\bootaa64.efi
^[[?25l ^[[2J^[[1;1H^[[0;37;40m^[[2J^[[1;1H^[[12;23H^[[0;30;47m   NixOS (Generation 84 NixOS Tapir 23.11.5541.56528ee42526 (Linux 6.7.7), built on 2024-03-23)   ^[[13;23H^[[0;37;40m   NixOS (Generation 83 NixOS Tapir 23.11.5541.56528ee42526 (Linux 6.8.1), built on 2024-03-23)   ^[[14;23H^[[0;37;40m   NixOS (Generation 82 NixOS Tapir 23.11.5511.f091af045dff (Linux 6.8.1), built on 2024-03-22)   ^[[15;23H^[[0;37;40m   NixOS (Generation 81 NixOS Tapir 23.11.5511.f091af045dff (Linux 6.8.1), built on 2024-03-22)   ^[[16;23H^[[0;37;40m   NixOS (Generation 80 NixOS Tapir 23.11.5511.f091af045dff (Linux 6.8.1), built on 2024-03-22)   ^[[17;23H^[[0;37;40m   NixOS (Generation 79 NixOS Tapir 23.11.5511.f091af045dff (Linux 6.8.1), built on 2024-03-22)   ^[[18;23H^[[0;37;40m   NixOS (Generation 78 NixOS Tapir 23.11.5511.f091af045dff (Linux 6.8.1), built on 2024-03-21)   ^[[19;23H^[[0;37;40m   NixOS (Generation 77 NixOS Tapir 23.11.5474.fa9f817df522 (Linux 6.7.8), built on 2024-03-21)   ^[[20;23H^[[0;37;40m   NixOS (Generation 76 NixOS Tapir 23.11.5441.614b4613980a (Linux 6.7.8), built on 2024-03-20)   ^[[21;23H^[[0;37;40m   NixOS (Generation 75 NixOS Tapir 23.11.5441.614b4613980a (Linux 6.7.8), built on 2024-03-20)   ^[[22;23H^[[0;37;40m   NixOS (Generation 74 NixOS Tapir 23.11.5441.614b4613980a (Linux 6.7.8), built on 2024-03-19)   ^[[23;23H^[[0;37;40m   NixOS (Generation 73 NixOS Tapir 23.11.5441.614b4613980a (Linux 6.7.8), built on 2024-03-19)   ^[[24;23H^[[0;37;40m   NixOS (Generation 72 NixOS Tapir 23.11.5441.614b4613980a (Linux 6.7.8), built on 2024-03-19)   ^[[25;23H^[[0;37;40m   NixOS (Generation 71 NixOS Tapir 23.11.5441.614b4613980a (Linux 6.7.8), built on 2024-03-19)   ^[[26;23H^[[0;37;40m   NixOS (Generation 70 NixOS Tapir 23.11.5441.614b4613980a (Linux 6.7.8), built on 2024-03-19)   ^[[27;23H^[[0;37;40m   NixOS (Generation 69 NixOS Tapir 23.11.5441.614b4613980a (Linux 6.7.8), built on 2024-03-18)   ^[[28;23H^[[0;37;40m   NixOS (Generation 68 NixOS Tapir 23.11.5441.614b4613980a (Linux 6.7.8), built on 2024-03-18)   ^[[29;23H^[[0;37;40m   NixOS (Generation 67 NixOS Tapir 23.11.5441.614b4613980a (Linux 6.8.1), built on 2024-03-18)   ^[[30;23H^[[0;37;40m   NixOS (Generation 66 NixOS Tapir 23.11.5441.614b4613980a (Linux 6.8.1), built on 2024-03-18)   ^[[31;23H^[[0;37;40m   NixOS (Generation 65 NixOS Tapir 23.11.5441.614b4613980a (Linux 6.7.8), built on 2024-03-18)   ^[[33;1H^[[0;37;40m                                                                 Boot in 5 s.                                                                 ^[[32;20H^[[0;37;40m────────────────────────────────────────────────────────────────────────────────────────────────────────^[[12;23H^[[0;37;40m   NixOS (Generation 84 NixOS Tapir 23.11.5541.56528ee42526 (Linux 6.7.7), built on 2024-03-23)   ^[[13;23H^[[0;30;47m   NixOS (Generation 83 NixOS Tapir 23.11.5541.56528ee42526 (Linux 6.8.1), built on 2024-03-23)   ^[[32;1H^[[0;37;40m                                                                                                                                               ^[[33;1H^[[0;37;40m                                                                                                                                              ^[[13;23H^[[0;37;40m   NixOS (Generation 83 NixOS Tapir 23.11.5541.56528ee42526 (Linux 6.8.1), built on 2024-03-23)   ^[[14;23H^[[0;30;47m   NixOS (Generation 82 NixOS Tapir 23.11.5511.f091af045dff (Linux 6.8.1), built on 2024-03-22)   ^[[32;1H^[[0;37;40m                                                                                                                                               ^[[33;1H^[[0;37;40m                                                                                                                                              ^[[0;37;40m^[[2J^[[1;1HEFI stub: Booting Linux Kernel...
EFI stub: EFI_RNG_PROTOCOL unavailable
EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services...
[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x412fd050]
[    0.000000] Linux version 6.8.1 (nixbld@localhost) (gcc (GCC) 12.3.0, GNU ld (GNU Binutils) 2.40) #1-NixOS SMP Fri Mar 22 07:27:36 UTC 2024
[    0.000000] KASLR disabled due to lack of seed
[    0.000000] Machine model: Radxa ROCK 5 Model B
[    0.000000] printk: debug: ignoring loglevel setting.
[    0.000000] efi: EFI v2.10 by Das U-Boot
[    0.000000] efi: RTPROP=0xecba2040 SMBIOS=0xecbd6000 INITRD=0xec0bc040 MEMRESERVE=0xec0bb040 
[    0.000000] OF: reserved mem: 0x00000003fc000000..0x00000003fc4fffff (5120 KiB) nomap non-reusable gap1@3,fc000000
[    0.000000] OF: reserved mem: 0x00000003fff00000..0x00000003ffffffff (1024 KiB) nomap non-reusable gap2@3,fff00000
[    0.000000] NUMA: No NUMA configuration found
[    0.000000] NUMA: Faking a node at [mem 0x0000000000200000-0x00000003ffffffff]
[    0.000000] NUMA: NODE_DATA [mem 0x3fdea58c0-0x3fdea8fff]
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x0000000000200000-0x00000000ffffffff]
[    0.000000]   DMA32    empty
[    0.000000]   Normal   [mem 0x0000000100000000-0x00000003ffffffff]
[    0.000000]   Device   empty
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000000200000-0x00000000ecba1fff]
[    0.000000]   node   0: [mem 0x00000000ecba2000-0x00000000ecba2fff]
[    0.000000]   node   0: [mem 0x00000000ecba3000-0x00000000ecba3fff]
[    0.000000]   node   0: [mem 0x00000000ecba4000-0x00000000ecbc5fff]
[    0.000000]   node   0: [mem 0x00000000ecbc6000-0x00000000ecbd5fff]
[    0.000000]   node   0: [mem 0x00000000ecbd6000-0x00000000ecbd6fff]
[    0.000000]   node   0: [mem 0x00000000ecbd7000-0x00000000efefffff]
[    0.000000]   node   0: [mem 0x00000000eff00000-0x00000000eff0ffff]
[    0.000000]   node   0: [mem 0x00000000eff10000-0x00000000efffffff]
[    0.000000]   node   0: [mem 0x0000000100000000-0x00000003fbffffff]
[    0.000000]   node   0: [mem 0x00000003fc000000-0x00000003fc4fffff]
[    0.000000]   node   0: [mem 0x00000003fc500000-0x00000003ffefffff]
[    0.000000]   node   0: [mem 0x00000003fff00000-0x00000003ffffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000000200000-0x00000003ffffffff]
[    0.000000] On node 0, zone DMA: 512 pages in unavailable ranges
[    0.000000] cma: Reserved 32 MiB at 0x00000000ede00000 on node -1
[    0.000000] psci: probing for conduit method from DT.
[    0.000000] psci: PSCIv1.1 detected in firmware.
[    0.000000] psci: Using standard PSCI v0.2 function IDs
[    0.000000] psci: MIGRATE_INFO_TYPE not supported.
[    0.000000] psci: SMC Calling Convention v1.4
[    0.000000] percpu: Embedded 53 pages/cpu s91112 r8192 d117784 u217088
[    0.000000] pcpu-alloc: s91112 r8192 d117784 u217088 alloc=53*4096
[    0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [0] 4 [0] 5 [0] 6 [0] 7 
[    0.000000] Detected VIPT I-cache on CPU0
[    0.000000] CPU features: detected: GIC system register CPU interface
[    0.000000] CPU features: detected: Virtualization Host Extensions
[    0.000000] CPU features: detected: Qualcomm erratum 1009, or ARM erratum 1286807, 2441009
[    0.000000] CPU features: detected: ARM errata 1165522, 1319367, or 1530923
[    0.000000] alternatives: applying boot alternatives
[    0.000000] Kernel command line: initrd=\efi\nixos\pb837bxwkd30cqyh6m9cirkgf81ylmd8-initrd-linux-6.8.1-g488fc7ad2bc8-initrd.efi init=/nix/store/v00aha5h3cm5fi4d5ghm1mz5g4pjyxlv-nixos-system-mahadev-23.11.5511.f091af045dff/init audit=0 ignore_loglevel boot.shell_on_fail fsck.mode=auto fsck.repair=preen plymouth.enable=0 rd.plymouth=0 no_console_suspend loglevel=4 kvm-intel.vmentry_l1d_flush=always
[    0.000000] audit: disabled (until reboot)
[    0.000000] Dentry cache hash table entries: 2097152 (order: 12, 16777216 bytes, linear)
[    0.000000] Inode-cache hash table entries: 1048576 (order: 11, 8388608 bytes, linear)
[    0.000000] Fallback order for Node 0: 0 
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 4063752
[    0.000000] Policy zone: Normal
[    0.000000] mem auto-init: stack:all(zero), heap alloc:off, heap free:off
[    0.000000] software IO TLB: area num 8.
[    0.000000] software IO TLB: mapped [mem 0x00000000e74e0000-0x00000000eb4e0000] (64MB)
[    0.000000] Memory: 16013768K/16513024K available (22272K kernel code, 6394K rwdata, 21480K rodata, 14656K init, 1018K bss, 466488K reserved, 32768K cma-reserved)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=8, Nodes=1
[    0.000000] ftrace: allocating 71385 entries in 279 pages
[    0.000000] ftrace: allocated 279 pages with 5 groups
[    0.000000] trace event string verifier disabled
[    0.000000] rcu: Hierarchical RCU implementation.
[    0.000000] rcu: 	RCU event tracing is enabled.
[    0.000000] rcu: 	RCU restricting CPUs from NR_CPUS=384 to nr_cpu_ids=8.
[    0.000000] 	Rude variant of Tasks RCU enabled.
[    0.000000] 	Tracing variant of Tasks RCU enabled.
[    0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
[    0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=8
[    0.000000] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
[    0.000000] GICv3: GIC: Using split EOI/Deactivate mode
[    0.000000] GICv3: 480 SPIs implemented
[    0.000000] GICv3: 0 Extended SPIs implemented
[    0.000000] GICv3: MBI range [424:479]
[    0.000000] GICv3: Using MBI frame 0x00000000fe610000
[    0.000000] Root IRQ handler: gic_handle_irq
[    0.000000] GICv3: GICv3 features: 16 PPIs
[    0.000000] GICv3: CPU0: found redistributor 0 region 0:0x00000000fe680000
[    0.000000] ITS [mem 0xfe640000-0xfe65ffff]
[    0.000000] GIC: enabling workaround for ITS: Rockchip erratum RK3588001
[    0.000000] ITS@0x00000000fe640000: allocated 8192 Devices @1002d0000 (indirect, esz 8, psz 64K, shr 0)
[    0.000000] ITS@0x00000000fe640000: allocated 32768 Interrupt Collections @1002e0000 (flat, esz 2, psz 64K, shr 0)
[    0.000000] ITS: using cache flushing for cmd queue
[    0.000000] ITS [mem 0xfe660000-0xfe67ffff]
[    0.000000] GIC: enabling workaround for ITS: Rockchip erratum RK3588001
[    0.000000] ITS@0x00000000fe660000: allocated 8192 Devices @100300000 (indirect, esz 8, psz 64K, shr 0)
[    0.000000] ITS@0x00000000fe660000: allocated 32768 Interrupt Collections @100310000 (flat, esz 2, psz 64K, shr 0)
[    0.000000] ITS: using cache flushing for cmd queue
[    0.000000] GICv3: using LPI property table @0x0000000100320000
[    0.000000] GIC: using cache flushing for LPI property table
[    0.000000] GICv3: CPU0: using allocated LPI pending table @0x0000000100330000
[    0.000000] GICv3: GIC: PPI partition interrupt-partition-0[0] { /cpus/cpu@0[0] /cpus/cpu@100[1] /cpus/cpu@200[2] /cpus/cpu@300[3] }
[    0.000000] GICv3: GIC: PPI partition interrupt-partition-1[1] { /cpus/cpu@400[4] /cpus/cpu@500[5] /cpus/cpu@600[6] /cpus/cpu@700[7] }
[    0.000000] rcu: srcu_init: Setting srcu_struct sizes based on contention.
[    0.000000] arch_timer: cp15 timer(s) running at 24.00MHz (phys).
[    0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x588fe9dc0, max_idle_ns: 440795202592 ns
[    0.000000] sched_clock: 56 bits at 24MHz, resolution 41ns, wraps every 4398046511097ns
[    0.006274] Console: colour dummy device 80x25
[    0.006287] printk: legacy console [tty0] enabled
[    0.009265] Calibrating delay loop (skipped), value calculated using timer frequency.. 48.00 BogoMIPS (lpj=96000)
[    0.009298] pid_max: default: 32768 minimum: 301
[    0.013557] LSM: initializing lsm=capability,landlock,yama,bpf,integrity
[    0.018396] landlock: Up and running.
[    0.018413] Yama: becoming mindful.
[    0.018454] LSM support for eBPF active
[    0.019967] Mount-cache hash table entries: 32768 (order: 6, 262144 bytes, linear)
[    0.020033] Mountpoint-cache hash table entries: 32768 (order: 6, 262144 bytes, linear)
[    0.026493] RCU Tasks Rude: Setting shift to 3 and lim to 1 rcu_task_cb_adjust=1.
[    0.026636] RCU Tasks Trace: Setting shift to 3 and lim to 1 rcu_task_cb_adjust=1.
[    0.026994] rcu: Hierarchical SRCU implementation.
[    0.027014] rcu: 	Max phase no-delay instances is 1000.
[    0.028786] Platform MSI: msi-controller@fe640000 domain created
[    0.028825] Platform MSI: msi-controller@fe660000 domain created
[    0.029155] PCI/MSI: /interrupt-controller@fe600000/msi-controller@fe640000 domain created
[    0.029202] PCI/MSI: /interrupt-controller@fe600000/msi-controller@fe660000 domain created
[    0.029534] fsl-mc MSI: msi-controller@fe640000 domain created
[    0.029570] fsl-mc MSI: msi-controller@fe660000 domain created
[    0.039009] Remapping and enabling EFI services.
[    0.039671] smp: Bringing up secondary CPUs ...
[    0.040591] Detected VIPT I-cache on CPU1
[    0.040665] GICv3: CPU1: found redistributor 100 region 0:0x00000000fe6a0000
[    0.040680] GICv3: CPU1: using allocated LPI pending table @0x0000000100340000
[    0.040731] CPU1: Booted secondary processor 0x0000000100 [0x412fd050]
[    0.041704] Detected VIPT I-cache on CPU2
[    0.041772] GICv3: CPU2: found redistributor 200 region 0:0x00000000fe6c0000
[    0.041787] GICv3: CPU2: using allocated LPI pending table @0x0000000100350000
[    0.041832] CPU2: Booted secondary processor 0x0000000200 [0x412fd050]
[    0.042789] Detected VIPT I-cache on CPU3
[    0.042858] GICv3: CPU3: found redistributor 300 region 0:0x00000000fe6e0000
[    0.042872] GICv3: CPU3: using allocated LPI pending table @0x0000000100360000
[    0.042915] CPU3: Booted secondary processor 0x0000000300 [0x412fd050]
[    0.043846] CPU features: detected: Spectre-v4
[    0.043851] CPU features: detected: Spectre-BHB
[    0.043857] Detected PIPT I-cache on CPU4
[    0.043899] GICv3: CPU4: found redistributor 400 region 0:0x00000000fe700000
[    0.043908] GICv3: CPU4: using allocated LPI pending table @0x0000000100370000
[    0.043937] CPU4: Booted secondary processor 0x0000000400 [0x414fd0b0]
[    0.044815] Detected PIPT I-cache on CPU5
[    0.044866] GICv3: CPU5: found redistributor 500 region 0:0x00000000fe720000
[    0.044876] GICv3: CPU5: using allocated LPI pending table @0x0000000100380000
[    0.044906] CPU5: Booted secondary processor 0x0000000500 [0x414fd0b0]
[    0.045889] Detected PIPT I-cache on CPU6
[    0.045937] GICv3: CPU6: found redistributor 600 region 0:0x00000000fe740000
[    0.045947] GICv3: CPU6: using allocated LPI pending table @0x0000000100390000
[    0.045976] CPU6: Booted secondary processor 0x0000000600 [0x414fd0b0]
[    0.046821] Detected PIPT I-cache on CPU7
[    0.046871] GICv3: CPU7: found redistributor 700 region 0:0x00000000fe760000
[    0.046880] GICv3: CPU7: using allocated LPI pending table @0x00000001003a0000
[    0.046909] CPU7: Booted secondary processor 0x0000000700 [0x414fd0b0]
[    0.047032] smp: Brought up 1 node, 8 CPUs
[    0.047326] SMP: Total of 8 processors activated.
[    0.047339] CPU: All CPU(s) started at EL2
[    0.047352] CPU features: detected: 32-bit EL0 Support
[    0.047365] CPU features: detected: Data cache clean to the PoU not required for I/D coherence
[    0.047383] CPU features: detected: Common not Private translations
[    0.047396] CPU features: detected: CRC32 instructions
[    0.047413] CPU features: detected: RCpc load-acquire (LDAPR)
[    0.047427] CPU features: detected: LSE atomic instructions
[    0.047441] CPU features: detected: Privileged Access Never
[    0.047454] CPU features: detected: RAS Extension Support
[    0.047470] CPU features: detected: Speculative Store Bypassing Safe (SSBS)
[    0.047673] alternatives: applying system-wide alternatives
[    0.053944] CPU features: detected: Hardware dirty bit management on CPU4-7
[    0.059766] devtmpfs: initialized
[    0.074402] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
[    0.074422] futex hash table entries: 2048 (order: 5, 131072 bytes, linear)
[    0.076136] pinctrl core: initialized pinctrl subsystem
[    0.078742] SMBIOS 3.0 present.
[    0.078758] DMI: Unknown Unknown Product/Unknown Product, BIOS 2024.01 01/01/2024
[    0.080100] NET: Registered PF_NETLINK/PF_ROUTE protocol family
[    0.081023] DMA: preallocated 2048 KiB GFP_KERNEL pool for atomic allocations
[    0.081356] DMA: preallocated 2048 KiB GFP_KERNEL|GFP_DMA pool for atomic allocations
[    0.081563] DMA: preallocated 2048 KiB GFP_KERNEL|GFP_DMA32 pool for atomic allocations
[    0.082309] thermal_sys: Registered thermal governor 'step_wise'
[    0.082313] thermal_sys: Registered thermal governor 'power_allocator'
[    0.082351] cpuidle: using governor ladder
[    0.082370] cpuidle: using governor menu
[    0.082721] hw-breakpoint: found 6 breakpoint and 4 watchpoint registers.
[    0.082872] ASID allocator initialised with 65536 entries
[    0.085129] Serial: AMBA PL011 UART driver
[    0.110076] gpio gpiochip0: Static allocation of GPIO base is deprecated, use dynamic allocation.
[    0.110401] rockchip-gpio fd8a0000.gpio: probed /pinctrl/gpio@fd8a0000
[    0.110601] gpio gpiochip1: Static allocation of GPIO base is deprecated, use dynamic allocation.
[    0.110720] rockchip-gpio fec20000.gpio: probed /pinctrl/gpio@fec20000
[    0.110885] gpio gpiochip2: Static allocation of GPIO base is deprecated, use dynamic allocation.
[    0.111004] rockchip-gpio fec30000.gpio: probed /pinctrl/gpio@fec30000
[    0.111217] gpio gpiochip3: Static allocation of GPIO base is deprecated, use dynamic allocation.
[    0.111323] rockchip-gpio fec40000.gpio: probed /pinctrl/gpio@fec40000
[    0.111491] gpio gpiochip4: Static allocation of GPIO base is deprecated, use dynamic allocation.
[    0.111597] rockchip-gpio fec50000.gpio: probed /pinctrl/gpio@fec50000
[    0.116146] platform fc000000.usb: Fixed dependency cycle(s) with /i2c@feac0000/usb-typec@22/connector
[    0.117630] platform fed80000.phy: Fixed dependency cycle(s) with /i2c@feac0000/usb-typec@22/connector
[    0.119097] Modules: 16256 pages in range for non-PLT usage
[    0.119102] Modules: 507776 pages in range for PLT usage
[    0.120107] HugeTLB: registered 1.00 GiB page size, pre-allocated 0 pages
[    0.120123] HugeTLB: 0 KiB vmemmap can be freed for a 1.00 GiB page
[    0.120131] HugeTLB: registered 32.0 MiB page size, pre-allocated 0 pages
[    0.120137] HugeTLB: 0 KiB vmemmap can be freed for a 32.0 MiB page
[    0.120144] HugeTLB: registered 2.00 MiB page size, pre-allocated 0 pages
[    0.120150] HugeTLB: 0 KiB vmemmap can be freed for a 2.00 MiB page
[    0.120156] HugeTLB: registered 64.0 KiB page size, pre-allocated 0 pages
[    0.120161] HugeTLB: 0 KiB vmemmap can be freed for a 64.0 KiB page
[    0.123530] fbcon: Taking over console
[    0.123573] ACPI: Interpreter disabled.
[    0.126163] iommu: Default domain type: Translated
[    0.126175] iommu: DMA domain TLB invalidation policy: strict mode
[    0.130680] SCSI subsystem initialized
[    0.130835] libata version 3.00 loaded.
[    0.130979] usbcore: registered new interface driver usbfs
[    0.131004] usbcore: registered new interface driver hub
[    0.131025] usbcore: registered new device driver usb
[    0.132020] pps_core: LinuxPPS API ver. 1 registered
[    0.132027] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[    0.132047] PTP clock support registered
[    0.132168] EDAC MC: Ver: 3.0.0
[    0.132930] scmi_core: SCMI protocol bus registered
[    0.133027] efivars: Registered efivars operations
[    0.134140] FPGA manager framework
[    0.134285] Advanced Linux Sound Architecture Driver Initialized.
[    0.135019] vgaarb: loaded
[    0.135858] clocksource: Switched to clocksource arch_sys_counter
[    0.137405] VFS: Disk quotas dquot_6.6.0
[    0.137567] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    0.137757] netfs: FS-Cache loaded
[    0.137975] pnp: PnP ACPI: disabled
[    0.144988] NET: Registered PF_INET protocol family
[    0.145305] IP idents hash table entries: 262144 (order: 9, 2097152 bytes, linear)
[    0.203655] tcp_listen_portaddr_hash hash table entries: 8192 (order: 5, 131072 bytes, linear)
[    0.203797] Table-perturb hash table entries: 65536 (order: 6, 262144 bytes, linear)
[    0.203840] TCP established hash table entries: 131072 (order: 8, 1048576 bytes, linear)
[    0.204835] TCP bind hash table entries: 65536 (order: 9, 2097152 bytes, linear)
[    0.206727] TCP: Hash tables configured (established 131072 bind 65536)
[    0.207115] MPTCP token hash table entries: 16384 (order: 6, 393216 bytes, linear)
[    0.207315] UDP hash table entries: 8192 (order: 6, 262144 bytes, linear)
[    0.207682] UDP-Lite hash table entries: 8192 (order: 6, 262144 bytes, linear)
[    0.208211] NET: Registered PF_UNIX/PF_LOCAL protocol family
[    0.208778] RPC: Registered named UNIX socket transport module.
[    0.208790] RPC: Registered udp transport module.
[    0.208795] RPC: Registered tcp transport module.
[    0.208801] RPC: Registered tcp-with-tls transport module.
[    0.208806] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    0.208816] NET: Registered PF_XDP protocol family
[    0.208830] PCI: CLS 0 bytes, default 64
[    0.209128] Trying to unpack rootfs image as initramfs...
[    0.216400] kvm [1]: IPA Size Limit: 40 bits
[    0.216429] kvm [1]: GICv3: no GICV resource entry
[    0.216436] kvm [1]: disabling GICv2 emulation
[    0.216456] kvm [1]: GIC system register CPU interface enabled
[    0.216479] kvm [1]: vgic interrupt IRQ18
[    0.216512] kvm [1]: VHE mode initialized successfully
[    0.217603] Initialise system trusted keyrings
[    0.217785] workingset: timestamp_bits=42 max_order=22 bucket_order=0
[    0.217821] zbud: loaded
[    0.222723] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[    0.224044] NFS: Registering the id_resolver key type
[    0.224083] Key type id_resolver registered
[    0.224088] Key type id_legacy registered
[    0.224171] nfs4filelayout_init: NFSv4 File Layout Driver Registering...
[    0.224178] nfs4flexfilelayout_init: NFSv4 Flexfile Layout Driver Registering...
[    0.224284] 9p: Installing v9fs 9p2000 file system support
[    0.263496] Key type asymmetric registered
[    0.263507] Asymmetric key parser 'x509' registered
[    0.263557] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 245)
[    0.263784] io scheduler mq-deadline registered
[    0.263792] io scheduler kyber registered
[    0.286712] EINJ: ACPI disabled.
[    0.301701] dma-pl330 fea10000.dma-controller: Loaded driver for PL330 DMAC-241330
[    0.301720] dma-pl330 fea10000.dma-controller: 	DBUFF-128x8bytes Num_Chans-8 Num_Peri-32 Num_Events-16
[    0.302585] dma-pl330 fea30000.dma-controller: Loaded driver for PL330 DMAC-241330
[    0.302598] dma-pl330 fea30000.dma-controller: 	DBUFF-128x8bytes Num_Chans-8 Num_Peri-32 Num_Events-16
[    0.303432] dma-pl330 fed10000.dma-controller: Loaded driver for PL330 DMAC-241330
[    0.303442] dma-pl330 fed10000.dma-controller: 	DBUFF-128x8bytes Num_Chans-8 Num_Peri-32 Num_Events-16
[    0.314949] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    0.316893] feb50000.serial: ttyS2 at MMIO 0xfeb50000 (irq = 41, base_baud = 1500000) is a 16550A
[    0.317022] printk: legacy console [ttyS2] enabled
[    0.435225] Freeing initrd memory: 9992K
[    0.436255] feb90000.serial: ttyS0 at MMIO 0xfeb90000 (irq = 42, base_baud = 1500000) is a 16550A
[    0.468133] msm_serial: driver initialized
[    0.468868] SuperH (H)SCI(F) driver initialized
[    0.469477] STM32 USART driver initialized
[    0.479642] loop: module loaded
[    0.480709] megasas: 07.727.03.00-rc1
[    0.484940] spi spi2.0: Fixed dependency cycle(s) with /spi@feb20000/pmic@0/regulators/dcdc-reg7
[    0.485747] spi spi2.0: Fixed dependency cycle(s) with /spi@feb20000/pmic@0/dvs3-null-pins
[    0.486475] spi spi2.0: Fixed dependency cycle(s) with /spi@feb20000/pmic@0/dvs2-null-pins
[    0.487203] spi spi2.0: Fixed dependency cycle(s) with /spi@feb20000/pmic@0/dvs1-null-pins
[    0.490237] tun: Universal TUN/TAP device driver, 1.6
[    0.491652] thunder_xcv, ver 1.0
[    0.491965] thunder_bgx, ver 1.0
[    0.492259] nicpf, ver 1.0
[    0.493567] hns3: Hisilicon Ethernet Network Driver for Hip08 Family - version
[    0.494202] hns3: Copyright (c) 2017 Huawei Corporation.
[    0.494682] hclge is initializing
[    0.495002] e1000: Intel(R) PRO/1000 Network Driver
[    0.495430] e1000: Copyright (c) 1999-2006 Intel Corporation.
[    0.495981] e1000e: Intel(R) PRO/1000 Network Driver
[    0.496420] e1000e: Copyright(c) 1999 - 2015 Intel Corporation.
[    0.496969] igb: Intel(R) Gigabit Ethernet Network Driver
[    0.497445] igb: Copyright (c) 2007-2014 Intel Corporation.
[    0.497972] igbvf: Intel(R) Gigabit Virtual Function Network Driver
[    0.498522] igbvf: Copyright (c) 2009 - 2012 Intel Corporation.
[    0.499328] sky2: driver version 1.30
[    0.512741] usbcore: registered new interface driver usb-storage
[    0.515759] i2c_dev: i2c /dev entries driver
[    0.519486] platform fe470000.i2s: Fixed dependency cycle(s) with /i2c@fec90000/audio-codec@11
[    0.519645] fan53555-regulator 0-0042: FAN53555 Option[10] Rev[1] Detected!
[    0.520116] fan53555-regulator 0-0043: FAN53555 Option[10] Rev[1] Detected!
[    0.520284] i2c 3-0011: Fixed dependency cycle(s) with /i2s@fe470000
[   21.583850] rcu: INFO: rcu_sched self-detected stall on CPU
[   21.584347] rcu: 	4-....: (5248 ticks this GP) idle=68ac/1/0x4000000000000000 softirq=22/29 fqs=2625
[   21.585154] rcu: 	(t=5250 jiffies g=-1151 q=98 ncpus=8)
[   21.585618] CPU: 4 PID: 1 Comm: swapper/0 Not tainted 6.8.1 #1-NixOS
[   21.586179] Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2024.01 01/01/2024
[   21.586910] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[   21.587523] pc : smp_call_function_many_cond+0x174/0x5f8
[   21.587999] lr : smp_call_function_many_cond+0x134/0x5f8
[   21.588470] sp : ffff8000840bb810
[   21.588763] x29: ffff8000840bb810 x28: 0000000000000000 x27: 0000000000000005
[   21.589396] x26: ffff0003fde0e7e0 x25: ffff80008393ece0 x24: 0000000000000008
[   21.590027] x23: 0000000000000001 x22: 0000000000000001 x21: ffff0003fddcfd08
[   21.590657] x20: ffff8000839431d8 x19: ffff0003fddcfd00 x18: 0000000000000014
[   21.591288] x17: 00000000bf994921 x16: 000000009a336ddc x15: 00000000013520bf
[   21.591918] x14: 0000000000000000 x13: 0000000000000008 x12: 0101010101010101
[   21.592549] x11: 7f7f7f7f7f7f7f7f x10: ffff8400843d0417 x9 : ffff800080809060
[   21.593179] x8 : ffff0003fddcfd40 x7 : 0000000000000000 x6 : 0000000000000004
[   21.593808] x5 : ffff80008393e000 x4 : 0000000000000005 x3 : ffff0003fde0e7e8
[   21.594438] x2 : 0000000000000000 x1 : 0000000000000011 x0 : 0000000000000005
[   21.595068] Call trace:
[   21.595288]  smp_call_function_many_cond+0x174/0x5f8
[   21.595728]  on_each_cpu_cond_mask+0x2c/0x40
[   21.596109]  cpuidle_register_driver+0x294/0x318
[   21.596524]  cpuidle_register+0x24/0x100
[   21.596875]  psci_cpuidle_probe+0x2e4/0x490
[   21.597247]  platform_probe+0x70/0xd0
[   21.597575]  really_probe+0x18c/0x3d8
[   21.597905]  __driver_probe_device+0x84/0x180
[   21.598294]  driver_probe_device+0x44/0x120
[   21.598669]  __device_attach_driver+0xc4/0x168
[   21.599063]  bus_for_each_drv+0x8c/0xf0
[   21.599408]  __device_attach+0xa4/0x1c0
[   21.599748]  device_initial_probe+0x1c/0x30
[   21.600118]  bus_probe_device+0xb4/0xc0
[   21.600462]  device_add+0x68c/0x888
[   21.600775]  platform_device_add+0x19c/0x270
[   21.601154]  platform_device_register_full+0xdc/0x178
[   21.601602]  psci_idle_init+0xa0/0xc8
[   21.601934]  do_one_initcall+0x60/0x290
[   21.602275]  kernel_init_freeable+0x20c/0x3e0
[   21.602664]  kernel_init+0x2c/0x1f8
[   21.602979]  ret_from_fork+0x10/0x20
[   21.603299] Sending NMI from CPU 4 to CPUs 5:

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]

Re: Fixing the devicetree of Rock 5 Model B (and possibly others)

[Dragan Simic]

Hello Pratham,

On 2024-03-23 18:02, Pratham Patel wrote:
> Since the introduction of the `of: property: fw_devlink: Fix stupid
> bug in remote-endpoint parsing` patch, an issue with the device-tree
> of the Rock 5 Model B has been detected. All the stable kernels (6.7.y
> and 6.8.y) work on the Orange Pi 5, which has the Rockchip RK3588S SoC
> (same as the RK3588, but less I/O basically). So, being an owner of
> only two SBCs which use the RK3588* SoC, it appears that the Rock 5
> Model B's DT is incorrect.
> 
> I looked at the patch and tried several things, neither resulted in
> anything that would point me to the core issue. Then I tried this:

Could you, please, clarify a bit what's the actual issue you're
experiencing on your Rock 5B?

> ```
> $ grep -C 3 remote-endpoint 
> arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts
> 
>                 port {
>                         es8316_p0_0: endpoint {
>                                 remote-endpoint = <&i2s0_8ch_p0_0>;
>                         };
>                 };
>         };
> --
>                 i2s0_8ch_p0_0: endpoint {
>                         dai-format = "i2s";
>                         mclk-fs = <256>;
>                         remote-endpoint = <&es8316_p0_0>;
>                 };
>         };
> };
> ```
> 
> So, from a cursory look, the issue seems to be related to either the
> DT node for the audio codec or related to the es8316's binding itself.
> Though I doubt that the later is the issue because if that were the
> issue, _someone_ with a Pine64 Pinebook Pro would've raised alarms. So
> far, this seems to be related to the `rk3588-rock-5b.dts` and possibly
> with the `rk3588s-rock-5a.dts` too.
> 
> I would **love** to help but I'm afraid I device-trees are not
> something that I am at-all familiar with. That said, I am open to
> methods of debugging this issue to provide a fix myself.
> 
> I would have replied to the patch's link but unfortunately, I haven't
> yet setup neomutt and my email provider's web UI doesn't have a
> [straightforward] way to reply using the 'In-Reply-To' header, hence a
> new thread. Apologies for the inconvenience caused.
> 
>   -- Pratham Patel
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: Fixing the devicetree of Rock 5 Model B (and possibly others)

[Linux regression tracking (Thorsten Leemhuis)]

On 23.03.24 18:02, Pratham Patel wrote:
> Since the introduction of the `of: property: fw_devlink: Fix stupid bug in remote-endpoint parsing` patch,

There is an earlier bug report asking for a revert of that patch:

https://lore.kernel.org/all/ZfvN5jDrftG-YRG4@titan/

> an issue 

Is your problem maybe similar to the one above?

Ciao, Thorsten

> with the device-tree of the Rock 5 Model B has been detected. All the stable kernels (6.7.y and 6.8.y) work on the Orange Pi 5, which has the Rockchip RK3588S SoC (same as the RK3588, but less I/O basically). So, being an owner of only two SBCs which use the RK3588* SoC, it appears that the Rock 5 Model B's DT is incorrect.
> 
> I looked at the patch and tried several things, neither resulted in anything that would point me to the core issue. Then I tried this:
> 
> ```
> $ grep -C 3 remote-endpoint arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts
> 
>                 port {
>                         es8316_p0_0: endpoint {
>                                 remote-endpoint = <&i2s0_8ch_p0_0>;
>                         };
>                 };
>         };
> --
>                 i2s0_8ch_p0_0: endpoint {
>                         dai-format = "i2s";
>                         mclk-fs = <256>;
>                         remote-endpoint = <&es8316_p0_0>;
>                 };
>         };
> };
> ```
> 
> So, from a cursory look, the issue seems to be related to either the DT node for the audio codec or related to the es8316's binding itself. Though I doubt that the later is the issue because if that were the issue, _someone_ with a Pine64 Pinebook Pro would've raised alarms. So far, this seems to be related to the `rk3588-rock-5b.dts` and possibly with the `rk3588s-rock-5a.dts` too.
> 
> I would **love** to help but I'm afraid I device-trees are not something that I am at-all familiar with. That said, I am open to methods of debugging this issue to provide a fix myself.
> 
> I would have replied to the patch's link but unfortunately, I haven't yet setup neomutt and my email provider's web UI doesn't have a [straightforward] way to reply using the 'In-Reply-To' header, hence a new thread. Apologies for the inconvenience caused.
> 
>   -- Pratham Patel

Re: Fixing the devicetree of Rock 5 Model B (and possibly others)

[Pratham Patel]

[-- Attachment #1.1: Type: text/plain, Size: 620 bytes --]

On Saturday, March 23rd, 2024 at 22:47, Linux regression tracking (Thorsten Leemhuis) <regressions@leemhuis.info> wrote:

> 

> 

> On 23.03.24 18:02, Pratham Patel wrote:
> 

> > Since the introduction of the `of: property: fw_devlink: Fix stupid bug in remote-endpoint parsing` patch,
> 

> 

> There is an earlier bug report asking for a revert of that patch:
> 

> https://lore.kernel.org/all/ZfvN5jDrftG-YRG4@titan/
> 

> > an issue
> 

> 

> Is your problem maybe similar to the one above?

I don't get that exact message in the boot log but yes.

> Ciao, Thorsten

 -- Pratham Patel

[-- Attachment #1.2: publickey - prathampatel@thefossguy.com - 0xF2DDE54D.asc --]
[-- Type: application/pgp-keys, Size: 669 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]

Re: Fixing the devicetree of Rock 5 Model B (and possibly others)

[Saravana Kannan]

On Sat, Mar 23, 2024 at 10:10 AM Dragan Simic <dsimic@manjaro.org> wrote:
>
> Hello Pratham,
>
> On 2024-03-23 18:02, Pratham Patel wrote:
> > Since the introduction of the `of: property: fw_devlink: Fix stupid
> > bug in remote-endpoint parsing` patch, an issue with the device-tree
> > of the Rock 5 Model B has been detected. All the stable kernels (6.7.y
> > and 6.8.y) work on the Orange Pi 5, which has the Rockchip RK3588S SoC
> > (same as the RK3588, but less I/O basically). So, being an owner of
> > only two SBCs which use the RK3588* SoC, it appears that the Rock 5
> > Model B's DT is incorrect.
> >
> > I looked at the patch and tried several things, neither resulted in
> > anything that would point me to the core issue. Then I tried this:
>
> Could you, please, clarify a bit what's the actual issue you're
> experiencing on your Rock 5B?

Pratham, can you reply to this please? I don't really understand what
your issue is for me to be able to help.

Also, can you give the output of <debugfs>/devices_deferred for the
good vs bad case?

Thanks,
Saravana

>
> > ```
> > $ grep -C 3 remote-endpoint
> > arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts
> >
> >                 port {
> >                         es8316_p0_0: endpoint {
> >                                 remote-endpoint = <&i2s0_8ch_p0_0>;
> >                         };
> >                 };
> >         };
> > --
> >                 i2s0_8ch_p0_0: endpoint {
> >                         dai-format = "i2s";
> >                         mclk-fs = <256>;
> >                         remote-endpoint = <&es8316_p0_0>;
> >                 };
> >         };
> > };
> > ```
> >
> > So, from a cursory look, the issue seems to be related to either the
> > DT node for the audio codec or related to the es8316's binding itself.
> > Though I doubt that the later is the issue because if that were the
> > issue, _someone_ with a Pine64 Pinebook Pro would've raised alarms. So
> > far, this seems to be related to the `rk3588-rock-5b.dts` and possibly
> > with the `rk3588s-rock-5a.dts` too.
> >
> > I would **love** to help but I'm afraid I device-trees are not
> > something that I am at-all familiar with. That said, I am open to
> > methods of debugging this issue to provide a fix myself.
> >
> > I would have replied to the patch's link but unfortunately, I haven't
> > yet setup neomutt and my email provider's web UI doesn't have a
> > [straightforward] way to reply using the 'In-Reply-To' header, hence a
> > new thread. Apologies for the inconvenience caused.
> >
> >   -- Pratham Patel
> > _______________________________________________
> > Linux-rockchip mailing list
> > Linux-rockchip@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: Fixing the devicetree of Rock 5 Model B (and possibly others)

[Pratham Patel]

On Tue Apr 2, 2024 at 4:54 AM IST, Saravana Kannan wrote:
> On Sat, Mar 23, 2024 at 10:10 AM Dragan Simic <dsimic@manjaro.org> wrote:
> >
> > Hello Pratham,
> >
> > On 2024-03-23 18:02, Pratham Patel wrote:
> > > I looked at the patch and tried several things, neither resulted in
> > > anything that would point me to the core issue. Then I tried this:
> >
> > Could you, please, clarify a bit what's the actual issue you're
> > experiencing on your Rock 5B?
>
> Pratham, can you reply to this please? I don't really understand what
> your issue is for me to be able to help.

Hi,

I apologize for not replying. Somehow, I did not notice the reply from
Dragan. :(

Since this patch was applied, an issue in the Rock 5B's DT has been
unearthed which now results in the kernel being unable to boot properly.

Following is the relevant call trace from the UART capture:

[   21.595068] Call trace:
[   21.595288]  smp_call_function_many_cond+0x174/0x5f8
[   21.595728]  on_each_cpu_cond_mask+0x2c/0x40
[   21.596109]  cpuidle_register_driver+0x294/0x318
[   21.596524]  cpuidle_register+0x24/0x100
[   21.596875]  psci_cpuidle_probe+0x2e4/0x490
[   21.597247]  platform_probe+0x70/0xd0
[   21.597575]  really_probe+0x18c/0x3d8
[   21.597905]  __driver_probe_device+0x84/0x180
[   21.598294]  driver_probe_device+0x44/0x120
[   21.598669]  __device_attach_driver+0xc4/0x168
[   21.599063]  bus_for_each_drv+0x8c/0xf0
[   21.599408]  __device_attach+0xa4/0x1c0
[   21.599748]  device_initial_probe+0x1c/0x30
[   21.600118]  bus_probe_device+0xb4/0xc0
[   21.600462]  device_add+0x68c/0x888
[   21.600775]  platform_device_add+0x19c/0x270
[   21.601154]  platform_device_register_full+0xdc/0x178
[   21.601602]  psci_idle_init+0xa0/0xc8
[   21.601934]  do_one_initcall+0x60/0x290
[   21.602275]  kernel_init_freeable+0x20c/0x3e0
[   21.602664]  kernel_init+0x2c/0x1f8
[   21.602979]  ret_from_fork+0x10/0x20

> 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.

 -- Pratham Patel

Re: Fixing the devicetree of Rock 5 Model B (and possibly others)

[Saravana Kannan]

On Tue, Apr 2, 2024 at 4:32 PM Pratham Patel
<prathampatel@thefossguy.com> wrote:
>
> On Tue Apr 2, 2024 at 4:54 AM IST, Saravana Kannan wrote:
> > On Sat, Mar 23, 2024 at 10:10 AM Dragan Simic <dsimic@manjaro.org> wrote:
> > >
> > > Hello Pratham,
> > >
> > > On 2024-03-23 18:02, Pratham Patel wrote:
> > > > I looked at the patch and tried several things, neither resulted in
> > > > anything that would point me to the core issue. Then I tried this:
> > >
> > > Could you, please, clarify a bit what's the actual issue you're
> > > experiencing on your Rock 5B?
> >
> > Pratham, can you reply to this please? I don't really understand what
> > your issue is for me to be able to help.
>
> Hi,
>
> I apologize for not replying. Somehow, I did not notice the reply from
> Dragan. :(
>
> Since this patch was applied, an issue in the Rock 5B's DT has been
> unearthed which now results in the kernel being unable to boot properly.
>
> Following is the relevant call trace from the UART capture:
>
> [   21.595068] Call trace:
> [   21.595288]  smp_call_function_many_cond+0x174/0x5f8
> [   21.595728]  on_each_cpu_cond_mask+0x2c/0x40
> [   21.596109]  cpuidle_register_driver+0x294/0x318
> [   21.596524]  cpuidle_register+0x24/0x100
> [   21.596875]  psci_cpuidle_probe+0x2e4/0x490
> [   21.597247]  platform_probe+0x70/0xd0
> [   21.597575]  really_probe+0x18c/0x3d8
> [   21.597905]  __driver_probe_device+0x84/0x180
> [   21.598294]  driver_probe_device+0x44/0x120
> [   21.598669]  __device_attach_driver+0xc4/0x168
> [   21.599063]  bus_for_each_drv+0x8c/0xf0
> [   21.599408]  __device_attach+0xa4/0x1c0
> [   21.599748]  device_initial_probe+0x1c/0x30
> [   21.600118]  bus_probe_device+0xb4/0xc0
> [   21.600462]  device_add+0x68c/0x888
> [   21.600775]  platform_device_add+0x19c/0x270
> [   21.601154]  platform_device_register_full+0xdc/0x178
> [   21.601602]  psci_idle_init+0xa0/0xc8
> [   21.601934]  do_one_initcall+0x60/0x290
> [   21.602275]  kernel_init_freeable+0x20c/0x3e0
> [   21.602664]  kernel_init+0x2c/0x1f8
> [   21.602979]  ret_from_fork+0x10/0x20

This doesn't make a lot of sense. "remote-endpoint" shouldn't be
related to anything to do with psci cpuidle. I'm guessing something
else is failing much earlier in boot that's indirectly causing this
somehow? Can you please take a look at what's failing earlier and let
us know? Or see what driver probe is failing up to this point but used
to work in the good case.

Also, where is the dts file that corresponds to this board in upstream? Is it
arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts

>
> > 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.

-Saravana

Re: Fixing the devicetree of Rock 5 Model B (and possibly others)

[Pratham Patel]

On Wed Apr 3, 2024 at 6:16 AM IST, Saravana Kannan wrote:
> On Tue, Apr 2, 2024 at 4:32 PM Pratham Patel
> <prathampatel@thefossguy.com> wrote:
> >
> > On Tue Apr 2, 2024 at 4:54 AM IST, Saravana Kannan wrote:
> > > On Sat, Mar 23, 2024 at 10:10 AM Dragan Simic <dsimic@manjaro.org> wrote:
> > > >
> > > > Hello Pratham,
> > > >
> > > > On 2024-03-23 18:02, Pratham Patel wrote:
> > > > > I looked at the patch and tried several things, neither resulted in
> > > > > anything that would point me to the core issue. Then I tried this:
> > > >
> > > > Could you, please, clarify a bit what's the actual issue you're
> > > > experiencing on your Rock 5B?
> > >
> > > Pratham, can you reply to this please? I don't really understand what
> > > your issue is for me to be able to help.
> >
> > Hi,
> >
> > I apologize for not replying. Somehow, I did not notice the reply from
> > Dragan. :(
> >
> > Since this patch was applied, an issue in the Rock 5B's DT has been
> > unearthed which now results in the kernel being unable to boot properly.
> >
> > Following is the relevant call trace from the UART capture:
> >
> > [   21.595068] Call trace:
> > [   21.595288]  smp_call_function_many_cond+0x174/0x5f8
> > [   21.595728]  on_each_cpu_cond_mask+0x2c/0x40
> > [   21.596109]  cpuidle_register_driver+0x294/0x318
> > [   21.596524]  cpuidle_register+0x24/0x100
> > [   21.596875]  psci_cpuidle_probe+0x2e4/0x490
> > [   21.597247]  platform_probe+0x70/0xd0
> > [   21.597575]  really_probe+0x18c/0x3d8
> > [   21.597905]  __driver_probe_device+0x84/0x180
> > [   21.598294]  driver_probe_device+0x44/0x120
> > [   21.598669]  __device_attach_driver+0xc4/0x168
> > [   21.599063]  bus_for_each_drv+0x8c/0xf0
> > [   21.599408]  __device_attach+0xa4/0x1c0
> > [   21.599748]  device_initial_probe+0x1c/0x30
> > [   21.600118]  bus_probe_device+0xb4/0xc0
> > [   21.600462]  device_add+0x68c/0x888
> > [   21.600775]  platform_device_add+0x19c/0x270
> > [   21.601154]  platform_device_register_full+0xdc/0x178
> > [   21.601602]  psci_idle_init+0xa0/0xc8
> > [   21.601934]  do_one_initcall+0x60/0x290
> > [   21.602275]  kernel_init_freeable+0x20c/0x3e0
> > [   21.602664]  kernel_init+0x2c/0x1f8
> > [   21.602979]  ret_from_fork+0x10/0x20
>
> This doesn't make a lot of sense. "remote-endpoint" shouldn't be
> related to anything to do with psci cpuidle. I'm guessing something
> else is failing much earlier in boot that's indirectly causing this
> somehow? Can you please take a look at what's failing earlier and let
> us know? Or see what driver probe is failing up to this point but used
> to work in the good case.

I'm pretty new to this, "just starting". I'm not sure how to do that,
since the kernel doesn't really "move forward". I will verify if
a8037ceb8964 fixes it or not and get back by the end of this week.

> Also, where is the dts file that corresponds to this board in upstream? Is it
> arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts

Yes.

> >
> > > 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!

 -- Pratham Patel

Re: Fixing the devicetree of Rock 5 Model B (and possibly others)

[Dragan Simic]

Hello Pratham,

On 2024-04-03 01:32, Pratham Patel wrote:
> On Tue Apr 2, 2024 at 4:54 AM IST, Saravana Kannan wrote:
>> On Sat, Mar 23, 2024 at 10:10 AM Dragan Simic <dsimic@manjaro.org> 
>> wrote:
>> > On 2024-03-23 18:02, Pratham Patel wrote:
>> > > I looked at the patch and tried several things, neither resulted in
>> > > anything that would point me to the core issue. Then I tried this:
>> >
>> > Could you, please, clarify a bit what's the actual issue you're
>> > experiencing on your Rock 5B?
>> 
>> Pratham, can you reply to this please? I don't really understand what
>> your issue is for me to be able to help.
> 
> I apologize for not replying. Somehow, I did not notice the reply from
> Dragan. :(

No worries, I saw the serial console log file in one of your messages,
which actually provided the answer to my question. :)

> Since this patch was applied, an issue in the Rock 5B's DT has been
> unearthed which now results in the kernel being unable to boot 
> properly.
> 
> Following is the relevant call trace from the UART capture:
> 
> [   21.595068] Call trace:
> [   21.595288]  smp_call_function_many_cond+0x174/0x5f8
> [   21.595728]  on_each_cpu_cond_mask+0x2c/0x40
> [   21.596109]  cpuidle_register_driver+0x294/0x318
> [   21.596524]  cpuidle_register+0x24/0x100
> [   21.596875]  psci_cpuidle_probe+0x2e4/0x490
> [   21.597247]  platform_probe+0x70/0xd0
> [   21.597575]  really_probe+0x18c/0x3d8
> [   21.597905]  __driver_probe_device+0x84/0x180
> [   21.598294]  driver_probe_device+0x44/0x120
> [   21.598669]  __device_attach_driver+0xc4/0x168
> [   21.599063]  bus_for_each_drv+0x8c/0xf0
> [   21.599408]  __device_attach+0xa4/0x1c0
> [   21.599748]  device_initial_probe+0x1c/0x30
> [   21.600118]  bus_probe_device+0xb4/0xc0
> [   21.600462]  device_add+0x68c/0x888
> [   21.600775]  platform_device_add+0x19c/0x270
> [   21.601154]  platform_device_register_full+0xdc/0x178
> [   21.601602]  psci_idle_init+0xa0/0xc8
> [   21.601934]  do_one_initcall+0x60/0x290
> [   21.602275]  kernel_init_freeable+0x20c/0x3e0
> [   21.602664]  kernel_init+0x2c/0x1f8
> [   21.602979]  ret_from_fork+0x10/0x20
> 
>> 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.

Re: Fixing the devicetree of Rock 5 Model B (and possibly others)

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 1529 bytes --]

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

So it could be one of your downstream patches, which is introducing
this problem.

-- Sebastian

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Fixing the devicetree of Rock 5 Model B (and possibly others)

[Pratham Patel]

On Wednesday, April 3rd, 2024 at 06:33, Pratham Patel <prathampatel@thefossguy.com> wrote:

> 
> 
> On Wed Apr 3, 2024 at 6:16 AM IST, Saravana Kannan wrote:
> 
> > On Tue, Apr 2, 2024 at 4:32 PM Pratham Patel
> > prathampatel@thefossguy.com wrote:
> > 
> > > On Tue Apr 2, 2024 at 4:54 AM IST, Saravana Kannan wrote:
> > > 
> > > > On Sat, Mar 23, 2024 at 10:10 AM Dragan Simic dsimic@manjaro.org wrote:
> > > > 
> > > > > Hello Pratham,
> > > > > 
> > > > > On 2024-03-23 18:02, Pratham Patel wrote:
> > > > > 
> > > > > > I looked at the patch and tried several things, neither resulted in
> > > > > > anything that would point me to the core issue. Then I tried this:
> > > > > 
> > > > > Could you, please, clarify a bit what's the actual issue you're
> > > > > experiencing on your Rock 5B?
> > > > 
> > > > Pratham, can you reply to this please? I don't really understand what
> > > > your issue is for me to be able to help.
> > > 
> > > Hi,
> > > 
> > > I apologize for not replying. Somehow, I did not notice the reply from
> > > Dragan. :(
> > > 
> > > Since this patch was applied, an issue in the Rock 5B's DT has been
> > > unearthed which now results in the kernel being unable to boot properly.
> > > 
> > > Following is the relevant call trace from the UART capture:
> > > 
> > > [ 21.595068] Call trace:
> > > [ 21.595288] smp_call_function_many_cond+0x174/0x5f8
> > > [ 21.595728] on_each_cpu_cond_mask+0x2c/0x40
> > > [ 21.596109] cpuidle_register_driver+0x294/0x318
> > > [ 21.596524] cpuidle_register+0x24/0x100
> > > [ 21.596875] psci_cpuidle_probe+0x2e4/0x490
> > > [ 21.597247] platform_probe+0x70/0xd0
> > > [ 21.597575] really_probe+0x18c/0x3d8
> > > [ 21.597905] __driver_probe_device+0x84/0x180
> > > [ 21.598294] driver_probe_device+0x44/0x120
> > > [ 21.598669] __device_attach_driver+0xc4/0x168
> > > [ 21.599063] bus_for_each_drv+0x8c/0xf0
> > > [ 21.599408] __device_attach+0xa4/0x1c0
> > > [ 21.599748] device_initial_probe+0x1c/0x30
> > > [ 21.600118] bus_probe_device+0xb4/0xc0
> > > [ 21.600462] device_add+0x68c/0x888
> > > [ 21.600775] platform_device_add+0x19c/0x270
> > > [ 21.601154] platform_device_register_full+0xdc/0x178
> > > [ 21.601602] psci_idle_init+0xa0/0xc8
> > > [ 21.601934] do_one_initcall+0x60/0x290
> > > [ 21.602275] kernel_init_freeable+0x20c/0x3e0
> > > [ 21.602664] kernel_init+0x2c/0x1f8
> > > [ 21.602979] ret_from_fork+0x10/0x20
> > 
> > This doesn't make a lot of sense. "remote-endpoint" shouldn't be
> > related to anything to do with psci cpuidle. I'm guessing something
> > else is failing much earlier in boot that's indirectly causing this
> > somehow? Can you please take a look at what's failing earlier and let
> > us know? Or see what driver probe is failing up to this point but used
> > to work in the good case.
> 
> 
> I'm pretty new to this, "just starting". I'm not sure how to do that,
> since the kernel doesn't really "move forward". I will verify if
> a8037ceb8964 fixes it or not and get back by the end of this week.
> 
> > Also, where is the dts file that corresponds to this board in upstream? Is it
> > arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts
> 
> 
> Yes.
> 
> > > > 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.

I confirm that a8037ceb8964 fixed this issue for me. Now, v6.8.2+ boots on my Rock 5B,
with my distro's config and the arm64 defconfig.

 -- Pratham Patel

Re: Fixing the devicetree of Rock 5 Model B (and possibly others)

[Pratham Patel]

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