A full build of all kernel modules can be pretty time consuming, not to mention some might not build, or be in conflict with each other. With a clean build (after toolchain is built) taking me 20 minutes or less on a moderate Debian box, I tend to just rebuild. You can also make some guesses about what you might need and select those as modules (<M>)
There is a "build all kernel modules" which I'm about to try for amusement on my 12-core Ryzen 5 box, which normally can build an image with time make -j12 clean download world with my "standard load" plus LuCI in about 4 minutes (ccache enabled).
This, however, does not appear re-select kernel modules that were not previously selected
The sledgehammer of
sed -i -E -e 's/^# (CONFIG_PACKAGE_kmod-[^ ]+) is not set.*$/\1=M/' .config`
(be aware that this will overwrite a symlink to, for example, env/.config, if you are managing config within its own directory)
then running make defconfig to "clean things up" a bit (as the first attempt to build failed) warns me that some can't be modules for some reason
jeff@deb-devel:~/devel/openwrt-tl-wdr4300$ make defconfig
.config:2762:warning: symbol value 'M' invalid for PACKAGE_kmod-cryptodev
.config:2767:warning: symbol value 'M' invalid for PACKAGE_kmod-fs-afs
.config:3187:warning: symbol value 'M' invalid for PACKAGE_kmod-rtc-ds1307
.config:3188:warning: symbol value 'M' invalid for PACKAGE_kmod-rtc-ds1374
.config:3189:warning: symbol value 'M' invalid for PACKAGE_kmod-rtc-ds1672
.config:3190:warning: symbol value 'M' invalid for PACKAGE_kmod-rtc-isl1208
.config:3191:warning: symbol value 'M' invalid for PACKAGE_kmod-rtc-pcf2123
.config:3192:warning: symbol value 'M' invalid for PACKAGE_kmod-rtc-pcf8563
.config:3193:warning: symbol value 'M' invalid for PACKAGE_kmod-rtc-pt7c4338
.config:3194:warning: symbol value 'M' invalid for PACKAGE_kmod-rtc-rs5c372a
#
# configuration written to .config
#
-- back in a bit if/when this finishes
It actually wasn't too bad (6 min vs. 4 min) with ccache enabled for the second run -- that's the "magic" of ccache at work. The first run (or likely any kernel-code changes) was another story.
I'd still pick and choose, rather than the sledgehammer approach.
Note that this has some "interesting" side effects, such as apparently compiling kernels that have nothing to do with the target, perhaps because the drivers for certain devices are "hard tied" to those devices -- make[3] -C package/kernel/mt76 compile