Re: [PATCH 03/13] ARM: remove riscpc

Hi Daniel,

On Sat, Sep 12, 2026 at 3:29 AM Daniel Palmer [off-list ref] wrote:

On Sat, 12 Sept 2026 at 03:15, Linus Walleij [off-list ref] wrote:

quoted

I would say using generic entry would be a prerequisite for
doing m68k SMP so we don't introduce *more* entry
oddities, but after that I'm game.

I have started this for one part of the m68k tree (68000), but it's
one of those things that is hard/frustrating to test on real hardware.

Pretty cool!

For the last few weeks I've had claude create a QEMU that can boot all
of the m68k supported machines to Linux, Netbsd and their original OS.
It already found this:
https://lore.kernel.org/linux-m68k/20260828094940.3882602-1-daniel@0x0f.com/ (local)

Now we're talking.

quoted

As SoC maintainer I see that m68k has a lot of technical debt
like drivers under arch/m68k and no proper hardware description
(such as device tree)

I have m68k machines using devicetree... :)

quoted

There are things like
amiints.c, cia.c, ataints.c, q40ints.c etc that should be in
drivers/irqchip. So many time.c that should be in
drivers/clocksource/* and many other unmodern things.

Would be easier with devicetree. But is anyone crazy enough to go
through the pain of merging the devicetree support and then arguing
about devicetree bindings for each of those drivers only to be told
m68k should just be removed?

That's conflating two completely different things that think
about themselves as different communities.

Devicetree is in its ambition OS-independent and the fact that
the bindings are all in the Linux git is just a convenience because
that community works well and is dominant.

No device tree maintainer should *ever* complain abot
*any* binding with reference to what Linux supports or
where Linux want to go. Only people not actually working
with device tree would say such things.

Device tree bindings have been deleted but then by the
person who is maintainer of the binding itself, and for
the argument that "no operating system" supports the
platform anymore.

Reviewing and merging m68k bindings should not be
any more problem than any other binding, and it should
not have an impact on Linux support of m68k.

Once you have an emulator that the LLM can operate it can do the
change/build/test/debug cycle all on its own.
With a test harness it can even test the changes work on the real hardware.
But I don't think that's enough to convince people the changes are
worth reviewing/merging.

I will review them. And I do not think the DT maintainers
have anything against m68k.

Yours,
Linus Walleij