3.14.52 kernel build fails. due to some implicit declarations in sdhci-pltfm.c any suggestions?

Looking for suggestions as to the right way to fix this problem.

Build info:
My build machine is running Ubuntu 15.10 amd64
I am using the recommended kernel and the following environment for cross compiling:

export CC=/opt/linaro/gcc-linaro-4.9-2014.11-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf- 
export CROSS_COMPILE=${CC} 
export ARCH=arm
export PATH=/opt/linaro/gcc-linaro-4.9-2014.11-x86_64_arm-linux-gnueabihf/bin/:$PATH

I cloned the kernel tree and did git checkout toradex_imx_3.14.52_1.1.0_ga.

Configured the kernel and built with:

make -j4 LOCALVERSION=-${BUILD} LOADADDR=10008000 uImage

Which gave the following error:

drivers/mmc/host/sdhci-pltfm.c: In function 'sdhci_pltfm_suspend':
drivers/mmc/host/sdhci-pltfm.c:246:2: error: implicit declaration of function 'pinctrl_pm_select_sleep_state' [-Werror=implicit-function-declaration]
  pinctrl_pm_select_sleep_state(dev);
  ^
drivers/mmc/host/sdhci-pltfm.c: In function 'sdhci_pltfm_resume':
drivers/mmc/host/sdhci-pltfm.c:256:2: error: implicit declaration of function 'pinctrl_pm_select_default_state' [-Werror=implicit-function-declaration]
  pinctrl_pm_select_default_state(dev);
  ^
cc1: some warnings being treated as errors
scripts/Makefile.build:308: recipe for target 'drivers/mmc/host/sdhci-pltfm.o' failed
make[3]: *** [drivers/mmc/host/sdhci-pltfm.o] Error 1
scripts/Makefile.build:455: recipe for target 'drivers/mmc/host' failed
make[2]: *** [drivers/mmc/host] Error 2
scripts/Makefile.build:455: recipe for target 'drivers/mmc' failed
make[1]: *** [drivers/mmc] Error 2
Makefile:845: recipe for target 'drivers' failed
make: *** [drivers] Error 2
make: *** Waiting for unfinished jobs....
  CC      lib/raid6/int2.o

Found a reference on the web for errors with implicit declarations of pinctrl_pm_select_sleep_state:

From the log I guess wee need the include file:

> "#include "

I tried this which compiled that file and got the same error on another file.

In any case mostly I am wondering if anyone else has seen this?

Also wondering if adding the header is the right thing to do or if this is an indication of a problem with my build system that is showing up in this manner? In which case I need to get an idea of what I do need to fix.

Any suggestions would be greatly appreciated.

Best regards,
Curtis

More info:
After adding that header the next complaint is:

drivers/usb/chipidea/ci_hdrc_imx.c: In function 'ci_hdrc_imx_notify_event':
drivers/usb/chipidea/ci_hdrc_imx.c:264:4: error: implicit declaration of function 'pinctrl_select_state' [-Werror=implicit-function-declaration]
    ret = pinctrl_select_state(data->pinctrl,
  data->pinctrl = devm_pinctrl_get(&pdev->dev);
  ^
drivers/usb/chipidea/ci_hdrc_imx.c:408:16: warning: assignment makes pointer from integer without a cast
  data->pinctrl = devm_pinctrl_get(&pdev->dev);
                ^
drivers/us

And after adding the header there I get:

  LD      init/built-in.o
drivers/built-in.o: In function   ci_hdrc_host_resume:
:(.text+0x8d9bc): undefined reference to imx_gpc_mf_request_on
drivers/built-in.o: In function ci_hdrc_host_suspend:
:(.text+0x8dfe4): undefined reference to imx_gpc_mf_request_on
sound/built-in.o: In function snd_dmaengine_pcm_close:
:(.text+0x14cc0): undefined reference to dma_sync_wait_tasklet
Makefile:831: recipe for target 'vmlinux' failed

May I ask why exactly you do not do it as we describe it in the following article on our developer website?

You definitely do not want to point CC to the cross compiler as CC stands for C compiler and usually just points to whatever your distro uses as regular host aka X86 compiler. Plus CC is usually not used as a prefix but rather pointing to the actual binary gcc compiler thereof. I would really advice against defining any such if you do not know exactly what you are doing.

As for the cross compiler itself while gcc 4.9 should still work just fine please note that with Jethro we are actually using gcc 5.2 now as well.

What exactly did you configure your kernel for as to me it all looks just like a complete misconfiguration thereof?

Rest assured that if you indeed proceed as explained in above linked article no further fiddling with any such as you did will be required.

Thanks very much. I looked around to see if the newer GCC was OK/recommended but did not see any notes on the web so I kept with the one I inherited (Note that it is the one the article points to from Linaro). I recently inherited this project and I think you are right about some potential configuration issues.

I have read the article and followed it when I made a 3.10 kernel a few weeks ago. I think the guy that wrote the script I m using was trying to followi that article as well but I see that it diverges a bit in places. But the script does work on 3.10 kernels but not on 3.14.

I’ll change the ‘CC’ and check the script against the article.
I’ll also update the compiler and see where I am at that point in time.
Hopefully something in the script is amiss and is easily solved. I was a little skeptical about needing to fix the headers. This could also be caused by the .config that was used in the project. It is possible that the changes in kernel features between 3.10 and 3.14 results in mis-configuration when I updated the config. Unfortunately I do see a likely cause.

Thanks and best regards

The first issue looks like CONFIG_PM or one of those is missing. Of course sdhci_pltfm_suspend should be properly if’defed in that case…