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=-7.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 94F5DC433F5 for ; Tue, 21 Sep 2021 08:35:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7C6DB61090 for ; Tue, 21 Sep 2021 08:35:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231223AbhIUIhY (ORCPT ); Tue, 21 Sep 2021 04:37:24 -0400 Received: from smtp-relay-internal-1.canonical.com ([185.125.188.123]:35006 "EHLO smtp-relay-internal-1.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231216AbhIUIhV (ORCPT ); Tue, 21 Sep 2021 04:37:21 -0400 Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-internal-1.canonical.com (Postfix) with ESMTPS id 3CE043F226 for ; Tue, 21 Sep 2021 08:35:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1632213353; bh=lQRT6EGGve1EBnMNNxr8uMFKa9VogaceuvltbqBrtr8=; h=To:Cc:References:From:Subject:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type; b=V5Ar01ZNphCZj8Na1gOBq7Qvw566jlPqmlah2+FMP6sGwGjQQBIBAddnPWWDOui/V jYoUBr+jqXfxAVibGMdUt3HHRK7nFKnTEEMtuywYzYIBmzUVqXa83I+QIr82LgGQEH XlSHAhSjfnXahYcxD90phiJzgzXCwvKZR/6YGtyG2fuYNN3HKiWGsAr2WThTCh19Z3 TGQc3agt+Nstl9FcYiNoqlbRXDWZ0iFX2MzQiblboKfIb/NrjrQernd2eej3URKiLU S/6u0gakPtlyYpj5ZbPNKCEYEnB0ncYo3Fayst6tM676U8lyRv+zsimf8czavu1WHL 6CjnrpVPIFmtA== Received: by mail-wr1-f69.google.com with SMTP id f7-20020a5d50c7000000b0015e288741a4so8198098wrt.9 for ; Tue, 21 Sep 2021 01:35:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:to:cc:references:from:subject:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=lQRT6EGGve1EBnMNNxr8uMFKa9VogaceuvltbqBrtr8=; b=ilh42GnQ9Y6M5YYpJZR77PWjKxJqpYitxkMLu6CtYuv+fnKuBBSU+TT300cWMGOquS cahx9zd5CgbR16ryftkmXoIxtq0Pedbpo0Zk2gOguVsPm6isQk2u6LLXRhxoHj19g7kf uSOSK0+WYnoB00r0o+hiLR8Orxh4aHDyPNMC07Q4mnqm96TwTTMKVlixIsF6AYO3pRt1 ODxvHHPS/c/JN2tmdEU/enAFkIiiU5JTKPbcvjfReXjKurJKyi9L4LZ1gQ4s9UEcUhDh 6kZYqyuk0nkSjhkhngK0Kzu7yWoHS9M1EjjIVArubQ6GoiSmu3FQyIdOa4cBXU3UadeP VA5Q== X-Gm-Message-State: AOAM532fA+GPBv/Z9/ZYs/Gz+uif4bMSOw2je8ldCO5bi5ovtkalsJ2S Tky9xtr7dSnl6U3fJ2Nw8nIcgoeVpppwgtJGR1kQ/KdRmNAmRfO6UVg17NfsdFSjzxo7QtHvVXJ fDjgprnD7n6zDEagg6pH4XdpfJdjDkDtqCvtXyrd3Aw== X-Received: by 2002:a7b:c142:: with SMTP id z2mr3357162wmi.10.1632213352914; Tue, 21 Sep 2021 01:35:52 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxDvUrXflYulapeJv6L1lTo5OVRdOzoWqHitDx/QOp0/pTxHCrxTBBq7VpLs3ZVu4Jpt3sotw== X-Received: by 2002:a7b:c142:: with SMTP id z2mr3357151wmi.10.1632213352769; Tue, 21 Sep 2021 01:35:52 -0700 (PDT) Received: from [192.168.0.134] (lk.84.20.244.219.dc.cable.static.lj-kabel.net. [84.20.244.219]) by smtp.gmail.com with ESMTPSA id c185sm2235289wma.8.2021.09.21.01.35.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 21 Sep 2021 01:35:52 -0700 (PDT) To: Geert Uytterhoeven Cc: Will McVicker , Catalin Marinas , Will Deacon , Sylwester Nawrocki , Tomasz Figa , Chanwoo Choi , Michael Turquette , Stephen Boyd , Lee Jones , Android Kernel Team , Linux ARM , Linux Kernel Mailing List , linux-samsung-soc , linux-clk References: <20210920190350.3860821-1-willmcvicker@google.com> <20210920190350.3860821-2-willmcvicker@google.com> From: Krzysztof Kozlowski Subject: Re: [PATCH v1 1/4] clk: samsung: change COMMON_CLK_SAMSUNG default config logic Message-ID: <2c8a79f7-711a-b075-745f-ea77b82a1117@canonical.com> Date: Tue, 21 Sep 2021 10:35:51 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 21/09/2021 09:50, Geert Uytterhoeven wrote: > On Tue, Sep 21, 2021 at 9:31 AM Krzysztof Kozlowski wrote: >> On 20/09/2021 21:03, Will McVicker wrote: >>> COMMON_CLK_SAMSUNG is selected by ARCH_EXYNOS which forces this config >>> to be built-in when ARCH_EXYNOS is enabled. Switch the logic to use a >>> "default y if ARCH_EXYNOS" to provide flexibilty for vendors to disable >>> or modularize this driver. >> >> The clock drivers are essential, you cannot disable them for a generic >> kernel supporting ARCH_EXYNOS. Such kernel won't work properly on platforms. > > Obviously it's not gonna work if the clock driver is not enabled > at all. But does it work if you make the clock driver modular, and > put it with all other essential driver modules in initramfs? Debugging > would be hard, as the serial console driver also relies on clocks > and PM Domains etc. The kernel could boot without clock drivers (default settings from bootloader), probe clocks from initramfs and proceed with rootfs from eMMC/SD/net. In theory. However I have no reports that it ever worked. If there is such working upstream configuration, I don't mind here. Just please explain this in the commit msg. > > If not, this patch should be NAKed, until it works with a modular > clock driver. > > If yes, perhaps another line should be added (_before_ the other line)? > > + default m if ARCH_EXYNOS && MODULES > default y if ARCH_EXYNOS > > However, many developers may want MODULES=y, but not want to bother > with an initramfs. So perhaps we need a new symbol > MINIMUM_GENERIC_KERNEL or so, protected by EXPERT, and make the > driver default to m if that is enabled? Yeah, that's indeed a problem to solve. For most users (and distros) building kernel for Exynos this should be built-in by default. Anyway, the option is non-selectable so it cannot be converted to "m" or disabled. And this is claimed in the commit msg: "provide flexibilty for vendors to disable or modularize this driver." The commit does not achieve it. Best regards, Krzysztof 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=-6.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 BAB5BC433EF for ; Tue, 21 Sep 2021 08:37:56 +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 8A8DA610E8 for ; Tue, 21 Sep 2021 08:37:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 8A8DA610E8 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=canonical.com 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:In-Reply-To:MIME-Version:Date: Message-ID:Subject:From:References:Cc:To:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Owner; bh=1ygd7gmMYf226Mnxd3kObzru6tPiXWz1xs+Xx2vPzBs=; b=zdJHKZh1FBbKazgt19PpNLTx40 uQZ7DqL3GPQesWzjCNxR2tBpZbZRaraV9wUzDH08P2P1IyE7R643BypuirCdyVVcjU7HAXVlgUV1k yUmxYSlfW2mN9J4aqApfZ1D3ewCBr+8dfBFf2DuEqu5GE803681Csk54SR3jH2BuTBGne0NIZHIPL 6FETPkRpSNMS7Q0fNuyEVBY9hGL0Az6mQxP/TrD6I/xsTncYDKe/kU3OaPiwI8463/UW5kOr+Vku6 e2tMh/rVus0Z3UIu2Pei+AicuJu2jUMWgVIqUJVR9nK9MYzs2TtG1pJ+20eqSeBjFGcD1APn8G+d4 PSIPDC1Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mSbFu-003xch-MI; Tue, 21 Sep 2021 08:35:58 +0000 Received: from smtp-relay-internal-0.canonical.com ([185.125.188.122]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mSbFq-003xbt-Oo for linux-arm-kernel@lists.infradead.org; Tue, 21 Sep 2021 08:35:56 +0000 Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-internal-0.canonical.com (Postfix) with ESMTPS id 3A5B73F335 for ; Tue, 21 Sep 2021 08:35:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1632213353; bh=lQRT6EGGve1EBnMNNxr8uMFKa9VogaceuvltbqBrtr8=; h=To:Cc:References:From:Subject:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type; b=V5Ar01ZNphCZj8Na1gOBq7Qvw566jlPqmlah2+FMP6sGwGjQQBIBAddnPWWDOui/V jYoUBr+jqXfxAVibGMdUt3HHRK7nFKnTEEMtuywYzYIBmzUVqXa83I+QIr82LgGQEH XlSHAhSjfnXahYcxD90phiJzgzXCwvKZR/6YGtyG2fuYNN3HKiWGsAr2WThTCh19Z3 TGQc3agt+Nstl9FcYiNoqlbRXDWZ0iFX2MzQiblboKfIb/NrjrQernd2eej3URKiLU S/6u0gakPtlyYpj5ZbPNKCEYEnB0ncYo3Fayst6tM676U8lyRv+zsimf8czavu1WHL 6CjnrpVPIFmtA== Received: by mail-wr1-f69.google.com with SMTP id z2-20020a5d4c82000000b0015b140e0562so8227397wrs.7 for ; Tue, 21 Sep 2021 01:35:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:to:cc:references:from:subject:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=lQRT6EGGve1EBnMNNxr8uMFKa9VogaceuvltbqBrtr8=; b=RSbJGd0zhRUTxDQFBNTiEOs/YA83eoa63IcyvzRIytmmm4JrLUhdlmIvnEEb9SUrpX nPgIsReNJQ/XvGTvB1NqXkESVSjsSrXGfdAri6ysPffyIb60V9VQgz12ld02n7UhcFP6 BQ7L2M1Fb1v5BM09vG25xXd7pdGvS2Eybaz1w42LJ93hQNV+W9uOyiqojlAIwmr4P3DO Cl9bTAsLJrI8onwlogHEY8xadjD5iFVOhtJO3e+KptIePPrfZyRHT7GKzNQJx5j3ymRs BQiUsD+2N9SF7Pm16gtNcc0QWFq2p9LtXS0kDWdUnaouoIDSqJ5Crkp5lbHGm4t+ht+5 s3vA== X-Gm-Message-State: AOAM531WUiQ8fkBt1x2sT0O1O6VCgonBXik9mFsDSiKJTIz2OYwNGJg2 qsbViFshMMFTfEbkpHy+MwS0wu+ylG7xDEWLMrIR8jCsW8isw2Sbek2mcFu35XeN7803Keqft/g q6PGLBweB37ppVMoi7lHr7uQr2GZCpMIP22rzNNYjRf2Ejm2ViYXY X-Received: by 2002:a7b:c142:: with SMTP id z2mr3357165wmi.10.1632213352914; Tue, 21 Sep 2021 01:35:52 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxDvUrXflYulapeJv6L1lTo5OVRdOzoWqHitDx/QOp0/pTxHCrxTBBq7VpLs3ZVu4Jpt3sotw== X-Received: by 2002:a7b:c142:: with SMTP id z2mr3357151wmi.10.1632213352769; Tue, 21 Sep 2021 01:35:52 -0700 (PDT) Received: from [192.168.0.134] (lk.84.20.244.219.dc.cable.static.lj-kabel.net. [84.20.244.219]) by smtp.gmail.com with ESMTPSA id c185sm2235289wma.8.2021.09.21.01.35.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 21 Sep 2021 01:35:52 -0700 (PDT) To: Geert Uytterhoeven Cc: Will McVicker , Catalin Marinas , Will Deacon , Sylwester Nawrocki , Tomasz Figa , Chanwoo Choi , Michael Turquette , Stephen Boyd , Lee Jones , Android Kernel Team , Linux ARM , Linux Kernel Mailing List , linux-samsung-soc , linux-clk References: <20210920190350.3860821-1-willmcvicker@google.com> <20210920190350.3860821-2-willmcvicker@google.com> From: Krzysztof Kozlowski Subject: Re: [PATCH v1 1/4] clk: samsung: change COMMON_CLK_SAMSUNG default config logic Message-ID: <2c8a79f7-711a-b075-745f-ea77b82a1117@canonical.com> Date: Tue, 21 Sep 2021 10:35:51 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210921_013555_052743_2EC80D50 X-CRM114-Status: GOOD ( 29.28 ) 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 21/09/2021 09:50, Geert Uytterhoeven wrote: > On Tue, Sep 21, 2021 at 9:31 AM Krzysztof Kozlowski wrote: >> On 20/09/2021 21:03, Will McVicker wrote: >>> COMMON_CLK_SAMSUNG is selected by ARCH_EXYNOS which forces this config >>> to be built-in when ARCH_EXYNOS is enabled. Switch the logic to use a >>> "default y if ARCH_EXYNOS" to provide flexibilty for vendors to disable >>> or modularize this driver. >> >> The clock drivers are essential, you cannot disable them for a generic >> kernel supporting ARCH_EXYNOS. Such kernel won't work properly on platforms. > > Obviously it's not gonna work if the clock driver is not enabled > at all. But does it work if you make the clock driver modular, and > put it with all other essential driver modules in initramfs? Debugging > would be hard, as the serial console driver also relies on clocks > and PM Domains etc. The kernel could boot without clock drivers (default settings from bootloader), probe clocks from initramfs and proceed with rootfs from eMMC/SD/net. In theory. However I have no reports that it ever worked. If there is such working upstream configuration, I don't mind here. Just please explain this in the commit msg. > > If not, this patch should be NAKed, until it works with a modular > clock driver. > > If yes, perhaps another line should be added (_before_ the other line)? > > + default m if ARCH_EXYNOS && MODULES > default y if ARCH_EXYNOS > > However, many developers may want MODULES=y, but not want to bother > with an initramfs. So perhaps we need a new symbol > MINIMUM_GENERIC_KERNEL or so, protected by EXPERT, and make the > driver default to m if that is enabled? Yeah, that's indeed a problem to solve. For most users (and distros) building kernel for Exynos this should be built-in by default. Anyway, the option is non-selectable so it cannot be converted to "m" or disabled. And this is claimed in the commit msg: "provide flexibilty for vendors to disable or modularize this driver." The commit does not achieve it. Best regards, Krzysztof _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel