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=-5.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 515A9C433EF for ; Tue, 21 Sep 2021 08:41:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 31D926124A for ; Tue, 21 Sep 2021 08:41:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231277AbhIUIme (ORCPT ); Tue, 21 Sep 2021 04:42:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41286 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231269AbhIUImd (ORCPT ); Tue, 21 Sep 2021 04:42:33 -0400 Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6AAC7C06175F for ; Tue, 21 Sep 2021 01:41:05 -0700 (PDT) Received: by mail-wr1-x435.google.com with SMTP id u15so36834040wru.6 for ; Tue, 21 Sep 2021 01:41:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=Jpo5hVx8FocmwTc1vBarjOAvcclKIu4PIomViQO7n7o=; b=sXGd/CWVpW8T0oDZMr7aFCXoqz8iL5jce66I3q3miAC0b3bP2wp9kbmEO0y+bNhIhM eJbm7KcynwZQ4Ncg6SOVssxvJOMntvanrOGx7BLr+OS2gtjCXhIzgL8pPRxXgUufNEpO SfUv8Cwj91XCM1jMIrtjcJvbqmybo9mVbR1LBtZLwomkFTJCUPY51CzHLrCAdjpo2rRx Yz8kkMt/4/JdBlYt26/EI79Kf2xP6gbcRu1gRZZyTb6vCK5QyJ0P//dCYv+6Av0Ko5vv 8BjOZ5SxtwRzhZkBo8/ySVYiluiK85TWRTXut+FwhGPMASjaojRaacV90LRCtxecb1my eCZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=Jpo5hVx8FocmwTc1vBarjOAvcclKIu4PIomViQO7n7o=; b=I4XJAPz18XPax59mm+hrHsRLDbX1CZdX4ba40xKVRqMMSOwetzg9UacgK+DZMeRyU/ 5SkF+o4+YD2Ld+v269iG8h2jPg+3waOv41EV8G02kNJRzl2qXBeHMdk24JRm7cQgccjE oHmn90pYZJOUC8Wi5pqAJDoPQxSnvr9yW4lP5d2t2vmvsvOBw21kwE08ekXwwuEqCht4 W0/xTVTIZCjIhpqlqHq+AHWHFyUnSr5cdsdSBbo5CviQagVCQmJvv+ale1isUDh8psSP Ok2fdh4fRQKQvlwUre5uFCraEB3x/VNOI3+IJ2gJeDYKChI7PAoQIL+PLjxsUNYN2qBw 1LUQ== X-Gm-Message-State: AOAM533Apn/J9bFhiBXA7OZuA0uKhGTb1KL7Du6KU3QjGi/9Yy4jpppR fHAoFTbi0G//CuZayi5jMOeC7A== X-Google-Smtp-Source: ABdhPJyVa4q4Tr9xInJmFQ4KLGfuU0f32NWO99Wuwos1Hr/1lN0IZskRsr47p4hltHVfBz5jFqK1zw== X-Received: by 2002:a5d:4e90:: with SMTP id e16mr33059922wru.243.1632213663872; Tue, 21 Sep 2021 01:41:03 -0700 (PDT) Received: from google.com ([95.148.6.233]) by smtp.gmail.com with ESMTPSA id y197sm2403557wmc.18.2021.09.21.01.41.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 21 Sep 2021 01:41:03 -0700 (PDT) Date: Tue, 21 Sep 2021 09:41:01 +0100 From: Lee Jones To: Krzysztof Kozlowski Cc: Will McVicker , Catalin Marinas , Will Deacon , Sylwester Nawrocki , Tomasz Figa , Chanwoo Choi , Michael Turquette , Stephen Boyd , Linus Walleij , Alessandro Zummo , Alexandre Belloni , kernel-team@android.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-samsung-soc@vger.kernel.org, linux-clk@vger.kernel.org, linux-gpio@vger.kernel.org, linux-rtc@vger.kernel.org Subject: Re: [PATCH v1 0/4] arm64: Kconfig: Update ARCH_EXYNOS select configs Message-ID: References: <20210920190350.3860821-1-willmcvicker@google.com> <7735b09c-cf1c-5e37-a737-9a330fbacf1e@canonical.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-clk@vger.kernel.org On Tue, 21 Sep 2021, Krzysztof Kozlowski wrote: > On 21/09/2021 10:11, Lee Jones wrote: > > On Tue, 21 Sep 2021, Krzysztof Kozlowski wrote: > > > >> On 20/09/2021 21:03, Will McVicker wrote: > >>> This patch series tries to address the issue of ARCH_EXYNOS force selecting > >>> a handful of drivers without allowing the vendor to override any of the > >>> default configs. This takes away from the flexibilty of compiling a generic > >>> kernel with exynos kernel modules. For example, it doesn't allow vendors to > >>> modularize these drivers out of the core kernel in order to share a generic > >>> kernel image across multiple devices that require device-specific kernel > >>> modules. > >> > >> You do not address the issue in these patches. The problem you describe > >> is that drivers are not modules and you are not changing them into modules. > > > > The wording is unfortunate. The reason for this change doesn't have > > much to do with kernel modules. > > > > Let's go back in time 18 months or so when Greg KH submitted this [0] > > patch, which you Acked. Greg was trying to solve the problem of not > > having to enable ARCH_EXYNOS on kernels which are designed to be > > platform agnostic (sometimes called Generic Kernels). For some reason > > SERIAL_SAMSUNG is the only symbol with these dependencies, so the > > solution seemed simple and straight forward at the time. > > > > However, For sound reasons Geert NACKed the patch. > > > > Quoting from [1] he says: > > > > "A generic kernel will include Samsung SoC support, hence > > PLAT_SAMSUNG or ARCH_EXYNOS will be enabled." > > Yes, it's correct reasoning. There is also one more use-case - > non-upstreamed (out of tree) platform which wants to use Exynos-specific > drivers. Something like was happening with Apple M1 except that it got > upstreamed and we do not care much about out-of-tree. > > > However, since the entry for ARCH_EXYNOS *insists* on building-in a > > bunch of other symbols (via 'select') which will be unused in most > > cases, this is not a currently acceptable approach for many Generic > > Kernels due to size constraints. > > In the mainline kernel there is no such use case. If you want to have > Exynos-whatever-driver (e.g. SERIAL_SAMSUNG or S3C RTC), you should > select ARCH_EXYNOS because otherwise it does not make any sense. Zero > sense. Such kernel won't work. > > It makes sense only if there is some other work, hidden here, where > someone might want to have SERIAL_SAMSUNG or S3C RTC without > ARCH_EXYNOS. Although GKI is not that work because GKI kernel will > select ARCH_EXYNOS. It must select ARCH_EXYNOS if it wants to support > Exynos platforms. > > Therefore I expect first to bring this "some other work, hidden here" to > broader audience, so we can review its use case. AFAIA, there really isn't any GKI specific code. Everything that can be upstreamed, is upstreamed. The delta consists of some vendor over-rides (implemented using trace events/hooks spread out over the code-base), lots of function exports (non-upstreamable due to no upstream user) and some defconfig/fragments. There really is nothing else to share/upstream/unhide. The only thing GKI needs is a little Kconfig flexibility above what is currently offered. > > What this patch does is migrates those symbols from being 'select'ed > > (always built-in with no recourse) to 'default y'. Where the former > > cannot be over-ridden, but the latter can be via a vendor's > > defconfig/fragment. > > It cannot be overridden by vendor fragment because options are not > visible. You cannot change them. > > The patch does nothing in this regard (making them selectable/possible > to disable), which is why I complained. 100% agree. As I commented in the other patch, this was a good point that should be addressed > > I doubt many (any?) of these symbols can be converted to kernel > > modules anyway, as they are required very early on in the boot > > sequence. > > True, some could, some not. Also some platforms are set up via > bootloader, so actually could "survive" till module is loaded from some > initrd. If these could be turned into modules, that would be even better! -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog