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

[Krzysztof Kozlowski]

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