[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMuHMdVC-FUSA5C9aNrvP3=RaRWrchhUEC5UYcSGMz_ep1PEhg@mail.gmail.com>
Date: Sun, 18 Aug 2024 13:08:16 +0200
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Arnd Bergmann <arnd@...nel.org>
Cc: Arnd Bergmann <arnd@...db.de>, kernel test robot <lkp@...el.com>, Greg Ungerer <gerg@...ux-m68k.org>,
linux-m68k@...ts.linux-m68k.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] m68k: move sun3 into a top-level platform option
Hi Arnd,
On Sat, Aug 3, 2024 at 4:01 PM Arnd Bergmann <arnd@...nel.org> wrote:
> From: Arnd Bergmann <arnd@...db.de>
>
> It is possible to select an m68k MMU build but not actually
> enable any of the three MMU options, which then results in a
> build failure:
>
> arch/m68k/include/asm/page.h:10:25: error: 'CONFIG_PAGE_SHIFT' undeclared here (not in a function); did you mean 'CONFIG_LOG_BUF_SHIFT'?
>
> Change the Kconfig selection to ensure that exactly one of the
> three options is always enabled whenever an MMU-enabled kernel
> is built, but moving CONFIG_SUN3 into a top-level option next
> to M68KCLASSIC and COLDFIRE.
>
> All defconfig files should keep working without changes,
> but alldefconfig now builds support for the classic MMU.
>
> Reported-by: kernel test robot <lkp@...el.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202408032138.P7sBvIns-lkp@intel.com/
> Signed-off-by: Arnd Bergmann <arnd@...db.de>
> ---
> I saw another copy of the bug report today.
>
> Geert, any opinions on this approach? I posted this before but
> it looks like you missed it.
I was still thinking about it, and then holidays kicked in...
> --- a/arch/m68k/Kconfig.cpu
> +++ b/arch/m68k/Kconfig.cpu
> @@ -32,13 +32,23 @@ config COLDFIRE
> select HAVE_LEGACY_CLK
> select HAVE_PAGE_SIZE_8KB if !MMU
>
> -endchoice
> +config SUN3
> + bool "Sun3 support"
> + depends on MMU
> + select HAVE_ARCH_PFN_VALID
> + select LEGACY_TIMER_TICK
> + select NO_DMA
> + select M68020
> + help
> + This option enables support for the Sun 3 series of workstations
> + (3/50, 3/60, 3/1xx, 3/2xx systems). These use a classic 68020 CPU
> + but the custom memory management unit makes them incompatible with
> + all other classic m68k machines, including Sun 3x.
Yes, it's a good idea to factor out at the top level machines that
need special handling.
However, the name of the choice now sounds a bit odd. Perhaps it should
be changed to "CPU/machine family support"?
Likewise for M68KCLASSIC.
>
> -if M68KCLASSIC
> +endchoice
>
> config M68000
> - def_bool y
> - depends on !MMU
> + def_bool M68KCLASSIC && !MMU
I think this is unrelated, and should be spun-off into a separate patch
to fix the "no CPU type selected" issue?
> select CPU_HAS_NO_BITFIELDS
> select CPU_HAS_NO_CAS
> select CPU_HAS_NO_MULDIV64
> @@ -56,7 +66,8 @@ config M68000
> a paging MMU.
>
> config M68020
> - bool "68020 support"
> + bool "68020 support" if M68KCLASSIC
> + default !(M68030 || M68040 || M68060)
Part of the "no CPU type selected" fix?
> depends on MMU
> select FPU
> select CPU_HAS_ADDRESS_SPACES
You also need:
config M68KFPU_EMU
bool "Math emulation support"
- depends on M68KCLASSIC && FPU
+ depends on (M68KCLASSIC || SUN3) && FPU
> --- a/arch/m68k/kernel/Makefile
> +++ b/arch/m68k/kernel/Makefile
> @@ -5,16 +5,8 @@
>
> extra-y += vmlinux.lds
>
> -obj-$(CONFIG_AMIGA) := head.o
> -obj-$(CONFIG_ATARI) := head.o
> -obj-$(CONFIG_MAC) := head.o
> -obj-$(CONFIG_APOLLO) := head.o
> -obj-$(CONFIG_VME) := head.o
> -obj-$(CONFIG_HP300) := head.o
> -obj-$(CONFIG_Q40) := head.o
> -obj-$(CONFIG_SUN3X) := head.o
> -obj-$(CONFIG_VIRT) := head.o
> -obj-$(CONFIG_SUN3) := sun3-head.o
> +obj-$(CONFIG_M68KCLASSIC) := head.o
> +obj-$(CONFIG_SUN3) := sun3-head.o
Nice cleanup ;-)
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
Powered by blists - more mailing lists