• Arnd Bergmann's avatar
    ARM: omap1: fix !ARCH_OMAP1_ANY link failures · 980a637d
    Arnd Bergmann authored
    While compile-testing randconfig builds for the upcoming boardfile
    removal, I noticed that an earlier patch of mine was completely
    broken, and the introduction of CONFIG_ARCH_OMAP1_ANY only replaced
    one set of build failures with another one, now resulting in
    link failures like
    
    ld: drivers/video/fbdev/omap/omapfb_main.o: in function `omapfb_do_probe':
    drivers/video/fbdev/omap/omapfb_main.c:1703: undefined reference to `omap_set_dma_priority'
    ld: drivers/dma/ti/omap-dma.o: in function `omap_dma_free_chan_resources':
    drivers/dma/ti/omap-dma.c:777: undefined reference to `omap_free_dma'
    drivers/dma/ti/omap-dma.c:1685: undefined reference to `omap_get_plat_info'
    ld: drivers/usb/gadget/udc/omap_udc.o: in function `next_in_dma':
    drivers/usb/gadget/udc/omap_udc.c:820: undefined reference to `omap_get_dma_active_status'
    
    I tried reworking it, but the resulting patch ended up much bigger than
    simply avoiding the original problem of unused-function warnings like
    
    arch/arm/mach-omap1/mcbsp.c:76:30: error: unused variable 'omap1_mcbsp_ops' [-Werror,-Wunused-variable]
    
    As a result, revert the previous fix, and rearrange the code that
    produces warnings to hide them. For mcbsp, the #ifdef check can
    simply be removed as the cpu_is_omapxxx() checks already achieve
    the same result, while in the io.c the easiest solution appears to
    be to merge the common map bits into each soc specific portion.
    This gets cleaned in a nicer way after omap7xx support gets dropped,
    as the remaining SoCs all have the exact same I/O map.
    
    Fixes: 615dce5b ("ARM: omap1: fix build with no SoC selected")
    Cc: stable@vger.kernel.org
    Acked-by: default avatarAaro Koskinen <aaro.koskinen@iki.fi>
    Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
    980a637d
mcbsp.c 7.99 KB