On Fri, Mar 06, 2020 at 11:23:01AM +0100, Geert Uytterhoeven wrote:
> This reverts commit 175b558d0efb8b4f33aa7bd2c1b5389b912d3019.
>
> When the user configures a kernel without support for Samsung SoCs, it
> makes no sense to ask the user about enabling "Samsung SoC serial
> support", as Samsung serial ports can only be found on Samsung SoCs.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@xxxxxxxxx>
> ---
> drivers/tty/serial/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
> index 880b962015302dca..932ad51099deae7d 100644
> --- a/drivers/tty/serial/Kconfig
> +++ b/drivers/tty/serial/Kconfig
> @@ -237,6 +237,7 @@ config SERIAL_CLPS711X_CONSOLE
>
> config SERIAL_SAMSUNG
> tristate "Samsung SoC serial support"
> + depends on PLAT_SAMSUNG || ARCH_EXYNOS || COMPILE_TEST
> select SERIAL_CORE
> help
> Support for the on-chip UARTs on the Samsung S3C24XX series CPUs,
{sigh}
No, I don't want this. My "goal" is to be able to get rid of all of the
crazy "PLAT_*" symbols as they make it impossible to build a single
kernel that supports multiple ARM64 systems.
As an example of just such a system, see the 5.4 tree here:
https://android.googlesource.com/kernel/common/+/refs/heads/android-5.4
it is now building and booting on multiple SoCs.
But yes, it still does have to enable some PLAT_* config options, but
the goal is to not have to do that eventually.
There is no reason that we need vendor-specific config options just to
lump random drivers into, like serial drivers. If the hardware is not
present, the driver will just not bind to the hardware, and all is fine.
Just like x86, we don't have this issue there, and ARM64 should also not
have this.
Sorry for delay in writing this back to the original thread where you
objected to the original patch, it's still in my review queue along with
a ton of other serial patches.
thanks,
greg k-h
