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 4A352C433DF for ; Mon, 27 Jul 2020 13:43:46 +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 14E0E20775 for ; Mon, 27 Jul 2020 13:43:46 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="cL43Vn3B" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 14E0E20775 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=EKEJidSCFrS2wSRu3Ja8+bUx73QHzIpi2iUP3GYi1A4=; b=cL43Vn3BQ9pk2n3paNxVNZUiO zx0bYZeoFOW20a4ysbXZr4cN7smlGrcaC6+/TONH1v9cFIVanB3tbUARAC9+JseqqTpRaUhl5AgQs WfMqVj828V3Rad3uJ+X0Z0GEB8v8ZzeyuvnK7vawpsfN8fKX4d8CZNd6ReZ32xU1+Q/o80kyqiYYg uxa3iP7GTFkcjCevNPd68T417lLYyrSwbimCNJ5duFwstvATawv3hYI6hwsPVCM6kvp+KAkSq+Sap xm/OVy2WZMfAda0eMolMwamCgmrsQ+wLpuEwRIm/UnJokulr5OxFyeGabSeLEn2NvnOkIMBMkRvj3 ZIlSLlfqg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1k03OH-0007tS-6P; Mon, 27 Jul 2020 13:42:05 +0000 Received: from mout.kundenserver.de ([212.227.17.10]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1k03OE-0007sQ-Ls for linux-arm-kernel@lists.infradead.org; Mon, 27 Jul 2020 13:42:03 +0000 Received: from mail-qk1-f180.google.com ([209.85.222.180]) by mrelayeu.kundenserver.de (mreue107 [212.227.15.145]) with ESMTPSA (Nemesis) id 1MpUpW-1kaE5C2NtU-00pxdc for ; Mon, 27 Jul 2020 15:41:58 +0200 Received: by mail-qk1-f180.google.com with SMTP id l6so15209647qkc.6 for ; Mon, 27 Jul 2020 06:41:58 -0700 (PDT) X-Gm-Message-State: AOAM532LxXO6JE+IouaixoDkd3pvQyMmjsLLJrHCRdDKGO2syyYxwbc+ CvqdMhwD3BedY6u/4mICmwwB0rV2AMQI0b94BTI= X-Google-Smtp-Source: ABdhPJzqySuIuVB3czYYTZfyLd6uhBrv9RKw8ilEdQwRCvqND1MWjmxKJ0rPM4aQhz302ObDF3kYrSDVo+yClkDXAmc= X-Received: by 2002:a37:385:: with SMTP id 127mr21536451qkd.3.1595857317286; Mon, 27 Jul 2020 06:41:57 -0700 (PDT) MIME-Version: 1.0 References: <1595382353-17486-1-git-send-email-Anson.Huang@nxp.com> In-Reply-To: From: Arnd Bergmann Date: Mon, 27 Jul 2020 15:41:41 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH V2 1/4] gpio: mxc: Support module build To: Anson Huang X-Provags-ID: V03:K1:PbLjuUrUtd4sEmu8wOMNJM4w3DGiA/ujp/wdPprWwjsN/f7PfOC gQj4Qbm6zt+6BBx/hAKoAjUebPrLcFX0UYRvK8+VL+JsS91KTYqzGC9bFG4r9TurC73E7+X 5Zuc1EqfVcbfudOiNNk2OJcctLC4es1lfqjln8qnNdc0DMHmdnrGodb/MctUsBZ2ZueEzxn 5RQlf8Za/5l5XZQ4UJzCA== X-UI-Out-Filterresults: notjunk:1;V03:K0:r8hbj/rBie8=:QVq7vqqnRLyDlH3v3jyvMv 9HaDQ6Bn9GVZyuPvquY0qkydC9xQCvVGKSWCOdjF7AUDGU3PMYKGHNkPRKHRuT9bup52tdwp9 XKYhFiKumLu+U1IiuUI9lewBVjheS2XmvC9Wxo0jl20wOtngdAjJAP+X3qI7sTUJbVNN/DHBM 83obPTKc4A9lP1XDkjAhLFcbXQOoEEe95Rig4J4RbKH7QHDDhJD6ttKqpGTuzF+QPToOQ6/eF 8IqTx2tDtXwWIR38vlphoVneSRMgjKcJMKDT3a3ZLF4nHhoSyJzImyUh7Afj7aLHkWrCIqVXB nU60epXsfUKs1eXy84xkV9r7XNahgZaoLqyQsGG6Gj9R6eH3n1AyV0lishhOBjntIupMZc9ZQ 28m3MQ3z/7uh9HmhY6TDAGitAWrccP/1X9HwKUc65nbMg+ILAR74tNNNBrJqfhXvXMjwYX0aw 3GM9tR0WhEZeCozMCuS76snnNtSksprOOCmLAKVfbnyCi2y1XXNHLZlJXKg016EmOasoc0hIJ veX8hwSrdsU4hHOn5qLPmSnTtl7c4g6pzkCQTvqJ1+jiUXyQLO3nZuoTv7zVmJdR+EyDzKbSq DE/2FQ1AM1R1GivpaA4l77HDmIqOv+j3zPEmMqtzSYGIZrRzw27klrqNoQkeEc+DYWuH6N91t VIBXRkjOzXhGVXaX57e7OgSBEguMzZeKWV75ug/oSaV8zeMBnfWXcjqPjGj+xJYofV2GVsKIP VS+isTTjtdA/coNpMzERvNGITjmXDfAq+4SLM8/6exY88qYmj20ZcWedvoRMwq8wBryUqU+ey kGz+6a4V5QoYseIpIH7pKdIMJz79LG/You5jYOfyDYiY1qwQSbKfzVaqiN+og94x/Ulokajt1 3UoMa4xGJjvRoelTQhazmSHUbaDV4Fycn0zu+XOwRlQb0AJuJPPWFZ3L5yINXB8KEOAtm6d4m fEUqUlPKjh2to8PxXoRTz32EEqR2GativemOiI4+BrFo++WpdzACh X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200727_094202_956324_D6747698 X-CRM114-Status: GOOD ( 32.44 ) 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: Peter Chen , Peng Fan , Geert Uytterhoeven , Catalin Marinas , Linus Walleij , Bjorn Andersson , "oleksandr.suvorov@toradex.com" , Will Deacon , Marek Szyprowski , Hans Verkuil , Russell King - ARM Linux , Krzysztof Kozlowski , Bartosz Golaszewski , Andreas Kemnade , Joel Stanley , dl-linux-imx , Alexandre Torgue , "linux-kernel@vger.kernel.org" , Sascha Hauer , Lubomir Rintel , Christian Gmeiner , Fabio Estevam , Linux ARM , "open list:GPIO SUBSYSTEM" , Patrice Chotard , Leo Li , "michael@walle.cc" , Sascha Hauer , Olof Johansson , 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 Mon, Jul 27, 2020 at 2:23 PM Anson Huang wrote: > > Subject: Re: [PATCH V2 1/4] gpio: mxc: Support module build > > > > > So, could you please help advise how to proceed it for this GPIO > > > driver to support loadable module? > > > > I would start by getting a reference board to work with a kernel in which all > > drivers are built-in except for the pinctrl driver, to see what exactly breaks > > when you do that, and what other drivers may have the same problems. > > Maybe it's not that bad after all and you only need a few modifications. > > > > I agreed, but the situation is i.MX SoC contains more than 20 modules, and most of > them are NOT owned by me, so I am NOT sure when the module owner will start > working on the support. And if with minimum devices enabled, such as tiny kernel > with ramfs, it is working even with pinctrl/clock etc. built as loadable module. Do you have an example that is actually broken? I checked how the gpio chip is actually used and found that "regulator-fixed", "virtual,mdio-gpio", "regulator-gpio", "gpio-leds", "marvell,mv88e6085", "microchip,usb2513b", "fsl,imx7d-usdhc", "fsl,imx6sx-fec", "mmc-pwrseq-simple", "brcm,bcm43438-bt", "rohm,bd71837", "nxp,pca9546", "rtc-m41t80", should all work fine here. I'm not sure about "fsl,mma8451", maybe test that one manually or look at the driver in more detail. "fsl,imx8mq-pcie" looks broken but easily fixed, and this is something we have already discussed. imx8mq-nitrogen.c has a "vsel-gpios" property in its "fcs,fan53555" device node that is neither part of the binding nor handled by the driver, so this is broken regardless of the gpio driver. > Meanwhile, as you said, most of the users are still using built-in model, so adding the > support for GPIO can be in parallel with other modules' work, in other words, with this > GPIO loadable module support patch, if other modules can NOT work due to lack of > defer probe implementation, then the patch should be done in other module, adding > that the default configuration of GPIO is still built-in, do you think it can be an independent > patch and get into linux-next first? I think you should be reasonably sure that making the driver a loadable module does not break other drivers that might rely on the probe order and that are known to be used with an i.MX chip. With the list above, that seems to actually be the case for the most part, but testing is always better. If there are boards that use other drivers which do not support deferred probing but don't have those listed in the dts files in the kernel, then that is not something you have to worry about I think. I'll let Linus Walleij comment on whether he thinks the initcall should stay at subsys_initcall() to avoid breaking users with buggy drivers, or whether this should be changed to module_init() or builtin_platform_driver() to have a better chance of finding and fixing those broken drivers. Arnd _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel