Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp17383346rwd; Tue, 27 Jun 2023 02:08:29 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ76Y/3P3QMjTyOxP5zgPWdsUuWczcR+qE0Q/UuvWrLdtLdzDO97tjQR41Tdw1wsMH48e7UP X-Received: by 2002:a17:907:7d8a:b0:989:444b:725 with SMTP id oz10-20020a1709077d8a00b00989444b0725mr20531902ejc.26.1687856908828; Tue, 27 Jun 2023 02:08:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1687856908; cv=none; d=google.com; s=arc-20160816; b=GBhba0vkFgJomS1QFIqLwsJELxyxKOD8SxFht6jJyWOHxn6GdS9oDbONzcjpaeqBDV vmoJ6DkB6dieWaJn2T+Kay5LGsOVbExyg4rMFdzsRjoWLX6lAjKDzrL9BDhxwZEu4AbN iVrVqaDDNT+EMs06ilkRXmYdaut9Sbm5N47HuT2uikWvpI8EHd/9nIcOF8v/pDuNfSle Cd1RIQLQJAfWQg8744wYVJwcfQmUbODqRYlKdQblSMkw4raClvCgnEgao0boC6D5rEnY P/YmAeQIaYkIPRAT02I/CpWnjsbdMmjD6Ib2TcyHwmdFz7rL09LB6emh7M7WC7rpny6c DHyg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=mZ2fPxejabewXc+fee9DxuFtGuqUADqxUfC9TwMPZEo=; fh=ICAANXfAspVNTtbri0pF1cBWvEfnAb0M8CR36XuODO4=; b=oPhCNtigNWuG5afBZy4WbBkUd29KxOY0Y6y5AL5Pe9LWZzHfUvOPKgC1NJEniK0Xr+ Vmb++GBPgD+QZvXMD27twBBR5Mbd3HFDYf16KJ8iJu843e2D0WDxzrzECm/aShsfOXPz KDHAmX9qpOwDD9l7nLR/WWGa958uWl10OAHXdb2HXh9r7JzeGXgm9EevvP+8lEt4xMrZ R9ylwHZboaCIG39ZGYPplXZuKRxk9V5XaoIKbKS1aVh5hmRFNh9Vn1u+IlkJmc9zjgD9 0EYOyrbtKU9YbGHcMmSiXTlfgh05rp2N1FPzJ+JhT4C79L414w7MT7vD/FfRaFd9DtLG wpmg== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id op27-20020a170906bcfb00b00988ab18386bsi3977080ejb.1050.2023.06.27.02.08.03; Tue, 27 Jun 2023 02:08:28 -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; 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 S230169AbjF0JCk (ORCPT + 99 others); Tue, 27 Jun 2023 05:02:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56590 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230164AbjF0JCj (ORCPT ); Tue, 27 Jun 2023 05:02:39 -0400 Received: from relay08.th.seeweb.it (relay08.th.seeweb.it [IPv6:2001:4b7a:2000:18::169]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4372710C9 for ; Tue, 27 Jun 2023 02:02:36 -0700 (PDT) Received: from SoMainline.org (94-211-6-86.cable.dynamic.v4.ziggo.nl [94.211.6.86]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by m-r2.th.seeweb.it (Postfix) with ESMTPSA id C0A7A3F792; Tue, 27 Jun 2023 11:02:28 +0200 (CEST) Date: Tue, 27 Jun 2023 11:02:27 +0200 From: Marijn Suijten To: Krzysztof Kozlowski Cc: Konrad Dybcio , Andy Gross , Bjorn Andersson , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Michael Turquette , Stephen Boyd , Rob Clark , Abhinav Kumar , Dmitry Baryshkov , Sean Paul , David Airlie , Daniel Vetter , Krishna Manikandan , ~postmarketos/upstreaming@lists.sr.ht, AngeloGioacchino Del Regno , Martin Botka , Jami Kettunen , linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Krzysztof Kozlowski , linux-clk@vger.kernel.org, dri-devel@lists.freedesktop.org, freedreno@lists.freedesktop.org, Lux Aliaga Subject: Re: [PATCH 03/15] dt-bindings: clock: qcom,dispcc-sm6125: Require GCC PLL0 DIV clock Message-ID: References: <52c57cab-10cf-2e7e-2c1d-fa6506786d45@linaro.org> <6311f26f-79ee-c471-649f-5e0b4629cfcc@linaro.org> <16731023-7dc7-d43d-1b16-fda44c0948ed@linaro.org> <683a6f7e-bf1a-aff2-070b-472fb14e0353@linaro.org> <3nnk4xvmpnum2q6g6c6crjlqq3ra7j2z5zis53xcqbvevymuhz@mkffvs45n6ut> <145ab255-b3f8-1c6c-824d-5f1b40568d30@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <145ab255-b3f8-1c6c-824d-5f1b40568d30@linaro.org> X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,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: X-Mailing-List: linux-kernel@vger.kernel.org On 2023-06-27 10:21:12, Krzysztof Kozlowski wrote: > On 27/06/2023 09:49, Marijn Suijten wrote: > > On 2023-06-27 09:29:53, Krzysztof Kozlowski wrote: > >> On 27/06/2023 08:54, Marijn Suijten wrote: > >>> On 2023-06-27 08:24:41, Krzysztof Kozlowski wrote: > >>>> On 26/06/2023 20:53, Marijn Suijten wrote: > >>>>> On 2023-06-26 20:51:38, Marijn Suijten wrote: > >>>>> > >>>>>>> Not really, binding also defines the list of clocks - their order and > >>>>>>> specific entries. This changes. > >>>>>> > >>>>>> And so it does in "dt-bindings: clock: qcom,dispcc-sm6125: Remove unused > >>>>>> GCC_DISP_AHB_CLK"? > >>>>> > >>>>> Never mind: it is the last item so the order of the other items doesn't > >>>>> change. The total number of items decreases though, which sounds like > >>>>> an ABI-break too? > >>>> > >>>> How does it break? Old DTS works exactly the same, doesn't it? > >>> > >>> So deleting a new item at the end does not matter. But what if I respin > >>> this patch to add the new clock _at the end_, which will then be at the > >>> same index as the previous GCC_DISP_AHB_CLK? > >> > >> I think you know the answer, right? What do you want to prove? That two > >> independent changes can have together negative effect? We know this. > > > > The question is whether this is allowed? > > That would be an ABI break and I already explained if it is or is not > allowed. How should we solve it then, if we cannot remove GCC_DISP_AHB_CLK in one patch and add GCC_DISP_GPLL0_DIV_CLK_SRC **at the end** in the next patch? Keep an empty spot at the original index of GCC_DISP_AHB_CLK? - Marijn