On this day, September  1, 2021, thus sayeth Greg KH:

On Wed, Sep 01, 2021 at 05:34:36PM +0200, Krish Jain wrote:

quoted

Can you tell me why this is the case?

Again, it depends on your kernel configuration file as to what will, or
will not, be built.

If you have some things set as modules, they can be built as a module,
but the ashmem code can not be built as a module, so you would never
build it if you did the above line.

Here, look at this sequence, starting with a tree that does nothing if I
do a simple 'make' in it, as the whole kernel is already built, and
ashmem is enabled in the kernel configuration

$ grep ASHMEM .config
CONFIG_ASHMEM=y
$ make
$

So, let's change the time stamp on the ashmem.c file and see what gets
built if you use the M= option:

$ touch drivers/staging/android/ashmem.c
$ make M=drivers/staging/android
  MODPOST drivers/staging/android/Module.symvers
$

Nothing gets built as ashmem is NOT a module, and M= only builds any
modules in the directory you specified.

But, if you tell make to just build the whole subdirectory, no matter
what the setting is, it will be built:

$ make drivers/staging/android/
  CALL    scripts/checksyscalls.sh
  CALL    scripts/atomic/check-atomics.sh
  DESCEND objtool
  CC      drivers/staging/android/ashmem.o
  AR      drivers/staging/android/built-in.a
$

So that's the difference, "M=" builds modules in that directory, but if
you tell it to build the subdir, everything in there that needs to be
built, will be built.

Be careful about your kernel configuration, that is the key for what
will, and will not, be built.

Ouch...

I want to *really* apologize to you Krish for introducing so much
confusion while you, and apparently I, am still learning. And for your
persistence with seeking the correct answer here Krish.

I did not notice that this could only be build as a built-in object.
Thank you Greg for pointing out my mistake, and I apologize for dragging
this out longer than it had to and the frustration this caused.

It seems I will be reading the documentation again, along with Greg's
book recommendation, "Linux Kernel in a Nutshell" over this merge
window.

Thank you again Krish and Greg
~Bryan