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 B07CCC433E0 for ; Fri, 17 Jul 2020 13:23:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8898120717 for ; Fri, 17 Jul 2020 13:23:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1594992193; bh=YXmOefMvlOs7G1IJ3/xGseJf7pS/JY+GgUOoWYCRdsw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=ByVjO/bh7Wqlnd71JQupspXifNEWZdRuVNoP3UayHO3VyK+2ObSMe6KLv4cV6Y9Md S8xL+3epKQhJ16Obi0SLYDnuHqvo5av6h8fbMyxRfIHR1uV/sVzrhUVVYQqTMlEw2F ORbDqcXWGHiKFfnd9jWsWJOevEEeKaxTkz/XBFgk= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726113AbgGQNXN (ORCPT ); Fri, 17 Jul 2020 09:23:13 -0400 Received: from mail.kernel.org ([198.145.29.99]:51210 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726071AbgGQNXM (ORCPT ); Fri, 17 Jul 2020 09:23:12 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 292DD2064B; Fri, 17 Jul 2020 13:23:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1594992191; bh=YXmOefMvlOs7G1IJ3/xGseJf7pS/JY+GgUOoWYCRdsw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=iHGfSp04sqXJQGRHKlCZEVORFrAeFfBcvjwv355yCV8T6VUkl3GdsRlSeMV4e25Sz NrGX9IhzqSeUa/5SSfAylaRUiv28hLSgYvwA/tiAiqobuA2T+Zdes/mMzw30FEFnkR yKxrtUYcsWx1fcspFFMyM94qyDRRJRU9dONpKnNs= Date: Fri, 17 Jul 2020 15:23:03 +0200 From: Greg KH To: Arnd Bergmann 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 Subject: Re: [PATCH 1/3] gpio: mxc: Support module build Message-ID: <20200717132303.GB2984939@kroah.com> References: <1594164323-14920-1-git-send-email-Anson.Huang@nxp.com> <20200717121436.GA2953399@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 03:02:54PM +0200, Arnd Bergmann wrote: > 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. Yeah, ick, for IOMMU and stuff like this, no, load it once and never unload it makes much more sense. Just know how to dynamically load the specific driver out of a collection of them, and all should be fine. > > > 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. Ok, then turn that off for the subsystems this does not support, no objection from me. It's just a fun hack that people use for testing out drivers on new devices, and for virtual devices. thanks, greg k-h 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 C0DA0C433DF for ; Fri, 17 Jul 2020 13:24:29 +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 8C6AF20717 for ; Fri, 17 Jul 2020 13:24:29 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="NkC3lLEG"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="iHGfSp04" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8C6AF20717 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linuxfoundation.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:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=sBffT1F5m/FJ/k5OuAM3fSTRwq6FrqRrfCAul5Q92Nk=; b=NkC3lLEGI6E7ZlmxfpzWxk6C6 ZVl9EsNO6CpnPa3JFhhrnsJxJ8Fv6pe07XWuyQuTmWxyxRNJ69zjs9Dx0hiQq/Hyjn+xpBi+NfamJ GStZRf+JI2Lvd3xy1Iy+kpvrmvQiRBZpZ60asjGdI585J1qvhYIBRsfSj0sH+PXARlZAJXz2TO8DB /uSCpXENLpjbiWUF4kQxoT1v7mF1Tf3V0PTYs724XDe5jT7+JIwHL0Z9K+euFAbyuYErzNfGO2aXa ad8m+p3SJ9Jy0AbaIq9Y2T3XbN8cWbPou2CYi5Wom1TPPMJlH+2WHvVFubZ9isx2IhB6dUWE0YkvY 3Ultw5z2A==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jwQKZ-0007Qu-8n; Fri, 17 Jul 2020 13:23:15 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jwQKW-0007Pe-Sr for linux-arm-kernel@lists.infradead.org; Fri, 17 Jul 2020 13:23:13 +0000 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 292DD2064B; Fri, 17 Jul 2020 13:23:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1594992191; bh=YXmOefMvlOs7G1IJ3/xGseJf7pS/JY+GgUOoWYCRdsw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=iHGfSp04sqXJQGRHKlCZEVORFrAeFfBcvjwv355yCV8T6VUkl3GdsRlSeMV4e25Sz NrGX9IhzqSeUa/5SSfAylaRUiv28hLSgYvwA/tiAiqobuA2T+Zdes/mMzw30FEFnkR yKxrtUYcsWx1fcspFFMyM94qyDRRJRU9dONpKnNs= Date: Fri, 17 Jul 2020 15:23:03 +0200 From: Greg KH To: Arnd Bergmann Subject: Re: [PATCH 1/3] gpio: mxc: Support module build Message-ID: <20200717132303.GB2984939@kroah.com> References: <1594164323-14920-1-git-send-email-Anson.Huang@nxp.com> <20200717121436.GA2953399@kroah.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200717_092313_108433_7D5801C5 X-CRM114-Status: GOOD ( 36.49 ) 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 03:02:54PM +0200, Arnd Bergmann wrote: > 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. Yeah, ick, for IOMMU and stuff like this, no, load it once and never unload it makes much more sense. Just know how to dynamically load the specific driver out of a collection of them, and all should be fine. > > > 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. Ok, then turn that off for the subsystems this does not support, no objection from me. It's just a fun hack that people use for testing out drivers on new devices, and for virtual devices. thanks, greg k-h _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel