Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
MIME-Version: 1.0
References: <20220518065639.2432213-1-gerg@linux-m68k.org> <20220518065639.2432213-4-gerg@linux-m68k.org>
In-Reply-To: <20220518065639.2432213-4-gerg@linux-m68k.org>
From:   Geert Uytterhoeven <geert@linux-m68k.org>
Date:   Wed, 18 May 2022 11:20:27 +0200
Message-ID: <CAMuHMdWADK4d-OxKYdnRvbtVsGtbZ_+vF2D70S-5hXNt0rqg9w@mail.gmail.com>
Subject: Re: [PATCH 3/3] m68knommu: fix 68000 CPU link with no platform selected
To:     Greg Ungerer <gerg@linux-m68k.org>
Cc:     "Linux/m68k" <linux-m68k@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Arnd Bergmann <arnd@arndb.de>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hi Greg.

On Wed, May 18, 2022 at 8:56 AM Greg Ungerer <gerg@linux-m68k.org> wrote:
> If building for a nommu m68k classic CPU and no platform (board) is
> selected then the final link fails with:
>
>      LD      vmlinux.o
>    m68k-linux-ld: cannot find arch/m68k/kernel/head.o: No such file or directory
>    make: *** [Makefile:1158: vmlinux] Error 1
>
> Not selecting a platform is ok, that is a generic 68000 system build.
> All of the platform selections are for 68328 variants.
>
> The underlying problem is that the CPU config option (CONFIG_M68000)
> ends up not being set, it is currently only selected by one of the
> platform choices.
>
> Change CONFIG_M68000 so that it is always enabled for the nommu m68k
> classic configuration.
>
> Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>

Thanks for your patch!

> --- a/arch/m68k/Kconfig.cpu
> +++ b/arch/m68k/Kconfig.cpu
> @@ -37,7 +37,7 @@ endchoice
>  if M68KCLASSIC
>
>  config M68000
> -       bool
> +       def_bool y

And then the selects can be removed, too, as the symbol is now always
enabled?

I'm wondering how to handle this when another nommu-m68k-classic
platform shows up (again, cfr. the removed 68360 support) , that
would need a different head.S?  Of course that's something to be
solved later...

>         depends on !MMU
>         select CPU_HAS_NO_BITFIELDS
>         select CPU_HAS_NO_CAS

Note that mmu-m68k-classic (e.g. CONFIG_MMU=y + allnonfig) has the
same problem.  That config does need other fixes too.  E.g. I have
a local patch to make sure NR_IRQS is never zero, but never got to
solve the missing head.o problem in an acceptable way.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-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