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 0367DC433EF for ; Thu, 30 Sep 2021 12:08:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CA5E4615E2 for ; Thu, 30 Sep 2021 12:08:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348656AbhI3MKS (ORCPT ); Thu, 30 Sep 2021 08:10:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58326 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348161AbhI3MKM (ORCPT ); Thu, 30 Sep 2021 08:10:12 -0400 Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 78EA5C06176C for ; Thu, 30 Sep 2021 05:08:29 -0700 (PDT) Received: by mail-wr1-x42b.google.com with SMTP id d26so9658674wrb.6 for ; Thu, 30 Sep 2021 05:08:29 -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=5fh0H0/jWr4jNH0+hAgBKwSacygBp5h9lUF6Rwc7alg=; b=HIqt7cGoqJJQIOdZP/Foj7lyVcPXpPckL+e8J8hEPS4X5BlSOs75D2MjxEHS9sXSue nbXyguX+HL4GYHA7dWpjKcBET3bGYvPe72KAAwoANqo6Btaq5vPwpia5jJrEDeWEDktW 0HMh+lyxzlPBtMhRT9B0ZQvWnBV7LHyDFydMdObVoa5g8IGlAYhW08hb5bCVt1Qy0jWj 6k2dsf5VdMaSCvk7oZJoneYuu7ltzLCKfRmauxvWtELLuhjTNmsorbLqrSE7QHPUVsQx kIcJcP3UTpwijuDznHqx/qf1fHaST4O4HxV4+34cyYnzeVI5LyzyRaLVYyOlVAxli8dZ 5kwg== 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=5fh0H0/jWr4jNH0+hAgBKwSacygBp5h9lUF6Rwc7alg=; b=b83L/a1Y6GFQQm5obDkGDxKuEGvyMzhFgazL05yuOGA3PyJaL/8kH1y/N7ukXn+yoL uAzt23fUI5dkG22PmsUEJ0OfQ2OgQ2OhgAxLdKnMn2C/EKEYLBOw0WrPdn1CHi50xT1w kj0GP1LTi4mHjFY7Nxmpi5osPVoWxjZNLc/xybT0AegUjEOtb5sUnevKnHrDm0ct7e+i Abr8M2DYxF4NpSpTpZfuc/6DUDr2nYuccA5fkEIDOfapNwQbxxFht/KxHlBMDeb9a5Sl 6Ye72YBvxS2ShuY1l8uOCl2PSyJJdPhSHUomroe4LMLsa4XNjz/UmOUNBewTOmXzUlAg Go1Q== X-Gm-Message-State: AOAM530K5qyQ9KWLRI8JpDRre0ieMuwG94OoHxMev4AXZp12GQM/OtwL MxIgAboFpMiO+a0H56EpwUeeYQ== X-Google-Smtp-Source: ABdhPJybI7D4Op6CUpT3YQKDibjf3O8iYGR2Haw/KF8+iMJzOVuX0RjVV9HDMl4I/r5lf64HRvJ5gQ== X-Received: by 2002:a5d:6c65:: with SMTP id r5mr5727101wrz.85.1633003708018; Thu, 30 Sep 2021 05:08:28 -0700 (PDT) Received: from google.com ([95.148.6.233]) by smtp.gmail.com with ESMTPSA id k22sm2928865wrd.59.2021.09.30.05.08.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 30 Sep 2021 05:08:27 -0700 (PDT) Date: Thu, 30 Sep 2021 13:08:25 +0100 From: Lee Jones To: Geert Uytterhoeven Cc: Krzysztof Kozlowski , Will McVicker , 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 , Saravana Kannan , "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 , Olof Johansson Subject: Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs Message-ID: References: <20210928235635.1348330-1-willmcvicker@google.com> <7766faf8-2dd1-6525-3b9a-8ba790c29cff@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-kernel@vger.kernel.org On Thu, 30 Sep 2021, Geert Uytterhoeven wrote: > Hi Lee, > > On Thu, Sep 30, 2021 at 12:56 PM Lee Jones wrote: > > On Thu, 30 Sep 2021, Geert Uytterhoeven wrote: > > > On Thu, Sep 30, 2021 at 11:23 AM Lee Jones wrote: > > > > I've taken the liberty of cherry-picking some of the points you have > > > > reiteratted a few times. Hopefully I can help to address them > > > > adequently. > > > > > > > > On Thu, 30 Sep 2021, Krzysztof Kozlowski wrote: > > > > > Reminder: these are essential drivers and all Exynos platforms must have > > > > > them as built-in (at least till someone really tests this on multiple > > > > > setups). > > > > > > > > > Therefore I don't agree with calling it a "problem" that we select > > > > > *necessary* drivers for supported platforms. It's by design - supported > > > > > platforms should receive them without ability to remove. > > > > > > > > > The selected drivers are essential for supported platforms. > > > > > > > > SoC specific drivers are only essential/necessary/required in > > > > images designed to execute solely on a platform that requires them. > > > > > > Why? > > > > Because without them the image wouldn't functional on any level. > > > > But you're right, there is still no requirement for it to be built-in. > > > > > > For a kernel image which is designed to be generic i.e. one that has > > > > the ability to boot on vast array of platforms, the drivers simply > > > > have to be *available*. > > > > > > If the drivers are really essential/necessary/required, this precludes > > > running the generic kernel image on the platform that requires them, > > > making the kernel not sufficiently generic. > > > > If they are not at all present, then yes. However that is not what is > > being suggested. The essential functionality will be provided. Just > > not built-in. > > I really meant "essential/necessary/required to be built-in". Then I agree with you. My position is that if they don't *have* to be built-in, then why force it? > > > > Forcing all H/W drivers that are only *potentially* utilised on *some* > > > > platforms as core binary built-ins doesn't make any technical sense. > > > > The two most important issues this causes are image size and a lack of > > > > configurability/flexibility relating to real-world application i.e. > > > > the one issue we already agreed upon; H/W or features that are too > > > > new (pre-release). > > > > > > True, if "potentially". If not potentially, they must be included. > > > > I'm not sure what you're trying to say here. Would you mind elaborating? > > It was a comment to your "*potentially* utilised on *some* platforms". > It is clear they are not used on the other ("not *some*") platforms, but your > sentence was unclear whether they are always or only sometimes used on > "*some*" platforms. > "always" => "not potentially" > "sometimes" => "potentially". > > I hope this makes it more clear. Not really, but I'll try to clean mine up: The aim is to have a single kernel (image + modules) that can be booted on a plethora of platforms. For the sake of argument say 10. Let's also say that each of the platforms are equal and will be booted the same amount of times. Taking the example above, when I say that the H/W specific drivers will only be *potentially* utilised, I mean that they will only be bound and probed 1/10 times i.e. when booted on the associated platform. Which means that in the vast majority of boots (9/10) they will lie dormant, taking up unnecessary space. Another way to say this would be; the kernel needs to have the capability to boot all of the supported platforms, but it will only ever be utilised on one at a time. > > > > Bloating a generic kernel with potentially hundreds of unnecessary > > > > drivers that will never be executed in the vast majority of instances > > > > doesn't achieve anything. If we have a kernel image that has the > > > > ability to boot on 10's of architectures which have 10's of platforms > > > > each, that's a whole host of unused/wasted executable space. > > > > > > The key here is if the driver is required or not to use the platform, > > > and why it is required. If the requirement comes from some deficiency > > > in the kernel code or config system, it should be fixed, if possible. > > > And the fix should be tested. > > > If it cannot be fixed, the driver should be included, else it would > > > preclude running the generic kernel on the affected platform. > > > > Sorry, I'm not following. > > It all depends on why the driver is "required to be built-in". > Depending on the reason behind that requirement, the driver can be > changed from built-in to modular without ill effects on functionality. Absolutely. There are cases where drivers simply can't be built as modules. These unavoidable situations are legitimate use-cases and the technology/ code-base will have to work around these as required. The argument here is that if they can be separated and have been shown to work well in either use-case, then it is my opinion that placing an artificial barrier up based mostly on politics is not the correct approach. -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog