Hi Dmitry,
On Tue, 25 Apr 2017 10:28:09 -0700, Dmitry Torokhov wrote:
> So this looks like we are dealing with a device designed for a specific
> board, but not architecture or board-specific. Similar to
> atmel_captouch, ims_pcu, or all drivers living in platform/x86 (I
> understand that they do not bother Jean simply because he cares mostly
> about x86 and, with SUSE being generic distro, he needs to enable all
> the drivers there anyway, but a person configuring "their" kernel still
> has to go and consider all options).
Actually they do bother me at times (some of them can't be built as
modules.) Also while I indeed care mostly about x86, openSUSE supports
various other architectures, so I would be equally worried about
x86-specific drivers being proposed on these architectures, for
example. The only difference is that I typically do not catch these
myself.
> 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.
--
Jean Delvare
SUSE L3 Support
--
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
