linux-kernel - Re: [PATCH 16/43] dt-bindings: phy: qcom,qmp-pcie: drop unused vddp-ref-clk supply

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 5 Jul 2022 14:43:01 +0200
From:   Johan Hovold <johan@...nel.org>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc:     Johan Hovold <johan+linaro@...nel.org>,
        Vinod Koul <vkoul@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Kishon Vijay Abraham I <kishon@...com>,
        linux-arm-msm@...r.kernel.org, linux-phy@...ts.infradead.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 16/43] dt-bindings: phy: qcom,qmp-pcie: drop unused
 vddp-ref-clk supply

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.

> 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 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?

Johan