[RFC] m68k: stale CONFIG_MTD_UCLINUX still guards ROMFS relocation paths

[Pengpeng Hou]

Hi,

while auditing conditional source paths, I noticed that current m68k source
still has an early boot/data path guarded by CONFIG_MTD_UCLINUX, but that
symbol no longer appears to have a Kconfig provider in current mainline.

The relevant guard is in arch/m68k/68000/head.S:

#if defined(CONFIG_ROMFS_FS) && defined(CONFIG_RAMKERNEL) && \
    defined(CONFIG_MTD_UCLINUX)

That guarded block moves ROMFS data and adjusts _ramstart / __bss_stop
related state.  At the same time, several m68k defconfigs still request
CONFIG_MTD_UCLINUX together with ROMFS support.

A bounded config oracle over representative m68k defconfigs shows that the
final .config drops CONFIG_MTD_UCLINUX because the symbol has no current
provider.  In other words, the source still describes a boot/data world that
the current Kconfig universe cannot realize.

I am not sending a patch yet because the intended repair is a policy question:

1. remove the stale defconfig requests and guarded source path;
2. retarget the guard to a current condition; or
3. restore an arch-local option if this boot path is still intended.

Could you advise which direction is expected for the remaining
CONFIG_MTD_UCLINUX guarded m68k path?

This is static source/config analysis only.  I have not runtime-tested the
affected boards.

Thanks,
Pengpeng