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=-4.0 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 CBFACC43445 for ; Fri, 17 Jul 2020 13:55:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B448F207DD for ; Fri, 17 Jul 2020 13:55:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726852AbgGQNzK (ORCPT ); Fri, 17 Jul 2020 09:55:10 -0400 Received: from mout.kundenserver.de ([212.227.17.24]:39399 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726232AbgGQNzI (ORCPT ); Fri, 17 Jul 2020 09:55:08 -0400 Received: from mail-qv1-f52.google.com ([209.85.219.52]) by mrelayeu.kundenserver.de (mreue106 [212.227.15.145]) with ESMTPSA (Nemesis) id 1M27ix-1jyLZL49bF-002Vsh; Fri, 17 Jul 2020 15:55:07 +0200 Received: by mail-qv1-f52.google.com with SMTP id ed14so4261995qvb.2; Fri, 17 Jul 2020 06:55:06 -0700 (PDT) X-Gm-Message-State: AOAM531ODp20DY28PbUj0yWR7rLEccpc5k8Ovz5CcAi35OHgcqR/9gD8 Tvvv1Fy9VKCD9+Zbm+HqK4SdN4v/sKAQSLPye4g= X-Google-Smtp-Source: ABdhPJx8LtIaLQvziKo3lourUrEUkUS4ZMZUlWIjb/0jYwIJLV5qk1IAswyVggaESYzsgRC5Y1NVn7LRruYETW4HxFQ= X-Received: by 2002:a0c:f802:: with SMTP id r2mr9068143qvn.197.1594994105686; Fri, 17 Jul 2020 06:55:05 -0700 (PDT) MIME-Version: 1.0 References: <1594164323-14920-1-git-send-email-Anson.Huang@nxp.com> <20200717121436.GA2953399@kroah.com> <20200717132101.GA2984939@kroah.com> In-Reply-To: <20200717132101.GA2984939@kroah.com> From: Arnd Bergmann Date: Fri, 17 Jul 2020 15:54:49 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 1/3] gpio: mxc: Support module build To: Greg KH Cc: Geert Uytterhoeven , Linus Walleij , Anson Huang , John Stultz , Russell King , Shawn Guo , Sascha Hauer , Sascha Hauer , Fabio Estevam , Catalin Marinas , Will Deacon , Bartosz Golaszewski , "oleksandr.suvorov@toradex.com" , Adam Ford , Andreas Kemnade , "hverkuil-cisco@xs4all.nl" , Bjorn Andersson , Leo Li , Vinod Koul , Linux ARM , "linux-kernel@vger.kernel.org" , "open list:GPIO SUBSYSTEM" , dl-linux-imx , Jon Corbet , Olof Johansson , Kevin Hilman Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:dEZrwx+hzGiTO58D77scQNmTcn4qBOJ4MxH9Pt6/XGIoFsCYPgx 8+8Z4oqNp0EXx8voOmSwoJLPt4yIRYSbema98zXDcFZfv44gguS59RhHC/ya+BWeCtQf/0a 6JHum5COraJZ+48BGLVoiz/b2W/SxC7DRMhVrgkUlhBIk+XN/0UaZWqxAvsA/jrwJLNNtTu u21KH88s+7Z/WD4Y2NvdQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:T+04+9APdXo=:t1jJfhZF3ic/+H9We7UQqy Qv7PMTQSjEKLQ9zt7L9oPnutUjn92bqyPYD3EGItpRVHV8BuVHnJk+knywJI+DQwsnJNfdqR+ 2Dv0/ttH/40MpY8NPGYKnjSPaQG0u7j76oZFyWLM7/hnvdHGyoO1MdD9pbBqYJqsI0nnp50d7 ebBD1424kWkXyko5xVMrr3AnUXte7L9sSkXRK8dCbwzz3L0LbIIJYkxRkRkmunJoCI30TQFT5 A+zWR8QNISc6+S3ZZyTfjUtDVAEVrKzQ8hxioaARllP+++KZvtrOh3Se8e9qeeHJw/ty/zzsz GAl/UOeq4tnZrX1oTmkQ01n3DyGLnMIyxDr5E5FP/Hm5tL1w0nd6OOrZdQ3V/AOgnUt2OWJET qFZcWSlQIH25VVbNOZFFW63AGwWFtS99F9Pi4M4bzLRPyrLQKzXEdG70CTczsqfb78bfgaGy1 8NyZRAzmU+3RQ+RZB0ygTDXTpDnIFF8SP84dopLVQnaHdWgDtNXXFp9/kiYhZTKo96ejesz9b SBBP5+zY02C4JsITREaZUBzlrl/PZBlu0c0snwmFuhKp82EBuU31MjOm+DM83R9WtidiypJl0 EiQKpsb22Oh85iGS1W0nScYAzadPD8Iuk3t9dqRVW/fRkhMsikm/RGMz/Dtj4uah2YqUbmGdd hPUHWRkCkiDqRrHGKjbcwECPRVBt2uPhhKhVb8itKSkJtETIH0Pbqc4M3xGNY/rDw0KCG0z85 aERgimF5OMx5YKbWPb9W0KrsL6o4QWZQfOsON0fzXMIRwpZC1/xfqNXByf6dFn3Lvh3IQUqUL tGmDQLPTzk7SlprMXch4LQU+xA5P4k7WHQkR1ShZj4NIoj1Qu4PQvfWen/LoibFmDzeNC7eeI 6ng9/YWmAETYF/rBDMuSWS6vUDmg0C5chGLA2Z84k0OOO7C2a8RXxiBdz1A7vtNkaApNcLATv 3Mjhgmu1DFrzzpQ8gL2dpKCj23Wzf1Qm1t4yyUYoZzLxxXOJ6+NXc Sender: linux-gpio-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org On Fri, Jul 17, 2020 at 3:21 PM Greg KH wrote: > On Fri, Jul 17, 2020 at 02:27:43PM +0200, Geert Uytterhoeven wrote: > > Hi Greg, > > > > On Fri, Jul 17, 2020 at 2:14 PM Greg KH wrote: > > > Android is just finally pushing vendors to get their code upstream, > > > which is a good thing to see. And building things as a module is an > > > even better thing as now it is finally allowing arm64 systems to be > > > built to support more than one specific hardware platform at runtime. > > > > Can you please stop spreading this FUD? > > For many many SoCs today, this is not true. Their drivers are required > to be built in and will not work as modules, as we are seeing the > patches try to fix. There are two different points here: a) having drivers as loadable modules: I think everyone agrees this is a good thing in general. Having more of them makes smaller kernels, which is good. arm64 is no different from arm32 and powerpc here, and probably a bit better than x86, which requires all platform specific core code (PC, numachip, UV, ScaleMP, ...) to be built-in. b) supporting multiple hardware platforms at runtime: this is totally unrelated to the platform specific drivers being loadable modules. arm64 is a little better here than arm32 and powerpc, which need more than one configuration to support all hardware, about the same as x86 or s390 and much better than most others that have to chose a machine at compile time. > > As I said before, Arm64 kernels have supported more than one specific > > hardware platform at runtime from the beginning of the arm64 port > > (assumed the needed platform support has been enabled in the kernel > > config, of course). > > Even most arm32 kernels support this, since the introduction of the > > CONFIG_ARCH_MULTIPLATFORM option. In fact every recently > > introduced arm32 platform is usually v7, and must conform to this. > > The sole exceptions are very old platforms, and the v4/v5/v6/v7 split > > due to architectural issues (the latter still support clusters of > > platforms in a single kernel). > > I think the confusion here is that this really does not work well, if at > all, on most "high end" SoC chips due to the collection of different > things all of the vendors ship to their customers. This is the work > that is trying to be fixed up here. > > And look at the driver core work for many driver subsystems to be fixed > up just to get a single kernel image to work on multiple platforms. > Just because older ones did it, doesn't mean it actually works today :) Can you give a specific example? The only problem I'm aware of for those SoCs is drivers being outside of the mainline kernel. Clearly having support for loadable modules helps SoC vendors because it allows them to support a new platform with an existing binary kernel by shipping third-party driver modules, but for stuff that is already in mainline, we could in theory support all hardware in a single gigantic binary kernel with no support for loadable modules at all. Arnd 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=-4.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 48BFAC433E0 for ; Fri, 17 Jul 2020 13:58:10 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 12F8720717 for ; Fri, 17 Jul 2020 13:58:10 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="EmPQSAdc" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 12F8720717 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arndb.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+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=merlin.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=J4Vl+MBtqBhSPaPlPH3WlildixXwaoZG6wEPOLKF9Ds=; b=EmPQSAdc8rbyWU8U1G4EV6PF2 U17unAi0NjYp/8Xs0cXvBK8PUIWgFinL2z5wj6ZNFuRlkCBE/5OeHQ6PkrplUkK0tdFXbObG0pogs Dcl9j8l2bSUCOMlHkl7SlsUe00nVVF86g9m8iGkzfWC5FGGy9ScekClpFPFhwTvg5Dlr08S9JpdRL opOKN2LTMfhPAKGMKozu1pkpE6WZzRj8jcUDdnsjcEPcKwR+R+/CSikf36hIBFw1uLfsRXyVZNfX1 ApJ1PNiM/YTaBp8MK+u5ecL1fOnCJ+FUotwdCETlaBLboA4hDwL3wTKr+ERK3TJDcKdxRIdf+jP6s Yotdj/yng==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jwQqq-0003rD-Pa; Fri, 17 Jul 2020 13:56:38 +0000 Received: from mout.kundenserver.de ([212.227.126.131]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jwQpT-00037G-QQ for linux-arm-kernel@lists.infradead.org; Fri, 17 Jul 2020 13:55:13 +0000 Received: from mail-qv1-f50.google.com ([209.85.219.50]) by mrelayeu.kundenserver.de (mreue009 [212.227.15.129]) with ESMTPSA (Nemesis) id 1MnJdE-1kfLt03jGe-00jFpC for ; Fri, 17 Jul 2020 15:55:07 +0200 Received: by mail-qv1-f50.google.com with SMTP id h17so4259278qvr.0 for ; Fri, 17 Jul 2020 06:55:06 -0700 (PDT) X-Gm-Message-State: AOAM530crzhagvNRMubQsbZx7NJSxuQNm+o1o4BGvWIBBHitc4r+qxC+ Fpz+sjJYe7XrUrxhMivEyA93Elm38UqTe3Q3EaE= X-Google-Smtp-Source: ABdhPJx8LtIaLQvziKo3lourUrEUkUS4ZMZUlWIjb/0jYwIJLV5qk1IAswyVggaESYzsgRC5Y1NVn7LRruYETW4HxFQ= X-Received: by 2002:a0c:f802:: with SMTP id r2mr9068143qvn.197.1594994105686; Fri, 17 Jul 2020 06:55:05 -0700 (PDT) MIME-Version: 1.0 References: <1594164323-14920-1-git-send-email-Anson.Huang@nxp.com> <20200717121436.GA2953399@kroah.com> <20200717132101.GA2984939@kroah.com> In-Reply-To: <20200717132101.GA2984939@kroah.com> From: Arnd Bergmann Date: Fri, 17 Jul 2020 15:54:49 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 1/3] gpio: mxc: Support module build To: Greg KH X-Provags-ID: V03:K1:JlqMPelJu81P7XAC0S5YmiGkI/SjAbNrf76xkD2WlRGEMi5s1hn uH2rYTlSNF7oHUTKLSeNSbe3tQ8cflf73ZZuhLa1TyKMRuqt3TU9+KVv18vl24SVNzA5BrZ TNpN/+UA7pmI7xDwnu8QUiVUqr+d0pq0h6mKQG8y/EnSru5PUK53g1KPjoVMxQRnvXBozam cSods4L61Wpdb2h6H7SlQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:BqNEJhK+s/8=:yqRIFqf0akECD0ZfI9KL+h CJQi8xBqdgSPPiDr0JhC4xqgAHT6dsBoeicHJCfTsnfAWK9KjxZoEKf2t5KPeumzN01wJB1lh ONghgdESZmosXRMKcQCn4qlbironoscAA9bjMG0Wv2EzJtAaHesSDvYK5cf1SDnd7sflllK8+ /6cD+DnNZySdV7mQP+ZsC9HYNAXGW2FTgw6kibvrh1DWqUuwGbX3qEMGNd/A4Sd6/1Jd1LGRa ujL2httn7guGZQCqDR5c9zdzKVgA5gG+g69fcm1RXg3twL4X+NLHuoK0jeI1zxB0ejl0tG5IC jXV+JpgUl+6kh+GUFCZ8VlMdruSjOja4TG8/Db0i2V5MP/kOWxMXG8ExoS3ynCErExrdPGGp0 L0YAAB+uQtQvaMhISVcZx2mc0FPdTWW3foZcCKOJpOY2plJWPCoLS906+VFuq2qPAwF+m3snP tTkw3RryJUMMb3PllYIqASazL8XdapQyIAYwyv5fm1hiewGfwVIjWSfZJFwrlLUquidRXspj8 SSdSlQGJdTW3KygjLJmg0ORZYj2zz+SECU+xg2xsrUat/NCfXMxUQqBcr9u0sldKoA3q/SpiG u2KA623Dq8+ttIx8t35O5L19C+fT0FBvzRwmDs6G8k15YLHxIYcDcub38aTMyfzhrV8IVKl5r n20W/2cYVZZO2GUYCHHRyRuWK9FcKJYL9deFPAccAt7qyMdM/Xyw+YeJsuowhQ7vc+gfUQ8mo 2rvzlLQFZLXY7rCuCrRV8JkXSpfINssr6FCQKQmDERUGxYHoIEzxzGJuhWgSVY5PJklIplSeZ XNe7rGea1pNVT5G9sq7OcjdbfIlrUDxx+K8xhw/MYeH+UCkTl/Ts07gFmMqLI3FS6pnhrUuo2 xVE3JgNZwjTyOUu7Qu89SsaUeSCXyVxUThRtGQD4NaDyXDzk7zQ0D/W2KZfVcippW+EqJlL/m bhGvstKUiAq72EV+RDYyBRF0TZjIGzEdbwhD1u4dq5S9xGeJDtjpE X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200717_095512_116676_01C89EBF X-CRM114-Status: GOOD ( 26.91 ) 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: Catalin Marinas , Linus Walleij , Bjorn Andersson , "oleksandr.suvorov@toradex.com" , Fabio Estevam , Anson Huang , Jon Corbet , Will Deacon , Olof Johansson , Russell King , Bartosz Golaszewski , Andreas Kemnade , Geert Uytterhoeven , dl-linux-imx , Sascha Hauer , "open list:GPIO SUBSYSTEM" , John Stultz , Adam Ford , Linux ARM , "linux-kernel@vger.kernel.org" , Leo Li , Vinod Koul , Sascha Hauer , Kevin Hilman , "hverkuil-cisco@xs4all.nl" , Shawn Guo Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Jul 17, 2020 at 3:21 PM Greg KH wrote: > On Fri, Jul 17, 2020 at 02:27:43PM +0200, Geert Uytterhoeven wrote: > > Hi Greg, > > > > On Fri, Jul 17, 2020 at 2:14 PM Greg KH wrote: > > > Android is just finally pushing vendors to get their code upstream, > > > which is a good thing to see. And building things as a module is an > > > even better thing as now it is finally allowing arm64 systems to be > > > built to support more than one specific hardware platform at runtime. > > > > Can you please stop spreading this FUD? > > For many many SoCs today, this is not true. Their drivers are required > to be built in and will not work as modules, as we are seeing the > patches try to fix. There are two different points here: a) having drivers as loadable modules: I think everyone agrees this is a good thing in general. Having more of them makes smaller kernels, which is good. arm64 is no different from arm32 and powerpc here, and probably a bit better than x86, which requires all platform specific core code (PC, numachip, UV, ScaleMP, ...) to be built-in. b) supporting multiple hardware platforms at runtime: this is totally unrelated to the platform specific drivers being loadable modules. arm64 is a little better here than arm32 and powerpc, which need more than one configuration to support all hardware, about the same as x86 or s390 and much better than most others that have to chose a machine at compile time. > > As I said before, Arm64 kernels have supported more than one specific > > hardware platform at runtime from the beginning of the arm64 port > > (assumed the needed platform support has been enabled in the kernel > > config, of course). > > Even most arm32 kernels support this, since the introduction of the > > CONFIG_ARCH_MULTIPLATFORM option. In fact every recently > > introduced arm32 platform is usually v7, and must conform to this. > > The sole exceptions are very old platforms, and the v4/v5/v6/v7 split > > due to architectural issues (the latter still support clusters of > > platforms in a single kernel). > > I think the confusion here is that this really does not work well, if at > all, on most "high end" SoC chips due to the collection of different > things all of the vendors ship to their customers. This is the work > that is trying to be fixed up here. > > And look at the driver core work for many driver subsystems to be fixed > up just to get a single kernel image to work on multiple platforms. > Just because older ones did it, doesn't mean it actually works today :) Can you give a specific example? The only problem I'm aware of for those SoCs is drivers being outside of the mainline kernel. Clearly having support for loadable modules helps SoC vendors because it allows them to support a new platform with an existing binary kernel by shipping third-party driver modules, but for stuff that is already in mainline, we could in theory support all hardware in a single gigantic binary kernel with no support for loadable modules at all. Arnd _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel