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.2 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,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 B3C0CC433F5 for ; Tue, 21 Sep 2021 18:04:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9E0DE61242 for ; Tue, 21 Sep 2021 18:04:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232435AbhIUSGA (ORCPT ); Tue, 21 Sep 2021 14:06:00 -0400 Received: from smtp-relay-internal-1.canonical.com ([185.125.188.123]:58078 "EHLO smtp-relay-internal-1.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232289AbhIUSFz (ORCPT ); Tue, 21 Sep 2021 14:05:55 -0400 Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) (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 0107C40257 for ; Tue, 21 Sep 2021 18:04:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1632247466; bh=E+U9M1hOnkJj7BjeE3jXuEWq5COKAKZc20zg2UQGqwg=; h=Subject:To:Cc:References:From:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type; b=E4Tpw2VtkkYkmzX/9/r0Yob0hHIlSSWudii5+rhPv/mYbTpRFyEhI/OON+tUjFg4y LDD1bKItJ89Co2YfUL6Kyua2Vd5lqg+r0mSxcnGR//8H1kZVZQAB4+2DT5S6/o9wTz 1e3sz2yD/iRV0sKMwwpxQCGDCWdHqNkz8Z2boFfOUSlDUfp1JARZI2AfKPONN7dC6+ 7Zipirni4ikxJ+6LSe3a6cMHXP4WlluPVTWod5GjmN6D7YupAjgfu9kL2nuItO1NCr s+ygtEhQNZdDdBc8c8pGw24gYX+rmqR5MjLK6jooqIhrWsRp7ttbLfb1E/SZYiACt4 L2llOXULKIn9A== Received: by mail-wr1-f72.google.com with SMTP id v1-20020adfc401000000b0015e11f71e65so9542539wrf.2 for ; Tue, 21 Sep 2021 11:04:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=E+U9M1hOnkJj7BjeE3jXuEWq5COKAKZc20zg2UQGqwg=; b=t25ZmDQwwrgCUWxLWdjHm1wG44AwMLgolVvf4GntpS2hKCmxCd8JTanpXqaNl8BJNT t/hVqNDnSY84wRtVszAg3NLjHpV2nHULc0mzoOT3HIbKmK5TexiiGGPu/Szvfs4vgame GqL0CtwxrgsS2YF4filKClOcOorUG9t3RYvphjS1TSjXaFklWj/p+QK6qD1sONONyOAi lROHXFVaAMY8CKgyF3DBP1+J4/Ng3UKfjcmmq+YbQCRbTy+Ss8vKELe/zPmpRLLQ+b7e RuWNFcszVYJsg2PCeTIzujOJ+LzHX+9JzM28daHcwU51lr1EHmRRaGYAidgWZP5ugJwc z0Ig== X-Gm-Message-State: AOAM5326BWLB81jm4ym4M8+Ui2dkSvfFGsBhBJ7jb8w+a7Nd03WwfAK5 1aJWYxeBDNk9s0IgZRe5xnkQiqR4F9mLZnqzyoK4UVLGG/WzGak+a8L4B5EKgBU22IEM33fnMcU f9PHWsOZZ2Cz8JNJhmbU+ikWhDMI5m23eIrhuj7Ngng== X-Received: by 2002:a05:600c:4a16:: with SMTP id c22mr6106903wmp.72.1632247465503; Tue, 21 Sep 2021 11:04:25 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx0/tb/AS73ULX2b3IOIxReTNR7zjlkrcMrJj7f6rnKykXODM+qPZZEH9ABX/TMOHQ2+StX+g== X-Received: by 2002:a05:600c:4a16:: with SMTP id c22mr6106863wmp.72.1632247465152; Tue, 21 Sep 2021 11:04:25 -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 a72sm3736431wme.5.2021.09.21.11.04.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 21 Sep 2021 11:04:24 -0700 (PDT) Subject: Re: [PATCH v1 1/4] clk: samsung: change COMMON_CLK_SAMSUNG default config logic To: Will McVicker Cc: Geert Uytterhoeven , 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> <2c8a79f7-711a-b075-745f-ea77b82a1117@canonical.com> From: Krzysztof Kozlowski Message-ID: <001cd621-53d1-fe22-0eaa-d13137827297@canonical.com> Date: Tue, 21 Sep 2021 20:04:23 +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: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 21/09/2021 19:58, Will McVicker wrote: > On Tue, Sep 21, 2021 at 1:35 AM Krzysztof Kozlowski > wrote: >> >> 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 > > Thanks for the reviews! As Lee has explained in his replies, the > intent of this series is to provide config flexibility to create a > defconfig that allows us to move out SoC specific drivers in order to > create a generic kernel that can be used across multiple devices with > different SoCs. That's quite generic statement... or let me put it that way - we already have this ability to create a generic kernel supporting different SoCs. Exynos and other ARMv7 and ARMv8 platforms are multiplatform. Task is done. Please be more specific about use case and describe what exactly in current upstream multiplatform kernel is missing, what is not multiplatform enough. > I'm sorry I added confusion by mentioning > modularization. All of these drivers that I am modifying in this > series can be modularized which is an ongoing effort, but is not > addressed here and I don't believe that modularizing them should be a > requirement before supporting enabling/disabling them. Since the disabling the driver for a kernel supporting Exynos does not make any sense, then making it at least modular unfortunately it is a requirement. > I will update the series with my patch that refactors the Samsung SoC > drivers menuconfig to make these visible as well. I would first recommend to really describe your use case because my questions about this are still unanswered. 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 F3D4EC433EF for ; Tue, 21 Sep 2021 18:07:02 +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 C40EA60527 for ; Tue, 21 Sep 2021 18:07:02 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org C40EA60527 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:From:References:Cc:To:Subject:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Owner; bh=qpRMsGT6YTC82e6f8k78pYuEiH6AikWsO9Laxp2NQao=; b=UKgD6LqGpQEL4hEhx2odBbtc2c zTXD+FxAUotWy4pBqQRG0iUc0fPIxN5Jk3AWQcdRoARev5KdhIqVPGNADHQ6QTc6S24pIxYHJSiUj F85pfKjPYXUTtCMFnksn50YA8/YI5t4YriGPb2B9AFN657POiCz/c4doglFIAcrgMf43KUcdTrCKf Ax7Y7zmVwZqEGWDA+SyBmzYwWMmBD5SmDjZy48kgoQU1Pje1jn8N6PmDXTMfJ+twncupz+wtr2Ay6 fJB7KP5ugs/RaCBRhbZMDtg5E7eW14aIfmFiWgyoXvmMWXul+W0qB97uO90Ojlvwe/pzC8crAmff6 q0ibz1QA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mSk8B-005ReE-RO; Tue, 21 Sep 2021 18:04:36 +0000 Received: from smtp-relay-internal-1.canonical.com ([185.125.188.123]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mSk88-005RdA-1S for linux-arm-kernel@lists.infradead.org; Tue, 21 Sep 2021 18:04:33 +0000 Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) (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 C9B333F4BE for ; Tue, 21 Sep 2021 18:04:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1632247465; bh=E+U9M1hOnkJj7BjeE3jXuEWq5COKAKZc20zg2UQGqwg=; h=Subject:To:Cc:References:From:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type; b=aUdU70iYJiKJweujBGSx4YQfiBhZJARkozcMg28vb6YFOIYL4GolCdZdI+7EpSUEi IqIFYKbCVqRIP1iIUvbzbTsW7LPoE79pHaaFe15awnblNOYNRBmjARL7F3vzlNQ/ON cazS4TnkFxEMUtaTQ7mACC1+RC01A9ig5BRwx2IgrV3m6Aos3ED45VdZ56uBgGXN2G g7LT2+azU+u3tHpFB0j7740espbk0S1kfAipCexhUqF72AXTBuSTG776o/k4sxHOXN Xx4W9ZOHZw5/2w36TLaEYDDOoCJyw0Qxq8u+EjeT9GxIIz3Iueq26ZQAcmhtqtYNae 6/wXYLF7hKpBg== Received: by mail-wr1-f72.google.com with SMTP id i4-20020a5d5224000000b0015b14db14deso9508535wra.23 for ; Tue, 21 Sep 2021 11:04:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=E+U9M1hOnkJj7BjeE3jXuEWq5COKAKZc20zg2UQGqwg=; b=QzCdOI8rylijoa5fun4ifzZwUkqXAAn7cJ/Q9fMHrbxexraq6B2HREYLzmbyvmei72 tqOsWZhcM0bR/9kR0ZcguiT6NWjc5PwZkuMAjpeX2XvUFBHjsaQyzldnX5iejHO9twwd sv1afqywONdPYtbhn/ki/K/bluqmAuLvA0aTbwe4GG/yII1k/WyBSP5hmRstyU2GXh0C L8jdx8D6bCal5jRF4D2FYhxfXVLN9TrbK90B/VRuokxMV5oxJNPhhc+GnLefK08lYcX0 rRkEi3ikZbxKLrIFemEjpWM7Trj99JGgpJFuDZTDleB/a6uNl2aQMIBJ/Z7S1gz/9rkK MPhQ== X-Gm-Message-State: AOAM531huVLddMnVF3aZ1UEJ4mWdCIzoNiLibERz838aF8rcEtl04o4w 5snjWcKMTSaiqTI71NhqjxclZwGGe2CvX6inWUHRfNqA+VZhM0mBUoteUGqP73O6fGj1A2mUvfh MYR8/OeUgIIWNnbN35voh+nw1QpdaYXc5gTSjgd7ezufU23uEiMDY X-Received: by 2002:a05:600c:4a16:: with SMTP id c22mr6106888wmp.72.1632247465401; Tue, 21 Sep 2021 11:04:25 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx0/tb/AS73ULX2b3IOIxReTNR7zjlkrcMrJj7f6rnKykXODM+qPZZEH9ABX/TMOHQ2+StX+g== X-Received: by 2002:a05:600c:4a16:: with SMTP id c22mr6106863wmp.72.1632247465152; Tue, 21 Sep 2021 11:04:25 -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 a72sm3736431wme.5.2021.09.21.11.04.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 21 Sep 2021 11:04:24 -0700 (PDT) Subject: Re: [PATCH v1 1/4] clk: samsung: change COMMON_CLK_SAMSUNG default config logic To: Will McVicker Cc: Geert Uytterhoeven , 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> <2c8a79f7-711a-b075-745f-ea77b82a1117@canonical.com> From: Krzysztof Kozlowski Message-ID: <001cd621-53d1-fe22-0eaa-d13137827297@canonical.com> Date: Tue, 21 Sep 2021 20:04:23 +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_110432_267974_E792AD70 X-CRM114-Status: GOOD ( 38.65 ) 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 19:58, Will McVicker wrote: > On Tue, Sep 21, 2021 at 1:35 AM Krzysztof Kozlowski > wrote: >> >> 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 > > Thanks for the reviews! As Lee has explained in his replies, the > intent of this series is to provide config flexibility to create a > defconfig that allows us to move out SoC specific drivers in order to > create a generic kernel that can be used across multiple devices with > different SoCs. That's quite generic statement... or let me put it that way - we already have this ability to create a generic kernel supporting different SoCs. Exynos and other ARMv7 and ARMv8 platforms are multiplatform. Task is done. Please be more specific about use case and describe what exactly in current upstream multiplatform kernel is missing, what is not multiplatform enough. > I'm sorry I added confusion by mentioning > modularization. All of these drivers that I am modifying in this > series can be modularized which is an ongoing effort, but is not > addressed here and I don't believe that modularizing them should be a > requirement before supporting enabling/disabling them. Since the disabling the driver for a kernel supporting Exynos does not make any sense, then making it at least modular unfortunately it is a requirement. > I will update the series with my patch that refactors the Samsung SoC > drivers menuconfig to make these visible as well. I would first recommend to really describe your use case because my questions about this are still unanswered. Best regards, Krzysztof _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel