On Thu, Nov 17, 2016 at 03:10:11PM +0100, Arnd Bergmann wrote: > On Thursday, November 17, 2016 2:53:55 PM CET Lukas Wunner wrote: > > 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? > > I also found that we need "depends on ACPI" because APPLE_PROPERTIES > does "select EFI_DEV_PATH_PARSER" and that requires APCI...
There's a series coming up to power the Thunderbolt controller down when nothing is plugged in and this is done via ACPI. This commit (slated for 4.11) was going to add a dependency on ACPI anyway: https://github.com/l1k/linux/commit/c1f379d5dee4 So adding "depends on ACPI" now would be fine I guess. > > 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? > > We try to avoid adding architecture-specific dependencies that > prevent build testing, and we are adding '|| COMPILE_TEST' to > a lot of drivers for this. We could use 'depends on X86 || > COMPILE_TEST' here, but that wouldn't help the problem on ARM. Yes, "depends on X86 || COMPILE_TEST" sounds like the right thing to do, independently of the build breakage at hand. > Another option would be to use 'depends on APPLE_PROPERTIES || > APPLE_PROPERTIES=n', which would force the thunderbolt driver > to be a loadable module if APPLE_PROPERTIES is one, but otherwise > just allow all configurations. APPLE_PROPERTIES is bool, not tristate, so this would work. However the solution you proposed earlier ("select APPLE_PROPERTIES if (X86 && EFI_STUB)") is more explicit and easier to understand, thus seems preferable to me. Thanks! Lukas
