Just a bit of an intuitive (non-recipe) answer: When you configure a kernel with something like the make target “tegra_defconfig” you are setting up a basic configuration which a Jetson dev kit would ship with. When you use something like the “menuconfig” make target you instead are accessing individual features (often drivers). If you go to some individual item you find in menuconfig, then typing the letter “n” (meaning “no”), then the feature is disabled. If you type the letter “y”, then the feature is enabled by directly and permanently integrating it into the kernel (installing a new kernel is much different than installing a module…a kernel install is riskier and more invasive than the simple file copy of a module). If you answer by typing the letter “m”, then the feature is enabled as a module format (the easiest and safest way a new feature can be installed).
Do note that not all features or drivers can be in module (“=m”) format, and not all features can be in integrated (“=y”) format. The program “menuconfig” knows what is possible and will not allow you to use “m” or “y” for your answer if the code has not been created for that format. Directly editing a “.config” file without using something like “menuconfig” could break function by setting a format which is not allowed.
Furthermore there may be dependencies. As an example, suppose you were to enable some feature for disk encryption. That feature might require a particular algorithm, and so having “menuconfig” enable that feature might also silently enable the missing algorithm as well.
There are other configuration editors as well, and I like “nconfig”. This is almost the same as “menuconfig”, but it has a symbol search function.
To see the setting of all existing configuration settings on a running Jetson use the file “/proc/config.gz”. One way to see this and browse:
zcat /proc/config.gz | less