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] [day] [month] [year] [list]

Message-ID: <9cdb0b92-2bd5-6e0e-9a37-571538d79735@linux-m68k.org>
Date: Tue, 14 Jan 2025 11:42:00 +1100 (AEDT)
From: Finn Thain <fthain@...ux-m68k.org>
To: Geert Uytterhoeven <geert@...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


On Thu, 9 Jan 2025, Geert Uytterhoeven wrote:

> On Mon, Jan 6, 2025,Finn Thain 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>/*.
> 

In the case of pmac_zilog, we still have to avoid pmac_call_feature() and 
the macio_dev stuff, so many ifdefs would remain.

If DT compatibility was needed in pmac_zilog in order to port Linux/m68k 
to new hardware (e.g. Mac Classic II) then I'd be in favour of such a 
driver patch. I don't have time to write it though.

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

That's a lot of work. The old drivers would end up being more portable 
when converted to DT, but is there a need for those drivers on new 
platforms?

MVME147 is different in that Daniel is proposing new drivers to support 
boards that are presently unsupported. (Not unlike the hypothetical Mac 
Classic II example I gave.)

Supporting new hardware is good, but any benefit from retro-fitting DT 
onto existing drivers is dubious, if those drivers will only end up being 
used on systems on which they are already being used...