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

[Linus Walleij]

Hi Daniel,

On Sat, Sep 12, 2026 at 3:29 AM Daniel Palmer <daniel@xxxxxxxx> wrote:
> On Sat, 12 Sept 2026 at 03:15, Linus Walleij <linusw@xxxxxxxxxx> wrote:

> > 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@xxxxxxxx/

Now we're talking.

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