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.5 required=3.0 tests=BAYES_00,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 911B7C433F5 for ; Thu, 23 Sep 2021 16:27:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7D75960F4C for ; Thu, 23 Sep 2021 16:27:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242444AbhIWQ3V (ORCPT ); Thu, 23 Sep 2021 12:29:21 -0400 Received: from mail-wr1-f52.google.com ([209.85.221.52]:38773 "EHLO mail-wr1-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242290AbhIWQ3F (ORCPT ); Thu, 23 Sep 2021 12:29:05 -0400 Received: by mail-wr1-f52.google.com with SMTP id u18so18876303wrg.5; Thu, 23 Sep 2021 09:27:33 -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=6oZ+XUtQEDrny/KQntjDoiQWQURAQNGi1iLVidQw//k=; b=rHawQ8SXR+/N/K2YoK+SAKotCOy1EwfMuM7tu+h58BWpWPc6OozTItMqa9KoV2EfE5 WHM6u2PGgeq40hjLijiUgacD08Ofv4Gp1YhZFybde0kEpjO9Ia+WxgJvZXI3RWAi33b3 Is6zFvHe6JpU2NcQyVf47IFZYX6dHvEjjz+KvRt6hHKiZxMCYq59BeAcGJPSBAVpFC87 M+EQF/xmjl4x/l8HbAexiXRuxU9+5Jdt1BLjFyCIEKsCzjQby/L1czVDImtPSCZWtIdZ 3Z4uvQ6QgzGKYgLiUL+KcmSspCI37Aa8q5kuMAZanOE4tU8jQz11eKpd7Pukgp3jb4kV LhdQ== X-Gm-Message-State: AOAM531eVwLzF3UcQn1KY9jNgp0XsfjGXJvOGM0V6xN7M6QsAgtRqzr1 IuH9ZFVO9fgy6D/w26ESXy3xnKP4Lcj1WA== X-Google-Smtp-Source: ABdhPJx1XUGWyc8DO+i1cz/XpGWL6buzyo9KmMMCSh32fHq65J1KI02NFcY6GOANSG215QA6Ti6udQ== X-Received: by 2002:a1c:2543:: with SMTP id l64mr16960192wml.9.1632414451033; Thu, 23 Sep 2021 09:27:31 -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.googlemail.com with ESMTPSA id g2sm6249670wrb.20.2021.09.23.09.27.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 23 Sep 2021 09:27:30 -0700 (PDT) To: Lee Jones Cc: Will McVicker , Geert Uytterhoeven , Catalin Marinas , Will Deacon , Sylwester Nawrocki , Tomasz Figa , Chanwoo Choi , Michael Turquette , Stephen Boyd , 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> <001cd621-53d1-fe22-0eaa-d13137827297@canonical.com> <30a1d0f3-a17c-bf87-2519-542063a7a663@kernel.org> From: Krzysztof Kozlowski Subject: Re: [PATCH v1 1/4] clk: samsung: change COMMON_CLK_SAMSUNG default config logic Message-ID: <6ea9e6fc-1b38-7a45-3aed-c092da5fc044@kernel.org> Date: Thu, 23 Sep 2021 18:27:28 +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 23/09/2021 16:18, Lee Jones wrote: >> Thanks Lee, you described the use case. In general I like it and support >> it, except for what I wrote in the other mail. >> >> Vendor does not contribute much therefore there is no balance in >> upstreaming. Since none of other vendor's platforms are supported, I am >> looking only at what is supported. From that perspective - the change >> proposed by Will and previous guys, does not have much sense. >> >> My perspective probably would change a lot if vendor did contribute some >> of its non-edge platforms (3-5 years old)... especially that unlike few >> community guys (e.g. PostmarketOS), vendor has shit-tons of money and >> the hardware manuals. :) > > But no incentive to upstream code old (dead) platforms that they no > longer make money from. We're not talking about kind-hearted > individuals here. These are business entities. > > What is the business incentive to put hundreds of thousands of dollars > into something with no RoI? Before you mentioned business entities refrain from upstreaming recent hardware. You question upstreaming not that recent, so basically business entity will claim it has zero incentives working with upstream. Actually there are incentives for both cases - better code quality for the pieces being base for future devices, selling mainline supported hardware to other businesses, eventually less work for themselves around keeping code in sync with mainline. All these are of course difficult to measure from business perspective. > >> Instead of pushing this change, please let's give some incentive to the >> vendor for upstreaming anything. > > Again, you're being specific. We would also like/need to make the > same kinds of changes to other vendor configurations. One's which do > contribute significantly at their own cost. Yes, I am specific because we talk here about specfic Kconfig changes for one specific ARM sub-architecture. Same set of changes can be applied to other SoCs and usually have more sense there because number of upstream platforms is bigger. If you have 10 different pinctrl drivers, you might decide to narrow the defconfigs to subset of it. If you have 2-3, the extra complexity does not matter and you just enable all of them. That's also decision we made few years ago internally in Samsung. > The technical reasoning cannot be different because you do or don't > like the way the company operates. Try to detach a little from > your feelings during discussions which should be purely technical. I mentioned the less-contributing vendor arguments because you said: >> Vendors are not able to upstream all functionality right away That's the side-topic in this discussion. Technically, all supported Exynos platforms require selecting ARCH_EXYNOS and require all drivers selected by ARCH_EXYNOS. If you mention some unsupported out-of-tree platforms, which I cannot audit/see/use, it is not a valid reason to change statement above. Make them supported, available to audit and check and statement above stops being valid. 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=-7.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,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 B954CC433EF for ; Thu, 23 Sep 2021 16:30:11 +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 7F54960F4C for ; Thu, 23 Sep 2021 16:30:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 7F54960F4C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.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: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=Avrfj/oLKSWsMnDr3IhDBO/gSezXtLIoABl0gZ//odo=; b=YtL0d8yRRC/1gbJ/1sx/m8ftyU Nd5IXxogPZ840sYDHkxqDlwvzMBaO9jBtWEK+7q65Em1Y8EquB5UaPaw8kM6blx9qil2UC4J95XjM yvnBWMkeNthQlZWtfE7IpzG4/yKWFu0owNUwdg0+cIX11i9MO1KfLG6rACm4Pv5ir4SODkPBl1L8j FnwRJ0F1Xwv1x9FdH6Z1qPqrH98HOYX0XHEFmyW5TCRAciXXRW83b4VySqMvyrwveI37GO2xN8nOb 96M0nneeAfMlH8kwrXnHxBIY4VxfDUL24ZzlwyVebeuFYmvdmspSeO61/GK7Zg/Nf4Ndzr7DDSP3n gDL4nsMQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mTRZQ-00C9U1-NF; Thu, 23 Sep 2021 16:27:36 +0000 Received: from mail-wr1-f54.google.com ([209.85.221.54]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mTRZN-00C9Sv-2K for linux-arm-kernel@lists.infradead.org; Thu, 23 Sep 2021 16:27:34 +0000 Received: by mail-wr1-f54.google.com with SMTP id t8so18895107wrq.4 for ; Thu, 23 Sep 2021 09:27:32 -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=6oZ+XUtQEDrny/KQntjDoiQWQURAQNGi1iLVidQw//k=; b=JvChTR+T3UNGBayHqayhjRgX9vvEVpr9e8gVh4LJazcfkUvfLLthau0muHd+S/ExNN eqkbOK1OhGTiXGpKxkImE6JWwM4v3bsLsHVdV2ng0pZw357zUd8+fvxXyoW099sNVmib UHHUj2ZvpSMdo87WJGRYddCy7pXYuTcLn7UVd3wzOOChvXd8WGXISPMQ6X9kq3cBs5p6 0wRty0yCPSwLA0fuVXS3nPReqkTB7Xp2BRd3++uUQEh5+uvr2j2pPF4ACdDQWMhQVMWe OYDiZ3O0LqNJG0KVr8IXguih4uamtLSQbi6+ZUWvD8Ok/I+9ehKmbAPBMix0Z7kj9PQx fyYA== X-Gm-Message-State: AOAM530cmjjWXEZD9rDXXOu0C1KW3Cjwb7leOiElHrZP54/PcErpm6lg fhKntZ41LN0OlMsO5lvWw08= X-Google-Smtp-Source: ABdhPJx1XUGWyc8DO+i1cz/XpGWL6buzyo9KmMMCSh32fHq65J1KI02NFcY6GOANSG215QA6Ti6udQ== X-Received: by 2002:a1c:2543:: with SMTP id l64mr16960192wml.9.1632414451033; Thu, 23 Sep 2021 09:27:31 -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.googlemail.com with ESMTPSA id g2sm6249670wrb.20.2021.09.23.09.27.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 23 Sep 2021 09:27:30 -0700 (PDT) To: Lee Jones Cc: Will McVicker , Geert Uytterhoeven , Catalin Marinas , Will Deacon , Sylwester Nawrocki , Tomasz Figa , Chanwoo Choi , Michael Turquette , Stephen Boyd , 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> <001cd621-53d1-fe22-0eaa-d13137827297@canonical.com> <30a1d0f3-a17c-bf87-2519-542063a7a663@kernel.org> From: Krzysztof Kozlowski Subject: Re: [PATCH v1 1/4] clk: samsung: change COMMON_CLK_SAMSUNG default config logic Message-ID: <6ea9e6fc-1b38-7a45-3aed-c092da5fc044@kernel.org> Date: Thu, 23 Sep 2021 18:27:28 +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-20210923_092733_164770_611BE086 X-CRM114-Status: GOOD ( 25.51 ) 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 23/09/2021 16:18, Lee Jones wrote: >> Thanks Lee, you described the use case. In general I like it and support >> it, except for what I wrote in the other mail. >> >> Vendor does not contribute much therefore there is no balance in >> upstreaming. Since none of other vendor's platforms are supported, I am >> looking only at what is supported. From that perspective - the change >> proposed by Will and previous guys, does not have much sense. >> >> My perspective probably would change a lot if vendor did contribute some >> of its non-edge platforms (3-5 years old)... especially that unlike few >> community guys (e.g. PostmarketOS), vendor has shit-tons of money and >> the hardware manuals. :) > > But no incentive to upstream code old (dead) platforms that they no > longer make money from. We're not talking about kind-hearted > individuals here. These are business entities. > > What is the business incentive to put hundreds of thousands of dollars > into something with no RoI? Before you mentioned business entities refrain from upstreaming recent hardware. You question upstreaming not that recent, so basically business entity will claim it has zero incentives working with upstream. Actually there are incentives for both cases - better code quality for the pieces being base for future devices, selling mainline supported hardware to other businesses, eventually less work for themselves around keeping code in sync with mainline. All these are of course difficult to measure from business perspective. > >> Instead of pushing this change, please let's give some incentive to the >> vendor for upstreaming anything. > > Again, you're being specific. We would also like/need to make the > same kinds of changes to other vendor configurations. One's which do > contribute significantly at their own cost. Yes, I am specific because we talk here about specfic Kconfig changes for one specific ARM sub-architecture. Same set of changes can be applied to other SoCs and usually have more sense there because number of upstream platforms is bigger. If you have 10 different pinctrl drivers, you might decide to narrow the defconfigs to subset of it. If you have 2-3, the extra complexity does not matter and you just enable all of them. That's also decision we made few years ago internally in Samsung. > The technical reasoning cannot be different because you do or don't > like the way the company operates. Try to detach a little from > your feelings during discussions which should be purely technical. I mentioned the less-contributing vendor arguments because you said: >> Vendors are not able to upstream all functionality right away That's the side-topic in this discussion. Technically, all supported Exynos platforms require selecting ARCH_EXYNOS and require all drivers selected by ARCH_EXYNOS. If you mention some unsupported out-of-tree platforms, which I cannot audit/see/use, it is not a valid reason to change statement above. Make them supported, available to audit and check and statement above stops being valid. Best regards, Krzysztof _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel