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

From: Lukas Wunner
Date: Thu Nov 17 2016 - 09:31:00 EST


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