Message ID | 20230517-fix-clk-index-v2-1-1b686cefcb7e@baylibre.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:994d:0:b0:3d9:f83d:47d9 with SMTP id k13csp431424vqr; Thu, 25 May 2023 07:55:34 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5SqggGwmIBa59YvR1TJpmhFv72XxptA5O3F2mvg6YuuY4fcd5S90G3s2FMFpKSCnGYvSE1 X-Received: by 2002:a17:902:f391:b0:1af:df8e:d534 with SMTP id f17-20020a170902f39100b001afdf8ed534mr1647839ple.27.1685026533855; Thu, 25 May 2023 07:55:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1685026533; cv=none; d=google.com; s=arc-20160816; b=zKPbHn/Viz2vrgFNvh/Msl9lhGr3S5NvvqwRyT0GZgXUx5h9CQSoPRtlepNtN0Anuz 62hFncCR1vKjN9LvYj1G1aKzb4Rdg9GQKwhg19o3Q/jYEa0vWusXfRXwIhgF+xr5t0RN DglP5jDTFPpdwVIgaBNsfen58A4ZfKlF+UHriKLZbyb1cbg55ienDvYUt5tPrv81H2hg cpKjgd/7yINjOg9OH2r6kv+K36ra3piksyBnCRiQvTljhRF3NJY7CA8/AnVRgbMmob81 Si5fFhYVunJQX/M+/GcqRhowBAvqgYjpsgDh3Uvb7o8XfEUPBqhksOZnYPkRfuNTpzZr HM5Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:in-reply-to:references:message-id :content-transfer-encoding:mime-version:subject:date:from :dkim-signature; bh=5TpRYfzHZx9/tYc3Y2Xk8BfOtPKBqHSj0KnEjzeNrxg=; b=rfWyx4nFFg8ly4SktLiFXOqyBaYEi6IWsGYVAKHtd3rsR92mroMft/JYPd5bvpwtgx 0KX7fuWOt099R50DN0hOYhiPS2TH5sMyET+zGK5pXn5aywy3ZD8n5y8txwhvCYW+6TMi j/L2GcaMs6E2/pOms5XcDCRgT+uI89eJwo7GU6Dm2cLSZpoRpV6OsU3kQJAwvt4yUqX6 dNGqREMwiS3GjZ34+kri6jZELJnIS9OCu2gmBi/OIyyc1S0vtuG9dV7Q6IBieRJlqETD z8AxZw0JlhNUanMwO9z/r506RxcKtL4uM5BDTcAu5izZKN6nLGbplpAT98COMUudLA2N o8sQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@baylibre-com.20221208.gappssmtp.com header.s=20221208 header.b=AaPqVFvr; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id qe9-20020a17090b4f8900b00237155f2303si1846938pjb.136.2023.05.25.07.55.20; Thu, 25 May 2023 07:55:33 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@baylibre-com.20221208.gappssmtp.com header.s=20221208 header.b=AaPqVFvr; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241669AbjEYOur (ORCPT <rfc822;ahmedalshaiji.dev@gmail.com> + 99 others); Thu, 25 May 2023 10:50:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35500 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241659AbjEYOun (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 25 May 2023 10:50:43 -0400 Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 65A83189 for <linux-kernel@vger.kernel.org>; Thu, 25 May 2023 07:50:42 -0700 (PDT) Received: by mail-wm1-x32e.google.com with SMTP id 5b1f17b1804b1-3f6e1393f13so3319135e9.0 for <linux-kernel@vger.kernel.org>; Thu, 25 May 2023 07:50:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20221208.gappssmtp.com; s=20221208; t=1685026241; x=1687618241; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:from:to:cc:subject:date:message-id :reply-to; bh=5TpRYfzHZx9/tYc3Y2Xk8BfOtPKBqHSj0KnEjzeNrxg=; b=AaPqVFvrAOWUK3qmHkZXUicT1qRBkEZv57Fe+e/GAE0StnFP4aZxpfDnw9g8YpPTkW axzTngNoWUl0jSZ8kkpyUFJgVGdXm/AXUUSgnnDpcHXFoamZjOITehuH71aUTrLwVOaJ 5n3XT4YxPJSxTx6GzBE5vqHSxRY7DvgEGy4om5YrhWdLBDhA/67jd3Dt4P9d2LjX99tQ RXA/i6b0wBKRnnMJRuIRHYG7B6s9M0tBOhoFNCwXgYBqSP7iH2WukkaLTpw7uUuW9Hp/ 6q+9d6xAyN6e4CyaH5qAFDm1OXHOTIeomBPn/k4Z0OOEL4VqHkANdIPqF2GWFcAIhISz XQxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685026241; x=1687618241; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=5TpRYfzHZx9/tYc3Y2Xk8BfOtPKBqHSj0KnEjzeNrxg=; b=BQ6BlE17OpewxZubHGsFGJlEzFyeC+iTU/Il8XUiac9M2gyUIoFIOqYXNY1MIQrpbb AGqK6geST8TTH82BIhW459s9ST2H+xk3IKvjdIc6g9gAR+nTUldbPguLg105BoznCoEo LhrRwNV8CPu5iGisOiSSvCIXHtZc3YpjzvxB8MSbhXG2Idxwhjg6p2U/kCUk+vmVLXiI yWU8ZJhRxnCBleIGE3nnmKE2R3QetzxyvPRrG9iPj0CnIU3G3w7++qxMAyC99xUjCTZz Ay1k59IoY8KyRC+YdhcGigv20lNr2LLm9Rqt6iYOtYV6UEaNVqUUulGX2ldHaq1PEsaD k5og== X-Gm-Message-State: AC+VfDw3ZQ6/Ich4XbRlKku7KKOrt+mO86e4etKwClI1/9UeXXAZQp2v Za4ui110JRtKJXvrUy3iI6n2fQ== X-Received: by 2002:a05:600c:3784:b0:3f6:552:8722 with SMTP id o4-20020a05600c378400b003f605528722mr2994082wmr.18.1685026240799; Thu, 25 May 2023 07:50:40 -0700 (PDT) Received: from [127.0.1.1] (158.22.5.93.rev.sfr.net. [93.5.22.158]) by smtp.googlemail.com with ESMTPSA id n4-20020a05600c294400b003f3157988f8sm2349559wmd.26.2023.05.25.07.50.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 25 May 2023 07:50:40 -0700 (PDT) From: Alexandre Mergnat <amergnat@baylibre.com> Date: Thu, 25 May 2023 16:50:27 +0200 Subject: [PATCH v2 1/2] dt-bindings: clock: mediatek: replace unusable clock MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-Id: <20230517-fix-clk-index-v2-1-1b686cefcb7e@baylibre.com> References: <20230517-fix-clk-index-v2-0-1b686cefcb7e@baylibre.com> In-Reply-To: <20230517-fix-clk-index-v2-0-1b686cefcb7e@baylibre.com> To: Michael Turquette <mturquette@baylibre.com>, Stephen Boyd <sboyd@kernel.org>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor+dt@kernel.org>, Matthias Brugger <matthias.bgg@gmail.com>, AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>, Chen-Yu Tsai <wenst@chromium.org> Cc: Markus Schneider-Pargmann <msp@baylibre.com>, linux-clk@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, Alexandre Mergnat <amergnat@baylibre.com> X-Mailer: b4 0.12.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=1018; i=amergnat@baylibre.com; h=from:subject:message-id; bh=OTCpf/cGWX/QOa+k7U0XGlCX28v0JhFQ08iD6/fULvs=; b=owEBbQKS/ZANAwAKAStGSZ1+MdRFAcsmYgBkb3W+pK5Qktvbj+oP/LMTRHEHloR67cHOvXTgd2LW dFOw9wSJAjMEAAEKAB0WIQQjG17X8+qqcA5g/osrRkmdfjHURQUCZG91vgAKCRArRkmdfjHURfElD/ 4hfHecM1fx+yBLw5NYTj/6RqIFsLxIIyQbHNLDQ5/s8ICD8S77k6rhGsLhdrps8Buh/RmvzxD4spRV kCYEfz6n5CwEktvF3Wzi3p0Ybmw+WMnk2mBiP4F5Q1243KtrAr6pJbKuOxuRRXTTOmhHCWhH28OlSz +DhTPwzTlXfMBhkL8bF36YRgFuCEDDKd4LXk7tLd2j0SptQp8vK4emu72Z0SknrP8ISVeDf+9kc9jW 2oFagHjJ93dMCu5s9qIuaMTvcgs6GtPcSf6HBxGKc2/6aSxnigUQr4N2Q2V5kwMrPadNIzqsXqG9Rt zoUskveZR0+Y4kH5SaNUpGIdOV9fTzEx/9ZBE5pCVFCxv7wE8sbLQuL8ydX/VRO8a527B0OMTmTwLC aHBhs2hbL/RiffOWhuyLwnhnsTm4Wxf6D4DrjkoEChXmgTCwCeYUXMo3AfU48Qp1Lwfkk3ElMXB7qI e38e1/pVG1tfdkhR/XFJvzDx1ATbsN6/wHC7+DB/1mBFU6PIM38y1FKiXe+zz7GT+kpgBmP+g4Pqmm v3NSNm7VP4tqy6NicpXR78U0hJHUREee7xc62d24qaHG0xqWZhSeU+5iEBDBtJ64xjeoYIcthDSMzS eTOhjSjMialozHY9QY+pZ6oa2mLQp2ydFlGWTKpnXc4qZV6ynS2OuIKU+6vg== X-Developer-Key: i=amergnat@baylibre.com; a=openpgp; fpr=231B5ED7F3EAAA700E60FE8B2B46499D7E31D445 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1766878382656267334?= X-GMAIL-MSGID: =?utf-8?q?1766878382656267334?= |
Series |
Fix and clean MT8365 clock indexes
|
|
Commit Message
Alexandre Mergnat
May 25, 2023, 2:50 p.m. UTC
The “mcu_pm_bclk_ck_cg” clock is used by co-processors and should not be
added to the kernel driver, otherwise the CPU just halt and the board is
rebooted by the wathdog.
Instead, add the "aes_top0_bclk_ck_cg" missing clock to prevent
re-shuffling index and then preserve the ABI.
Signed-off-by: Alexandre Mergnat <amergnat@baylibre.com>
---
include/dt-bindings/clock/mediatek,mt8365-clk.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Comments
On Thu, May 25, 2023 at 04:50:27PM +0200, Alexandre Mergnat wrote: > The “mcu_pm_bclk_ck_cg” clock is used by co-processors and should not be > added to the kernel driver, otherwise the CPU just halt and the board is > rebooted by the wathdog. > > Instead, add the "aes_top0_bclk_ck_cg" missing clock to prevent > re-shuffling index and then preserve the ABI. How does this preserve the ABI exactly? Please describe exactly what you mean by that. Also, what about any other users of these definitions, outside of Linux? Cheers, Conor > Signed-off-by: Alexandre Mergnat <amergnat@baylibre.com> > --- > include/dt-bindings/clock/mediatek,mt8365-clk.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/dt-bindings/clock/mediatek,mt8365-clk.h b/include/dt-bindings/clock/mediatek,mt8365-clk.h > index f9aff1775810..0a841e7cc1c3 100644 > --- a/include/dt-bindings/clock/mediatek,mt8365-clk.h > +++ b/include/dt-bindings/clock/mediatek,mt8365-clk.h > @@ -199,7 +199,7 @@ > #define CLK_IFR_PWRAP_TMR 46 > #define CLK_IFR_PWRAP_SPI 47 > #define CLK_IFR_PWRAP_SYS 48 > -#define CLK_IFR_MCU_PM_BK 49 > +#define CLK_IFR_AES_TOP0_BK 49 > #define CLK_IFR_IRRX_26M 50 > #define CLK_IFR_IRRX_32K 51 > #define CLK_IFR_I2C0_AXI 52 > > -- > 2.25.1 >
Il 25/05/23 16:50, Alexandre Mergnat ha scritto: > The “mcu_pm_bclk_ck_cg” clock is used by co-processors and should not be > added to the kernel driver, otherwise the CPU just halt and the board is > rebooted by the wathdog. > > Instead, add the "aes_top0_bclk_ck_cg" missing clock to prevent > re-shuffling index and then preserve the ABI. It's still a breakage. Besides, have you tried to add it as CLK_IS_CRITICAL? :-) Cheers, Angelo > > Signed-off-by: Alexandre Mergnat <amergnat@baylibre.com> > --- > include/dt-bindings/clock/mediatek,mt8365-clk.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/dt-bindings/clock/mediatek,mt8365-clk.h b/include/dt-bindings/clock/mediatek,mt8365-clk.h > index f9aff1775810..0a841e7cc1c3 100644 > --- a/include/dt-bindings/clock/mediatek,mt8365-clk.h > +++ b/include/dt-bindings/clock/mediatek,mt8365-clk.h > @@ -199,7 +199,7 @@ > #define CLK_IFR_PWRAP_TMR 46 > #define CLK_IFR_PWRAP_SPI 47 > #define CLK_IFR_PWRAP_SYS 48 > -#define CLK_IFR_MCU_PM_BK 49 > +#define CLK_IFR_AES_TOP0_BK 49 > #define CLK_IFR_IRRX_26M 50 > #define CLK_IFR_IRRX_32K 51 > #define CLK_IFR_I2C0_AXI 52 >
On 25/05/2023 19:51, Conor Dooley wrote: > On Thu, May 25, 2023 at 04:50:27PM +0200, Alexandre Mergnat wrote: >> The “mcu_pm_bclk_ck_cg” clock is used by co-processors and should not be >> added to the kernel driver, otherwise the CPU just halt and the board is >> rebooted by the wathdog. >> >> Instead, add the "aes_top0_bclk_ck_cg" missing clock to prevent >> re-shuffling index and then preserve the ABI. > > How does this preserve the ABI exactly? Please describe exactly what you > mean by that. I mean that reduce the impact of the change compared to the v1 where I've changed the index of the following defines to be clean. > Also, what about any other users of these definitions, outside of Linux? The clock driver and bindings are only a couple of kernel versions old, I'm pretty sure no one is using it. Also, if someone use CLK_IFR_MCU_PM_BK define, I'm wondering how his CPU is working since Mediatek told me that shouldn't be used, and after some try, I confirm. I've a question: If something is wrong in the binding, you don't fix it to avoid ABI change ? TBH, I just try to clean the binding. I can fix the driver index issue (patch 2/2) without fixing the binding if you prefer. But IMHO, keep an unusable define isn't great...
On 26/05/2023 10:30, AngeloGioacchino Del Regno wrote: > Il 25/05/23 16:50, Alexandre Mergnat ha scritto: >> The “mcu_pm_bclk_ck_cg” clock is used by co-processors and should not be >> added to the kernel driver, otherwise the CPU just halt and the board is >> rebooted by the wathdog. >> >> Instead, add the "aes_top0_bclk_ck_cg" missing clock to prevent >> re-shuffling index and then preserve the ABI. > > It's still a breakage. Besides, have you tried to add it as > CLK_IS_CRITICAL? :-) As I said to Conor, I can fix the driver index issue (patch 2/2) without fixing the binding (using CLK_IGNORE_UNUSED but CLK_IS_CRITICAL works too).
On Fri, May 26, 2023 at 10:54:04AM +0200, Alexandre Mergnat wrote: > On 25/05/2023 19:51, Conor Dooley wrote: > > On Thu, May 25, 2023 at 04:50:27PM +0200, Alexandre Mergnat wrote: > > > The “mcu_pm_bclk_ck_cg” clock is used by co-processors and should not be > > > added to the kernel driver, otherwise the CPU just halt and the board is > > > rebooted by the wathdog. > > > > > > Instead, add the "aes_top0_bclk_ck_cg" missing clock to prevent > > > re-shuffling index and then preserve the ABI. > > > > How does this preserve the ABI exactly? Please describe exactly what you > > mean by that. > > I mean that reduce the impact of the change compared to the v1 where I've > changed the index of the following defines to be clean. Oh, you can't do that at all as you probably discovered! > > Also, what about any other users of these definitions, outside of Linux? > > The clock driver and bindings are only a couple of kernel versions old, I'm > pretty sure no one is using it. Pretty sure, or sure? > Also, if someone use CLK_IFR_MCU_PM_BK > define, I'm wondering how his CPU is working since Mediatek told me that > shouldn't be used, and after some try, I confirm. Maybe that person is actually using the index to make sure that the clock at that index is left untouched. > I've a question: If something is wrong in the binding, you don't fix it to > avoid ABI change ? I don't quite get what you mean by "wrong". These header files just define a set of arbitrary meanings, since the clock numbers are really just something that developers came up with rather than being lifted from a TRM. They don't prescribe behaviour for each of these clocks, or that these clocks should actually be used - just a simple "this number means this clock". It sounds more like a driver or devicetree is _using_ the number incorrectly, but that does not make the binding wrong :) > TBH, I just try to clean the binding. I can fix the driver index issue > (patch 2/2) without fixing the binding if you prefer. But IMHO, keep an > unusable define isn't great... I, at least, would prefer that. Thanks, Conor.
diff --git a/include/dt-bindings/clock/mediatek,mt8365-clk.h b/include/dt-bindings/clock/mediatek,mt8365-clk.h index f9aff1775810..0a841e7cc1c3 100644 --- a/include/dt-bindings/clock/mediatek,mt8365-clk.h +++ b/include/dt-bindings/clock/mediatek,mt8365-clk.h @@ -199,7 +199,7 @@ #define CLK_IFR_PWRAP_TMR 46 #define CLK_IFR_PWRAP_SPI 47 #define CLK_IFR_PWRAP_SYS 48 -#define CLK_IFR_MCU_PM_BK 49 +#define CLK_IFR_AES_TOP0_BK 49 #define CLK_IFR_IRRX_26M 50 #define CLK_IFR_IRRX_32K 51 #define CLK_IFR_I2C0_AXI 52