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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0B61CC43334 for ; Tue, 5 Jul 2022 18:14:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230214AbiGESOB (ORCPT ); Tue, 5 Jul 2022 14:14:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54858 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230026AbiGESOA (ORCPT ); Tue, 5 Jul 2022 14:14:00 -0400 Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ECDA213F16 for ; Tue, 5 Jul 2022 11:13:58 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id bu42so2090115lfb.0 for ; Tue, 05 Jul 2022 11:13:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=FPRBABzcy3/6j/H39EHsr5gxtbkpnqGjLMhqvBz/Czo=; b=djx0pAkFwqxgWa5my5EzUkiQpqLhNheKKV64f2/fsqX5W5FB9RS3ZDox4NcIcDRGdG Ya17IYQfDClXXzbe0qmpqiwE7hXOqKYLNcmVh0TpCknQWeRXvE6/VooRJ+5cpYDLs64C 3pOh7GzWZGtvvEQFtJWTKUCt+lP5053ywVdpnfyANA8N9JX6cPv63LmrBikzmvX/ctUs +MTl5ghz2d374ToKZosd3eCN47RfGFZGg6spPpUATZVlurK0HleOV+uKRvyIKU1xuItK LqAKhCG5SEkeqcFJk3KifIBaw+wWi51JTYmsNGlFORvviG6RJvJmqR/JKwpniA/ddYMn sbdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=FPRBABzcy3/6j/H39EHsr5gxtbkpnqGjLMhqvBz/Czo=; b=IC+/SHbGGhYXi2rvu9iyZ6iGe5FiFUwxOuGr9lcvUYmrtlcEemQna30wZJWrdn7lMY SkAWZHLit63d0Qmupa5b5Cvu4el9uzkpOuvQS19TO9nYmv11BW18hiB+E/T5WPr9bWwd MdoVvhb+0jKroc+8CmVXmaWoWBvbyYJ0QeSsg3O7wQxA8cvOQr79rbPCf30YCMKMj2g8 hdu9/LWbh9sp1YZScJxPERr6y5xJytgaCryGbfnTlpJuLq1MBYIisIg/tpyIsyIBSAC+ CtBS7sjZpM+nm8HoTkoTKBfAFfUbtdvARqSM4t+xm1Ecym96yPHWDFNFy7wg0UHANeLh wR+A== X-Gm-Message-State: AJIora+JWyjTyz5Hvp++5Znmdo6z50eKM2uqnYvZWUhRsqJPY2v0zshF u5qmx2CplBmqc1Gmk3cz9pwxgw== X-Google-Smtp-Source: AGRyM1uBmRSnQOgKHceCWdDFKVuwOgtjkU/PRVtuYm24BdlUqxq1ppyibaQTEX/6mCzvVwBuEDOkWQ== X-Received: by 2002:a05:6512:acb:b0:481:cce:3c22 with SMTP id n11-20020a0565120acb00b004810cce3c22mr22671522lfu.45.1657044837333; Tue, 05 Jul 2022 11:13:57 -0700 (PDT) Received: from [192.168.1.52] ([84.20.121.239]) by smtp.gmail.com with ESMTPSA id s14-20020a19770e000000b0047f68d77008sm5812103lfc.178.2022.07.05.11.13.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 Jul 2022 11:13:56 -0700 (PDT) Message-ID: <5b6f5e15-f3fd-badb-3ada-eb2f58053857@linaro.org> Date: Tue, 5 Jul 2022 20:13:55 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCH 16/43] dt-bindings: phy: qcom,qmp-pcie: drop unused vddp-ref-clk supply Content-Language: en-US To: Johan Hovold Cc: Johan Hovold , Vinod Koul , Rob Herring , Krzysztof Kozlowski , Andy Gross , Bjorn Andersson , Kishon Vijay Abraham I , linux-arm-msm@vger.kernel.org, linux-phy@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org References: <20220705094239.17174-1-johan+linaro@kernel.org> <20220705094239.17174-17-johan+linaro@kernel.org> <8d739c84-ba61-a030-ea8a-63a3f45c642c@linaro.org> From: Krzysztof Kozlowski In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On 05/07/2022 14:43, Johan Hovold wrote: > On Tue, Jul 05, 2022 at 01:59:26PM +0200, Krzysztof Kozlowski wrote: >> On 05/07/2022 13:46, Johan Hovold wrote: >>>> It's okay to copy existing bindings which are applicable and then in >>>> separate patch deprecate things or remove pieces which are not correct. >>>> But all this in assumption that the first copy already selected only >>>> applicable parts. >>> >>> But how would you be able to tell what parts I left out from the >>> original copy >> >> They are obvious and immediately visible. I see old bindings and new >> bindings - no troubles to compare. I review new bindings - everything in >> place. > > Heh, with all these conditionals in place that may be harder than it > sounds. True and your patchset split does not make it easier. > >> I don't want to review old code, inapplicable code. The patch I am >> reviewing (the one doing the split) must bring correct bindings, except >> these few differences like deprecated stuff. > > Sure, I get that. But this very patch is an example of why I tried to > remove things explicitly instead folding this into the original patch > and risking it not being noticed. > > It's not always obvious what is applicable and what is not, especially > when the old schema is in the state it is. Unless bindings are very precise, usually it's not visible what is applicable or not, so there is just no benefit in multi-step approach in split from old bindings. The same as with conversion of bindings, the assumption is that original file was not correct, so we review the final file. > >>> unless I first do the split and then explicitly remove >>> things that were presumably *never* applicable and just happened to be >>> added because all bindings where combined in one large mess of a schema? > > So you suggest we keep this regulator for all PHY variants even though > it was probably only needed for UFS on some older SoCs? No. I commented only that reason is not a good one. The proper reason could be: there is or there is no such pin in the device or the history tells that adding it for all variants was a mistake. Best regards, Krzysztof