Aw: Re: Re: [PATCH v5 1/5] dt-bindings: ata: ahci-platform: Convert DT bindings to yaml

[Rob Herring]

On Sun, Mar 06, 2022 at 12:15:39PM +0100, Krzysztof Kozlowski wrote:
> On 06/03/2022 11:41, Frank Wunderlich wrote:
> >> Gesendet: Sonntag, 06. März 2022 um 11:27 Uhr
> >> Von: "Krzysztof Kozlowski" <krzysztof.kozlowski at canonical.com>
> >>>     add compatibles used together with generic-ahci
> >>>       - marvell,berlin2-ahci
> >>
> >> This is fine, just mention it in commit msg.
> >>
> >>>       - qcom,apq8064-ahci
> >>>       - qcom,ipq806x-ahci
> >>
> >> These you need to consult with qcom-sata.txt. This could be a following
> >> commit which will integrate qcom-sata.txt and remove it.
> > 
> > this depends on Robs opinion
> 
> Then maybe precise the question for Rob...

I would leave qcom separate, but the warnings should be fixed. For that 
you need a custom 'select' schema that lists everything but 
'generic-ahci'. Adding the berlin compatible looks right.

> >> Either you have
> >> binding document for all devices or you create a common part, like for UFS:
> >> https://lore.kernel.org/linux-devicetree/20220222145854.358646-1-krzysztof.kozlowski@canonical.com/
> >> https://github.com/krzk/linux/commits/n/dt-bindings-ufs-v2
> >>
> >> The choice depends more or less on complexity of bindings, IOW, how big
> >> and complicated bindings would be if you combine everything to one YAML.
> >>
> >> In the case of UFS, the devices differ - by clocks, resets, phys and
> >> sometimes supplies. Therefore it easier to have one common shared part
> >> and several device bindings.
> >>
> >> AHCI looks more consistent - except that Qualcomm - so maybe better to
> >> have one document.
> >>
> >>>     increase reg-count to 2 (used in omap5-l4.dtsi)
> >>>     increase clock-count to 5 (used in qcom-apq8064.dtsi)
> >>
> >> This would need allOf+if.
> > 
> > if i get ok from rob i add only the berlin-compatible and skip the 
> > qcom+reg/clock-change in the first applied version. Adding the 
> > allOf/if (and making it right) will only delay the sata-binding/dts-change.
> 
> I don't get what is the problem with delaying this patch for the time
> needed to make the bindings correct? Especially that alternative is to
> add bindings document which soon will need to be modified, e.g. split
> into common part. Is there a particular hurry with these bindings
> conversion?

Qcom doesn't use sata-port nodes, so I don't think there is anything to 
share. And if it did, that's already in sata-common.yaml.

Rob