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

Hi Pengpeng,

On 25/6/26 16:07, Pengpeng Hou wrote:
> 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 for pointing this out. This is news to me, and looks to only have
been removed in the current 7.2 merge window. I am digging now, but I
believed this still worked before removal and was in fact in use.

Regards
Greg