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=-3.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no 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 0C834C10F27 for ; Tue, 10 Mar 2020 10:13:07 +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 CF21720637 for ; Tue, 10 Mar 2020 10:13:06 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="WncOR6DG" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CF21720637 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-m68k.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:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=MJCn/K/QknvS68bKtpZiLeculCw8u94aYdDghM+iIiU=; b=WncOR6DGQRCDRy +v9hi45W+DLTSjCsWNe0EbriEZ2004NFXJHp8eFYEDzRxvGzqFQDEoQ4IzItNCOJkOCyG8W5UD4dx EBK5kuTF4i4Bj02A4YucHumm8GT0SaeGznPxYN5yzX+6PQaKnKqzZM2TFN1Z0BVuPUVPeTj6RhMzS 4cA/NYf5Xdc76Sm9XT5MfwHIAXu/UglIcTTjaMkuyf+PDd/XADoBX08sVqDRJYYL3edD+QOYwqJ+y QR1LHH0oGUsK0MOseshpSECRYjMdjPIfqqBenny/vME7n0eiuEtxrk/+AU3t/osMoF6o6eunFkvHD gFN1ARQwLbMVP0xObuLA==; 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 1jBbsn-0002mC-DP; Tue, 10 Mar 2020 10:13:05 +0000 Received: from mail-ot1-f65.google.com ([209.85.210.65]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jBbrV-0001n3-Ba for linux-arm-kernel@lists.infradead.org; Tue, 10 Mar 2020 10:11:48 +0000 Received: by mail-ot1-f65.google.com with SMTP id a9so6375934otl.6 for ; Tue, 10 Mar 2020 03:11:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jCYTtqKtRPChhEMP3SdFyK3zUQ497N5Se4SQbI0RklA=; b=ibOxsz8RqHH4hdcNy1GB9DyjVsi3+TWRhDzxfmLYWSo2FT2IfJse0Yb9VoboHV2fMd JUQsOWEtPR3kNEJXPSCf/YDpw839piZ/zxNRIngzy+FrE6sjrQ4AwrsStckdPZg4NW23 LGIavGQ3aUqQhciyRdVeflzlnUJfVJeaIpDjsr/2TT/N+CG727swB2xH3o1mLGvXblSV GQNstsA7i0M2QNKy8HZxVZtbu4mVDsGJzrKmHtW46KzSlzjgVN9QlKGwu3P9NsulF+Vw dFtRu6TCCEQzblN/PJD94vsKFDH3AsaKUwlc8zsMAPyPpHjOGwdtxSPDWQohBEgPKoXx KB4g== X-Gm-Message-State: ANhLgQ1Itpc949rwyZ5FHPHQdMmelsNp7SLS7nhpNse9WTAISrdfaYTk rex7RL3pzxoLSGBBKfB6BSPzOLJE+NB/KbtpeDg= X-Google-Smtp-Source: ADFU+vssgAzcj0QjNkwqKXMBxmZbVcV4/65kDwlBPN53wWEVCESi0Az4nNTiu33PAlepRYJQFKcqU7lq18xKx1kM570= X-Received: by 2002:a9d:b89:: with SMTP id 9mr16497345oth.297.1583835103460; Tue, 10 Mar 2020 03:11:43 -0700 (PDT) MIME-Version: 1.0 References: <20200306102301.16870-1-geert+renesas@glider.be> In-Reply-To: From: Geert Uytterhoeven Date: Tue, 10 Mar 2020 11:11:32 +0100 Message-ID: Subject: Re: [PATCH] Revert "tty: serial: samsung_tty: build it for any platform" To: Krzysztof Kozlowski X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200310_031145_434874_805BC40F X-CRM114-Status: GOOD ( 20.66 ) 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 , Greg Kroah-Hartman , Kukjin Kim , "open list:SERIAL DRIVERS" , Jiri Slaby , Linux ARM 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 Hi Krzysztof, On Mon, Mar 9, 2020 at 7:09 PM Krzysztof Kozlowski wrote: > .On Fri, 6 Mar 2020 at 11:23, 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(+) > > > > Discussion about removal and then re-adding of PLAT_SAMSUNG and > ARCH_EXYNOS dependencies remind me [1]: "[RFC] Input: tm2-touchkey - > add hardware dependency". > > In both cases the driver is clearly only for Samsung SoC or even for > particular device, although one could argue that touchscreen could be > reused while re-usage of serial IP of SoC is highly unlikely. My > understanding, maybe not correct, of "depends on" syntax is a kernel > source code, building or running dependency. I do not see it as a > hardware dependency. Although Samsung S3C/Exynos serial driver will > not exist outside of Samsung SoC, there is no kernel dependency. > Unless I missed something... The touchscreen is something different: I can easily mount that type of touchscreen on my own board, while I cannot integrate a Samsung serial port on my board, unless I'm using a Samsung SoC. > I understand and agree with concerns mentioned in [1] and in the > thread here, that removal of this "depends on" makes life of > distributions and generic users more difficult. To solve this problem > I was thinking about adding weaker type of dependency. A hint about > hardware dependency. Something like the "imply" is for "select". This > did not happen, therefore I still stand on my understanding of > "depends on" thus I gave positive feedback to Greg's patch. A weak dependency can be expressed using "|| COMPILE_TESTING". <(not so) wild idea> During the past few days, I've been giving this more thought. And I realized we might as well get rid of pci_driver, and just have platform_drivers that match against "pci," (yes, this is what real Open Firmware had in the compatible property, cfr. http://users.telenet.be/geertu/Linux/PPC/pci/ethernetAT4/). That way there would be no longer a build dependency on CONFIG_PCI, and we can drop all "depends on PCI" from driver Kconfig symbols. But would dropping that dependency be welcomed? Perhaps, as "everybody" uses PCI. Now repeat the exercise for Zorro, TURBOchannel, NuBus, Sbus, PCMCIA, ..., and wait for the outcry from Linus suddenly seeing lots of questions about support for hardware he can't possibly have in his machine... Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel