From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 877AEC10DCE for ; Fri, 6 Mar 2020 12:29:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 5E90E2084E for ; Fri, 6 Mar 2020 12:29:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1583497753; bh=d17V1gYzsp+fRg5i888PyT+fPs0MnH0tdgO0t6VHh5c=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=hlTgpf6Fa2VZh6UQrkMQk0bspBI+srMZMVH/WfssbLfktz3Gr15e9GpBBClCLj3qC nXLE9b8uofIO/WTkNIGO8UOGHcv2tKwg3Rev/wK2pbIbydqIOxy8TjbdudFfNFaQ+N CD9E2f/VXAHFrwmYXv5eIPNfgh1ctClc9NlFzFdg= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726299AbgCFM3M (ORCPT ); Fri, 6 Mar 2020 07:29:12 -0500 Received: from mail.kernel.org ([198.145.29.99]:45862 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726194AbgCFM3M (ORCPT ); Fri, 6 Mar 2020 07:29:12 -0500 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id BAB152072A; Fri, 6 Mar 2020 12:29:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1583497752; bh=d17V1gYzsp+fRg5i888PyT+fPs0MnH0tdgO0t6VHh5c=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=t8BQ8YdbCK8NYU8ae8N+ekQAjgvaSQzA7GVKOg+FTl8RTt2VhDRHXrOS8WVRJe5Qs VKqUVw49sgIRfZ+yXYduMabcWYcoW/+Z16RanU9qF4gjAdeZ9POw8jLj/Nyaw+lLN1 d+jW+ooS7YNAzqqMGQgAS8GB1DZJ+4fEGz9EpTWY= Date: Fri, 6 Mar 2020 11:36:52 +0100 From: Greg Kroah-Hartman To: Geert Uytterhoeven Cc: Jiri Slaby , Kukjin Kim , Krzysztof Kozlowski , Bartlomiej Zolnierkiewicz , linux-arm-kernel@lists.infradead.org, linux-samsung-soc@vger.kernel.org, linux-serial@vger.kernel.org Subject: Re: [PATCH] Revert "tty: serial: samsung_tty: build it for any platform" Message-ID: <20200306103652.GA3634389@kroah.com> References: <20200306102301.16870-1-geert+renesas@glider.be> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200306102301.16870-1-geert+renesas@glider.be> Sender: linux-samsung-soc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-samsung-soc@vger.kernel.org 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 > --- > 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A0F02C10F00 for ; Fri, 6 Mar 2020 12:29:17 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 78C2D20848 for ; Fri, 6 Mar 2020 12:29:17 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="GMkemgKK"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="t8BQ8Ydb" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 78C2D20848 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linuxfoundation.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=Hs1B26lesMIvUN7diRFTW8MNAQxVMhc+eSkculzEwgs=; b=GMkemgKKRnyG92 jCKWqHd6hUDKlcUwW1K9qQ7D4lfM1r/Yys7g0DT6iEkv4FhwKlfjXgI8fSiU38m1qjC3Jpa1SRguw plvQahNNSiPLcGxMBIJGG/pyFhafNsaAMDL0rzIv1KnKjOwP1vr6z4e3Gz6i8wwSgn4ITwzGYYxFb 9ZhhkteOK9vUeUlb9vzuhmdBcx+eNfSYHsYZFU198Hzq3m8hFUByCPmnEm3d8Hank0UY7/Msphr67 2wOPBDtsUaFHxY34zclNYYPEpREnjgMhU1iL49XFfg1/03C8VGEMKvzOqi/fpuStL0WLRltXdqhoN 2/AX3OiYdqDD5gRXVi1g==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jAC6O-0007MB-NZ; Fri, 06 Mar 2020 12:29:16 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jAC6K-0007LY-VB for linux-arm-kernel@lists.infradead.org; Fri, 06 Mar 2020 12:29:14 +0000 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id BAB152072A; Fri, 6 Mar 2020 12:29:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1583497752; bh=d17V1gYzsp+fRg5i888PyT+fPs0MnH0tdgO0t6VHh5c=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=t8BQ8YdbCK8NYU8ae8N+ekQAjgvaSQzA7GVKOg+FTl8RTt2VhDRHXrOS8WVRJe5Qs VKqUVw49sgIRfZ+yXYduMabcWYcoW/+Z16RanU9qF4gjAdeZ9POw8jLj/Nyaw+lLN1 d+jW+ooS7YNAzqqMGQgAS8GB1DZJ+4fEGz9EpTWY= Date: Fri, 6 Mar 2020 11:36:52 +0100 From: Greg Kroah-Hartman To: Geert Uytterhoeven Subject: Re: [PATCH] Revert "tty: serial: samsung_tty: build it for any platform" Message-ID: <20200306103652.GA3634389@kroah.com> References: <20200306102301.16870-1-geert+renesas@glider.be> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200306102301.16870-1-geert+renesas@glider.be> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200306_042913_029707_333D5F31 X-CRM114-Status: GOOD ( 20.17 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-samsung-soc@vger.kernel.org, Bartlomiej Zolnierkiewicz , Krzysztof Kozlowski , Kukjin Kim , linux-serial@vger.kernel.org, Jiri Slaby , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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 > --- > 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel