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