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 18977C433F5 for ; Fri, 1 Oct 2021 06:31:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 02B3B61A65 for ; Fri, 1 Oct 2021 06:30:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1352378AbhJAGcm (ORCPT ); Fri, 1 Oct 2021 02:32:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55832 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1352314AbhJAGce (ORCPT ); Fri, 1 Oct 2021 02:32:34 -0400 Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E68A6C061773 for ; Thu, 30 Sep 2021 23:30:50 -0700 (PDT) Received: by mail-pj1-x1031.google.com with SMTP id g13-20020a17090a3c8d00b00196286963b9so8522858pjc.3 for ; Thu, 30 Sep 2021 23:30:50 -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=cFaWGqP2C9gymM7/xIsnUKhVwQDKbxB31NvGBdiYcLA=; b=4ocJW6VsE5Ak+SaEWbMlGHnwUTU9mu716bs6zxu6tAUfmGk7yE5iplL38jYh3kA/KL eeMU7inGCL3k2iHWHOINlMkO3QWTPaoP/nXdQf3VOnRvbkZ+PDCaZrDWCQpx8BsttabS CK3d8lKluQkN02sVYw/hGwF/tpcBSvr8qxqIk4zhaudgU111Dl93oeyNYddynt+zKLai ICYJOyZMKmY8kOpFOuaGbUylu09CBNQ6PlLnvdtXpWCGSFh5Nu+K08COIIptOvrPuUlM zIPgWdgCE7LICZKVNF+RklvjO6335j2YDh9XvAdcavHfeZ6SHHP54wV/uEVdnzLHAyhG TGug== 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=cFaWGqP2C9gymM7/xIsnUKhVwQDKbxB31NvGBdiYcLA=; b=k2BzpXkTkKRFthfQGFK0r9cW1EdROAwZ4DPZjnIXrch02W9JU5PQDmKxwDS5Y1VH07 EAx6IZ2CPmjMwFufgyjg2s23iavxO7aifg0hYHloV8EnhfR84/H4YuWFrahM5pRdWCcN hfjRT9CL8dt+EKvHj5SQrS9/vvYOYzikSkjf4URtlbpDTMsEgDYhi5pABr+Eaniwd19K H2nLJKjZPA5D43RTq6FLQSuJbHbwRBbitVYrT1DAbqaDe5iPhH31+hLQxA65KwVtdyon 1fcKJSsGBmsQ2FEb22Q++mR2gNGaMl8QVSBeVkrFDeKnsc75qf6+q881BgLJYRmm3jwN tQpQ== X-Gm-Message-State: AOAM5306pji816fejgxjeO4iq7h4MAMswiGcWVXIJbld6vPeZnM11E8a 4R4NezljKvruIX8AO2VvC0Htcx5+u2mxGOJD6M+W6w== X-Google-Smtp-Source: ABdhPJzugW2gRpjUhIx7TVpMheVS0CqLw1m8cGY1dM+98GPdSokT3IcybwpvmxO8Q8v7apOWVV89E0+k35pmEy/if2M= X-Received: by 2002:a17:90a:5ac2:: with SMTP id n60mr11297133pji.184.1633069850324; Thu, 30 Sep 2021 23:30:50 -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 23:30:38 -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-samsung-soc@vger.kernel.org On Thu, Sep 30, 2021 at 11:27 PM Olof Johansson wrote: > > On Thu, Sep 30, 2021 at 11:03 PM Saravana Kannan wrote: > > > > On Thu, Sep 30, 2021 at 10:36 PM Olof Johansson wrote: > > > > > > 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'm sorry, it's pretty late here and I'm sleepy and messed it up. > > This email thread will be here in the morning too, this is the last > reply I will make tonight myself. > > > > > 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. > > > > How is this not an upstream problem? Having a minimal kernel with as > > many drivers as modules is of interest to upstream. And what's the > > complexity in having a config to easily disable a bunch of configs? > > The new config gives a clear config against which new > > platforms/systems should be developed against. > > The approach for general kernel upstream has been to have the built-in > drivers needed to reach rootfs and runtime load the rest from there. Correction: The intent for our own multiconfigs have been this. If people want to go more granular and allow for modules of their core drivers, we have never pushed back (but the rest of the argument still stands). > For downstream embedded kernels, the right answer is to just exclude > the drivers you don't need. > > I agree, some of this is probably useful work but > 1) It was posted as a burden on the maintainers of the legacy > platforms to test and make sure it's not broken > 2) It regresses distro configs, which we do care about > 3) Based on the above, it's unclear whether the people pushing for > this patchset cares about the existing platforms, they're looking to > solve a different problem > > I didn't go back and look at who and where, but the person who started > justifying this work with making it easier for out-of-tree vendors to > integrate their non-contributed code killed this patchset. > > Would the out-of-tree argument on its own kill it? No, but the above > complexities/cost, plus the actual intent behind the patchset did. > > > > 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. > > > > Sure it would help memory after boot, but it won't help with size on > > "disk", kernel load time, etc. And some of the devices have very tight > > boot requirements. Think battery operated outdoor cameras for example. > > I would question the choices made if someone ships a camera with a > generic kernel (without a generic filesystem which at that point also > needs sufficient storage such that the kernel image size becomes a > secondary consideration). Once your storage is that constrained the > balance shifts towards a custom minimal config. > > > -Olof