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]
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)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ