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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <Z6J7NF8AKNHDzwd1lbld1obVJZrKq0UKLSzKVtoL0TmOzpdyM8PRMvel8IUyhwsphxBg1bjku4ZaeQcwMhfKagEM2lRYtMChYv6VNPK5Tvg=@thefossguy.com>
Date: Fri, 05 Apr 2024 08:32:08 +0000
From: Pratham Patel <prathampatel@...fossguy.com>
To: Saravana Kannan <saravanak@...gle.com>
Cc: Dragan Simic <dsimic@...jaro.org>, 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)

On Wednesday, April 3rd, 2024 at 06:33, Pratham Patel <prathampatel@...fossguy.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@...fossguy.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@...jaro.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@...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.
> > 
> > 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