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

[Lukas Wunner <lukas@wunner.de>]

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