From: Hans de Goede on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/3428#note_2143127655 I noticed this on the fedora-kernel list and I was wondering why we want this on x86_64. More generally speaking IMHO we really must do better with commit messages for these configs changes. In the upstream kernel community we have gotten pretty good in writing proper commit messages explaining not only what is being changed but also why it is being changed. I really wish we would adhere to the same standards for kernel-ark configs commits, rather then having these empty commit message bodies like this one has. I was wondering why CONFIG_CMA itself is enabled on x86_64 in the first place, the redhat/configs/fedora/generic/x86/CONFIG_DMA_CMA file was introduced in commit cebc0b756a6a940b02633dd, which does actually have some contents in its commit message but that says: "Several configurations in ARK and Fedora have changed type (tristate <-> bool) or have started being required by other configured modules. Adjust the Fedora configurations to match the current Rawhide settings and move ARK settings that have changed back to pending for review." So it does in no way explain why CONFIG_CMA was enabled on x86_64 in the first place. And grepping Kconfig files for drivers which depend on or select CMA related Kconfig options finds only when Kconfig option which is relevant on x86_64: CONFIG_FB_HYPERV which with this being an old style fbdev video driver is not enabled in the Fedora or RHEL kernels. So I'm wondering if we should not disable CONFIG_CMA on x86_64 al together instead of enabling CONFIG_DMA_NUMA_CMA. I'll also send a copy of this to the fedora-kernel list for some wider exposure. -- _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue