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 75843C433E2 for ; Fri, 17 Jul 2020 13:03:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 52CAD208DB for ; Fri, 17 Jul 2020 13:03:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726629AbgGQNDP (ORCPT ); Fri, 17 Jul 2020 09:03:15 -0400 Received: from mout.kundenserver.de ([212.227.17.13]:43175 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726238AbgGQNDP (ORCPT ); Fri, 17 Jul 2020 09:03:15 -0400 Received: from mail-qk1-f173.google.com ([209.85.222.173]) by mrelayeu.kundenserver.de (mreue108 [212.227.15.145]) with ESMTPSA (Nemesis) id 1MTiLj-1kPt8u0C9F-00U51X; Fri, 17 Jul 2020 15:03:13 +0200 Received: by mail-qk1-f173.google.com with SMTP id l6so8600047qkc.6; Fri, 17 Jul 2020 06:03:12 -0700 (PDT) X-Gm-Message-State: AOAM530mCiCYf9tTIJWUd/6WM6kGqzkyWI6uR6i3/wyO9zPppOQcz3b2 vlRhhqzZQ3lvUCFli22IOBSqeoWWsN/Rn3KkU1Y= X-Google-Smtp-Source: ABdhPJyuO3LBCBkI4UHoemjYpeb6qR3u+uWtsrdd2uoqpmSfLP4xlUiKZiLFZ4iPFUZK+KoMfzD0cl9SuOcz2YgadL4= X-Received: by 2002:a37:9004:: with SMTP id s4mr345881qkd.286.1594990990628; Fri, 17 Jul 2020 06:03:10 -0700 (PDT) MIME-Version: 1.0 References: <1594164323-14920-1-git-send-email-Anson.Huang@nxp.com> <20200717121436.GA2953399@kroah.com> In-Reply-To: <20200717121436.GA2953399@kroah.com> From: Arnd Bergmann Date: Fri, 17 Jul 2020 15:02:54 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 1/3] gpio: mxc: Support module build To: Greg KH Cc: Linus Walleij , Geert Uytterhoeven , Catalin Marinas , Bjorn Andersson , "oleksandr.suvorov@toradex.com" , Fabio Estevam , Anson Huang , Jon Corbet , Will Deacon , Russell King , Bartosz Golaszewski , Andreas Kemnade , dl-linux-imx , Sascha Hauer , "open list:GPIO SUBSYSTEM" , John Stultz , "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="UTF-8" X-Provags-ID: V03:K1:PnQgfgYwfYuuBJpj1xktjWOKhKrYJMPulmrPaQn13yympd5z086 fFNKoxjp399F/B0P/4xk4EeGefedP7JmZ8flmq6GwPByEKWy6VleOI/Q2UBESg7z0hq3FHA MebFneHpbr8IwlCDLrpvtRXEKweddZpXhS2WPgnpcb1Ar7lfqVXUZHTlsZj3CcM1/rQKw5i hAhvJ+QCfY0KNFmSgbHDQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:uuxEPBDLxAo=:ZBHYdUNSQHm+QtoJnY+ioX hohXKN6vTf1tWwYkMveqTS4QC6l6N1Ytq/2WVNTkzu3QQZP70LjkwD8JrRv1A+x49q3su6oVm d7hQNiTJ50b9bpSQQ2CPQR1adHflwe1f9nGe8bbbP9hVeRENlJ+Ogf4XqDJRmXZV+2lIPx34v b98Zujh7DXaV9S3ce/lhErC4tUngUsesrmwqnftOTx4RccGwVNLUrAQgJp2WxhX5CiPF+oK3n YQwL9ku7FruvORB/GFv+BdMCrfALHUKn+waeQSGjktmDcsaCzQQTuWk4ni7rW+5jazKniCf4V hLXg6vyuB3OwxFMEl7zhsQYiU9vx17oJKh/03NpF+FmrbBrulp6EyciHqAtmMpc6w6kG+i+aD JT4nbDc2ZxUlwQaOXzTvoY5T5a/Uc6JLPjtsJDqqGkxGL0+o6+4DAZhiAFnUOJsOTzkVttR+F q+vJxrsDpVD1hdHO9u9pmvWZywq3aTDHzlmpDSe6NpUqfGXdW/ollh46Ai80DJGXXawrYWuJ7 ciatQsAfLwL1wsDDSYkzyv1WvNO7DMpLgLAIz6jhscLDiJ1O8Cwg5EG/TqOMWVE6YzO0v9WVr yRr+36ZQ41H7iwJCerFnhpLuUY+FD9o2x4sdMF/OuwI7nBNdG7eESphX7S9jCne+qQwthtQpK WO5lhUrCEPQ1KpKeXVqGuRn7RkFvHIGrGBGilMi/sWy8I7UHY3qV/Ut/3ukwyFrYRptchvIL7 DpqUwx9CpSzblDKDv2OVsnB/Kt9saeRpNxro26kC513QwvWUiTOLEAWmbCzYQ4J9dG8ZQCbGf Vcadvn6WC/l5TfLDoZVfLyKM5KMO2zoKLKJjs9zCtFDg/6vAHZ9HaXqjQabbgqPzQM1BIEuJD xx3wEtvydBAje4ONy21hE+5LNAcPXK3k4BiLaUpqESs0709kZpAmBlb4wp6eZz2/H7n9HhdMM hqxBCKTdYNABvk4FdLZs+apHThFjRmPaCyP7w/LG5jZllZBdgayRs 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 2:16 PM Greg KH wrote: > On Fri, Jul 17, 2020 at 02:01:16PM +0200, Linus Walleij wrote: > > 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. > > Why can't the module be unloaded? Is it just because they never > implement the proper "remove all resources allocated" logic in a remove > function, or something else? For the core kernel parts, it's usually for the lack of tracking of who is using the resource provided by the driver, as the subsystems tend to be written around x86's "everything is built-in" model. For instance, a PCIe host bridge might rely on the IOMMU, a clock controller, an interrupt controller, a pin controller and a reset controller. The host bridge can still be probed at reduced functionality if some of these are missing, or it can use deferred probing when some others are missing at probe time. If we want all of drivers to be unloaded again, we need to do one of two things: a) track dependencies, so that removing one of the devices underneath leads to everything depending on it to get removed as well or will be notified about it going away and can stop using it. This is the model used in the network subsystem, where any ethernet driver can be unloaded and everything using the device gets torn down. b) use reference counting on the device or (at the minimum) try_module_get()/module_put() calls for all such resources so as long as the pci host bridge is there, so none of the devices it uses will go away when they are still used. Traditionally, we would have considered the PCIe host bridge to be a fundamental part of the system, implying that everything it uses is also fundamental, and there was no need to track usage at all, just to ensure the probing is done in the right order. > > 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; > > }; > > No, that's not what bind/unbind is really for. That's a per-subsystem > choice as to if you want to allow devices to be added/removed from > drivers at runtime. It has nothing to do with module load/unload. It's a one-way dependency: If we can't allow the device to be unbound, then we also should not allow module unloading because that forces an unbind. 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 B024AC433E0 for ; Fri, 17 Jul 2020 13:04:39 +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 7B25B208DB for ; Fri, 17 Jul 2020 13:04:39 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="y3pfURmU" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7B25B208DB 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=chgKon/XALSKmoUD9VGsfRGtR5eZ2/TWc6LAwejqX9E=; b=y3pfURmUHGnxtIcvarSZNvKVu zWneSBE+vq4cmTRSqNdBdx5CfDTHb2wSTHCV6DHRrnmBcJcrgOEltRWgHfGgSpiNrck/YIgU/1eFW crUW/MBA+dz2nA0Jzhzmm9+QZZGOiFgzXeR3pMjV+bXv8+6oMGjq0QEur2QF9wSmzyCONiZbNBzt4 Xh02ecgtpAWIk/ISs91u/vblv4R1FoZyWF9xgTGDgFTd+FWFHsst58AFNW20GU1yz0VITe34quQdc pjdE/xeyCf4AkFQ5q1ye8bTDxvs40ThS3TR4JqWqD1y4izt0xY8pk43ESQ1Xo1XZWB3S8WPzTsXJQ xJvHgSVsA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jwQ1H-0002aU-Ae; Fri, 17 Jul 2020 13:03:19 +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 1jwQ1E-0002ZU-Rb for linux-arm-kernel@lists.infradead.org; Fri, 17 Jul 2020 13:03:17 +0000 Received: from mail-qk1-f178.google.com ([209.85.222.178]) by mrelayeu.kundenserver.de (mreue012 [212.227.15.129]) with ESMTPSA (Nemesis) id 1MZSJa-1kK7qG11Qk-00WXek for ; Fri, 17 Jul 2020 15:03:14 +0200 Received: by mail-qk1-f178.google.com with SMTP id k18so8625136qke.4 for ; Fri, 17 Jul 2020 06:03:11 -0700 (PDT) X-Gm-Message-State: AOAM5308WInRncPeYhljuVjs89ETNG6T4+f9aJjgkV+dD/bBIaMHZYTa KOt62O3Kek29SFY1RkBjUersYG0x1jku7EMi864= X-Google-Smtp-Source: ABdhPJyuO3LBCBkI4UHoemjYpeb6qR3u+uWtsrdd2uoqpmSfLP4xlUiKZiLFZ4iPFUZK+KoMfzD0cl9SuOcz2YgadL4= X-Received: by 2002:a37:9004:: with SMTP id s4mr345881qkd.286.1594990990628; Fri, 17 Jul 2020 06:03:10 -0700 (PDT) MIME-Version: 1.0 References: <1594164323-14920-1-git-send-email-Anson.Huang@nxp.com> <20200717121436.GA2953399@kroah.com> In-Reply-To: <20200717121436.GA2953399@kroah.com> From: Arnd Bergmann Date: Fri, 17 Jul 2020 15:02:54 +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:i9gAUtIbRwbEWNzwy1xbYN01TQLwNFrzXcYHiCaq8honW7YVFZh T/lnODzhSBQA1PxsxE32kiEWjoSbvGL5Rqx9Go0UdZexzE2HQT0V7ID58FXzdRot3j7Hdo2 XDf9qmJaKPpnRPITEYvVWCIL5r8kr7q5VDZe+72fqx3vP1R0a6xvRfOpLAV5kPQmbFS4z7C zikuqGzCTXayMRXWoqaow== X-UI-Out-Filterresults: notjunk:1;V03:K0:LxHN8kbHEG0=:USodLBcG0c4epkFeks6WWn oha5iFTzxDlS3MkUubmkPX8y/B2UzOjKCoUUVD4+lwWNkTwIvifrzRbW4fL2G6Go7/pQLahNk QLGrVZvoBNv3/VpwU4GQ3LsIdArmPBd0WkXHJHr0CDqZMXA91C7mNK6mu/4Gqv3t8gmVYXfMB u7X68nsw3Qx/d52huH3ndyDlBzSnXcGvcXKkyKGPcHUtuPV0uwYUuNxnKNCP03EpwJbRRdIX9 pwIRjs13T8iKQPDyf1uIRJlmF+uta03rNSO95akJBrMvnN+ISk3ThaYmcMDK7wzGXrDJJjvDM QwnnODg0Bnw8QRtzwgrahT5X1InU3uz1Fuggk/xRF8cZo1h06Up2kz7wOGiujZuz/+xTMhTNh glPlQe80lAzVuQmPLZ6xHN1grU9Ft4B+toDl57m8ng5tGDW8jCk7qFffsSIih/LqFB2nAOVDU UWa+GmBdAGtv6/NNpUR7h3yl155agmfOKbRiL0Ow05SfFlslxt3dnvvI4la4WdSspQ8uueGjU aiejbbYuyQK9MjJk3yFKoE6kTsXCINglN5P5KdP5PbHQ5zuyoVaR6kDnCcztDFa/z7octZzXU zULZF+URfLSmwCVAXcahPdVVKyoP9rGsltOVfQGAcpn2pEhjUkNuO1dRmhq6z7sQwz/ablhKf xgaQXg3TT9bZencMyP3AmeN/OF+GE68RmMrJqVRWs5Sshc9rNFbMUgbfZeQkaAqu/OvyQPWAJ 88hjrlA8JO83kEKvI0pxSSUzbVA3aFPx/im8WpNWdCcZGr8l6PKhEATvhrWMa2nxD7n1MfgjR ytBipZeskO13i6zH2rX43pSItFwt4burRImLIF/wDh3FjVsTqMj/uXoIrxKlh7TTzGtB7zeJ2 Z1dBDdHDF67z//a4EBNkFMPffilZeywhmNwxhV3LEYhGGmjkVz2/90/kNO5BbMBpnqqYNSC3k szI3Tupj0+soOjzIdXZEVU/Xk92EVEIPO0TizPnT9rXU5C5h32C+9 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200717_090317_105428_D8967AAF X-CRM114-Status: GOOD ( 27.29 ) 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 , Linus Walleij , Bjorn Andersson , "oleksandr.suvorov@toradex.com" , Will Deacon , Anson Huang , Jon Corbet , Fabio Estevam , Olof Johansson , Russell King , Bartosz Golaszewski , Andreas Kemnade , 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 , "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 2:16 PM Greg KH wrote: > On Fri, Jul 17, 2020 at 02:01:16PM +0200, Linus Walleij wrote: > > 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. > > Why can't the module be unloaded? Is it just because they never > implement the proper "remove all resources allocated" logic in a remove > function, or something else? For the core kernel parts, it's usually for the lack of tracking of who is using the resource provided by the driver, as the subsystems tend to be written around x86's "everything is built-in" model. For instance, a PCIe host bridge might rely on the IOMMU, a clock controller, an interrupt controller, a pin controller and a reset controller. The host bridge can still be probed at reduced functionality if some of these are missing, or it can use deferred probing when some others are missing at probe time. If we want all of drivers to be unloaded again, we need to do one of two things: a) track dependencies, so that removing one of the devices underneath leads to everything depending on it to get removed as well or will be notified about it going away and can stop using it. This is the model used in the network subsystem, where any ethernet driver can be unloaded and everything using the device gets torn down. b) use reference counting on the device or (at the minimum) try_module_get()/module_put() calls for all such resources so as long as the pci host bridge is there, so none of the devices it uses will go away when they are still used. Traditionally, we would have considered the PCIe host bridge to be a fundamental part of the system, implying that everything it uses is also fundamental, and there was no need to track usage at all, just to ensure the probing is done in the right order. > > 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; > > }; > > No, that's not what bind/unbind is really for. That's a per-subsystem > choice as to if you want to allow devices to be added/removed from > drivers at runtime. It has nothing to do with module load/unload. It's a one-way dependency: If we can't allow the device to be unbound, then we also should not allow module unloading because that forces an unbind. Arnd _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel