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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D91C3C433F5 for ; Fri, 1 Oct 2021 16:51:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C21CF6124D for ; Fri, 1 Oct 2021 16:51:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1355035AbhJAQxV (ORCPT ); Fri, 1 Oct 2021 12:53:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59172 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1354604AbhJAQxU (ORCPT ); Fri, 1 Oct 2021 12:53:20 -0400 Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1FAC5C06177E for ; Fri, 1 Oct 2021 09:51:36 -0700 (PDT) Received: by mail-ed1-x529.google.com with SMTP id ba1so37045262edb.4 for ; Fri, 01 Oct 2021 09:51:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bBQZZYDYKRJHZigI6OY4bgMOmcGGR9Z1AlvP3TxeSEI=; b=s24lK/qyc7Hvu7PHx1upoHIf7M9KheKCgbiY3jC4htqP4K2hL8IPfH4FJA7GIOsfqD InRSTPJcDxqgsC+5JApYP6mycmEYweL32Rj80zaqoPRNmAzE9uF9o8YV2QvYI7epa10i xNiKV4whJUFQCX5h1Zhutyq8rJZ4tcsRViKX1FRnG18P/nrROuRoNUdFIWlysUPKyvuB a2AvXPYhYRbcOS/aWdNQLKv7maeKFw4I5cJg1t9R+SqWRh5cl3aupbc+Fdtg/KDgbbSr tO46ZhS1f9zorMIz9hzXLgOnCSew8ryM+60KbdTiQAJltydRYO61mPIrL5JOT6YWHdOF rsog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bBQZZYDYKRJHZigI6OY4bgMOmcGGR9Z1AlvP3TxeSEI=; b=KDartUvews22rnKysCf8JjFBlQEhd2K81XesJPZdU+ik/nW/m26Zajy85oLdGloqhg Bk7GJ3NkmlaiHn2JGHttVbmNboCkg4zfGncqdRYRyEeqLh3nQlOD09ij99AxA1xdrKlN /CdXr/dSl6j/jNd7ZS3TLNAZHknbB/QkOumKPIJcnnT8Hy0sTACy/P8hiJFVNpUKXeK2 xRB6gYHwYxD1usmwJ5jPAYoY2zAalNkT4+qvHw2YyYFfTObPx2Q6CW4wEmq0gDUZkACt 9P5PmVXdAjDTivuR2qU/SwrFCz6DSiDpZAkXZmbd4CO87EqN9m/2NyQ/nvnnHvWCCnrZ mHHw== X-Gm-Message-State: AOAM531UFgRTJqtx4LGd/eAGLXLBT+L7OzpvnW0/RZCUyqZXxjjw4x+8 7mvqhSeBo5UNTJPepMWDrlcX6XQhX3zo3KNxSuxxAg== X-Google-Smtp-Source: ABdhPJxpLQAYt75NaH1vdWxiIroNTAgkPN0fO2kMs4YItEm5vqCDC80CQdBK9C2906B/kcwERy3e2blHW5dUToSMBAs= X-Received: by 2002:a50:dacf:: with SMTP id s15mr15859419edj.385.1633107094312; Fri, 01 Oct 2021 09:51:34 -0700 (PDT) MIME-Version: 1.0 References: <20210928235635.1348330-1-willmcvicker@google.com> <7766faf8-2dd1-6525-3b9a-8ba790c29cff@canonical.com> In-Reply-To: From: Will McVicker Date: Fri, 1 Oct 2021 09:51:17 -0700 Message-ID: Subject: Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs To: Olof Johansson Cc: Geert Uytterhoeven , Saravana Kannan , Krzysztof Kozlowski , Russell King , Catalin Marinas , Will Deacon , Michael Turquette , Stephen Boyd , Sylwester Nawrocki , Tomasz Figa , Chanwoo Choi , Linus Walleij , Alessandro Zummo , Alexandre Belloni , John Stultz , Thomas Gleixner , Lee Jones , "Cc: Android Kernel" , Linux ARM , Linux Kernel Mailing List , linux-samsung-soc , linux-clk , "open list:GPIO SUBSYSTEM" , linux-rtc@vger.kernel.org, Arnd Bergmann Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org On Fri, Oct 1, 2021 at 9:00 AM Olof Johansson wrote: > > On Fri, Oct 1, 2021 at 4:59 AM Geert Uytterhoeven wrote: > > > > Hi Olof, > > > > On Fri, Oct 1, 2021 at 7:36 AM Olof Johansson wrote: > > > A much more valuable approach would be to work towards being able to > > > free up memory by un-probed drivers at the end of boot. That would > > > possibly benefit all platforms on all architectures. > > > > We used to have such a functionality in arch/ppc (not arch/powerpc!), > > where code/data could be tagged __prep, __chrp, or __pmac, to put it > > in a special section, and to be freed with initdata when unused. It > > was removed in v2.6.15[1], as the savings weren't worth the hassle. > > In a more fragmented space like arm the memory lost due to alignment > > of the sections would be even more substantial. > > Yeah, the balance between per-platform code size and overall kernel > code size shifted over time to a point where it wasn't as meaningful > on ppc. > > > Another problem is to know when is the end of the boot, especially > > with deferred probing. > > Most of this code either has a module_init() or an initcall that > actually registers the drivers and/or probes for the platform and does > the work. > > This means you can have a late equivalent hook/initcall that > determines whether this path ended up being probed/used. If it wasn't, > you can then unregister and flag the corresponding memory to be freed > at the end, and would take out the heuristics and guessing on needing > to do it automatically from the code path that's doing said freeing. > > > -Olof First off, I appreciate the constructive conversations and I understand the ask here. So I'd like to close the "we don't want this" and "this isn't possible" conversation. We have already proven downstream that it is in fact possible to modularize these drivers on other SoCs (mentioned earlier if you missed it) and I'd like to direct the conversation towards verifying/testing here instead of negatively arguing about how SoC vendors aren't upstreaming their drivers. I think everyone understands that, but unfortunately I have no control over that even though I would love everyone to work upstream directly. I am fine with forcing these drivers to always be enabled in some form upstream even though it doesn't really make much sense for a generic kernel that will run on Qualcomm, Exynos, Mediatek, (you name it) SoC devices. I thought about how to do this yesterday and wasn't able to come up with a proper solution that didn't always force this driver to be a module when CONFIG_MODULES is enabled. For example, if I do this below, then we will be forcing all builds to use CONFIG_XXX as a module if they want just one driver as a module. config XXX tristate "blah blah" if COMPILE_TEST default m if (ARCH_XXX && MODULES) default ARCH_XXX The best I was able to come up with was this below which would allow the driver to be a module or built-in; however, obviously it lets you disable it in EXPERT mode. config XXX tristate "blah blah" if COMPILE_TEST || EXPERT default ARCH_XXX Let me know if you have a better solution that doesn't force the driver to be a module when CONFIG_MODULES=y. Saravana did propose a MINIMUM_ARM64_GENERIC_KERNEL config that could solve this, but that too was shot down. Thanks, Will 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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8A723C433F5 for ; Fri, 1 Oct 2021 16:53:30 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 51A3B6124D for ; Fri, 1 Oct 2021 16:53:30 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 51A3B6124D Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc: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=UbQE52R40boAKwgfm1GPLpacK6fYb6DvvRdSVk8pYxM=; b=sODGZxfDxDfxtg ohLGAH7cT4/vyHu2J7SHsxFOAjyVAOMX9AUU7N3mEWCfUHd1Nxogx6fDDSLCuuekUhDjXbPJ6BMB7 QwfrCVqYoL3QovHl/DrnUCbOB4M3yd8EVcuBQILZFlo2LOsVtQsfzGe188mYILpvHKlyRZ6uVPYYo DnFOrZkdxNk1sWjQ4e7u2aX2PDRN4FvxsyRwoKH1rXwFmdFNmPXesAhZs4vplG91n++HIsD9j0C+t MwPcwy9oTHyuo66aLYnm/qFVih8AL/6f4K5pYK5uw3x5VsnxCMefHabYCGvBaRoRSAGso32S7v6jo irQlsL9C2SC0sj9RJ2JA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mWLl6-000v4e-IS; Fri, 01 Oct 2021 16:51:40 +0000 Received: from mail-ed1-x531.google.com ([2a00:1450:4864:20::531]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mWLl2-000v46-7x for linux-arm-kernel@lists.infradead.org; Fri, 01 Oct 2021 16:51:37 +0000 Received: by mail-ed1-x531.google.com with SMTP id g8so37205863edt.7 for ; Fri, 01 Oct 2021 09:51:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bBQZZYDYKRJHZigI6OY4bgMOmcGGR9Z1AlvP3TxeSEI=; b=s24lK/qyc7Hvu7PHx1upoHIf7M9KheKCgbiY3jC4htqP4K2hL8IPfH4FJA7GIOsfqD InRSTPJcDxqgsC+5JApYP6mycmEYweL32Rj80zaqoPRNmAzE9uF9o8YV2QvYI7epa10i xNiKV4whJUFQCX5h1Zhutyq8rJZ4tcsRViKX1FRnG18P/nrROuRoNUdFIWlysUPKyvuB a2AvXPYhYRbcOS/aWdNQLKv7maeKFw4I5cJg1t9R+SqWRh5cl3aupbc+Fdtg/KDgbbSr tO46ZhS1f9zorMIz9hzXLgOnCSew8ryM+60KbdTiQAJltydRYO61mPIrL5JOT6YWHdOF rsog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bBQZZYDYKRJHZigI6OY4bgMOmcGGR9Z1AlvP3TxeSEI=; b=ILqYy0swj9hWMJP9wgifS3jLIdKyxot67ucNuDU5EOaaZwH6w7enpoWz9M6EOBG+ie 6+3W6WfJh5anhYqlDqk++T6gCkINOzMGgwIswjh9hMhmBqbLOKN55A3RFEzTUQ677lUp 3yJcGhkN9BdZpzKsbZvAGLjkkC0Hg+iJZJU1lCwUq/0cqwJILQ66/lDLZ9KcGPdBn/nP LW4IJC+k177h+nRK3Vj31CX2yBeBz7l2Sbo4FokpwnhTpMhn3ShgC3S5RST3zKYyH3ar dde4FYCmlcIffnD5rsjr5L87bHcN7UM3GJve/DdNOqCpnsdkPy+TRj51a0+bnOV6hAsh gdIA== X-Gm-Message-State: AOAM532q7QspUEm55zrEFCprfgbxDFTj4X4YudNWydYwQu1kp1RRwi+C hu/Mj8aBIeNQTtG0Y04M3O4FeXOiDTSpgWuhmDVOvw== X-Google-Smtp-Source: ABdhPJxpLQAYt75NaH1vdWxiIroNTAgkPN0fO2kMs4YItEm5vqCDC80CQdBK9C2906B/kcwERy3e2blHW5dUToSMBAs= X-Received: by 2002:a50:dacf:: with SMTP id s15mr15859419edj.385.1633107094312; Fri, 01 Oct 2021 09:51:34 -0700 (PDT) MIME-Version: 1.0 References: <20210928235635.1348330-1-willmcvicker@google.com> <7766faf8-2dd1-6525-3b9a-8ba790c29cff@canonical.com> In-Reply-To: From: Will McVicker Date: Fri, 1 Oct 2021 09:51:17 -0700 Message-ID: Subject: Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs To: Olof Johansson Cc: Geert Uytterhoeven , Saravana Kannan , Krzysztof Kozlowski , Russell King , Catalin Marinas , Will Deacon , Michael Turquette , Stephen Boyd , Sylwester Nawrocki , Tomasz Figa , Chanwoo Choi , Linus Walleij , Alessandro Zummo , Alexandre Belloni , John Stultz , Thomas Gleixner , Lee Jones , "Cc: Android Kernel" , Linux ARM , Linux Kernel Mailing List , linux-samsung-soc , linux-clk , "open list:GPIO SUBSYSTEM" , linux-rtc@vger.kernel.org, Arnd Bergmann X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211001_095136_309495_EC164A3E X-CRM114-Status: GOOD ( 37.31 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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, Oct 1, 2021 at 9:00 AM Olof Johansson wrote: > > On Fri, Oct 1, 2021 at 4:59 AM Geert Uytterhoeven wrote: > > > > Hi Olof, > > > > On Fri, Oct 1, 2021 at 7:36 AM Olof Johansson wrote: > > > A much more valuable approach would be to work towards being able to > > > free up memory by un-probed drivers at the end of boot. That would > > > possibly benefit all platforms on all architectures. > > > > We used to have such a functionality in arch/ppc (not arch/powerpc!), > > where code/data could be tagged __prep, __chrp, or __pmac, to put it > > in a special section, and to be freed with initdata when unused. It > > was removed in v2.6.15[1], as the savings weren't worth the hassle. > > In a more fragmented space like arm the memory lost due to alignment > > of the sections would be even more substantial. > > Yeah, the balance between per-platform code size and overall kernel > code size shifted over time to a point where it wasn't as meaningful > on ppc. > > > Another problem is to know when is the end of the boot, especially > > with deferred probing. > > Most of this code either has a module_init() or an initcall that > actually registers the drivers and/or probes for the platform and does > the work. > > This means you can have a late equivalent hook/initcall that > determines whether this path ended up being probed/used. If it wasn't, > you can then unregister and flag the corresponding memory to be freed > at the end, and would take out the heuristics and guessing on needing > to do it automatically from the code path that's doing said freeing. > > > -Olof First off, I appreciate the constructive conversations and I understand the ask here. So I'd like to close the "we don't want this" and "this isn't possible" conversation. We have already proven downstream that it is in fact possible to modularize these drivers on other SoCs (mentioned earlier if you missed it) and I'd like to direct the conversation towards verifying/testing here instead of negatively arguing about how SoC vendors aren't upstreaming their drivers. I think everyone understands that, but unfortunately I have no control over that even though I would love everyone to work upstream directly. I am fine with forcing these drivers to always be enabled in some form upstream even though it doesn't really make much sense for a generic kernel that will run on Qualcomm, Exynos, Mediatek, (you name it) SoC devices. I thought about how to do this yesterday and wasn't able to come up with a proper solution that didn't always force this driver to be a module when CONFIG_MODULES is enabled. For example, if I do this below, then we will be forcing all builds to use CONFIG_XXX as a module if they want just one driver as a module. config XXX tristate "blah blah" if COMPILE_TEST default m if (ARCH_XXX && MODULES) default ARCH_XXX The best I was able to come up with was this below which would allow the driver to be a module or built-in; however, obviously it lets you disable it in EXPERT mode. config XXX tristate "blah blah" if COMPILE_TEST || EXPERT default ARCH_XXX Let me know if you have a better solution that doesn't force the driver to be a module when CONFIG_MODULES=y. Saravana did propose a MINIMUM_ARM64_GENERIC_KERNEL config that could solve this, but that too was shot down. Thanks, Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel