毫无疑问，这是Linux内核的一个BUG。内核版本是2.6.27.8，将会影响到所有ARM架构。本文所述及的思路、解决方法也都是基于ARM架构的，对其他架构不一定适用！
具体表现为，如果在driver目录下创建了一个新目录，然后在该目录下编写好Kconfig，并在drivers/Kconfig文件中添加了source选项。按道理，内核配置中就应该添加上了这个目录。make menuconfig后就能够找得到。但实际情况确实找不到。更为疯狂的是，即便是把drivers/Kconfig文件胡乱改掉、甚至是删除掉，都不会对内核的配置过程造成任何影响。
因此，我假设，内核在这个时候压根就没有读取drivers/Kconfig，因此删除或者修改该文件对内核配置一点影响都没有。自然，在这个文件中添加的读取自己创建目录下到Kconfig文件，也不会有效果。由内核配置树可见，drivers目录算是顶层目录了。如果这个目录下的Kconfig没有被读取，那么问题肯定出在顶层的Kconfig上。而内核根目录下又没有Kconfig这个文件。那么顶层的Kconfig文件在哪儿呢？
带着这个问题，我检查来内核在执行配置文件的日志输出：
由上面到内容可以分析出：内核（基于ARM架构，下文同）中所有的配置文件，都是由arch/arm/Kconfig包含进去的（其他平台类推，比如x86就是arch/x86/Kconfig）。因此我们打开这个文件，会发现文件中有很多类似下面的代码：
很明显，他们用于将driver下的各个子目录下到Kconfig文件读入。而且同时可以发现，这里把driver下所有的目录都做了source处理。为了防止冲突，就没有处理drivers目录下的Kconfig。这个是可以理解的。因为如果这里处理了子目录，又读取drivers下到Kconfig，就会再次处理drivers下面到子目录，造成前后冲突。
找到这里，就找到了症结所在了。我同时对比了其他的架构，比如x86架构。他们的处理和ARM的不太一样。他们是直接读取的drivers下到Kconfig，而drivers下的子目录，则由drivers下的Kconfig自己去处理。
为什么ARM会这么处理呢？从arch/arm/Kconfig中的内容，我猜测。可能是因为对于某些驱动，ARM架构不支持。为了防止用户误选取，并且尽量不修改drivers下面的内容（很明显，drivers下面的内容ARM架构的开发人员是应当尽量避免整体修改的，因为这些修改会对其他架构造成无法估计到影响）。
问题分析到这里，解决起来自然很简单了。只需要将自己建立的目录下到Kconfig文件通过source命令，在arch/arm/Kconfig即可。