linux-kernel - Re: [RFC PATCH 0/3] m68k goes DT

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: <980f40b3-fd1c-74c7-c651-b85040bbd3fc@linux-m68k.org>
Date: Tue, 7 Jan 2025 09:14:30 +1100 (AEDT)
From: Finn Thain <fthain@...ux-m68k.org>
To: Brad Boyer <flar@...andria.com>
cc: Greg Ungerer <gerg@...nel.org>, Daniel Palmer <daniel@...f.com>, 
    geert@...ux-m68k.org, linux-m68k@...ts.linux-m68k.org, 
    linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 0/3] m68k goes DT

On Mon, 6 Jan 2025, Brad Boyer wrote:

> There are a few drivers where we could eliminate complexity and #ifdef 
> trickery if it was all device tree based.

Ideally, yes. But how would we get there from here?

Should the kernel synthesize a device tree from the bootinfo data, so that 
an ideal no-ifdef pmac_zilog could work? (This seems like a maximum bloat 
solution.)

Or should the mac platform abandon bootinfo, and require a new bootloader 
for all kernel releases after device tree adoption? (This seems maximally 
difficult, since it requires simultaneously merging many patches to many 
subsystems, even if the bootloader changes could be done in advance...)

I wonder whether any other architectures have attempted to retrofit device 
tree support (?)