linux-kernel - Re: [PATCH] thunderbolt: fix compile-test dependencies

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]

Date:   Thu, 17 Nov 2016 14:53:55 +0100
From:   Lukas Wunner <lukas@...ner.de>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Andreas Noever <andreas.noever@...il.com>,
        Matt Fleming <matt@...eblueprint.co.uk>,
        Ingo Molnar <mingo@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] thunderbolt: fix compile-test dependencies

On Thu, Nov 17, 2016 at 11:00:31AM +0100, Arnd Bergmann wrote:
> On Tuesday, November 15, 2016 5:21:34 PM CET Lukas Wunner wrote:
> > On Tue, Nov 15, 2016 at 04:58:53PM +0100, Arnd Bergmann wrote:
> > > diff --git a/drivers/thunderbolt/Kconfig b/drivers/thunderbolt/Kconfig
> > > index 0056df7f3c09..4e7d92193b65 100644
> > > --- a/drivers/thunderbolt/Kconfig
> > > +++ b/drivers/thunderbolt/Kconfig
> > > @@ -1,7 +1,8 @@
> > >  menuconfig THUNDERBOLT
> > >  	tristate "Thunderbolt support for Apple devices"
> > > +	depends on (EFI_STUB && X86) || COMPILE_TEST
> > 
> > This addition isn't correct, the thunderbolt driver works without
> > the EFI stub, it just falls back to a hardcoded Device ROM.
> 
> Ok, makes sense.
> 
> I also needed this one though:
> 
> diff --git a/drivers/thunderbolt/Kconfig b/drivers/thunderbolt/Kconfig
> index bb0318ceaf93..de5d27ec67d6 100644
> --- a/drivers/thunderbolt/Kconfig
> +++ b/drivers/thunderbolt/Kconfig
> @@ -1,7 +1,7 @@
>  menuconfig THUNDERBOLT
>  	tristate "Thunderbolt support for Apple devices"
>  	depends on PCI
> -	select APPLE_PROPERTIES if EFI_STUB
> +	select APPLE_PROPERTIES if EFI_STUB && X86
>  	select CRC32
>  	help
>  	  Cactus Ridge Thunderbolt Controller driver
> 
> 
> Without that change, building on ARM with EFI_STUB enabled still
> gives me a build failure.

Hm, so far Thunderbolt is (unfortunately) an Intel proprietary
technology that is only available on x86, so compiling anything
in drivers/thunderbolt/ on other arches doesn't seem to make much
sense.  So maybe a "depends on X86" would be more appropriate?

One could argue that compiling on other arches helps avoid x86-isms
in case Thunderbolt does become available on other arches one day,
then again it seems like an enormous waste of CPU cycles. *shrug*

Opinions?

Thanks,

Lukas