linux-kernel - Re: Thinking about firmware and hardware description for latest Rockchip platforms

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: <b12103b968cd5817f25deb7277d6054a@manjaro.org>
Date: Wed, 23 Oct 2024 04:46:50 +0200
From: Dragan Simic <dsimic@...jaro.org>
To: Shimrra Shai <shimrrashai@...il.com>
Cc: linux-kernel@...r.kernel.org, linux-rockchip@...ts.infradead.org,
 linux-arm-kernel@...ts.infradead.org
Subject: Re: Thinking about firmware and hardware description for latest
 Rockchip platforms

Hello Shimrra,

On 2024-10-22 18:53, Shimrra Shai wrote:
> Now it would seem, then, that the most straightforward approach would
> be to simply bake a DTB in for the hardware, but the problem is that
> it appears that DTBs are continually revised in kernel development
> even for long-supported chips (e.g. the RK3568 and earlier). And that
> creates the possibility of breaking backward compatibility, so it
> seems there's a chance that if one were to just include a mainline
> .DTB into a firmware package there is no guarantee it will remain
> compatible forever with every future kernel version. And having a
> user have to upgrade firmwares all the time just because new kernels
> came out also seems kind of to defeat the purpose of having a
> firmware-provided HW description.

As you noted already, the DT definitions are fixed and improved
all the time, which is actually great.  However, the backward
compatibility is ensured, because newer kernels are guaranteed
to work with older DTs, which doesn't mean that the board DTs
provided through firmware should become frozen in any way, as
explained further below.

> And to this I can think only of two options. The first would be to
> have a "political change" on the part of the kernel developer team to
> agree to "freeze" in some part the DTBs for these platforms (I also
> seek to work on firmwares for the earlier RK3568 platform and perhaps
> also other RK35xx variants) so that they remain continuously
> backwards-compatible indefinitely. But I am not sure that would be
> something that'd go over well here.

Freezing anything would be simply wrong.  It might look good from
the perspective of having something "stable", which is similar to
how x86_64 firmware works on PC motheboards, but the continual
bugfixes and improvements are actually extremely good, because
they prevent various ARM boards from effectively becoming abandoned,
which is unfortunately rather usual with x86_64 motherboards that
become so "stable" that some nasty firmware bugs are never fixed
and their users are left high and dry.

> So that gives the alternative option, which is to do like on x86
> systems and start to add some form of ACPI support to the entire
> Rockchip driver stack, because the ACPI tables are maintained on the
> firmware side. However, it likely will still require a fair bit of
> back-and-forth here to do the initial establishment of a full
> "standard" of such tables for this kind of setup viz. my discussions
> in an early attempt at this on the I2C subsystem, e.g.:

So, there would be never any updates or fixes to the ACPI tables?
That goes back to the above-mentioned abandonware.