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] [thread-next>] [day] [month] [year] [list]

Message-ID: <oPAKiBSx5LwKy5573ItMWsN7j3q8rgBZ5epOoaDMVCYXINOBouiT-WBmGnnbZB-WiCTT2CC7lRuqn-YO0Cbtegfqko7Qpzat6Dpfufpf7sc=@thefossguy.com>
Date: Sat, 23 Mar 2024 17:08:49 +0000
From: Pratham Patel <prathampatel@...fossguy.com>
To: "sebastian.reichel@...labora.com" <sebastian.reichel@...labora.com>, "saravanak@...gle.com" <saravanak@...gle.com>
Cc: "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>, "linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>, "linux-rockchip@...ts.infradead.org" <linux-rockchip@...ts.infradead.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "regressions@...ts.linux.dev" <regressions@...ts.linux.dev>, "stable@...r.kernel.org" <stable@...r.kernel.org>
Subject: Re: Fixing the devicetree of Rock 5 Model B (and possibly others)

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@...fossguy.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
View attachment "rock5b-boot.log" of type "text/x-log" (30299 bytes)

Download attachment "signature.asc" of type "application/pgp-signature" (250 bytes)