On Wed, May 3, 2017 at 11:42 AM, Jean Delvare <jdelvare@xxxxxxx> wrote:
>> I am all for adding dependencies for drivers that are parts of
>> particular SoCs (you probably not going to have Broardcom IPROC
>> touchscreen on your x86 device), but external to SoC peripherals is a
>> different story.
>
> I understand that there is no direct relation between this TM2 touchkey
> driver and Exynos as a platform.
>
> My reasoning is as follows: given that at this point this driver is
> only useful on the Samsung TM2 board, it should only be presented to
> users configuring a kernel for that board. Then the question becomes:
> what other kernel option will definitely be enabled on any kernel
> running on that board? As the TM2 is based on an Exynos5433 SoC,
> ARCH_EXYNOS will have to be enabled, so it seems a convenient way to
> limit the visibility of KEYBOARD_TM2_TOUCHKEY.
>
> There are certainly other options that will also be always enabled for
> a TM2 board kernel, but ARCH_EXYNOS seems to be a good choice because
> it is both generic enough that it doesn't need to be changed if a
> variation of the TM2 board is released using a slightly different SoC,
> and specific enough that we will skip the question for most users.
>
> The alternative would be to add another option SAMSUNG_TM2 ("Support for
> the Samsung TM2 board"), just to let KEYBOARD_TM2_TOUCHKEY depend on it,
> but that's really only moving the problem, as there is no point in
> asking people about SAMSUNG_TM2 if they are building a kernel that can't
> support it anyway. And while I agree it would be somewhat cleaner to
> have KEYBOARD_TM2_TOUCHKEY which depends on SAMSUNG_TM2 and SAMSUNG_TM2
> which depends on ARCH_EXYNOS, it also seems overly complex to me for no
> benefit.
>
> Therefore I still believe that making KEYBOARD_TM2_TOUCHKEY depend on
> ARCH_EXYNOS || COMPILE_TEST makes sense from a practical perspective.
As I mentioned at beginning, I limiting unusable options looks worth
adding to the kernel as a new keyword. However dependency is not for
that purpose because this is not a hardware/software dependency. You
need to add something similar to "imply" keyword, but working not for
select statements but for dependencies. I think such new keyword would
be useful not only for Suse kernels but for many others as well.
But if you do not wish to do it right, then please do not go with this
workaround making a hard (static) dependency between some driver and
some ARM architecture.
On the other hand, maybe this particular driver problem for you can be
solved by removing i2c device binding and adding dependency on OF.
Assuming of course, you do not choose OF for your kernels.
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
