linux-kernel - Re: [PATCH] of: Skip devicetree kunit tests when RISCV+ACPI doesn't populate root node

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: <f5cc4e3e-ef66-7786-f9b5-f9d5f0846386@kernel.org>
Date: Thu, 13 Nov 2025 19:53:07 -0700 (MST)
From: Paul Walmsley <pjw@...nel.org>
To: "Rob Herring (Arm)" <robh@...nel.org>
cc: Guenter Roeck <linux@...ck-us.net>, devicetree@...r.kernel.org, 
    linux-kernel@...r.kernel.org, Han Gao <rabenda.cn@...il.com>, 
    linux-riscv@...ts.infradead.org, Paul Walmsley <pjw@...nel.org>, 
    Saravana Kannan <saravanak@...gle.com>
Subject: Re: [PATCH] of: Skip devicetree kunit tests when RISCV+ACPI doesn't
 populate root node

Hi Rob,

On Wed, 12 Nov 2025, Rob Herring (Arm) wrote:

> I guess the riscv folks don't care about supporting the relevant 
> features either, so I've applied it. Can kicked down the road again.

For the record: we do care.  However, it looks like this problem needs a 
more general solution, something that applies across CPU architectures.  
Lacking that, we might as well have behavior consistent with ARM64 - and 
for its faults, this approach is at least simpler to reason about.

(That's not to say that I don't have some personal opinions about this 
topic.  IMHO, we're missing a canonical Linux kernel way of representing 
device integration data.  The kernel would control how the various random 
device integration data formats are integrated and merged, which should 
sidestep at least some of the problems that we're facing today.  That 
would also give us a reasonable way to store superset data, such as bus 
topology information.  But as for me personally, as you might recall, 
I'm afraid I lost my appetite for trying to drive device data 
improvements during the ARM DT conversion of the late 2000s.)

Sorry for the delay in getting back to you, and that I don't have the 
ability to help further at the moment - 

- Paul