On Fri, Feb 07, 2025 at 11:59:58AM +0000, Lorenzo Stoakes wrote: > On Fri, Feb 07, 2025 at 03:24:13AM +0800, kernel test robot wrote: > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master > > head: 808eb958781e4ebb6e9c0962af2e856767e20f45 > > commit: 236ee083f1b9128fd5bd266054c5b8868f803cee [1418/1780] fbdev: have CONFIG_FB_DEFERRED_IO depend on CONFIG_MMU > > config: arm-kismet-CONFIG_FB_DEFERRED_IO-CONFIG_FB_DMAMEM_HELPERS_DEFERRED-0-0 (https://download.01.org/0day-ci/archive/20250207/202502070305.1rGTDnW0-lkp@xxxxxxxxx/config) > > I'm not really sure what a kismet device is or how it's configured or where > on earth this comes from? > > Could somebody on intel test side please clarify? Because you might just > have a broken config here? Hi Lorenzo, kismet is part of kmax [1] by Paul Gazzillo, which checks for unmet dependency bugs in Kconfig specifications due to reverse dependencies overriding direct dependencies. The 0day bot had used it to detect possible dependency issues [2]. And the issue can also be reproduced by running "make ARCH=arm olddefconfig" on the attached .config. Would you mind check again whether the generated .config is a valid one that exposes potential issue? [1] https://github.com/paulgazz/kmax#using-kismet [2] https://lore.kernel.org/oe-kbuild-all/?q=kismet [3] https://download.01.org/0day-ci/archive/20250207/202502070305.1rGTDnW0-lkp@xxxxxxxxx/reproduce > > Thanks! > > > reproduce: (https://download.01.org/0day-ci/archive/20250207/202502070305.1rGTDnW0-lkp@xxxxxxxxx/reproduce) > > > > If you fix the issue in a separate patch/commit (i.e. not just a new version of > > the same patch/commit), kindly add following tags > > | Reported-by: kernel test robot <lkp@xxxxxxxxx> > > | Closes: https://lore.kernel.org/oe-kbuild-all/202502070305.1rGTDnW0-lkp@xxxxxxxxx/ > > > > kismet warnings: (new ones prefixed by >>) > > >> kismet: WARNING: unmet direct dependencies detected for FB_DEFERRED_IO when selected by FB_DMAMEM_HELPERS_DEFERRED > > WARNING: unmet direct dependencies detected for FB_DEFERRED_IO > > Depends on [n]: HAS_IOMEM [=y] && FB_CORE [=y] && MMU [=n] > > Selected by [y]: > > - FB_DMAMEM_HELPERS_DEFERRED [=y] && HAS_IOMEM [=y] && FB_CORE [=y] > > This is a nommu device selecting a feature that absolutely requires an > mmu. Something's broken here. > > I'm not sure pretending an mmu-dependent feature is does not rely on the > mmu is the way to fix this. > > I'm VERY reluctant to add a stub for the function that explicitly relies on > CONFIG_MMU because it'd be very misleading. > > > > > > -- > > 0-DAY CI Kernel Test Service > > https://github.com/intel/lkp-tests/wiki >
