Sometimes, an external module uses exported symbols from
another external module. kbuild needs to have full knowledge of
all symbols to avoid spitting out warnings about undefined
symbols. Three solutions exist for this situation.
NOTE: The method with a top-level kbuild file is recommended
but may be impractical in certain situations.

Use a top-level kbuild file
If you have two modules, foo.ko and bar.ko, where
foo.ko needs symbols from bar.ko, you can use a
common top-level kbuild file so both modules are
compiled in the same build. Consider the following
directory layout:

./foo/ <= contains foo.ko
./bar/ <= contains bar.ko

The top-level kbuild file would then look like:

#./Kbuild (or ./Makefile):
obj-y := foo/ bar/

And executing

$ make -C $KDIR M=$PWD

will then do the expected and compile both modules with
full knowledge of symbols from either module.

Use an extra Module.symvers file
When an external module is built, a Module.symvers file
is generated containing all exported symbols which are
not defined in the kernel. To get access to symbols

from bar.ko, copy the Module.symvers file from the
compilation of bar.ko to the directory where foo.ko is
built. During the module build, kbuild will read the
Module.symvers file in the directory of the external
module, and when the build is finished, a new
Module.symvers file is created containing the sum of
all symbols defined and not part of the kernel.

Use “make” variable KBUILD_EXTRA_SYMBOLS
If it is impractical to copy Module.symvers from
another module, you can assign a space separated list
of files to KBUILD_EXTRA_SYMBOLS in your build file.
These files will be loaded by modpost during the
initialization of its symbol tables.