linux-kernel - Re: [PATCH] media: staging: davinci_vpfe: disallow building with COMPILE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAK8P3a16nO+1+niZ8XUUoxZsMnrXHsD7ZbxMB_Z=723Ce1cvDw@mail.gmail.com>
Date:   Tue, 5 Mar 2019 09:47:04 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:     Mauro Carvalho Chehab <mchehab@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Mark Brown <broonie@...nel.org>,
        Robin Murphy <robin.murphy@....com>,
        Linux Media Mailing List <linux-media@...r.kernel.org>,
        driverdevel <devel@...verdev.osuosl.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] media: staging: davinci_vpfe: disallow building with COMPILE_TEST

On Tue, Mar 5, 2019 at 9:05 AM Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
> On Mon, Mar 4, 2019 at 9:30 PM Arnd Bergmann <arnd@...db.de> wrote:
> > The driver should really call dm365_isif_setup_pinmux() through a callback,
> > but it runs platform specific code by itself, which never actually compiled:
> >
> > /git/arm-soc/drivers/staging/media/davinci_vpfe/dm365_isif.c:2028:2: error: implicit declaration of function 'davinci_cfg_reg' [-Werror,-Wimplicit-function-declaration]
> >         davinci_cfg_reg(DM365_VIN_CAM_WEN);
> >         ^
> > /git/arm-soc/drivers/staging/media/davinci_vpfe/dm365_isif.c:2028:2: error: this function declaration is not a prototype [-Werror,-Wstrict-prototypes]
> > /git/arm-soc/drivers/staging/media/davinci_vpfe/dm365_isif.c:2028:18: error: use of undeclared identifier 'DM365_VIN_CAM_WEN'
> >         davinci_cfg_reg(DM365_VIN_CAM_WEN);
> >                         ^
> > /git/arm-soc/drivers/staging/media/davinci_vpfe/dm365_isif.c:2029:18: error: use of undeclared identifier 'DM365_VIN_CAM_VD'
> >         davinci_cfg_reg(DM365_VIN_CAM_VD);
> >                         ^
> > /git/arm-soc/drivers/staging/media/davinci_vpfe/dm365_isif.c:2030:18: error: use of undeclared identifier 'DM365_VIN_CAM_HD'
> >         davinci_cfg_reg(DM365_VIN_CAM_HD);
> >                         ^
> > /git/arm-soc/drivers/staging/media/davinci_vpfe/dm365_isif.c:2031:18: error: use of undeclared identifier 'DM365_VIN_YIN4_7_EN'
> >         davinci_cfg_reg(DM365_VIN_YIN4_7_EN);
> >                         ^
> > /git/arm-soc/drivers/staging/media/davinci_vpfe/dm365_isif.c:2032:18: error: use of undeclared identifier 'DM365_VIN_YIN0_3_EN'
> >         davinci_cfg_reg(DM365_VIN_YIN0_3_EN);
> >                         ^
> > 7 errors generated.
>
> Which tree and which config is this?
> This driver compiles fine with m68k/allmodconfig on v5.0?

Ah, thanks for checking, I found the real issue now:

The Makefile contains a nasty hack that makes it work /almost/ everywhere

# Allow building it with COMPILE_TEST on other archs
ifndef CONFIG_ARCH_DAVINCI
ccflags-y += -I $(srctree)/arch/arm/mach-davinci/include/
endif

This is something we probably don't want to do, but it mostly happens to
do the right thing for compile testing. The case I ran into is the rare
exception of arch/arm/mach-omap1, which has a different mach/mux.h
header, so the '#include <mach/mux.h>' in the driver gets the omap
file rather than the davinci file, and then misses the davinci_cfg_reg()
declaration and the macros.

One way to work around this is to pile on to the hack by adding
'depends on !ARCH_OMAP1'. Should we do that, or is there
a better way out? Do we actually still need the staging driver
in addition to the one in drivers/media/platform/davinci ?

       Arnd