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 1840FC433E0 for ; Fri, 17 Jul 2020 12:03:01 +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 D5EBF2065F for ; Fri, 17 Jul 2020 12:03:00 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="Y5UsLB8c"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="IHn/oQ3b" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D5EBF2065F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org 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=+rcitd0LJ+32yOgELSmmuAOPOhRgP+lx1VdTOewmEa8=; b=Y5UsLB8cAd2gDN1fTSmqsbek7 1jREDYzQPIH63Vd3mBY6L37l693tYSDeYi8B1J/Om7poD0uTu4IGsyRvSszXxEl2zGpH+JVVr8Tl5 9BxuqfwsKiHNQeswY4f4OHdby1jDESxkncxcHKxMxa3Gkod+xDlu3cu/mftzd+1lAqpN6h/UUbGvz Pft0ge7dpu6rZ/EEp/OCmGWUDU94wwf58zqy9Rvvt5g3bNJfYuEqdfIsRAX/0KDo2gpiccxYYhta3 PXG0nz1BxreuSugn2O4WF5XA56Xaeft4DiBAp9bdaFYeZHS6vrERT5cVltXN5Q0O8m43oxnlM58U7 dKHEoCcsA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jwP3V-0008GX-1e; Fri, 17 Jul 2020 12:01:33 +0000 Received: from mail-lj1-x242.google.com ([2a00:1450:4864:20::242]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jwP3R-0008Fo-1T for linux-arm-kernel@lists.infradead.org; Fri, 17 Jul 2020 12:01:31 +0000 Received: by mail-lj1-x242.google.com with SMTP id f5so12256689ljj.10 for ; Fri, 17 Jul 2020 05:01:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ub697sVNwFF1cayMFoyuXRD/DoOaqjni0fvqH97Bh1w=; b=IHn/oQ3biBmtQTO5y7w6n8hxo4+QzjCMbkZ1yYDEmlK1IiEezprP1XH4WeAHB2zkHe hmdMyuTF1dqBdEUsXKFaqlfCQVn0rz3kdGh01jVdAMYMlh8dKckB6QiQb+Z3J9IEWpov Wj/tGt7StMejsVMfR63BSFLTj5vywd40zL2bAOryUkVHWuWJ2eGzJnYPRamRGxAo69hT l/EBIEEBX5eEqhjV4NKVn0aFVGQfI23mg+z0Q5NeiwOXlcFeOln4x5woeIRnF1hj6X3y RdMs52IyAVdBgTN7DeAzbCTCQrAMFhghih+fFuQ+cuBiRZ0Oo5JJF3eXDGk91tNE4Hqk CfaQ== 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=Ub697sVNwFF1cayMFoyuXRD/DoOaqjni0fvqH97Bh1w=; b=qKxBppIApjuOZ4Kaz7h1b8TsgOi3vWgS5YauRsv4oWqdM0hDK93cKztRiD/WihcaXd ewl+96Xkl4CepEQkm0Zvb0H5ARFoPrkW2igbHVIIvNfuxoOtrYo5sK19pvh4wSUaS10f qocBqszwvbLJO93326ETOPG8IJKCbRuWLHlbNQwSOhzyczfeG/VWeAdnhQMEj6LWSi/j zezi3pVuNbjYYxJG5wqsDsrwrxZpmXaHcUV1fb1NHedSCeyW9cxUWM2N+nPhcxDjWUvN /TntfKlTPdthpjHf/pNoQaS5l3BRuzmOYbhEgPdDJNqYXBOCXgOxMuUE1FuQxICp0Mmd p7PQ== X-Gm-Message-State: AOAM530bDtowMYfOj1nCUI+tqHAMJieNGYCuw4a3C2HqJIoXE6VO04WI NxdNH5dQNVkopMFuHRIdKvBv2R+fMRkISneaD3voAA== X-Google-Smtp-Source: ABdhPJx85nks8yaHQQYuyBdwuRKFsp37cc6OWGOcSWI/V0vNVyp7ufOAVlF+nDIW3hoBpajbiNi0N+nPII8MvmaiPNY= X-Received: by 2002:a2e:7a1a:: with SMTP id v26mr4129807ljc.104.1594987287043; Fri, 17 Jul 2020 05:01:27 -0700 (PDT) MIME-Version: 1.0 References: <1594164323-14920-1-git-send-email-Anson.Huang@nxp.com> In-Reply-To: From: Linus Walleij Date: Fri, 17 Jul 2020 14:01:16 +0200 Message-ID: Subject: Re: [PATCH 1/3] gpio: mxc: Support module build To: Anson Huang , Greg KH , John Stultz X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200717_080129_816644_94E40419 X-CRM114-Status: GOOD ( 29.32 ) 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: Geert Uytterhoeven , Catalin Marinas , Bjorn Andersson , "oleksandr.suvorov@toradex.com" , Will Deacon , Jon Corbet , Fabio Estevam , Russell King , Bartosz Golaszewski , Andreas Kemnade , dl-linux-imx , Sascha Hauer , "open list:GPIO SUBSYSTEM" , "hverkuil-cisco@xs4all.nl" , Adam Ford , Linux ARM , "linux-kernel@vger.kernel.org" , Leo Li , Vinod Koul , 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 Greg, John, we need some guidance here. See below. On Thu, Jul 16, 2020 at 4:38 PM Anson Huang wrote: > [Me] > > On Wed, Jul 15, 2020 at 4:44 AM Anson Huang > > > I tried to replace the subsys_initcall() with > > > module_platform_driver(), but met issue about " > > > register_syscore_ops(&mxc_gpio_syscore_ops);" which is called in > > > gpio_mxc_init() function, this function should be called ONLY once, > > > moving it to .probe function is NOT working, so we may need to keep the > > > gpio_mxc_init(), that is another reason that we may need to keep > > > subsys_initcall()? > > > > This looks a bit dangerous to keep like this while allowing this code to be used > > from a module. > > > > What happens if you insmod and rmmod this a few times, really? > > How is this tested? > > > > This is not really modularized if that isn't working, just that modprobing once > > works isn't real modularization IMO, it seems more like a quick and dirty way > > to get Androids GKI somewhat working with the module while not properly > > making the module a module. > > > > You need input from the driver maintainers on how to handle this. > > As far as I know, some general/critical modules are NOT supporting rmmod, like > clk, pinctrl, gpio etc., and I am NOT sure whether Android GKI need to support > rmmod for these system-wide-used module, I will ask them for more detail about > this. > > The requirement I received is to support loadable module, but so far no hard requirement > to support module remove for gpio driver, so, is it OK to add it step by step, and this patch > series ONLY to support module build and one time modprobe? While I am a big fan of the Android GKI initiative this needs to be aligned with the Linux core maintainers, so let's ask Greg. I am also paging John Stultz on this: he is close to this action. They both know the Android people very well. So there is a rationale like this going on: in order to achieve GKI goals and have as much as possible of the Linux kernel stashed into loadable kernel modules, it has been elevated to modus operandi amongst the developers pushing this change that it is OK to pile up a load of modules that cannot ever be unloaded. This is IIUC regardless of whether all consumers of the module are actually gone: it would be OK to say make it impossible to rmmod a clk driver even of zero clocks from that driver is in use. So it is not dependency-graph problem, it is a "load once, never remove" approach. This rationale puts me as subsystem maintainer in an unpleasant spot: it is really hard to tell case-to-case whether that change really is a technical advantage for the kernel per se or whether it is done for the greater ecosystem of Android. Often I would say it makes it possible to build a smaller kernel vmlinux so OK that is an advantage. On the other hand I have an inkling that I should be pushing developers to make sure that rmmod works. As a minimum requirement I would expect this to be marked by struct device_driver { (...) /* This module absolutely cannot be unbound */ .suppress_bind_attrs = true; }; So that noone would be able to try to unbind this (could even be an attack vector!) What is our broader reasoning when it comes to this? (I might have missed some mail thread here.) Yours, Linus Walleij _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel