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
