summaryrefslogtreecommitdiff
path: root/drivers/soc/sunxi/Kconfig
diff options
context:
space:
mode:
authorArnd Bergmann <arnd@arndb.de>2016-02-16 15:03:23 (GMT)
committerTomi Valkeinen <tomi.valkeinen@ti.com>2016-03-11 11:37:02 (GMT)
commit13aa38e291bdd4e4018f40dd2f75e464814dcbf3 (patch)
treeff7a296d7807417bd56190769aac7a9095291b4f /drivers/soc/sunxi/Kconfig
parent32ad61951574d011d363694d6037592e99da9421 (diff)
downloadlinux-13aa38e291bdd4e4018f40dd2f75e464814dcbf3.tar.xz
xen kconfig: don't "select INPUT_XEN_KBDDEV_FRONTEND"
The Xen framebuffer driver selects the xen keyboard driver, so the latter will be built-in if XEN_FBDEV_FRONTEND=y. However, when CONFIG_INPUT is a loadable module, this configuration cannot work. On mainline kernels, the symbol will be enabled but not used, while in combination with a patch I have to detect such useless configurations, we get the expected link failure: drivers/input/built-in.o: In function `xenkbd_remove': xen-kbdfront.c:(.text+0x2f0): undefined reference to `input_unregister_device' xen-kbdfront.c:(.text+0x30e): undefined reference to `input_unregister_device' This removes the extra "select", as it just causes more trouble than it helps. In theory, some defconfig file might break if it has XEN_FBDEV_FRONTEND in it but not INPUT_XEN_KBDDEV_FRONTEND. The Kconfig fragment we ship in the kernel (kernel/configs/xen.config) however already enables both, and anyone using an old .config file would keep having both enabled. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Suggested-by: David Vrabel <david.vrabel@citrix.com> Fixes: 36c1132e34bd ("xen kconfig: fix select INPUT_XEN_KBDDEV_FRONTEND") Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Diffstat (limited to 'drivers/soc/sunxi/Kconfig')
0 files changed, 0 insertions, 0 deletions