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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMuHMdVSGQNpsy7wtPVDksq01jW3QVRBR=zwmvOYddb1wdfAYw@mail.gmail.com>
Date: Thu, 9 Jan 2025 11:29:21 +0100
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Finn Thain <fthain@...ux-m68k.org>
Cc: Brad Boyer <flar@...andria.com>, Greg Ungerer <gerg@...nel.org>, Daniel Palmer <daniel@...f.com>, 
	linux-m68k@...ts.linux-m68k.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 0/3] m68k goes DT

Hi Finn,

On Mon, Jan 6, 2025 at 11:14 PM Finn Thain <fthain@...ux-m68k.org> wrote:
> 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.)

We can add a wrapper that starts from a basic Amiga/Atari/Mac/... FDT
and extends/modifies that, based on the bootinfo.
Modification can be done using libfdt, even from assembler.
See e.g. arch/arm/boot/compressed/*fdt*.

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

Drivers can easily support both DT and non-DT, assuming they use proper
platform devices.  That means no more MACH_IS_* and *HW_PRESENT()
checks in the drivers themselves, but proper platform data setup
in arch/m68k/<mach>/*.

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

ARM is the classical example.
Until recently, there was code under drivers/staging/board/ to support
mixed DT/non-DT systems, but I don't suggest going that way.
Conversion of SH to DT is still WIP (except for J-Core, which is
DT-only).

The largest initial step is usually irqchip, clocksource, and clock
drivers and DT bindings.  Existing drivers "just" need DT bindings
and DT support.

For e.g. Amiga, the clock driver would be rather simple.
Clocksource is much more complicated, as the timers are provided by
the CIAs, which are really multi-function-devices (MFD), providing
timer, gpio,spi, and irqchip functionalities.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds