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 2726CC433FE for ; Thu, 30 Sep 2021 11:25:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 14462619E2 for ; Thu, 30 Sep 2021 11:25:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1350403AbhI3L1B (ORCPT ); Thu, 30 Sep 2021 07:27:01 -0400 Received: from mail-vs1-f45.google.com ([209.85.217.45]:36374 "EHLO mail-vs1-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1350389AbhI3L1B (ORCPT ); Thu, 30 Sep 2021 07:27:01 -0400 Received: by mail-vs1-f45.google.com with SMTP id h30so6827497vsq.3; Thu, 30 Sep 2021 04:25:18 -0700 (PDT) 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=E4u4EeOna6gGNv61tDuQLud+cv6R+yD4WKIZiYqhxYg=; b=zn8BNuAI0rLInOaw/ZpK4o1yqL6gKx2eTIvX+mEP1POejojkK7mnyPpUZBgd3kksNb /0iC/5xOMt+taNQxtlAVP+sTsfkLEAT8jj/iRXyMVuVgJ4IoqIs9RXLxzivn4VCKGhLp ZpC1m/RFtI4Uuqk96wCEXBkbYHs3z0g4GLJI+IqBkdtx5A7jGwqmBJjVSVtwSRBlbyhC nwqI6uWzaLPEkBhjgBV841pVhiKHHBoBVZ+a3x2rRFqVO3voF/yRRlBcJQKCCsTydb+q IJBj0IvWuROW0MiaDVRnXbR519zsDlOaWZJ17icrwvuE6ZS6ey5bRFu2bUlxJeXzoE3X 9tJg== X-Gm-Message-State: AOAM531+GGYarzWxhtSVX3skBlbCqiTuc6gBlmmCj5HDkUv3FyP8J0Ti krZH8T03fxMNBuhQGK9d7QK59aMcRtjBTjJpxTM= X-Google-Smtp-Source: ABdhPJwtYPhT4dVxPEB3GWtrVuwFV+A5f63KMP1Llp8OL6G+fNBMIp1rXsoQDwNXodcMK35TqjyhIHusevl27khUwZg= X-Received: by 2002:a05:6102:21d4:: with SMTP id r20mr2796665vsg.50.1633001117937; Thu, 30 Sep 2021 04:25:17 -0700 (PDT) MIME-Version: 1.0 References: <20210928235635.1348330-1-willmcvicker@google.com> <7766faf8-2dd1-6525-3b9a-8ba790c29cff@canonical.com> In-Reply-To: From: Geert Uytterhoeven Date: Thu, 30 Sep 2021 13:25:06 +0200 Message-ID: Subject: Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs To: Lee Jones 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 Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org 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". > > > 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. > > > 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. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds 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 69946C433EF for ; Thu, 30 Sep 2021 11:27:55 +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 32E8D61452 for ; Thu, 30 Sep 2021 11:27:55 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 32E8D61452 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-m68k.org 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=BCficQ2N9CaycpUSpvDJN4Lxkf4897U1j87Kp0PCYs0=; b=N1FIwEUpVGmv92 yKgBkXEcU/gKPN+zhdvYduOn8A+8dFGajrj4u7FmSbJA3VFK6fZRsXg/4YusHeqS+DRiB58rvFsSS n6rFZYYuP4BNng+vTezvau1G44xSNWJ64SrKjkeKhpXzOfR1eb5r8Q9VDBvOwRzDsK5Lqk9XuHq/9 IQIouoktOHjw7oNtYo26q6LH8oldDZoLTn0cPzOwHJc8Aj60GTFffG4zJHJuPKLBldSR5h1Es9DCx kD76mKQ4F1z8vOLOBskC9OocdIsUdFmSGqEHneMHLwrCEKO/+aL3ohCj4y3v0J+0dVt7ty0R0MeSU X+4zizEhV9G0Zpqv8dBQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mVuBm-00E1WE-Qf; Thu, 30 Sep 2021 11:25:23 +0000 Received: from mail-vs1-f45.google.com ([209.85.217.45]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mVuBi-00E1Vf-Vs for linux-arm-kernel@lists.infradead.org; Thu, 30 Sep 2021 11:25:20 +0000 Received: by mail-vs1-f45.google.com with SMTP id z22so5165530vsp.1 for ; Thu, 30 Sep 2021 04:25:18 -0700 (PDT) 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=E4u4EeOna6gGNv61tDuQLud+cv6R+yD4WKIZiYqhxYg=; b=Nk/g1uTRVJR4Z8qp+ONhTYhwY8C2ch+5gJCyfTZedkvnhWVMq9oOsNrZ1+M2aj8oCe PMEzJAm/2V9ktDtTit4L+LLT3hfdgeuWGkkeHifwMOiqWpCz2aiOmdxBNpNqeTTbRsru nUZ4JqhK61q9o4byak4yz0R30P17rwNEahqkmy4OCxVfE8AAlH9+r2ZCJDu6R4nrL6OF vBt75aGzFY92o6UBAtWLgFf6n3nKWhd+EwvoRNz8XmMFTtm8fmrPVU+XrIjD1AWChTbC 0FxhjKZnyHldwQ8TnCijO/Ao5BqPHZgvvJf5/o/p3DgBXW9w/Lit6OBNR6M8TScmxmi+ TU1g== X-Gm-Message-State: AOAM533H7yBINnm0dHp1hjnKD/ff0CsByvrzlmjKm309Bv5bYpdLcQwW 5q90NkNHemmTttQbjRTbCISLyf2vqZsTTc2SuFY= X-Google-Smtp-Source: ABdhPJwtYPhT4dVxPEB3GWtrVuwFV+A5f63KMP1Llp8OL6G+fNBMIp1rXsoQDwNXodcMK35TqjyhIHusevl27khUwZg= X-Received: by 2002:a05:6102:21d4:: with SMTP id r20mr2796665vsg.50.1633001117937; Thu, 30 Sep 2021 04:25:17 -0700 (PDT) MIME-Version: 1.0 References: <20210928235635.1348330-1-willmcvicker@google.com> <7766faf8-2dd1-6525-3b9a-8ba790c29cff@canonical.com> In-Reply-To: From: Geert Uytterhoeven Date: Thu, 30 Sep 2021 13:25:06 +0200 Message-ID: Subject: Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs To: Lee Jones 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210930_042519_049507_F22BAA33 X-CRM114-Status: GOOD ( 51.91 ) 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 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". > > > 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. > > > 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. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel