arch/arm/mach-omap2/board-omap3evm.c:684: undefined reference to `usb_nop_xceiv_register'

[Loïc Minier]

Hi

While building linux-linaro-2.6.35.git (58f79bd3126ebf92b965014ee96def47430c7ca2) with the omap (3 + 4) config from people/lool/kernel/linux-linaro-2.6.35-configs.git (693f48ffdae042033589f5251433d19217347c4f) I got:
  LD .tmp_vmlinux1
arch/arm/mach-omap2/built-in.o: In function `omap3_evm_init':
/srv/hudson.dooz.org/home/jobs/linux-linaro-2.6.35/workspace/CONFIG/omap/arch/arm/mach-omap2/board-omap3evm.c:684: undefined reference to `usb_nop_xceiv_register'
make[1]: *** [.tmp_vmlinux1] Error 1

full log: http://hudson.dooz.org/job/linux-linaro-2.6.35/CONFIG=omap/7/console

the NOP_USB_XCEIV config seems to be selected when USB_MUSB_HDRC which is in the omap3_defconfig, but isn't required.

Cheers,

[Loïc Minier (lool)]

Config:
http://hudson.dooz.org/job/linux-linaro-2.6.35-configs/3/artifact/omap.config

[Loïc Minier (lool)]

Hey Amit, mind reviewing this patch?

I can't test it

[Amit Kucheria (amitk)]

I'd submitted a patch for this: https://patchwork.kernel.org/patch/101691/

It was eventually solved a different way IIRC, but the main reason is it is triggered when the OTG drivers are built as modules. You'll have to look for the eventual fix in linux-omap.

Let me know if you can't find it.

[Loïc Minier (lool)]

I can indeed see that I can't unset NOP_USB_XCEIV alone anymore, but setting CONFIG_MACH_OMAP3EVM=y and unsetting CONFIG_USB_MUSB_HDRC fails in a similar way in linux-omap tip:
  LD .tmp_vmlinux1
arch/arm/mach-omap2/built-in.o: In function `omap3_evm_init':
/home/lool/git/linux/tmlind/linux-omap-2.6/arch/arm/mach-omap2/board-omap3evm.c:682: undefined reference to `usb_nop_xceiv_register'
make: *** [.tmp_vmlinux1] Erreur 1

[Loïc Minier (lool)]

Ah my .config is apparently weird in that it has CONFIG_NOP_USB_XCEIV=m.

Setting CONFIG_NOP_USB_XCEIV=y or unsetting CONFIG_NOP_USB_XCEIV altogether builds fine.

[Loïc Minier (lool)]

I'm not sure I understand the USB driver concepts very well, so here is what I understand:
- OMAP (at least 3/4) makes use of two USB subsystems, musb and ehci
- the musb is an otg port and makes use of the otg kernel features
- attached to the OTG controller, there's an USB transceiver
- some boards use a real transceiver, while some others just use the dumb nop-usb-xceiv.c one, which basically does nothing

The three OMAP boards which use the NOP xceiver are 4430sdp, omap4panda, and omap3evm.

Now the boards using the nop-usb-xceiv transceiver want to make sure it's registered before initializing musb, which happens early in board init, so they do:
        usb_nop_xceiv_register();
        usb_musb_init(&musb_board_data);

usb_musb_init() does a platform_device_register() on a "musb_hdrc" device, which I understand basically means "initialize the corresponding module and/or send an uevent to userspace to load the module".

The musb HDRC driver is entirely modular, not specific to OMAP etc. but its Kconfig will:
    select NOP_USB_XCEIV if (ARCH_DAVINCI || MACH_OMAP3EVM || BLACKFIN)

but nothing forces HDRC to be built for the above OMAP boards.

From my reading, it seems board- or arch-specific code is in charge of loading some xceiver; the way the NOP xceiver hooks itself to the musb driver is via its probe function which calls otg_set_transceiver().

One new obvious issue is that the OMAP4 boards are missing from the above "select", so NOP_USB_XCEIV needs to be selected manually; the select case should be expanded for MACH_OMAP_4430SDP and MACH_OMAP4_PANDA.

I see multiple ways to deal with the original issue:
- force nop-xceiv as builtin when building for the above boards; not sure Kconfig allows that
- make nop-xceiv depend on hdrc, but apparently nop-xceiv isn't even musb-specific; doesn't seem sound
- make usb_nop_xceiv_register a no-op when nop-xceiv is built as a module; this seems bogus as the module wont work
- register a nop-xceiv platform device, and when it is loaded, call usb_nop_xceiv_register(), then usb_musb_init()

I'm not sure how to arrange to run code when the nop-xceiv platform device gets loaded, nor how to call into a module provided function though. At least this would allow for this driver to be built as a module for these boards.

[Loïc Minier (lool)]

Hmm I think the usb_nop_xceiv_register() call is useless if there's an explicit platform_device_register() at board init, so that solves one of the two issues.

[warmcat (andy-warmcat)]

Hello Jakub.... there is no TI Landing Team any more.

Please let whoever had the great idea to send these bugs to a nonexistent team know.