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 3264EC4332F for ; Fri, 1 Oct 2021 05:36:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 182B161052 for ; Fri, 1 Oct 2021 05:36:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1351961AbhJAFh5 (ORCPT ); Fri, 1 Oct 2021 01:37:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43770 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1351785AbhJAFhx (ORCPT ); Fri, 1 Oct 2021 01:37:53 -0400 Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2A953C06176D for ; Thu, 30 Sep 2021 22:36:10 -0700 (PDT) Received: by mail-pl1-x62b.google.com with SMTP id c4so5580493pls.6 for ; Thu, 30 Sep 2021 22:36:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lixom-net.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lwPyxDqaGBhT92QACUI/bh+VkUYF5Oo/5CIkAxgdtZ0=; b=x4+eS/mPHFSaWAR3xsBgO23T1i0mXQSg5zBlZyUWrRmossN4sDE/RgApQuGNJSyKlx LRsdEA+fHhNG7b37ubODdSxT8Bf61fc21oJV4cGXpJkBnDvVg9UMLor5aANUxLMedr2U +4HtKL/belqPrhzcWZUz40RVVQaz/86inqcF15fBdN0ujQStvUBFnBY3/Z9OOntVQa+5 BbeZX0aEr6/mohhEefytrMODC7pyF+qHZR1t4VPvZGC75jGvIy9pllZ1e1zV6aIbzo8P ED8gZPdtk/O1HyOl+alpfG38L+LhsnZN6H74QHGaNOZIdj3Bu+r/bbX89ffqFthfzbgn 6A6w== 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=lwPyxDqaGBhT92QACUI/bh+VkUYF5Oo/5CIkAxgdtZ0=; b=vTpvdm44QMlaWPFbYMgc0jHUJcJKAcJ/nzqRfHyovq6K9uAd82nbxftDcyHQmqOWyM 80Kxc2T0FkoVMKN7ocDbF+0DhD4brLOdmE/djKP68DWfPRwERy7OwUEO/ma+BiqLNG65 R3yljT2GT1D87eAA7PGSTXkhoavdNZ0lb8bdCFhu5B5XXijZu+BZU2/2s4O3sFnvTO3Y SAJYWuxF+gGoYXt8glpYDefNPXvSuXRt7/mz8FEs0MVsq61tO/EnCMDyY16sJpDa3WSU AjrVX8cNMWCD4e20jO4ddoKyqxhyeha52WxexCvXvHinQGEHgjkh9Gmp+RiJt3znDA/I T6LQ== X-Gm-Message-State: AOAM5307SuSbdRO64kHwnwVX8jL2yRJnW8s+HuZSByuYLvD94STmey+D Ai4v4X1E0OJi950yT//EUlkeQP0oS3H2uD1S9uy2vA== X-Google-Smtp-Source: ABdhPJyXrHEjSRsbvGuDy1U26vszb5TEBTH/srDHAuSr9YR7iT8IG7gbwvXgl1d4rlALNdae0jk7Dkp7FchFO9bSadM= X-Received: by 2002:a17:90a:9317:: with SMTP id p23mr11101909pjo.151.1633066567459; Thu, 30 Sep 2021 22:36:07 -0700 (PDT) MIME-Version: 1.0 References: <20210928235635.1348330-1-willmcvicker@google.com> <7766faf8-2dd1-6525-3b9a-8ba790c29cff@canonical.com> In-Reply-To: From: Olof Johansson Date: Thu, 30 Sep 2021 22:35:55 -0700 Message-ID: Subject: Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs To: Saravana Kannan Cc: Will McVicker , 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 , Geert Uytterhoeven , "Cc: Android Kernel" , Linux ARM , Linux Kernel Mailing List , linux-samsung-soc , linux-clk , linux-gpio@vger.kernel.org, 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 Thu, Sep 30, 2021 at 10:24 PM Saravana Kannan wrote: > > On Thu, Sep 30, 2021 at 9:52 PM Olof Johansson wrote: > > > > On Wed, Sep 29, 2021 at 12:48 PM Will McVicker wrote: > > > > > > On Wed, Sep 29, 2021 at 6:02 AM Krzysztof Kozlowski > > > wrote: > > > > > > > > On 29/09/2021 01:56, Will McVicker wrote: > > > > > This is v2 of the series of patches that modularizes a number of core > > > > > ARCH_EXYNOS drivers. Based off of the feedback from the v1 series, I have > > > > > modularized all of the drivers that are removed from the ARCH_EXYNOS > > > > > series of "select XXX". This includes setting the following configs as > > > > > tristate: > > > > > > > > > > * COMMON_CLK_SAMSUNG > > > > > * EXYNOS_ARM64_COMMON_CLK > > > > > * PINCTRL_SAMSUNG > > > > > * PINCTRL_EXYNOS > > > > > * EXYNOS_PMU_ARM64 > > > > > * EXYNOS_PM_DOMAINS > > > > > > > > > > Additionally, it introduces the config EXYNOS_PMU_ARM64 and EXYNOS_PMU_ARM > > > > > which was previously EXYNOS_PMU and EXYNOS_PMU_ARM_DRIVERS respectively. > > > > > The reason for these new configs is because we are not able to easily > > > > > modularize the ARMv7 PMU driver due to built-in arch dependencies on > > > > > pmu_base_addr under arch/arm/mach-exynos/*. So the new configs split up > > > > > the ARM and ARM64 portions into two separate configs. > > > > > > > > > > Overall, these drivers didn't require much refactoring and converted to > > > > > modules relatively easily. However, due to my lack of exynos hardware, I > > > > > was not able to boot test these changes. I'm mostly concerned about the > > > > > CLK_OF_DECLARE() changes having dependencies on early timers. So I'm > > > > > requesting help for testing these changes on the respective hardware. > > > > > > > > > > > > > These are all not tested at all? In such case, since these are not > > > > trivial changes, please mark the series as RFT. > > > > > > > > I will not be able to test these for some days, so it must wait. > > > > > > > > > > > > Best regards, > > > > Krzysztof > > > > > > +Cc Arnd and Olof, > > > > > > Hi Krzysztof, > > > > > > To avoid the scrambled conversation from the first patchset, I'm going > > > to address all your general questions here in the cover letter thread > > > so that it's easier for everyone to follow and reference in the > > > future. > > > > This patchset shouldn't go in. > > > > GKI is a fantastic effort, since it finally seems like Google has the > > backbone to put pressure on the vendors to upstream all their stuff. > > > > This patcheset dilutes and undermines all of that by opening up a > > truck-size loophole, reducing the impact of GKI, and overall removes > > leverage to get vendors to do the right thing. > > > > It's against our interest as a community to have this happen, since > > there's no other reasonably justifiable reason to do this. > > Oolf, Geert, Krzysztof, Arnd, So close. > I skimmed through the emails and you all make a lot of good points. I skimmed through this email and I think it adds a lot of new complexity and fragility to solve a problem that doesn't really exist for upstream, adding yet more config parameter combinations to build and test for. 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. -Olof 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 BE9EFC433EF for ; Fri, 1 Oct 2021 05:38:01 +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 84DC5619F5 for ; Fri, 1 Oct 2021 05:38:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 84DC5619F5 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=lixom.net 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=Wrd2PCP5Gy8YhZOdfHxXqADQybEp3gdoQIUcSBgSmHI=; b=t97oK0z6zS74J7 SFpiEEk4hYX5Nsw28JRjPOqzdkPzxDORjO7tslIi/D/SHuApeAbP708/99M8TISPtzpYKpLjqkPYR BZVbJaHMS6ffY8VouArEyU+JJjtyOI/rkltfO37OYtz2yyXbhXFzCZMywkBYpr+5HrbNd8C3KNYDZ +/8eNDVeBWudkKGBapJE9XpJpXUBZ4zXf6psQFJm8mQPHAvPmOF1Neu6MJfa7plQpFNxKhwMZa0zK 9xl4z1Wb6J0LSsVBigFlyNCaap5UChwdm7mQrXm+8/oWnAOjS22MmqiPv8Bv/DSQkdfACrh6xQmb6 e2YRD8VHufPNZb6TN8sg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mWBDT-00GiZv-A9; Fri, 01 Oct 2021 05:36:15 +0000 Received: from mail-pl1-x632.google.com ([2607:f8b0:4864:20::632]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mWBDO-00GiZb-RZ for linux-arm-kernel@lists.infradead.org; Fri, 01 Oct 2021 05:36:12 +0000 Received: by mail-pl1-x632.google.com with SMTP id y5so5593063pll.3 for ; Thu, 30 Sep 2021 22:36:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lixom-net.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lwPyxDqaGBhT92QACUI/bh+VkUYF5Oo/5CIkAxgdtZ0=; b=x4+eS/mPHFSaWAR3xsBgO23T1i0mXQSg5zBlZyUWrRmossN4sDE/RgApQuGNJSyKlx LRsdEA+fHhNG7b37ubODdSxT8Bf61fc21oJV4cGXpJkBnDvVg9UMLor5aANUxLMedr2U +4HtKL/belqPrhzcWZUz40RVVQaz/86inqcF15fBdN0ujQStvUBFnBY3/Z9OOntVQa+5 BbeZX0aEr6/mohhEefytrMODC7pyF+qHZR1t4VPvZGC75jGvIy9pllZ1e1zV6aIbzo8P ED8gZPdtk/O1HyOl+alpfG38L+LhsnZN6H74QHGaNOZIdj3Bu+r/bbX89ffqFthfzbgn 6A6w== 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=lwPyxDqaGBhT92QACUI/bh+VkUYF5Oo/5CIkAxgdtZ0=; b=B/zILfJOVTlDuZCSvC0qKm0oH2TGXpLXj55s82rBKiPfxKQfJXHeaStAcUvFPtpS3W JArJasFVSXMHv32ylvGcs+o/Vt2zwTzDqpEWfbCQ8aaUaXKutwvLlMw6T2DOrRzxE82q UKrqs8z/Oq1nQJcoGB8g7Hm0rDyz8vDR0J4a+mwB5xIY5WqI3RSvuJTxJ5Dayp+Gu+U4 06yL1Gth/+WOPfrAJOjvCw4j1ZrsOf2VIHlFtqmX5SGjRdOn3nHaul4QH54JJrCD/NQh SsxofRHlz2YWvipa9XXLCTVDbNtbDoaDEX0tjBECQPtxqppqTJSikbG8T3WPM/1RfIML YoeA== X-Gm-Message-State: AOAM532C8SBtn79bmwtQnGwx6ZUeo0QmKXSAZ9cBLQgrZyT4dz0QO2m2 Fe8dTnEXiIgEAf+Syu6MDl2uHW4M4yJOn2uxdwBRgA== X-Google-Smtp-Source: ABdhPJyXrHEjSRsbvGuDy1U26vszb5TEBTH/srDHAuSr9YR7iT8IG7gbwvXgl1d4rlALNdae0jk7Dkp7FchFO9bSadM= X-Received: by 2002:a17:90a:9317:: with SMTP id p23mr11101909pjo.151.1633066567459; Thu, 30 Sep 2021 22:36:07 -0700 (PDT) MIME-Version: 1.0 References: <20210928235635.1348330-1-willmcvicker@google.com> <7766faf8-2dd1-6525-3b9a-8ba790c29cff@canonical.com> In-Reply-To: From: Olof Johansson Date: Thu, 30 Sep 2021 22:35:55 -0700 Message-ID: Subject: Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs To: Saravana Kannan Cc: Will McVicker , 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 , Geert Uytterhoeven , "Cc: Android Kernel" , Linux ARM , Linux Kernel Mailing List , linux-samsung-soc , linux-clk , linux-gpio@vger.kernel.org, linux-rtc@vger.kernel.org, Arnd Bergmann X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210930_223610_940142_DEEC0FC0 X-CRM114-Status: GOOD ( 38.54 ) 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 Thu, Sep 30, 2021 at 10:24 PM Saravana Kannan wrote: > > On Thu, Sep 30, 2021 at 9:52 PM Olof Johansson wrote: > > > > On Wed, Sep 29, 2021 at 12:48 PM Will McVicker wrote: > > > > > > On Wed, Sep 29, 2021 at 6:02 AM Krzysztof Kozlowski > > > wrote: > > > > > > > > On 29/09/2021 01:56, Will McVicker wrote: > > > > > This is v2 of the series of patches that modularizes a number of core > > > > > ARCH_EXYNOS drivers. Based off of the feedback from the v1 series, I have > > > > > modularized all of the drivers that are removed from the ARCH_EXYNOS > > > > > series of "select XXX". This includes setting the following configs as > > > > > tristate: > > > > > > > > > > * COMMON_CLK_SAMSUNG > > > > > * EXYNOS_ARM64_COMMON_CLK > > > > > * PINCTRL_SAMSUNG > > > > > * PINCTRL_EXYNOS > > > > > * EXYNOS_PMU_ARM64 > > > > > * EXYNOS_PM_DOMAINS > > > > > > > > > > Additionally, it introduces the config EXYNOS_PMU_ARM64 and EXYNOS_PMU_ARM > > > > > which was previously EXYNOS_PMU and EXYNOS_PMU_ARM_DRIVERS respectively. > > > > > The reason for these new configs is because we are not able to easily > > > > > modularize the ARMv7 PMU driver due to built-in arch dependencies on > > > > > pmu_base_addr under arch/arm/mach-exynos/*. So the new configs split up > > > > > the ARM and ARM64 portions into two separate configs. > > > > > > > > > > Overall, these drivers didn't require much refactoring and converted to > > > > > modules relatively easily. However, due to my lack of exynos hardware, I > > > > > was not able to boot test these changes. I'm mostly concerned about the > > > > > CLK_OF_DECLARE() changes having dependencies on early timers. So I'm > > > > > requesting help for testing these changes on the respective hardware. > > > > > > > > > > > > > These are all not tested at all? In such case, since these are not > > > > trivial changes, please mark the series as RFT. > > > > > > > > I will not be able to test these for some days, so it must wait. > > > > > > > > > > > > Best regards, > > > > Krzysztof > > > > > > +Cc Arnd and Olof, > > > > > > Hi Krzysztof, > > > > > > To avoid the scrambled conversation from the first patchset, I'm going > > > to address all your general questions here in the cover letter thread > > > so that it's easier for everyone to follow and reference in the > > > future. > > > > This patchset shouldn't go in. > > > > GKI is a fantastic effort, since it finally seems like Google has the > > backbone to put pressure on the vendors to upstream all their stuff. > > > > This patcheset dilutes and undermines all of that by opening up a > > truck-size loophole, reducing the impact of GKI, and overall removes > > leverage to get vendors to do the right thing. > > > > It's against our interest as a community to have this happen, since > > there's no other reasonably justifiable reason to do this. > > Oolf, Geert, Krzysztof, Arnd, So close. > I skimmed through the emails and you all make a lot of good points. I skimmed through this email and I think it adds a lot of new complexity and fragility to solve a problem that doesn't really exist for upstream, adding yet more config parameter combinations to build and test for. 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. -Olof _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel