Message-ID: <0926eeecfec56fa9225a8aa2a319678a@manjaro.org>
Date: Wed, 03 Apr 2024 15:51:28 +0200
From: Dragan Simic <dsimic@...jaro.org>
To: Pratham Patel <prathampatel@...fossguy.com>
Cc: Saravana Kannan <saravanak@...gle.com>, sebastian.reichel@...labora.com,
 devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
 linux-rockchip@...ts.infradead.org, linux-kernel@...r.kernel.org,
 regressions@...ts.linux.dev, stable@...r.kernel.org
Subject: Re: Fixing the devicetree of Rock 5 Model B (and possibly others)

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@...jaro.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@...90000/usb3-port
> 1-0022  typec_fusb302: cannot register tcpm port
> fc000000.usb    platform: wait for supplier /phy@...80000/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.

Powered by blists - more mailing lists